New openHab2 EnOcean binding

Hello Daniel,

you write in the Enocean Readme " EnOceanPi has to be added manually to openHAB." Is there any proven master way to add.
Your Tutorial or Openocean was great and install was quite easy. Worked several month very fine.
Yesterday I tried a clean install and nothing worked.

thx for Info.

Hi all,

I’ve been using openocean-2.4.0 plugin for a while on a openhab 2.3 installation without problems. Even my PSC 234 plugs worked (thanks to @fruggy83 :wink: ). Yesterday I’ve upgraded my installation to 2.4 stable and the new EnOcean plugin and got stuck with a few problems. I’ve tried doing the necessary changes according to the “OpenHab Enocean Binding” page. Temp/Hum sensors and RockerSwitches are working normally.

Problem 1:
I only get the plugin working, if I add the bridge and things manually via the web interface. If I use a things config file I end up with UNINITIALIZED (HANDLER_CONFIGURATION_PENDING). I’ve noticed one difference in the item naming:

openhab> things list | grep enocean
enocean:contact:927aecfb (Type=Thing, Status=ONLINE, Label=BAD_REED1, Bridge=enocean:bridge:FTWYOPB8)
enocean:temperatureSensor:46ba5106 (Type=Thing, Status=ONLINE, Label=GZ_SUED_TEMP1, Bridge=enocean:bridge:FTWYOPB8)
enocean:rockerSwitch:24cc60e3 (Type=Thing, Status=ONLINE, Label=WZ_TASTER1, Bridge=enocean:bridge:FTWYOPB8)
enocean:temperatureSensor:FTWYOPB8:t01 (Type=Thing, Status=UNINITIALIZED (HANDLER_CONFIGURATION_PENDING), Label=DG_TEMP1, Bridge=enocean:bridge:FTWYOPB8)
enocean:contact:FTWYOPB8:c01 (Type=Thing, Status=UNINITIALIZED (HANDLER_CONFIGURATION_PENDING), Label=DG_REED1, Bridge=enocean:bridge:FTWYOPB8)

Config file: enocean:temperatureSensor:FTWYOPB8:t01
Manual setup: enocean:contact:927aecfb
There is always the bridge name in the UID

enocean.things

Bridge enocean:bridge:FTWYOPB8 "OpenOcean Gateway (USB300)" [ path="/dev/ttyUSB1" ] {
        Thing contact c01 "DG_REED1" @ "Haus" [ enoceanID="05115AAB", receivingEEPId="D5_00_01" ]
        Thing temperatureSensor t01 "DG_TEMP1" @ "Haus" [ enoceanID="0181B82F", receivingEEPId="A5_02_05" ]
}

Problem 2:
My NodOn contacts (SDO-2-1-05) stopped working. I get values of the channel receivingState but no item change of the contact channel.

Items:

Contact DG_REED1            "Fenster 1 [MAP(de.map):%s]"                <window>        (G_DG,G_FENSTER_ALLE,G_FENSTER_ALARM)   { channel="enocean:contact:5ad7031a:contact" }
String DG_REED1_STATE       "Status Fenster 1 [%s]"                     <window>        (G_DG,G_ENOCEAN_UPDATE)                 { channel="enocean:contact:5ad7031a:receivingState" }

Contact:
2018-12-19 08:51:07.369 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 08:51:07.372 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
2018-12-19 08:51:07.386 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _1BS for 05115AAB payload D50805115AAB0101FFFFFFFF5500 received
2018-12-19 08:51:07.389 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D50805115AAB01 for 05115AAB received
2018-12-19 08:51:09.592 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 08:51:09.601 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
2018-12-19 08:51:09.603 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _1BS for 05115AAB payload D50905115AAB0101FFFFFFFF5500 received
2018-12-19 08:51:09.608 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload D50905115AAB01 for 05115AAB received

Problem 3:

PSC plugs also stopped working. What is the right configuration for a PSC234?
Something like this?

Configuration parameters:
        enoceanId : 019459D1
        senderIdOffset : 1
        pollingInterval : 60
        suppressRepeating : false
        sendingEEPId : D2_01_09_PERMUNDO
        broadcastMessages : false
        receivingEEPId : [D2_01_09_PERMUNDO]

Maybe someone has an idea what I’m doing wrong and could point me in the right directon.
Thanks in advance
Christoph


Current state of the installation:

openhab> feature:list | grep ocean
openhab-binding-enocean1                    x 1.13.0           x          x Uninstalled x openhab-addons-legacy-2.4.0 x EnOcean Binding
openhab-binding-enocean                     x 2.4.0            x x        x Started     x openhab-addons-2.4.0        x EnOcean Binding
openhab-binding-oceanic                     x 2.4.0            x          x Uninstalled x openhab-addons-2.4.0        x Oceanic Binding


