Seems like there is a decent amount of interest in EnOcean and even a few people willing to step up and contribute. Iād put myself in that later category as well. Unfortunately I donāt have the time to commit to leading an effort to create an OH2 EnOcean binding, if someone is willing to take the lead Iāll gladly contribute.
@Kai are you aware of anyone with a desire to lead such an effort? Basic design\architecture, task\issue creation that would enable people in the community to pick up some features as time permits?
Hi, Iām interested too in enocean. Sadly, there is a HUGE mess on github / maven: aleoncean has ā¦ disappeared. and so has the binding.
There are some people that did fork the aleoncean binding, I cloned it and compilation fails because it doesnāt find aleoncean1.9.jar on maven (where it is not ā¦ anymore ?)
So I cloned some aleoncean lib (latest I could find) git repo, and compiled it (changed the version to 1.9 instead of 0.0.1-snapshot ā¦) ā¦ but still the compilation of the binding fails miserably on classes not found (wich are not present so I assume that I cloned a very old version, the only one available right now).
Someone has cleaned the web or what ? not cool at all ā¦
If someone can re-upload the right sources on github please ?
@hubertus_hettenkofe1 do you successfully use your EnOcean window handle with OH2? Which binding do you use these days? Do you mind to share your items configuration? I am using the Hoppe SecuSignalFHFS-vw window handle (eep=F6-10-00) and I could need some help in order to set things up. - Thanks!
No - it is not running under OH2 yet. In the moment there is no support for the 1.x binding under OH2. I hope this will change soon ;-). Under OH 1.8 i use the aleoncean binding and it works fine.
Not the answer I was looking for
Does that mean that EnOcean in general is not working under OH2, yet, or are you specifically referring to the window handles?
I am also trying to get an Eltako FT55-rw switch (eep=F6:02:01) working using the EnOcean 1.9 binding. However, I am struggling with this one as well as you can read here: EnOcean Pi 868 GPIO module gateway Setup with OH2 - #4 by mark_leonard_tuil
I simply donāt receive any kind of signal from the switch and I donāt understand what the problem is.
Whatās the current state of the development with regards to EnOcean in conjunction with OH2? I would love to make the switch from FHEM to OH2, however, EnOcean is critical for my setup!
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
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.