New openHab2 EnOcean binding

Tags: #<Tag:0x00007f01482b4198> #<Tag:0x00007f01482b4030> #<Tag:0x00007f01482b3ea0>

(Daniel Weber) #462

Hi Frank (@fnu),

I am glad that it works now. Sometimes you better do not ask why… :joy:

So, but some Debug output for you

Looks good to me!

Looks like I receive some polling

Yes you receive 4BS messages from three different actuators FFFA4100, FFB44900 and FFB44902. These messages could be energy measurement messages or anything else. Without knowing the EEP it is almost impossible to interpret the message content.

What is the correct way for the bi-directional actuators?

In most cases the bi-directional actuators support a teach in method called UTE. In this case they send a teach in messages which contains the EEP to control them. This should work at least for the NodOns as these are definitely not too old. Just do the following. Start discovery for the enocean binding and start the teach in process of you actuators afterwards. Shortly after you should find an item in your inbox which is completely configured sending/receiving EEP, enocean Id, senderId and so on. You just need to give it a name. However be sure to use the snapshot version, otherwise you are not able to switch these actuators :frowning_face:

Best regards and merry christmas

(Daniel Weber) #463

Hi all,

I wish you all a merry christmas and some peaceful days. As I am on a family round trip the next days, I will be a little more quiet.
Sorry for the troubles with this binding, I hope the next release will be more stable. Have a good time :gift::christmas_tree::santa:

Best regards

(Thorsten Oest) #464

Hi Daniel (@fruggy83),

thanks for checking this! Updating to 2.5 solved the problem.

Best regards,

(Frank) #465

Yes, FFB4490[0|2] (Channel [0|1]) is 4BS of the Peha dual channel actuator already installed (452 FU-EBI).

But I have no clue where the EnoceanID FFF4100 belongs to. Maybe some device from neighbours … nothing in my installation …

These Peha dual channel actuator do offer 4 different EnoceanIDs, the 2 above mentioned and 2 additional ones for VLD (FFB4490[1|3]). According to documentation VLD is EPP:D2-01-08. I have the versions w/o energy status …

If you need more information about the actuators or EPPs, I could provide information you are interessted in …

The manual of the 452 FU-EBI is saying EPP:F6-02-02 for 2 rocker and EPP:F6-03-02 for 4 rocker switches, just like I discovered it with the 1-channel 451.

I will stick with the snapshot version otherwise I couldn’t use my unidirectional actuators. The will stay, they are great quality, build for eternity …

I think about to move the definition into files out of the GUI, to have them more easy to recover …

I wish you also merry christmas and relaxing days.

Thank you for the great work on Enocean in openHAB2.


(Frank) #466

Hi Daniel (@fruggy83),

Ok, quickly tested that way (actually no debug level):

2018-12-24 12:05:31.087 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Stopping EnOcean discovery scan
2018-12-24 12:05:31.101 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Starting EnOcean discovery and accepting teach in requests
2018-12-24 12:05:59.573 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Received teach in message from XXXXXX03
2018-12-24 12:05:59.584 [INFO ] [covery.EnOceanDeviceDiscoveryService] - EnOcean Package discovered, RORG UTE, payload D4A0FF01000801D2XXXXXX0300, additional 01FFFFFFFF4300
2018-12-24 12:05:59.630 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Send teach in response for XXXXXX03
2018-12-24 12:05:59.647 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'enocean:measurementSwitch:9019d0f2:XXXXXX03' to inbox.

2018-12-24 12:05:59.661 [home.event.InboxAddedEvent] - Discovery Result with UID 'enocean:measurementSwitch:9019d0f2:XXXXXX03' has been added.

2018-12-24 12:06:10.513 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Received teach in message from XXXXXX01
2018-12-24 12:06:10.518 [INFO ] [covery.EnOceanDeviceDiscoveryService] - EnOcean Package discovered, RORG UTE, payload D4A0FF01000801D2XXXXXX0100, additional 01FFFFFFFF4400
2018-12-24 12:06:10.560 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Send teach in response for XXXXXX01
2018-12-24 12:06:10.579 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'enocean:measurementSwitch:9019d0f2:XXXXXX01' to inbox.

2018-12-24 12:06:10.579 [home.event.InboxAddedEvent] - Discovery Result with UID 'enocean:measurementSwitch:9019d0f2:FFB44901' has been added.

To my surprise I get the result of a Enocean Measurement Switch using the VFD EnoceanIDs … I expected the 4BS EnoceanIDs … what should it be?