openhab> feature:list | grep serial
esh.tp-serial-javacomm                      x 0.10.0.oh240     x          x Uninstalled x distro-2.4.0                x
esh.tp-serial-rxtx                          x 0.10.0.oh240     x          x Started     x distro-2.4.0                x
esh-config-serial                           x 0.10.0.oh240     x          x Started     x distro-2.4.0                x
esh-config-discovery-usbserial              x 0.10.0.oh240     x          x Started     x distro-2.4.0                x
esh-io-transport-serial                     x 0.10.0.oh240     x          x Started     x distro-2.4.0                x
esh-io-transport-serial-javacomm            x 0.10.0.oh240     x          x Uninstalled x distro-2.4.0                x
esh-io-transport-serial-rxtx                x 0.10.0.oh240     x          x Started     x distro-2.4.0                x
esh-io-transport-serial-rfc2217             x 0.10.0.oh240     x          x Started     x distro-2.4.0                x
openhab-transport-serial                    x 2.4.0            x          x Started     x distro-2.4.0                x Serial Transport
esh-binding-serialbutton                    x 0.10.0.oh240     x          x Uninstalled x openhab-addons-2.4.0        x
openhab-binding-serialbutton                x 2.4.0            x          x Uninstalled x openhab-addons-2.4.0        x Serial Button Binding
openhab-binding-lgtvserial                  x 2.4.0            x          x Uninstalled x openhab-addons-2.4.0        x LG TV Serial Binding
openhab-binding-serial1                     x 1.13.0           x          x Uninstalled x openhab-addons-2.4.0        x Serial Binding

Hi Thorsten (@ThAO),

your steps are correct. I would suspect your configuration too. Do you have mentioned any profiles in your current configuration? Next to your config changes, you also have to add an extra enoceanId property to your things. If I find time tonigt I will post a migration guide openocean => enocean.

Best regards
Daniel

Hi Tino (@flynux),

which version of openHAB are you running? Currently released 2.4 version or snapshot version 2.5. The 2.4 version unfortunately contains a bug in the classicDevice which prevents sending pressed messages from your classicDevices. You could use the snapshot version of openHAB or the precompiled jar from the issue30 branch of my binding. I will also update the marketplace version of this binding today.

Sorry for your problems.

Best regards
Daniel

Hello @cmowgli,

you add the EnOceanPI to openHAB in the same way as you did in the Openocean binding. I just wanted to say, that it cannot be autodetected as the USB300 gateway.

If you had already running the Openocean binding. You just have to change certain things in your thing and item files. I will try to post a migration guide today.

Best regards
Daniel

Thanks Daniel, indeed I am using 2.4.0. I will try the snapshot version and wit for your new binding version.
Thanks a lot! is it planned to support FMS61NP as an actuator natively in the future?
Thanks, Tino

Hi Tino (@flynux),

I really would like to support the FMS61NP as an actuator natively. However I could not found any documentation that it supports the A5-38 EEP or any other “Switching EEP”. Do you have more information about this? I just found out, that the FMS61NP sends a Rocker Switch message with its enoceanId whenever it gets switched. So you are able to use a classicDevice with just a single RockerSwitch listener. No need to define a listener for each of your physical switches which can switch your FMS61NP.

Best regards
Daniel

Same for me, I could not find any information on the EEP for the FMS61NP. It send back his enoceanId when I press the buttons on my FT55 (Rocker Switch).
I will try with the ClassicDevice again and a Listener on it.
Thanks, Tino

Hi Daniel, after upgrading to 2.5 snapshot the classic device is sending data :slight_smile:

But I still struggle with all the different Ids. The physical device ID from FMS61NP is 05127F5B. I get this id back when I press the physical FT55 Rocker Switch and it is also labeled at the back of the physical device.

When I create a Classic Device, should I replace the ThingID with 05127F5B? Or where can I “link” the physical device with the classic device? Can I do everything within PaperUI or do I need to define it in config files?

Many Thanks, Tino

Hi Tino (@flynux),

great to hear, that it work now with the snapshot version.

Regarding the Ids. The ThingId does not matter any longer, you can define the ThingId like you want now. To link a Thing to the device messages, you have to use the enoceanId property now. Therefore it is possible to define more than one thing which listens to the messages of a device. Currently the only exception for this is the ClassicDevice. As this thing just combines an old virtualRockerSwitch and one or more rockerSwitches, it does not own an enoceanId. You have to use the listener channels now, to bind the classicDevice thing to a device.

Therefore your classicDevice has to look like this:

