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:
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?
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?
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++.
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.
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!
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.