Within that 2 things I get 5 channels, generalswitch, receivingstate, totalusage, instantpower and dimmer. If I define a switch item to generalswitch, actuator doesn’t react if I try to switch it. Doesn’t matter if I define item manually or using Simple Mode for Item Linking.

Will reset both channels on actuator to delete all pairings, re-teach in my physical rockers and start over with discovery for OH2 …


(Frank) #467

Hi Daniel (@fruggy83) & all,

great christmas holidays.

I have taken some time to learn further on openhab2, defining sitemaps, things, items in files.

So I defined what I had already working kind of that in a default.things (gtwy seems to define the ThingID?):

Thing ntp:ntp:local "Lokale Zeit" @ "OPENHAB2" [ hostname="", refreshInterval=60, refreshNtp=30 ]

Bridge enocean:bridge:gtwy "EnOcean Gateway" @ "OPENHAB2" [ path="/dev/ttyAMA0" ] {
   Thing classicDevice flur_og_vswitch "Flur OG VSwitch (EEP F6-02-02)" @ "OPENHAB2" [
      receivingEEPId="F6_02_02" ]
   Thing classicDevice flur_eg_vswitch "Flur EG VSwitch (EEP F6-02-02)" @ "OPENHAB2" [
      receivingEEPId="F6_02_02" ]


DateTime Heute "[%1$tA, %1$td.%1$tm.%1$tY %1$tH:%1$tM]" <time> { channel="ntp:ntp:local:dateTime" }

//Virtuelle Schalter
Switch VSwitch_Flur_EG_Licht "VLicht Flur EG" <light> (EG_Flur) {
Switch VSwitch_Flur_OG_Licht "VLicht Flur OG" <light> (OG_Flur) {

So, these things work now like before creating them in PaperUI.

But, it sometime takes a while until the eoncean gets back online, e.g. after edited one of the things/irems files or just restarted openhab2 service. In the log there can be read something like this:

If I touch one of the files it might help to push things and get the bridge online immediately …

Offtopic: I am also looking for some documentation about the notation for DateTime. The linked help in openhab wiki for ntp does match with what I copied from the examples … and, does the NTP Binding update system time of the openhab2 hosts?


(Thorsten Oest) #468

Hi Daniel (@fruggy83),

unfortunately I have another problem. Some time ago you have adapted your code for the sensors F(A)BH63 (A5_08_01_FXBH). At least one of my two sensors worked under openocen. But now I don’t get any signal and also nothing appears in the log. My definiton is:

Thing enocean:lightTemperatureOccupancySensor:37182ce4:01028980 "Sensor - Bewegung - Thorsten" (enocean:bridge:37182ce4) @ "Thorsten" [enoceanId="01028980", receivingEEPId="A5_08_01_FXBH"]
Thing enocean:lightTemperatureOccupancySensor:37182ce4:008611A2 "Sensor - Bewegung - Veranda" (enocean:bridge:37182ce4) @ "Veranda" [enoceanId="008611A2", receivingEEPId="A5_08_01_FXBH"]

Number iHelligkeit_Thorsten "Helligkeit - Thorsten [%.0f Lux]" <sun> (gIllumination) {channel="enocean:lightTemperatureOccupancySensor:37182ce4:01028980:illumination"}
Number iHelligkeit_Veranda "Helligkeit - Veranda [%.0f Lux]" <sun> (gIllumination) {channel="enocean:lightTemperatureOccupancySensor:37182ce4:008611A2:illumination"}
Switch iBewegung_Thorsten "Bewegung - Thorsten" <motion> (gMotion) {channel="enocean:lightTemperatureOccupancySensor:37182ce4:01028980:motionDetection"}
Switch iBewegung_Veranda "Bewegung - Veranda" <motion> (gMotion) {channel="enocean:lightTemperatureOccupancySensor:37182ce4:008611A2:motionDetection"}

In PaperUI I see both things online and linked to the items.

The signal of the sensors as they are recorded in my FHEM log are:

2018.12.24 13:28:38 5: TCM EUL RAW: 55000A0701EBA59693000F010289800003FFFFFFFF5B0045
2018.12.24 13:28:38 5: EUL dispatch EnOcean:1:A5:9693000F:01028980:00:03FFFFFFFF5B00
2018.12.24 13:28:38 4: EnOcean received via EUL: EnOcean:1:A5:9693000F:01028980:00:03FFFFFFFF5B00
2018.12.24 13:28:38 4: EnOcean EnO_sensor_01028980 received PacketType: 1 RORG: A5 DATA: 9693000F SenderID: 01028980 STATUS: 00
2018.12.24 13:28:38 5: Triggering EnO_sensor_01028980 (3 changes)
2018.12.24 13:28:38 5: Starting notify loop for EnO_sensor_01028980, first event M: off E: 1180

2018.08.04 00:08:32 5: TCM EUL RAW: 55000A0701EBA57E00000F008611A20002FFFFFFFF5F0085
2018.08.04 00:08:32 5: EUL dispatch EnOcean:1:A5:7E00000F:008611A2:00:02FFFFFFFF5F00
2018.08.04 00:08:32 4: EnOcean received via EUL: EnOcean:1:A5:7E00000F:008611A2:00:02FFFFFFFF5F00
2018.08.04 00:08:32 4: EnOcean EnO_sensor_008611A2 received PacketType: 1 RORG: A5 DATA: 7E00000F SenderID: 008611A2 STATUS: 00
2018.08.04 00:08:32 5: Triggering EnO_sensor_008611A2 (3 changes)
2018.08.04 00:08:32 5: Starting notify loop for EnO_sensor_008611A2, first event M: off E: 0

Do you have any idea what could be wrong.

Best regards,

(Sepp99) #469

Hi Daniel (@fruggy83),
for the moment everything works as expected :wink:
Do you know how the binding update via the marketplace is done? Do I have to trigger something, once you provide a new version?
BTW: Thanks for all you work on this binding!

Best regards,

(Thorsten Oest) #470

Hi Daniel (@fruggy83),

I hope I did not waste your time with the issue. It was my fault. It was because of the reception strength of my EnoceanPi which is worse compared to my USB Stick which I use for FHEM.

Best regards,

(Thorsten Oest) #471

Hi Daniel (@fruggy83),

just one thing I observed. I am using the following generic thing

Thing enocean:genericThing:37182ce4:FFC75D0D "Aktor - Licht - Feld3_17_1" (enocean:bridge:37182ce4) @ "Garten" [enoceanId="FFC75D0D", senderIdOffset=13,sendingEEPId="A5_FF_FF", receivingEEPId="A5_FF_FF", broadcastMessages=true] {Channels: Type genericSwitch:genericSwitch [transformationType="MAP", transformationFunction=""]}
Switch iLicht_Gartenlampe_Walnuss "Licht - Gartenlampe Walnuß" <light> (gEveningLight) {channel="enocean:genericThing:37182ce4:FFC75D0D:genericSwitch",autoupdate="true"}

with a mapping file

// syntax for EEP A5_FF_FF:

which works fine for me. However I get a warning in the log

2018-12-28 10:21:57.697 [WARN ] [rm.AbstractFileTransformationService] - Could not transform 'genericSwitch|FFFF000F' with the file '' : Target value not found in map for 'genericSwitch|FFFF000F'

which disappears when I add

// syntax for EEP F6_FF_FF 

in the mapping file. Should I get the warning? Apart from the warning everything works fine for me.

Best regards,

(Frank) #472

Hi Daniel (@fruggy83) and all,

I don’t get this “Peha 452 FU-EBI o.T.” working.

First of all, that “Easyclick Gateway Binding Application Note” doesn’t meet it’s behaviour. The actuator doesn’t act like described in that PDF, albeit it should apply to that model. I always end in “Programming Mode” … both LEDs blink green.

So, I used “normal” teach in for each channel, while a running enocean discovery with OH2. In log I see the UTE requests and also that OH2 is answering those. This happens within “a second”, so enabling teach in on the actuator for one channel, blinking red led, solid red led, no led. Then I have a new devices in inbox.

From here it doesn’t make any difference, if I define this channels as a thing in PaperUI or in my things file, parameters and behaviour is the same. These two things are polled by OH2, I get the correct status of my switches, but cannot switch them from OH2.

Trying to switch I see outgoing payload and obviuously an answer RESPONSE with code RET_OK payload 00 received, but actuator doesn’t do anything … also I do see regular polling channels in log, followed by some enocean payload and RET_OK.

Definition looks like that, default.things:

   Thing measurementSwitch esszimmer_eg_vswitch0 "Esszimmer EG VSwitch Tisch (EEP D2_01_08)" @ "OPENHAB2" [
      pollingInterval=300 ]
   Thing measurementSwitch esszimmer_eg_vswitch1 "Esszimmer EG VSwitch Wand (EEP D2_01_08)" @ "OPENHAB2" [
      pollingInterval=300 ]


Switch VSwitch_Esszimmer_EG_Tisch_Licht "VLicht Esszimmer EG Tisch" <light> (EG_Esszimmer) {
Switch VSwitch_Esszimmer_EG_Wand_Licht "VLicht Esszimmer EG Wand" <light> (EG_Esszimmer) {

Any advice welcome :slight_smile:

Thanks so far.


PS.: I found the trailing EnoceanID from one of the former posts. I forgot, one of my single channel actuators is also an EBI, exactly a “Peha 451 FU-EBI o.T.”. But same issue, no gateway “teach in” modus and with normal teach in I just get the VLD part teached in and not the 4BS part. So no switching from OH2 possible …

(Tino) #473

Hi Daniel (@fruggy), did you received the log via email?
Thanks, Tino

(Rainer Jahn) #474

Hello all,
I give OpenHab a new chance because of the new EnOcean binding.
Thank you very much for this work!!

Can you tell me what is the detailed meaning of the RS485 option of this binding?

My understanding/hope is to be able to use a direct (cable) connection to the Eltako 14 - RS485 Bus.
Sending and receiving EnOcean radio telegrams over FGW14. Is this the right understanding?
Which baud rate is used (setting on FGW14)?

My installation is using self made light switches that are sending ERP telegrams over a second FGW14 to the actuators (FSB14/FSR14/FUD14/F4HK14).
For the moment no information of the sensors is available on the wireless interface.
Because of this, a cable connected solution would e great!

Thank you again!

(Thorsten Oest) #475

Hi Daniel (@fruggy83 ),

I have a push button and tried to integrate it with the definition

Thing enocean:pushButton:37182ce4:0082EB6D "Schalter - Mobil" (enocean:bridge:37182ce4) @ "Schlafzimmer" [enoceanId="0082EB6D", receivingEEPId="F6_01_01"]
Switch iSchalter_Schlafzimmer "Schalter - Schlafzimmer" <switch> (gSwitch) {channel="enocean:pushButton:37182ce4:0082EB6D:pushButton"}

In PaperUI it is marked online but when I push the button I get the following error in the log

2018-12-30 17:36:30.271 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-30 17:36:30.275 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
2018-12-30 17:36:30.283 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 0082EB6D payload F6100082EB6D2001FFFFFFFF5200 received
2018-12-30 17:36:30.289 [ERROR] [ding.enocean.internal.eep.EEPFactory] - Cannot instantiate EEP F6-01-01: null
2018-12-30 17:36:30.292 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - java.lang.reflect.InvocationTargetException
2018-12-30 17:36:30.575 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-30 17:36:30.580 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
2018-12-30 17:36:30.586 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for 0082EB6D payload F6000082EB6D2001FFFFFFFF5000 received
2018-12-30 17:36:30.592 [ERROR] [ding.enocean.internal.eep.EEPFactory] - Cannot instantiate EEP F6-01-01: null
2018-12-30 17:36:30.596 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - java.lang.reflect.InvocationTargetException

Do you have any idea what this means?

Best regards,

(Martin) #476

Good evening everybody,

I upgraded now to 2.5 snapshot of the binding running 2.4 OH and facing the issue to change all my item and config files related to the binding.

I achieved my mechanical handle to run. First issue I am facing to is that I don’t get a standard light (actuator + switch) running.


Bridge enocean:bridge:FT1M2J09 "EnOcean GatewaY" [ path="/dev/ttyUSB0" ] 
   Thing mechanicalHandle fk01 "Fensterkontakt" @ "Schlafzimmer" [ enoceanId="ABEFCDGH", receivingEEPId="F6_10_00" ]
   Thing classicDevice cd01 "Licht Leseecke" @ "Leseecke" [ 
      Type virtualSwitchA             : virtualSwitchA              [duration=300, switchMode="rockerSwitch"]
      Type rockerswitchListenerSwitch : Listener1 "Schalter Leseecke links"  [enoceanId="ABCDEFGH", channel="channelB", switchMode="rockerSwitch"]


Switch Leseecke "Leseecke"  {

Now my questions:

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:

old .item:

Switch Licht_Virtual_Rocker_Leseecke "Leseecke" <lightbulb> (Alle_Lichter_WZ) ["Lighting"]{channel="openocean:virtualRockerSwitch:6a9999c8:virtualRockerswitchA"}

Where can I set the existing EnOceanId ID (from the old virtual rocker) for the new virtual Rocker that I can use it again?

Second: What is the logic behind the listener? By now I get a signal for a dummy switch in my sitemap, but it is the opposite of DIR1 and DIR2. By switching the light to ON with DIR2, the sitemap status change to off and with DIR1 (OFF) the sitemap status of the switch changes to ON, which is confusing me a bit. Any hint where I can set the correct DIR?

I hope someone faced the same issue and solved it… :slight_smile:

(Torsten Sterntaler) #477

Hi community,
I recently bought an Enocean Pi (running on RPi 3 / openHAB2). So as of now, there’s not a single actor available at home. My intention was to make sure first the gateway is running.

dwc_otg.lpm_enable=0 console=serial0,115200 root=PARTUUID=8a390473-02 rootfstype=ext4 elevator=deadline rootwait quiet splash plymouth.ignore-serial-consoles


pi@raspberrypi:~ $ dmesg |grep tty
[ 0.000000] Kernel command line: 8250.nr_uarts=1 bcm2708_fb.fbwidth=800 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 root=PARTUUID=8a390473-02 rootfstype=ext4 elevator=deadline rootwait quiet splash plymouth.ignore-serial-consoles
[ 0.669650] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
[ 0.669696] console [ttyAMA0] enabled
[ 4.433993] usb 1-1.3: ch341-uart converter now attached to ttyUSB0


Bridge enocean:bridge:gtwy "EnOcean Gateway" [ path="/dev/ttyAMA0" ] {


2018-12-31 01:11:31.497 [hingStatusInfoChangedEvent] - ‘enocean:bridge:gtwy’ changed from OFFLINE (CONFIGURATION_PENDING): opening serial port… to OFFLINE (CONFIGURATION_PENDING): starting rx thread…
2018-12-31 01:11:31.504 [hingStatusInfoChangedEvent] - ‘enocean:bridge:gtwy’ changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread… to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id…

I’m having a Jeelink running. So i cannot deactivate uart/serial. Is that a show stopper? Already tried to set log level for binding to trace, but nothing happens:
/var/lib/openhab2/etc/org.ops4j.pax.logging.cfg => log:set TRACE org.openhab.binding.enocean

Any suggestions?

(Daniel Weber) #478

Hello everybody,

I am back from my family roundtrip and will try to answer your questions now. Please post your question again, if I should miss a question.

Best regards and a happy new year!

(Daniel Weber) #479

Hi Frank (@fnu),

you default.items file contains an error in the channel definition. A channel link for a measurementSwitch should look like enocean:measurementSwitch:gtwy:esszimmer_eg_vswitch0:generalSwitchor enocean:measurementSwitch:gtwy:esszimmer_eg_vswitch0:dimmer. You missed the last part of the channel Id.You can always click on the icon next to the channel name to copy the channel Id into your clipboard. So first of all fix your item file. Try the generalSwitch channel first, if it does not work, try the dimmer channel. If this still does not work, you should post the log containing the messages when you switching the item in openhab and when you switch the device with your physical rockers.

I just get the VLD part teached in and not the 4BS part

You PEHA devices use VLD and 4BS status messages with different EnoceanIds. As these messages should contains the same content, you can ignore the 4BS part.

But, it sometime takes a while until the eoncean gets back online

I also see such a behaviour in my logs. But did not looked into it as the EnOceanSerialTransceiver always initialized. Maybe the first try is to fast. It sends the base id request before the receiving thread is running and therefore missed the answer from the gateway.

Best regards

(Frank) #480

Yes, that’s right, it was wrong in my post, I corrected it in real life (and now in post) … :slight_smile: … but still doesn’t work … :frowning:

If I look in the debug enabled log, it looks like as there are too less messages send out to the Peha EBI. If I switch one of the unidirectional Peha ones, I see always two payploads been sent, with the EBI one just one. Unlike the Nodon actuators, there’s no payload answer from the Peha EBI ones …

In the meantime I replaced the 2-channel Peha EBI with a Nodon 2-channel, what worked in OH2 with your openocean 2.5.0-SNAPSHOT within a couple of minutes …

I still have the 1-channel Peha EBI in business for further investigations …

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


(Daniel Weber) #481

Hi Thorsten (@ThAO),

In PaperUI it is marked online but when I push the button I get the following error in the log

As I do not own a push button, I could not test it by my own. However I already found the bug and will fix it soon.

Should I get the warning?

Without these two lines, you can only send messages to the Aktor but you are not able to transform incoming messages. If you do not need this inbound messages, you can ignore these warnings.

I hope I did not waste your time with the issue

No problem. I had similar problems with my outdoor temperature sensor. Dev machine (USB300) receives the messages flawlessly, my server (EnOceanPi) not. But why are you using FHEM and openHAB in parallel? Do not you trust my binding :wink:

Best regards