The only way I see this not being part of the binding is, if the channel that I wrote would be made into a system channel and then there already being the very same profile that I just described as a system profile, right?
Exactly, that’s the idea. This use-case is not specific to enocean whatsoever. I’d expect the same to be necessary on many others (like e.g. KNX) and it’s gonna be chaotic quickly if every binding brings their own profiles for such standard use-cases. Are you going to use a system channel (e.g.
system:button) or will it be somewhat different?
Oh and I got another question: I have written a very simple profile now, that converts rocker presses to On and Off commands. I assume there is some part still missing that will pick up my profile factory and iterate over all registered profile factories to instantiate the profiles. From what I can see in the code right now there is just a hard-coded call to the default profile factory, right? I might just be missing the relevant code though.
This is done by using OSGi services, i.e. the ProfileFactory/ProfileAdvisor implementation needs to registered as an OSGi component. This can be done conveniently by annotating the implementation class with
By the way, a couple of minutes ago I pushed https://github.com/eclipse/smarthome/pull/4516 which changes the API according to your (and other) feedback - to the better, I believe. Let’s see what the review brings, but please be prepared for it to change.