New openHab2 EnOcean binding

Tags: #<Tag:0x00007f014b91a110> #<Tag:0x00007f014b919f80> #<Tag:0x00007f014b919dc8>

(Daniel Weber) #482

Hi Frank (@fnu),

If I look in the debug enabled log, it looks like as there are too less messages send out to the Peha EBI

Maybe we should just conntact the PEHA support and ask them what kind of messages they are expecting. The NodOn guys where really helpfull in such a case and even solved problems with the UTE teach in.

How to update the openocean binding? Stopping OH2, replace the jar file with a newer brew and restart OH2?

I am doing it in the same way. If you are in doubt you could also clean the cache before starting openHAB again. In this case you have to reinstall the serial feature to get the binding running.

Best regards

(Thorsten Oest) #483

Hi Daniel (@fruggy83),

thanks for checking my issue.

I am still running FHEM in parallel because I am using Busch-Jaeger motion detection sensors in conjunction with Peha 455 FU-S2 sender. To receive the signal I need the push button running (it also sends 0x00 / 0x10). The remaining thing to integrate is an Eltako FMH8 rocker switch - just not tried so far because we almost never use it.

Best regards,

(Frank) #484

Hi Daniel (@fruggy83),

Will try to call them this week …

The Peha EBI 1-channel is polled regular and correctly about its status (here after restart of OH2):

2018-12-31 14:53:02.124 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for XXXXXX01 payload D2046080XXXXXX010001FFFFFFFF5000 received
2018-12-31 14:53:02.132 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D2046080XXXXXX0100 for XXXXXX01 received
2018-12-31 14:53:02.159 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for XXXXXX00 payload A500009448XXXXXX000001FFFFFFFF5000 received

2018-12-31 14:53:02.165 [vent.ItemStateChangedEvent] - Schlafzimmer_OG_Aktor changed from NULL to OFF

And it looks kind of correct if trying to switch it from OH2:

2018-12-31 15:08:22.260 [ome.event.ItemCommandEvent] - Item 'Schlafzimmer_OG_Aktor' received command ON

2018-12-31 15:08:22.265 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2018-12-31 15:08:22.272 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E01YYYYYY050001XXXXXX01FF00

2018-12-31 15:08:22.285 [vent.ItemStateChangedEvent] - Schlafzimmer_OG_Aktor changed from OFF to ON

2018-12-31 15:08:22.301 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received

But doesn’t do anything. From the Nodon I get something like this after switching it from OH2:

2018-12-31 15:05:56.589 [ome.event.ItemCommandEvent] - Item 'Esszimmer_EG_Aktor_Kanal1' received command ON

2018-12-31 15:05:56.599 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2018-12-31 15:05:56.616 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2010101YYYYYY030001XXXXXXF6FF00

2018-12-31 15:05:56.622 [vent.ItemStateChangedEvent] - Esszimmer_EG_Aktor_Kanal1 changed from OFF to ON

2018-12-31 15:05:56.635 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2018-12-31 15:05:57.265 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for XXXXXXF6 payload D20461E4XXXXXXF60001FFFFFFFF5000 received
2018-12-31 15:05:57.271 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20461E4XXXXXXF600 for XXXXXXF6 received

The Nodon actuator sends some feedback after switching.


(Daniel Weber) #485

HI Christoph (@sepp99),

for the moment everything works as expected

Always good to hear, that the binding works as expected for someone and does not just make trouble :wink:

The marketplace does not have an autoupdate function. At least I am not aware of. So you just have to deinstall the marketplace binding and just reinstall it to get the newest version.

Best regards

(Daniel Weber) #486

Hi Rainer (@jahnra),

sorry that I must disappoint you. Currently the binding does only support radio connection. A wired (RS485) connection is plannend but not yet implemented. This option is the first part of the wired implementation and was not meant to be deployed.

Best regards

(Daniel Weber) #487

Hi Tino (@flynux),

yes thanks, I received the log. I will investigate it further tomorrow :+1: .

Best regards

(Rainer Jahn) #488

Hello Daniel (@fruggy83)

