i use the window-handles from hoppe to control window open/close as well. I migrated to OH2 a few month ago and have used the aleoncean binding which I used in OH1. Even there is an exception during OH2 startup, it looks like the aleoncean binding is working. I can get the status updates from the window handles. Sometimes some rules are not triggered because of the status updates, but I’m not sure if it’s an issue of the aleoncean binding or any other reason. I’m investigating in this.
For me this is a workaround and I would very appreciate an official solution for that kind of enocean integration into OH2. If I can help, please let me know.
@c214 If I recall correctly, I am not able to choose the aleoncean binding using Paper UI. How am I supposed to install this binding under OH2?
Do you mind to share your items definition regarding the window handles?
@KraxelHuber I don’t use the paperUI that much for OH2 configuration. As I migrated from OH1 most of my configuration is done manually via config files.
I put the org.openhab.binding.aleoncean-1.6.0-SNAPSHOT.jar into the addons folder and added a aleoncean.cfg file to the services folder. After that I was able to use the enocean items configuration as with OH1.
During OH2 startup I get the following exception:
2017-04-14 10:04:32.272 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService, id=332, bundle=220/file:/usr/share/openhab2/addons/org.openhab.binding.aleoncean-1.6.0-SNAPSHOT.jar]: Unexpected problem updating configuration org.openhab.aleoncean
java.lang.NullPointerException
at org.openhab.binding.aleoncean.internal.AleonceanBinding.updated(AleonceanBinding.java:149)[220:org.openhab.binding.aleoncean:1.6.0.201408140937]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1461)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1417)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.12]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Despite that exception, the aleoncean binding seems to work as the items are updated as expected.
@KraxelHuber
One of the items definition looks like
Number Fenster_DG_Bad_Fenstergriff "Balkontüre Bad DG [MAP(hoppe.map):%s]" <contact> (EnOcean, DG_Bad) {aleoncean="REMOTEID=xx:xx:xx:xx,TYPE=RD_F6-10-00,PARAMETER=WINDOW_HANDLE_POSITION"}
Due to problems with Enocean Binding I am having my enocean rocker switches setup in FHEM and use MQTT to bridge between FHEM and OH2. This works quite well but obviously is not a good solution.
I’ll start working on an new enocean 2.x binding (considering aspects of the old binding and the OSGI implementation). As i haven’t developed for OH so far it can take some time to get sth. useful.
I’ll publish this binding in the openhab namespace.
It’s a shame that the EnOcean Alliance doesn’t directly contribute to this effort. Support within a platform like OpenHAB2 seems to me like the KEY to their platform’s success.
From my perspective, there are not very many worthwhile problems that can be solved with EnOcean hardware alone, e.g. switches outlets, relays, and sensors, AND YET there are incredible solutions that can be accomplished by putting smart middleware between EnOcean and other technologies.
I see OpenHAB as being similar in concept to the Asterisk telephony engine. History shows that the ability to inter-operate, BETWEEN different communication technologies, (and insert workflows & business logic) that caused Asterisk to explode in popularity, and literally transform the industry.
If EnOcean wants their wireless technology to be increasingly adopted, I think they should be bending over backward to promote the powerful interoperability that OpenHAB can provide.
Well, i guess from thier perspective they’ve opened up enough so that one interrested can implement thier protocol. You can see this happening in those various EnOcean IP Gateways out there.Well… maybe later on OH2 has a EnoCean binding… let’s see
I was looking at writing an EnOcean binding for OH2 but I couldn’t find out how to develop for OH2 using my preferred development environment. Unfortunately the “open” in OpenHAB doesn’t seem to apply to IDEs.
So I’m developing an EnOcean-MQTT bridge based on dog-gateway/enj-library from GitHub that will tie into OpenHAB via the MQTT binding. For anyone who wants to develop an EnOcean binding for OH2 and doesn’t mind developing with Eclipse, I’d recommend taking a look at dog-gateway/enj-library.
My immediate needs are covered by the OH1 EnOcean binding, so I’m in no great hurry, and I’m unlikely to implement and test more than the F6:02:01 EEP. Though I am beginning to wonder whether MQTT might not be a good replacement for the event bus.
For anyone who wants to develop an EnOcean binding for OH2 and doesn’t mind developing with Eclipse, I’d recommend taking a look at dog-gateway/enj-library.
Hi all, just read your topics with deep interest. But feel a little bit frustrated…
Two years ago I started with some Homematic devices and a CCU-2. Works fine so far. But I’m not convinced with their dimmer actors. I’ve a HM-LC-Dim1T-DR and a HM-LC-Dim1T-FM. Both starts to flutter sporadically while Eltako dimmers do not. I could compare them with some Eltako EUD12NPN-UC universal dimmers I used for my kitchen for a couple of years. So I replaced them with the newer FUD14 dimmer plus a FAM14 and a FGW14 as a starting point.
Then I had to decide for a middleware to integrate Homematic and Eltako / EnOcean for my needs. Here’s the list of possible candidates I found:
Loxone: expensive
First choice seemed to be FHEM. Very good documentation including an excellent list of supported devices. But Perl is not my preferred programming language. The CUxD needs a license key for EnOcean and is hosted on the (slow) CCU-2. I’m more intending to use a separate server like a RaspberryPI. I took a look at DashUI and it’s successor ioBroker. Interesting project but it seems to be on a very early project state. Furthermore, it’s not clear if they ever implement an EnOcean gateway. Then I checked OH. Read a forum topic about successful enocean integration with a dimmer somewhere. Therefor I started with openHAB. Like the documentation / tutorial and the look&feel so far. The Homematic side works like a charm But when I started to get my enocean devices running I realized that the current EnOcean gateway doesn’t fit my needs.
But what’s next? Should I wait for the new gateway or should I start with the combination FHEM + MQTT+ MQTT-Broker just to be able to support the Eltako FUD14 dimmer inside OH? Crazy world
Currently I’m stagger between stop my activities with OH to start with FHEM or replace my EnOcean devices with…… maybe Z-Wave? Maybe a Fibaro Universal-Dimmer 2? But then I have to recheck the hardware side again Does the dimmer work properly with my new Philips LED bulbs? I’ve a strange feeling when I take a look at amazon reviews…. I’ve to mention, I’m very convinced about Eltako devices in terms of reliability and functionality. One examples: If you fasten the screws on a HM-LC-Dim1T-DR you’ve take care not to break the whole housing. Do the same with a Eltako and you suddenly feel the difference.
Home automation is a complex beast
Any suggestions?
Greetings Christian
I’m in a comparable situation. I am waiting for an native OH2 EnOcean binding. I am using some window handles that don’t seem to be supported (at least I struggled). In FHEM they are working properly. So what I do is sendig the window handle states via MQTT to OH2, but this is just a workaround.
I am still surprised why EnOcean support within OH2 is so limited. Maybe some of the devolopers may kick in here and tell us whether somebody is really working on an updated binding that will support various EnOcean hardware.
Hogan told me that he won’t find any time over the next months - so unfortunately, there is no activity on this; I have just added the “help wanted” label to the issue. Maybe it could also be worth to offer add a bounty on the issue, similar to what has been done for the InsteonPLM binding.
Definitely a bit delicate - but in any case, I would very much prefer if any new efforts regarding EnOcean support were put into https://github.com/openhab/openhab2-addons/issues/2261 instead - this would be a huge step forward for everyone and for sure the most future-proof solution.
Kai already mentioned my reasons why i’m pausing development here. As soon as i can spend more than an hour or so per Werk on development i will continue development on the binding. As i will have more time for doing that at the end of 2017 everyone wo wants to implementiert the enj-lib is welcome to do so. Either way i will contribute to the binding in 2017/2018.
But when I started to get my enocean devices running I realized that the current EnOcean gateway doesn’t fit my needs.
Does the dimmer work properly with my new Philips LED bulbs? I’ve a strange feeling when I take a look at amazon reviews…. I’ve to mention, I’m very convinced about Eltako devices in terms of reliability and functionality. One examples: If you fasten the screws on a HM-LC-Dim1T-DR you’ve take care not to break the whole housing. Do the same with a Eltako and you suddenly feel the difference.