New openHab2 EnOcean binding

Hi Daniel (@fruggy83),

it starts to become a nightmare. Now, after multiple tome cleaning cache and restarting OH and installing features, I was able to see your addon WITH available things. But now, again after trying to install a gateway, I have exceptions … bbbbrrrrrrrrrrrrr

2018-12-15 18:40:10.872 [DEBUG] [org.openhab.binding.openocean       ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=474, service.bundleid=191, service.scope=singleton} - org.openhab.binding.openocean
2018-12-15 18:40:10.876 [DEBUG] [org.openhab.binding.openocean       ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=475, service.bundleid=191, service.scope=singleton} - org.openhab.binding.openocean
2018-12-15 18:40:10.881 [hingStatusInfoChangedEvent] - 'enocean:bridge:9d459b35' changed from UNINITIALIZED to INITIALIZING
2018-12-15 18:40:10.882 [hingStatusInfoChangedEvent] - 'enocean:bridge:9d459b35' changed from INITIALIZING to OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway...
2018-12-15 18:40:10.892 [hingStatusInfoChangedEvent] - 'enocean:bridge:9d459b35' changed from OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway... to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2018-12-15 18:40:10.882 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - error during bridge init occured
org.eclipse.smarthome.io.transport.serial.UnsupportedCommOperationException: gnu.io.UnsupportedCommOperationException
	at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:157) ~[?:?]
	at org.openhab.binding.enocean.internal.transceiver.EnOceanSerialTransceiver.Initialize(EnOceanSerialTransceiver.java:61) ~[191:org.openhab.binding.openocean:2.4.0.201812100952]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.initTransceiver(EnOceanBridgeHandler.java:197) [191:org.openhab.binding.openocean:2.4.0.201812100952]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.access$2(EnOceanBridgeHandler.java:184) [191:org.openhab.binding.openocean:2.4.0.201812100952]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler$4.run(EnOceanBridgeHandler.java:176) [191:org.openhab.binding.openocean:2.4.0.201812100952]
	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) [?:?]
Caused by: gnu.io.UnsupportedCommOperationException
	at gnu.io.rfc2217.TelnetSerialPort.enableReceiveThreshold(TelnetSerialPort.java:948) ~[?:?]
	at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:155) ~[?:?]
	... 11 more

Best regards,
Ralf

Hi Daniel (@fruggy83),

it was nice to hear that you got your binding in an official relase. It tried to use it (deinstalled the openenocean binding first) but got errors like this

2018-12-16 13:07:01.718 [ERROR] [org.openhab.binding.enocean         ] - bundle org.openhab.binding.enocean:2.4.0.201812151803 (205)[org.openhab.binding.enocean.internal.profiles.EnOceanProfileFactory(14)] : Could not load implementation object class org.openhab.binding.enocean.internal.profiles.EnOceanProfileFactory
java.lang.ClassNotFoundException: org.openhab.binding.enocean.internal.profiles.EnOceanProfileFactory cannot be found by org.openhab.binding.enocean_2.4.0.201812151803

Do you have any idea if this could be the reason that I did not get it running? I have tried the last stable openHAB version and the newest version.

Thorsten

Hi Thorsten (@ThAO),

nice to hear you again. You should definitely get this error as I am no longer using profiles in my binding. The question is, why is openHAB trying to get this EnOceanProfileFactory? How did you installed the new binding?

Best regards
Daniel

Hi Daniel (@fruggy83),

I did the following

  • upgrade openhab to the newest version
  • unistalled openocean with bundle:uninstall <ID>
  • remove the openocean jar-File from the add-on directory
  • restart openhab
  • install the enocean binding

I have used the same configuration files just changing “openocean” to “enocean” and “genericLightSwitch” to “genericSwitch”. In addion I added the bridge gain manually.

Is it due to my old configuration files? Your examples look a bit different now.

Thorsten

p.s.: I was “absent” because I set up an irrigation system which is perfectly running with you binding using FAM14/FSR14 components.

Hi Ralf (@shotte),

Bugfix got into the official release today. So reverse everything and switch back to stable :wink:

Best regards
Daniel

Hi Martin, did you get it working?
I have a similar problem using FMS61NP and FT55.
The only thing I get working ist, that when I press a button on the FT55 it change the status of my RockerSwitch.
But I can’t update it from the RockerSwitch. I tried also a Classic Device and an Actuator (EPP A5-38). But nothing worked.
Can you share your definitions?
Many Thanks!

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