Thank you for your answer!
I think the way to support radio telegrams on the binding is not so far away.
Most of the parts are already there, expect listening for ERP on the interface.

Unfortunately I have no experience in programming JAVA,
but I think about writing a small Python interface between the binding and the serial interface
to do the job of the TCM310 in software.

But I am not disappointed at all! I can imagine how many hours you spent on this project…


(Frank) #489

Hi @all,

happy new year 2019!

Hi Daniel (@fruggy83),

if you have a look into my last post, you can see OH2@openocean does send different payloads to the actuators, for the same action:

Switch on for Peha:

Sending data, type RADIO_ERP1, payload D2011E01YYYYYY050001XXXXXX01FF00

Switch on for Nodon:

Sending data, type RADIO_ERP1, payload D2010101YYYYYY030001XXXXXXF6FF00

The octets for sender and receiver EnoIDs must be different, sure, but what about the others? I’m especially curious why the third octet is different?

Thanks so far.


(Wiss911) #490

Hi Daniel (@fruggy83),

happy new year, i hope you enjoyed the time with the Familiy.

I am using your binding since long time, we also had already conversations in the past on Github.
We have the same setup ( Eltako FSB14, etc… ) .

Everything is working fine, but until last week, i never cared about percentage control of my eltako rollershutters, then i started trieng this and it is not working. I tried 2 days many different things, reinstalling the binding, using genericrollershutter, deleted the things and items from my files and created via PaperUI etc. , but i don´t get it to work.

I am on the latest Openhab Snapshot Version, so your binding is also the latest.
The Shuttime is set in my Thing.
My FAM14 is sending the status, the operation mode is set to 2.
Commands Up, Down, Stop, 100,0 are working. But nothing between 1-99 is working. In that case, the command isn´t even send, as you can see in my log.

Is there a general problem or do you have a hint what i am doing wrong?

This is my thing

Thing rollershutter FFAA3DA3 "Arbeiten_rechts_Rollo" @ "Büro"  [enoceanId="FF9D66A3", senderIdOffset=35, sendingEEPId="A5_3F_7F_EltakoFSB", receivingEEPId="A5_3F_7F_EltakoFSB", broadcastMessages=true, suppressRepeating=false, pollingInterval=3] {Channels: Type rollershutter:rollershutter [shutTime=25]} 

This is my item

Rollershutter Arbeiten_rechts_Rollo_Rollershutter "Arbeiten rechts Rollo [%s%%]" &lt;blinds&gt; (Rollo) {channel="enocean:rollershutter:FT1R5UQ1:FFAA3DA3:rollershutter", autoupdate = "false" }

Here a log example, where you can see, that for Command(50) nothing is happening.