Thing classicDevice cd01 "FMS61NP " [ 
        senderIdOffset=XXX,                    // set this to the right id
        sendingEEPId="F6_02_01", 
        broadcastMessages=true, 
        receivingEEPId="F6_02_01",
        suppressRepeating=false 
   ] {
        Type virtualSwitchA             : virtualSwitchA              [duration=300, switchMode="rockerSwitch"]
        Type rockerswitchListenerSwitch : FMS61NPListener "FMS61NP"  [enoceanId="05127F5B", channel="channelA", switchMode="rockerSwitch"]
   }

As you can see, the listener gets the device Id now.

Can I do everything within PaperUI or do I need to define it in config files?

It is up to you. You can only use PaperUI or define everything in config files. However I would always recommend to use config files.

Best regards
Daniel

Hi Daniel, Thanks again. I defined my thing as you describes above within PaperUI.

On the Channel virtualSwitrch A and the rockerswitchListenerSwitch I created and Linked a Switch, but when I pressed the Switch Button in HABPanel I get the following output:

2018-12-19 16:10:30.553 [ome.event.ItemCommandEvent] - Item ‘FMS61NP_CD_RS_A_Upper_Left’ received command ON
2018-12-19 16:10:30.556 [nt.ItemStatePredictedEvent] - FMS61NP_CD_RS_A_Upper_Left predicted to become ON
2018-12-19 16:10:30.567 [vent.ItemStateChangedEvent] - FMS61NP_CD_RS_A_Upper_Left changed from NULL to ON
==> /var/log/openhab2/openhab.log <==
2018-12-19 16:10:30.565 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2018-12-19 16:10:30.568 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F630FF8913013001FFFFFFFFFF00
2018-12-19 16:10:30.582 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 16:10:30.582 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 1 optional length 0 packet type 2
2018-12-19 16:10:30.583 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2018-12-19 16:10:30.583 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Response without listener
2018-12-19 16:10:30.870 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2018-12-19 16:10:30.870 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600FF8913012001FFFFFFFFFF00
2018-12-19 16:10:30.882 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 16:10:30.882 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 1 optional length 0 packet type 2
2018-12-19 16:10:30.883 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2018-12-19 16:10:30.883 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Response without listener

The light is not switching on :frowning:

I also tried with a thing config file but with different problems.

Thanks, Tino

Hi Tino (@flynux),

from your log , I can see, that the PRESSED and RELEASED messages are send now. So the question is, did you already paired (teached in) your openhab thing with your FMS61NP? You are using the senderIdOffset 1 for your thing now.

Sorry if I ask it again or you already mentioned it, but did you formerly used the old openocean binding with this device or fhem?

Best regards
Daniel

Hi Daniel, I did not know that I had to teach-in the FMS61NP.

So I changed the switches on the FMS61NP to UT1 and LRN, so that it is in learning mode (teach-in). Then I had to press the Listener Item Switch and the virtualSwitchA button on the HABPanel. And know it is working :slight_smile: Light is on :slight_smile:

It wasn’t enough to press the virtualSwitchA, but I guess I can solve this with a rule.

To your other questions:
The senderIdOffset is 1, when I treid to config the thing manually in the thing file. I never tried the old openocean binding and fhem.

Many Thanks again!!!
Cheers, Tino

Daniel, one more. I tried to teach-in ChannelB, but this is whithin PaperUI a String and not a Switch. So teach-in is not working.

Do I need to create a new classic device for each of the 4 buttons on FT55? Do I need to create a new Listener on each classic device?

Thanks, Tino

Hi,

OK Thx.

Best regards
Carsten

Hi all,

as promised, here is the migration guide(hints) for all the openocean users who want to change to the new official binding or the snapshot version from my repo:

  • Binding Id changed from openocean to enocen => replace all occurances of openocean with enocean
  • Thing Id has no longer to be set to the enoceanId of the device, instead each thing has a parameter enoceanId which takes this id
  • Enocean bridge:
    • combined serialbridge and tcpbridge into bridge thing
    • renamed repeater channel to repeaterMode
    • changed parameter port to path, can take rfc2217 path now for ser2net connections
    • renamed nextDeviceId parameter to nextSenderId
  • Renamed contactSwitch thing to contact
  • measurementSwitch
    • renamed eepId parameter to sendingEEPId
    • added receivingEEPId parameter (more than one value possible)
  • Renamed humidityTemperatureSensor to temperatureHumiditySensor
  • Replaced virtualRockerSwitch with classicDevice
    • combines the virtualRockerSwitch (sending part) with one or more rockerSwitches (receiving part)
    • does not use profiles any longer => specific channels/listeners for switch or rollershutter devices
  • replaced lightSwitch channel with generalSwitch
  • Moved rockerswitch-to-play-pause profile to esh core (system)

I hope I have not forget anything.

Best regards
Daniel

Hi all,

I have just updated the openocean version.

