One of the big obstacles for Enocean support was the licensing / IP issues with the enocean alliance.
An open source implementation of the protocol is ok, but the statement of the alliance is that any business user would be required to be part of the alliance (and pay them money). Which is really difficulty for an open source project like openhab. Don’t know if this is still that case, but I fear yes.
The inclusion of the enocean (opencean) library in openhab 1 / 2 might even be incompatible with the eclipse license.
AFAIK these IP and licensing issues are the reason why the aleoncean library was withdrawn.
Any direct usage of the protocol inside EPL code is probably prohibited, preventing anyone from developing a binding included into the official openhab distro where everything is EPL.
If there would be a clear commitment of the Enocean Alliance to open source, all of this would probably be solved, but there isn’t.
For me this is a reason to not increase enocean device use in my house and even think about replacing the existing ones.
This is correct and the legal implications are indeed greyish. For openHAB itself, being non-commercial, there isn’t really an issue, but it is right that we strictly wouldn’t be allowed to re-distribute such code under EPL without constraints.
That’s why I very much like the idea of @Hogan, which is to use a the EnJ library, which is under active development and thus looks like a pretty good choice. The positive effect is that the legal questions are then on that project and not on openHAB. So I’d be really happy to see progress on such a binding - latest in 2018 when @Hogan finds time again, but maybe someone else already starts earlier.
Why does FHEM then have a working Enocean Binding? This is really annoying. I could get the Enocean switches to work within minutes in FHEM and they did not work in OH2.
Very likely because they don’t care too much about the legal aspects? If you have any other information, let us know.
Btw, the rocker switches work smoothly for me with the openHAB 1.x EnOcean binding.
I am currently studying features and possible connections for EnOcean components within OpenHAB for a private project. Read all the FHEM stuff concerning EnOcean already. The standard way would be to use an USB300 (TCM in the end). Has anyone tried it the official Eltako way round: Connecting to a FGW14 using USB/RS-232, which itself is connected to a FAM14 (which handles wireless connections and also the adressing of RS-485-Components from Eltako)? I have got two links that this is working with FHEM already, perhaps a FTD14 (to duplicate telegrams) is needed, too.
Would this perhaps solve the legal problems, as this connects to Eltako-Bus and the Eltako-Bus is handling the EnOcean-Components in the end?
Hi there,
I have played around a bit with getting an EnOcean binding for OH2 up and running by using the enj library.
So far I have gotten a plugin to work that supports my rocker switches as simple switches.
My next step would be to support a dimmer channel on these switches.
Now my question is: Is anyone else working on this whom I should cooperate with?
Don’t want to be doing unnecessary work. So far all of this has just been getting to know the library and how to program plugins for OH.
But now I would start investing more time into it.
Another question:
Would you guys already want a plugin that only supports rocker switches with the Switch and Dimmer channelns, or should I wait with publishing until I have a plugin that maybe also supports actors, so that it has more functionality than the already existing OH1 plugin?
I only have a FUD device and a remote switching actor myself, so I will probably be limited to getting those to work anyhow.
What do you guys think?
Great work! Yes, I would definitely want a plugin with just a rocker switch support, if only to have a view of the code and a path forward. And who knows, maybe someone will step up and contribute…
Sounds awesome! My suggestion would be to come up with a PR as quickly as possible - it can be marked as work in progress [WIP] to make sure that it does not get merged yet.
You might also want to read up on https://github.com/eclipse/smarthome/issues/2226, which has just been implemented (but not yet really documented) and was specifically designed for supporting rockers like the one from EnOcean. So this binding should be the perfect candidate for making use of this new feature.
Hi Kai,
That is mighty interesting about the triggers. Funnily enough I was just investigating that mysterious trigger function in the BaseThingHandler when I got the notification of your post.
I have now implemented such a trigger channel for the binding but it appears that there are so far no other profiles than the few non-specific ones, right?
Currently I really have no idea how to write my own other than understanding loads of internal code from the pull requests.
Got a few sentences on how to do that for me?
Also: It seems that a rocker trigger channel does not exist within the system wide channels. Shouldn’t it? Along with that then I would assume a few profiles would also be made into system wide profiles.
Is there a set syntax for directly reacting to channel events in rules already? I would like to write a few test rules for my existing channel before I go and write code for profiles.
Okay I have tried to implement it myself after some in-depth analysis of how the default profiles work. But it didn’t work, because the interface classes are not exposed via API yet. So I guess implementing custom profiles for a binding is simply not supported yet. After a bit of googling I found this post: https://www.eclipse.org/forums/index.php/t/1089653/
in which my guess seems to be confirmed.
So for now I guess I am stuck with only implementing the channel and everything else having to happen inside of rules.
Right?
So for now I guess I am stuck with only implementing the channel and everything else having to happen inside of rules.
Right?
Yeah, but that sucks big time. I’d rather suggest exporting the API from the o.e.sh.core.thing bundle then. As your implementation is going to be open source it shouldn’t be too hard adapting it in case the API needs to be tweaked a little.
Hi sjka,
thanks a lot!
Sadly I don’t think your patch is all that is needed. There are dependent types for the interfaces that are still not exported.
For the TriggerProfile interface there are types like EventPublisher and ItemChannelLink that are causing trouble.
I guess for now I will just manually export everything I need so I can continue working on this.
These classes simply reside in other (already exported) packages, but I see your point that these are non that bindings usually should import. I had a chat with @Kai this morning and I it looks like the profile API can be simplified a lot and thereby getting rid of these dependencies. So stay tuned…
In any case, to me it doesn’t look like in your case it’s the binding which should implement any specific profiles. Just focus on providing the trigger channels primarily. The rest should be secondary for now.
I don’t get this.
One of the profiles I would have written is a dimmer trigger profile that will do all the timing stuff to issue Increase and Decrease commands for long-presses.
How would that not be part of the binding?
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?
Is it planned to implement system profiles for all sorts of these channels and possible conversions?
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.
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 @Component.
I thought about using the button channel, but that would mean that a dual rocker, like the one I have, would have 4 independent channels, whereas logically they are more like 2 independent rockers. As such I created a new rocker switch trigger channel with up_pressed and down_pressed events and their release counterparts.
Yeah I assumed that and the classes have the @Component annotation.
But using the profile that I wrote in an item declaration, using the syntax [ profile=“bindingname:profilename” ], didnt do anything.
I assumed that the ProfileFactory just wasn’t picked up, Anything I am missing?