10:10:15.195 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Arbeiten_rechts_Rollo_Rollershutter' received command 50
10:10:27.937 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Arbeiten_rechts_Rollo_Rollershutter' received command 100
10:10:27.954 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
10:10:27.959 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload A500190208FFAA3DA30001FFFFFFFFFF00
10:10:27.973 [TRACE] [ternal.transceiver.EnOceanTransceiver] - Received Sync Byte
10:10:27.981 [TRACE] [ternal.transceiver.EnOceanTransceiver] - >> Received header, data length 1 optional length 0 packet type 2
10:10:27.985 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
10:10:27.990 [TRACE] [ternal.transceiver.EnOceanTransceiver] - Response without listener
10:10:28.465 [TRACE] [ternal.transceiver.EnOceanTransceiver] - Received Sync Byte
10:10:28.470 [TRACE] [ternal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
10:10:28.478 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for FF9D66A3 payload F602FF9D66A33001FFFFFFFF5000 received

Best regards and thanks


(Tino) #491

Hi Daniel (@fruggy83) , hope the logs helping you to make some improvements, but actually I got it working now.

For each of my two FMS61NP I created a Classic Device with 1 Listener and Swictch on ChannelA, which are controling the UT1 switch position on the FMS61NP. The UT2 position on it I control it with another Classic Device with Switch but no Listener anymore. Great stuff :slight_smile:

As you now I have a FT55 Rocker Switch which controls the both FMS61NP physically. So as a next step I want to change the status of my classic devices when I switch the physical FT55.

Do I need to create a Rocker Switch Device for the FT55 and setup a rule and change the state of the classic devices? I made several tests with different scenarios but I had no success. Any ideas?

Many Thanks, Tino

(Ralf) #492

Hi Daniel (@fruggy83),

beside my problem being unable to connect via rc2217 to my raspi (ser2net 3.51) I still have the issue with the state update of my Afriso APR 234 PowerPlug. When I switch from on to off, the item immediately switches back to on and I cannot switch any more.

The following log shows what happens when I switch from on to off:

2019-01-04 17:47:34.038 [ome.event.ItemCommandEvent] - Item 'PowerPlug_01_Switch' received command OFF
2019-01-04 17:47:34.039 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2019-01-04 17:47:34.040 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload D2011E00FF8FE0810001FFFFFFFFFF00
2019-01-04 17:47:34.041 [nt.ItemStatePredictedEvent] - PowerPlug_01_Switch predicted to become OFF
2019-01-04 17:47:34.044 [vent.ItemStateChangedEvent] - PowerPlug_01_Switch changed from ON to OFF
2019-01-04 17:47:34.068 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2019-01-04 17:47:34.180 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG VLD for 0509BFEC payload D20460800509BFEC0000FFFFFFFF4F00 received
2019-01-04 17:47:34.182 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D20460800509BFEC00 for 0509BFEC received
2019-01-04 17:47:34.188 [vent.ItemStateChangedEvent] - PowerPlug_01_Switch changed from OFF to ON

Only when I add “autoupdate=false” parameter to my item, I get it working. But this solution is unsatisfying due to missing updates in the GUI (BasicUI).

Here is my Thing configuration:

Bridge enocean:bridge:usb300 "ENO Gateway" @ "EnOcean" [ path="/dev/ttyNET0" ] {
   Thing measurementSwitch 0509BFEC "ENO PP01"  @ "EnOcean" [enoceanId="0509BFEC", senderIdOffset=1, sendingEEPId="D2_01_09_PERMUNDO", receivingEEPId="D2_01_09_PERMUNDO", broadcastMessages=false, suppressRepeating=false, pollingInterval=300]

Item config:

Switch          PowerPlug_01_Switch             "PowerPlug 01 Switch [MAP(]"       <switch>                (gSteckdosen, gENO)     {channel="enocean:measurementSwitch:usb300:0509BFEC:generalSwitch"}//, autoupdate = "false"}
Switch          PowerPlug_01_EcoMode            "PowerPlug 01 Eco Mode [MAP(]"     <switch>                (gENO)                  {channel="enocean:measurementSwitch:usb300:0509BFEC:ecoMode"}
String          PowerPlug_01_Status             "PowerPlug 01 Status [%s]"                      <scale>                 (gENO)                  {channel="enocean:measurementSwitch:usb300:0509BFEC:receivingState"}
Number:Energy   PowerPlug_01_Energy             "PowerPlug 01 Energie [%.3f kWh]"               <scale>                 (gENO)                  {channel="enocean:measurementSwitch:usb300:0509BFEC:totalusage"}
Number:Power    PowerPlug_01_Power              "PowerPlug 01 Leistung [%.1f W]"                <scale>                 (gENO)                  {channel="enocean:measurementSwitch:usb300:0509BFEC:instantpower"}

Please give me some advise how to debug this problem. Or is there any known bug arround my problem?

Thank you and kind regards,

(Dominik Krickl-Vorreiter) #493

Hey @ThAO,

I’ve just experienced the same :face_with_raised_eyebrow:

The reason is that your actor does not only receive telegrams sent from OpenHAB, it also sends telegrams by itself, maybe because it supports bidirectional communication, or you switch the light with a local switch.

OpenHAB receives these telegrams, it can assign it to your Thing by enoceanId, and now it tries to map the payload via your file. If you do not have a mapping from HEX -> State, you get the warning you have shown.

What device do you want to control? Maybe you can use an existing EEP? If not, feel free to open an issue at fruggy83/openocean to ask for integration. If you do so, please provide as much information as possible.


(Dominik Krickl-Vorreiter) #494

Hi @shotte,

please update the binding to the newest version, you use a version with a bug in this EEP implementation.

You can find it here: fruggy83/openocean
Uninstall previous version and place the .jar in your addons folder.

Ohh, and you do not need a MAP for your switch :wink:


(Dominik Krickl-Vorreiter) #495

Hi @wiss911,

I see that in the implementation of A5_3F_7F_EltakoFSB, there are many if () statements, and when one of these turns out to be false, the binding will not send any message.

So could you please try to drive the rollershutter to a new position with the local switch, check if the position has updated to the new percentage in OpenHAB, and then try to change the position through OpenHAB? The reason I suggest this is because the binding has to give the actuator the difference of current position and target position, so the binding has to know the current position.


(Martin) #496

Regarding my issue
@fruggy83, @dominikkv
Any Suggestion? Would be great,

(Daniel Weber) #497

Hi Martin (@Woogi),

Based on my old configuration I expected that I can enter the ID into the virtual Switch as before to avoid for each device the teach in mode again:

The old virtualSwitch did not really contained a meaningful Id ( 6a9999c8 is just a random hex). You just need the senderIdOffset of this virtualSwitch, defined in the thing file. Set the senderIdOffset of your new classicDevice to the exact same senderId and you should not need a second teach in.

What is the logic behind the listener?

The listener is used for updating the openhab item state whenever the actuator gets changed externaly. For example, if you own an onedirectional actuatur, you have to define a listener for all of your physical rockers which can switch your actuator. The listener then keeps the state of the item in sync with the physical state of the actuator. If you own a bidirectional actuator, you just need one listener, listening on the actuator itself.

By now I get a signal for a dummy switch in my sitemap, but it is the opposite of DIR1 and DIR2

Just use the EEP F6_02_02 as the receiving EEP in this case. This EEP just inverts the F6_02_01 messages (UP => DOWN and vice versa).

BTW: PaperUI displays your items based on the channels, therefore you get two items in your GUI, one for the virtualSwitcher and one for the listener although your bound both channels to the same item. The ClassicGUI displays just one item in this case.

Best regards

(Wiss911) #498


Hi Dominik,

thanks for that suggestion. The state is not updated, so i guess either the Actuator is not sending it properly or the receiving message is not read properly. In my log there is the payload of the answer, F602FF9D66A33001FFFFFFFF5000. But i don´t know how to read it right to tell if it contains the right information.

best regards


(Ralf) #499

Hi Dominik (@dominikkv),

thank you for your link. Now I installed the latest binding file and everything is working (switch and ser2net gateway connection).

Thankz to ALL who investigated that much time in this binding and all who spend some time in answering my partly stupid :kissing_heart: questions.

Great work,

(Martin) #500

Hi Daniel (@fruggy83 ),

thank you for your reply. The tipp with changing the EEP state to F6_02_02 was great and helped a lot.

For the senderIdOffset it is obviously not possible to use a HEX like I did 6a…c8. So I had to set a string and teached the actuator again. After that the light is switchable as expected. Thank you!

Please see my current thing config below, I changed the senderIdOffset, which lead to a new teach in process for this actuator, so it was not possible to use the old from previous virtual rocker switches. Furthermore I adjusted sending and receiving EEOId to F6_02_02.

   Thing classicDevice cd01 "Licht Leseecke" @ "Leseecke" [ 
      Type virtualSwitchA             : virtualSwitchA              [duration=300, switchMode="rockerSwitch"]
      Type rockerswitchListenerSwitch : Listener1 "Schalter Leseecke links"  [enoceanId="001059B7", channel="channelB", switchMode="rockerSwitch"]

Thank you again :-).


(Daniel Weber) #501

Hi Martin

your old virtualRockerSwitch should also have senderIdOffset. If you use this senderIdOffset for your new classicDevice, another teach in should not be needed. However good to know that it works now :+1:

Best regards