New openHab2 EnOcean binding

Hi Markus,
works great. Thanks.
In my official document from Eltako there is nothing mentioned for teaching in the GVFS.
Looks like they have different manuals for the same product.

Another step in home automation done. Coming weekend I will try to resovle two other points I still have with the EnOcean binding:

  • I don’t get any feedback in openhab if a rocker switch is pressed. Looks like the response of the actuator is not processed.
  • In rules I can only use up/down/stop with rollershutters but not percentage.


Glad it works now.
Regarding the response of the actuators, there are a multiple points in the chain where faults can occur. One just has to go step by step, but normally one can get it work.


Is there anyone who has contacts running with this binding?
I can‘t use my window contacts because of this log entry…
Need help!

„ [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _1BS for FFEF3D32 payload D500FFEF3D320001FFFFFFFF3400 received

[INFO ] [ernal.transceiver.EnOceanTransceiver] - Discard message because this is a teach-in telegram from FFEF3D32!“


And how do you configured them?

I started here, then did a search in this thread and found a ton of examples already.

After still having trouble I posted at least some basic information on the device I have trouble with (eg make and model, references to documentation eg. the EEP) along with the relevant parts of my Enocean OH setup. Notably my things and items setup.

As it still was not working I posted more than one line of log, and stated what I was doing that lead to that log-entry and the result I was expecting.

At that point users jumped on the topic, compared with their setup, some users even had my exact device already working (they knew because I provided that info as stated above) and posted their configuration.

I already posted this several weeks ago, but nobody „jumped“ on, see:

That is because also in your initial post it is nearly impossible to post less information.

I got a very extensive Eltako setup.
E.g. shutters, light, power consumption, weatherdata, poweroutlets and more…
Everything is working fine with openhab except the contacts because the message get discarded.

So I just want to know what’s the solution that these telegrams doesn’t get discarded. They are no teach in telegrams.
I think my case is so unique that only @fruggy83 can answer this.

I would start by creating a new topic. The info about your setup is scattered all around in this post.
The important part you missed mentioning is the FTS14EM, this is the guy you have issues with.

Per Eltako docs it send its messages with a lot of different base-IDs. @fruggy83 already told you earlier in this thread that once you discovered a switch/contact/window you need to note the base-id, remove that and create a new (rocker) item with that manually.

it mimics a normal FT55 rocker switch:

I tried to create a rocker thing (not item) but it doesn‘t work also.
If you look at the log which I posted you see that the telegramms and ID are received by the openhab correctly, but then they getting ignored because openhab says they are teach in telegramms. Which they are not.

I think this has something to do with this here:

I give up. If you are already sure that this is your problem, why post here in instead of opening an issue ?
(hint: it is not)

Hi Daniel (@fruggy83), hope you are well. Because of different reason I want to move to OH3. The connection to my enocean pi via RFC2217 works perfectly. No stress to get it run :slight_smile: My rollershutters FSB61NP working like hell. But my FMS61NP doesn’t work as expected. I tried to “copy” all from OH2 and did the learning and clearing several times with nuances of changes but the result is always the same. When I do switch 1 light on the second light switched on as well.
Question: Do you already have experience with OH3?
My next try would be to completely delete all on the FMS61NP instead only learning new RockerSwitches.
Many Thanks, Tino

Hi Tino @flynux,

I have no problems with OH3. Everythings works as expected, I have even switched my productive system to OH3.

Best regards

I am using openhab 2.5.10 with the enocean binding from fruggy83, and my configuration since more than a year.

Actually I have some trouble with my etalko FAH60. It seams to me, that the sensor does not get enought light during the daylight to fill its battery using its photo cells. The lux messaring stops some time in the evening at a value of e.g. 33 and restarts with values above 400 lux in the next morning.

I have checked the thing definition and found a switch, to receive battery status signal messages.

I am using thing definition files, so I cannot switch these message on in this dialog. It is competing.
How should I have to modify my thing definition to switch these messages to ON?

  enocean:lightSensor:Lichtsensor_FAH60_01 "Balkon Lichtsensor"
  [ enoceanId="01A5D305",
    broadcastMaessages=true ]

How can I have access to the battery value, e.g. by using a channel?

Thanks for your help

Hi Jörg @doko,

you just have to add the config parameter receivingSIGEEP and set it to true. However I am not sure if your FAH60 sends these special messages, but adding this paramter should not make it worse.

Best regards

Hi Daniel,
is there already any progress with the support for FUTH65D?

Thank you!

Danke Daniel,
danach habe ich gesucht :slight_smile:

Das hat funktioniert und gibt mir einen neuen channel.
Bisher ohne sinnvollen Rückgabewert, aber das liegt wohl daran, dass ich nicht die Batterievariante habe (FAH60B). FAH60 hat zwar auch irgendwas zum Strom speichern, aber vielleicht keinen auslesbaren Akku.

Bis auf ein Neues

Thanks Daniel, good to know. Have a great lockdown and merry christmas time.

Hey Daniel (@fruggy83), I double checked everything.
Removed all items and thing from OH3, clean cache, reboot.
On the FMS61NP I completely delete everything, completely disconnect all wires. Wired everything.
Create two new classic devices and teached them in. but If I press 1 the other light get switched on as well and vs.
Attached you will find the log:trace. I can’t find anything. Might be the hardware broken? But it works with my FT55 RockerSwitch. enocean_trace.log (10.2 KB)
Any thoughts?