Changes:

  • D2_01 switches can be switch to ON
  • rfc2217 connections can be used
  • classicDevices can switch ON/OFF
  • Teach in messages are no longer handled by things and do not mess up item states (thanks to @dominikkv)
  • Support for Eltako TF-FGB (or EEP A5-14-09, thanks to @dominikkv)

Although it is a 2.5.0 snapshot binding now, it can still be used withe current 2.4.0 stable openHAB version. You just have to feature:install openhab-transport-serial in the karaf console after adding the precompiled jar into your addons folder. Alternatively you can also use the marketplace to install the current version. If you want to get debug logs you have to use log:set debug org.openhab.binding.enocean

Best regards
Daniel

Hi @fruggy83,

thanks for your help and also again thanks for the help with my “legacy” rocker switches,
although i have a strange Problem with the binding currently.

After a restart my Dimmer things no longer update properly.
I spend some time debugging the issue and here is what i found so far:

I have:

  • Fresh Install of Openhab 2.4 (openhabian, empty config)
  • I Create serial Bridge
  • I add the Dimmer
  • Everything working Properly, I can dimm via OpenHab and the State is properly updated when i dimm from the wall switches as well
  • Restart Openhab service , the below log errors appear
  • I can control the dimmer from OpenHab but when i control it from the wall switch the state is not updated
  • I remove and re-create bridge and dimmer -> Working until restart

The behaviour is obsserverd with the 2.4 release and the issue branch you provided for me.

Logs on startup:

2018-12-19 22:33:26.800 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyUSB0
2018-12-19 22:33:26.808 [DEBUG] [org.openhab.binding.enocean         ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=351, service.bundleid=226, service.scope=singleton} - org.openhab.binding.enocean

==> /var/log/openhab2/events.log <==
2018-12-19 22:33:26.872 [hingStatusInfoChangedEvent] - 'enocean:centralCommand:050A7B7D' changed from UNINITIALIZED to INITIALIZING

==> /var/log/openhab2/openhab.log <==
2018-12-19 22:33:26.866 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - Initializing enocean base thing handler.
2018-12-19 22:33:26.889 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - initializeThing thing enocean:centralCommand:050A7B7D bridge status OFFLINE
2018-12-19 22:33:26.831 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - error during bridge init occured
java.io.IOException: Could not find a gateway on given path '/dev/ttyUSB0', 0 ports available.
	at org.openhab.binding.enocean.internal.transceiver.EnOceanSerialTransceiver.Initialize(EnOceanSerialTransceiver.java:54) ~[226:org.openhab.binding.enocean:2.4.0]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.initTransceiver(EnOceanBridgeHandler.java:197) [226:org.openhab.binding.enocean:2.4.0]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.access$2(EnOceanBridgeHandler.java:184) [226:org.openhab.binding.enocean:2.4.0]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler$4.run(EnOceanBridgeHandler.java:176) [226:org.openhab.binding.enocean:2.4.0]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

When I push the wall switch i see:

 2018-12-19 22:44:20.883 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
2018-12-19 22:44:20.895 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for FEFF4BE0 payload F600FEFF4BE02001FFFFFFFF5500 received
2018-12-19 22:44:21.965 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-19 22:44:21.969 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 10 optional length 7 packet type 1
2018-12-19 22:44:21.975 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for 050A7B7D payload A5025C0009050A7B7D0001FFFFFFFF5000 received
2018-12-19 22:44:21.979 [DEBUG] [rnal.handler.EnOceanBaseThingHandler] - ESP Packet payload A5025C0009050A7B7D00 for 050A7B7D received

Where B7D is my Dimmer Thing So the Packet is definitely received but somehow does not update
the associated item properly anymore.

As always greatfull for every tip you might have

Thanks

Martin

Hi Tino (@flynux),

in most cases you do not need to use the ChannelB. It is mainly intended for fhem users who want to save senderIds and have already teached in their devices. An enocean gateway supports (or can control) up to 127 devices (unlimited sensors). So do not worry about your senderIds :wink:

Do I need to create a new classic device for each of the 4 buttons on FT55?

It depends. For your FMS61NP you only need one listener, as you are directly listening to your FMS61NP answers. Other devices do not send such status messages back, in this case you have to listen to the FT55 switches and add a listener for each physical rocker switch which can switch your actuator.

Best regards
Daniel

Hi @flynux,

yes i got it working, i added a classic device with my sender ID and added a channel listening
for the return telegram and updating the state which i called a1 so my item is:

Switch   azDecke   "Arbeitszimmer"         <light>   (Office)  [ "Lighting" ]    {channel="enocean:classicDevice:01840526:virtualSwitchA", channel="enocean:classicDevice:01840526:a1"}

This lets me control my switches and get updates when they get switched externally as well.

Hope This helps

Martin