Eclipse Community Forums: Eclipse SmartHome » Using Threads in Profiles

Home » Archived » Eclipse SmartHome » Using Threads in Profiles

Using Threads in Profiles [message #1776128]

Sun, 12 November 2017 15:09

Eclipse User

Hi everyone,
Since we now have support for profiles in ESH, I am currently writing my second profile.
This profile needs to use a scheduler in order to transform button presses into long or short presses and button-holds and from there to ON, OFF, and Increase, Decrease events.
In the ThingHandlers there is access to a scheduler from the base class.
In the Profiles there is no such scheduler. When trying to get one the same way as the base handler like this:

ScheduledExecutorService scheduler = ThreadPoolManager .getScheduledPool(THING_HANDLER_THREADPOOL_NAME);

Eclipse complains about using a non-API class.

So there are two questions:
1.: Is it okay to just add the package that contains the scheduler to the imports in the MANIFEST.MF file anyways, even if the class is not part of the API?
2.: Is it okay to create a new pool for the profiles? Which keyword should I use to get this pool?

Re: Using Threads in Profiles [message #1776131 is a reply to message #1776128]

Sun, 12 November 2017 18:08

Eclipse User

Hi Jan!

Quote:

I am currently writing my second profile.

As it has been mentioned by Simon: These profiles that you describe do not seem to be specific to EnOcean, so we should definitely discuss whether they are added as a system profile in ESH.

But to answer your question:

Yes, I agree that for custom profiles a scheduler is important. Instead of directly accessing ThreadPoolManager, we could also introduce a common named threadpool (specifically for profiles) and make this available through some class/service in the profile package. @Simon, what do you think?

Re: Using Threads in Profiles [message #1776133 is a reply to message #1776131]

Sun, 12 November 2017 20:32

Eclipse User

Quote:

These profiles that you describe do not seem to be specific to EnOcean, so we should definitely discuss whether they are added as a system profile in ESH.

Yeah I have the same opinion. But for now I have been operating under the assumption that it will be easier for me to proceed if I keep it in the binding side for now so I can work with it all in one repository and then I can drive the implementation of the system profiles independently.

I will split off these profiles and create a PR for them to be included in ESH as system profiles. The problem is that they would then also need system channels for rocker switches, which also don't exist yet.
So I guess I will provide both in a PR and then switch over to the system versions for my binding, once they have been included.

The threading question would have to be solved first though.

If I understand correctly, one way to solve it would be to provide a scheduler in the Profile base class. This would mean that Profile is no longer an interface then.

Another way would be to do it like I do it now, which is to get the scheduler from some Singleton and just have a common pool for all profiles. I think that this is sort of what you were describing, right?

I can't say which is better in Java. I just know that I would really hate having to turn an "interface" into a base class in C++.

[Updated on: Sun, 12 November 2017 20:35] by Moderator

Re: Using Threads in Profiles [message #1776157 is a reply to message #1776133]

Mon, 13 November 2017 05:01

Eclipse User

Quote:

the assumption that it will be easier for me to proceed if I keep it in the binding side for now

Well, the point is that you are currently the Guinea pig for this feature, so there should not be the expectation that you can build a valid binding on top of what there is right now. It is rather your feedback that will show what is missing in the framework.
So my suggestion is to include the esh.core.thing bundle as well in your workspace and directly implement missing parts there and create PRs from this to ESH, so that we can directly discuss them there.

Quote:

The problem is that they would then also need system channels for rocker switches, which also don't exist yet.

Which should also definitely be added to the system channels - so please include such in your PR!

Quote:

one way to solve it would be to provide a scheduler in the Profile base class. This would mean that Profile is no longer an interface then.

Correct. I am also a bit torn on whether that would be a good idea or not... Singletons are not a real option either, though (Simon won't accept them for sure ;-)).

For the start, I think I would go for the existing ThreadPoolManager and we should simply define a constant somewhere that is to be used for the thread pool name.

Re: Using Threads in Profiles [message #1776169 is a reply to message #1776157]

Mon, 13 November 2017 06:21

Eclipse User

I have created the following two issues:

#4541: System channels for 2-button trigger channels (a.k.a. rockers)
#4542: System trigger profiles

in order to further discuss them. And yes, a fully agree that they should be implemented directly in the o.e.sh.core.thing bundle and not within a binding.

Regarding the scheduler: Yes, a static constant is a no-go. I'd suggest adding something like

ProfileCallback.getScheduler()

so that the binding really doesn't have to care how to get access to it. But I agree that it makes sense to have a scheduler in there. I created #4544: Scheduler in Profiles for it.

Previous Topic:	Profiles
Next Topic:	Nginx configuration to access ESH

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 14:31:52 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter