New openHab2 EnOcean binding

Hi Daniel @fruggy83,

I initially made the installation and the update via your repo.
I have now decided to use the official binding. Unfortunately I do not know exactly where I can install this. In Openhab itself, I only see the following choices: (EnOcean Binding binding-enocean1 - 1.12.0) that is not correct, right? The instructions from the old Readme had helped me a lot, but is now outdated. So how can I install the official version?

I’m still new to the Openhab and Enocean users. Please have the understanding that I ask such fundamental questions.
Best regards,
Dennis

Hi Dennis (@DennisAtHome),

I only see the following choices: (EnOcean Binding binding-enocean1 - 1.12.0) that is not correct, right?

Yes your are right. I forgot to say, that you need a snapshot build version of openHAB to be able to directly install the official version of this binding. I am running this snapshot/test builds for months now even on my productive system, so I just forget to mention it :man_facepalming:
So you have two options now:

  1. If you are using openhabian, you can easily switch to a snapshot build. Just use option 40 => 41 in openhabian-config.
  2. Wait until Dezember 17th. The release of openHAB 2.4 is planned for this day.

I’m still new to the Openhab and Enocean users. Please have the understanding that I ask such fundamental questions.

No problem. I guess without your questions other users would have the same problems.

Best regards
Daniel

Hi Daniel @fruggy83,

I just bought some ELTAKO TF-FGB window handle sensors which are currently not directly supported by your binding, cause the EEP is A5-14-09. I have the following information from the documentation:
Teach-In telegram: 0x50480D80
Data_byte0 = 0x08 --> window closed
0x0E --> window open
0x0A --> window tilted
Data_byte3 = battery power 0…250, 0…5V

Is it possible that you implement this quite in time? I was not able to get them working based on your instructions. Sorry.

Additionally I cannot activate your currently precompiled *.jar in my openhab 2.3 installation, which was possible a few weeks ago (I downloaded it November 26th). Are there meanwhile any changes made which corrupt functionality in openhab 2.3?

Thanks in advance,
Ralf

Hi Ralf (@shotte),

it should not be a big problem to implement this EEP A5-14-09. Fortunately Eltako describes the content of their enocean messages very good in detail. I wish this would do other manufacturers too.

As I synced my openocean repo with my work for the official binding, you have to use oh2.4 now. I am using the ESH serial port API now, which got implemented in one of the 2.4 snapshots. So I gues it has something to do with this change. However the release of OH 2.4 is coming (December, 17th).

Best regards
Daniel

Hi Daniel @fruggy83,

thank you for your quick response. I just updates to the current 2.4 snapshot but now I’m missing the OpenOcean TCP gateway, cause I’m using it in combination with ser2net which runs on my raspi. Is there any chance to get it back or are there alternatives to it?

Thank you,
Ralf

Hi Daniel (@fruggy83) again,

now I have another issue: I got the bridge from 2.4 snapshot version working (for a few minutes) using ser2net and socat based on thins article [Forwarding of serial and USB ports over the network to openHAB].
But just after editing the newly added thing (renaming the element), it turned into “offline - configuration pending”. On the server side I can see messages coming up the the related serial port after editing the thing but no more turning into “green/onlne”.

The log announces the following:

2018-12-13 02:52:51.436 [INFO ] [transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
2018-12-13 02:52:51.439 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id... to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2018-12-13 02:52:51.444 [INFO ] [transceiver.EnOceanSerialTransceiver] - EnOceanSerialTransceiver initialized
2018-12-13 02:52:51.447 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_PENDING): starting rx thread...
2018-12-13 02:52:51.448 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread... to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id...

The related HEX dump of the serial port after or while this message comes each minute up:

0000a60 ffff ffff 0041 556a 0500 0201 00db 8fff
0000a70 80e0 940a 0055 0021 2602 0200 000f 0200
0000a80 0906 0500 1f83 45c1 014f 4703 5441 5745

or

0000a90 5941 5443 4c52 0000 0000 8f00 0055 0105
0000aa0 db02 ff00 e08f 0a80 5594 2100 0200 0026
0000ab0 0f02 0000 0602 0009 8305 c11f 4f45 0301
0000ac0 4147 4554 4157 4359 5254 004c 0000 0000

I tried a lot: restarting openhab, clearing cache, restarting binding only, deleted and reinstalled thing… no chance. Now I’m at my end of all my knowledge and it’s late. Hope to hear quite quick from you with additional hints what to do.

Good night,
Ralf

Hi Ralf (@shotte),

the big advantage of using the ESH serial port API is that a serial connection over tcp is directly integrated. So I dropped the tcpbridge. You just have to ensure that the feature esh-io-transport-serial-rfc2217 is installed. In my setup this feature was already running. Next you have to specify the path in your bridge in the following way: rfc2217://a.b.c.d:e where a.b.c.d is the ip of ser2net server and d is the port. I had no problems in my tests doing it in this way.

Best regards
Daniel

Hi Daniel (@fruggy83) again,

I gave it a try but now get the error “port could not be initialized”. Must there also something be added to /etc/default/openhab2 like for activating serial ports?

Best regards,
Ralf

Hi Daniel(@fruggy83 ),

i have recently migrated from an older version to the m8 build of the plugin.
So i needed to re-create everything to switch from openocean: to enocean:
Which is fine the only problem is my FMS61NP which you originally helped me
to set up using virtual rocker switches here https://github.com/fruggy83/openocean/issues/7

For example i Have:

For the State:
openocean:rockerSwitch:36336014:018614c7:rockerswitchB
And for the switching:
openocean:virtualRockerSwitch:9268057a:virtualRockerswitchB

And the Actual Item looks like:
Switch baDecke “Badezimmer” (Bathroom) [ “Lighting” ] {channel=“openocean:virtualRockerSwitch:9268057a:virtualRockerswitchB” [profile=“openocean:rockerswitch-to-on-off”,switchMode=“rockerSwitch”, duration=250], channel=“openocean:rockerSwitch:36336014:018614c7:rockerswitchB” [profile=“openocean:rockerswitch-to-on-off”]}

So my question for this type of switch (sending rocker switch telegrams on state change), in the new binding
what should i use for those devices classicDevice or genericThing and more importantly how would a
config for the Classic device look like since it should not change state based on switch telegrams but
does actually send them itself ?

Thanks

Martin

Hi Daniel (@fruggy83),

now I got an exception. Maybe this is the reason for my problems?!?

2018-12-13 22:47:54.681 [DEBUG] [transceiver.EnOceanSerialTransceiver] - shutting down transceiver
2018-12-13 22:47:54.681 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2018-12-13 22:47:54.682 [DEBUG] [transceiver.EnOceanSerialTransceiver] - Closing serial port
2018-12-13 22:47:54.687 [INFO ] [transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
2018-12-13 22:47:54.691 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be initialized to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2018-12-13 22:47:54.693 [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) ~[237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.initTransceiver(EnOceanBridgeHandler.java:197) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.access$2(EnOceanBridgeHandler.java:184) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler$4.run(EnOceanBridgeHandler.java:176) [237:org.openhab.binding.enocean:2.4.0.201812121631]
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

2018-12-13 22:47:54.701 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be initialized 

Any hints?

Regards,
Ralf

Hi Martin (@martink2),

I implemented the ClassicDevice with your use case in mind. To ease things up, I combinded the old virtualRockerSwitch and the rockerSwitch into one device and dropped the profiles. In this way I can avoid the unnecessary double switch messages now too.

So your thing should look like

Thing classicDevice 9268057a "Badezimmer" @ "Bathroom" [ 
        senderIdOffset=??, 
        sendingEEPId="F6_02_01", 
        broadcastMessages=true, 
        receivingEEPId="F6_02_01",
        suppressRepeating=false 
   ] {
        Type virtualRockerswitchB       : virtualSwitch         [duration=300, switchMode="rockerSwitch"]
        Type rockerswitchListenerSwitch : Listener1 "Schalter"  [enoceanId="018614c7", channel="channelB", switchMode="rockerSwitch"]
   }

And your item

String virtualSwitcher "Switch" {channel="enocean:classicDevice:36336014:9268057a:virtualSwitch"}
Switch baDecke "Badezimmer" (Bathroorm) ["Lighting"] {channel="enocean:classicDevice:36336014:9268057a:Listener1"}

As you want to control your light through channelB of your “virtualRocker” you have to use the virtualRockerswitchB channel and a rule which converts the OnOff commands into Dir1Dir2 press commands. If you would use just channelA, you could avoid this stuff, use the virtualSwitchA channel and bind it together with the listener channel to the same item.

This is your rule

rule "Bathroom light switch"
when
    Item baDecke received command
then
    if(receivedCommand == ON) virtualSwitcher.sendCommand("DIR1_PRESSED")
    else virtualSwitcher.sendCommand("DIR2_PRESSED")
end

I did not test these snippets, hope this works.

Best regards
Daniel

Hi Ralf (@shotte),

really strange :thinking:. This seems to be a bug in the ESH serial API. The rfc2217 does not support ReceiveThresholds. However as I am just developing against an interface without knowing which type of serial port you are using (standard or rfc2217), I would suggest that the rfc2217 implementation just ignores this function call. I have tested it in an early stage of the API succesfully. I will check this tonight.

Best regards
Daniel

@fruggy83, thanks again for your fast help, i got it working with the rules as you suggested
above. When i tried to learn the A channel like you suggested i unfortunately was not
able to, i put my Aktor int LRN and pressed the switch button but unfortunately the
actor does not seem to process the telegram, i used config:

Switch   baDecke   "Badezimmer"         <light>   (Bathroom)  [ "Lighting" ]    {channel="enocean:classicDevice:17116df9:virtualSwitchA"}

And saw in the logs:

2018-12-14 15:11:42.319 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F650FF826D0A3001FFFFFFFFFF00
2018-12-14 15:11:42.333 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-14 15:11:42.336 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 1 optional length 0 packet type 2
2018-12-14 15:11:42.341 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2018-12-14 15:11:42.344 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Response without listener
2018-12-14 15:11:42.348 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-14 15:11:42.351 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 7 optional length 7 packet type 1
2018-12-14 15:11:42.366 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG RPS for FF826D0A payload F650FF826D0A3101FFFFFFFF4C00 received
2018-12-14 15:11:42.693 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Enqueue new send request with ESP3 type RADIO_ERP1 without callback
2018-12-14 15:11:42.696 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Sending data, type RADIO_ERP1, payload F600FF826D0A2001FFFFFFFFFF00
2018-12-14 15:11:42.716 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2018-12-14 15:11:42.721 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 1 optional length 0 packet type 2
2018-12-14 15:11:42.725 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RESPONSE with code RET_OK payload 00 received
2018-12-14 15:11:42.730 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Response without listener

Any Idea where i made a mistake here, i would really like to follow your suggestion and re-learn my actors on channel a?

Hi Daniel (@fruggy83),

perfect. If you need some support by, for instance, beta testing, please let me know.

Meanwhile I tested bit with my configurations:

  • using “rfc2217://192.168.8.222:7970” as device/port leads to a connection at ser2net:
2018/12/14 17:08:19 OPEN (::ffff:192.168.8.10:38238)
2018/12/14 17:08:19 tcp  ff fb 00 ff fd 00 ff fb  |........|
2018/12/14 17:08:19 tcp  03 ff fd 03 ff fb 2c     |......,|
2018/12/14 17:08:35 tcp  55 00 08 07 01 3d d2 03  |U....=..|
2018/12/14 17:08:35 tcp  1e ff 8f e0 81 00 01 05  |........|
2018/12/14 17:08:35 tcp  09 bf ec ff 00 7f        |......|
2018/12/14 17:08:35 term 55 00 01 00 02 65 00 00  |U....e..|

but exception mentioned above still remains in openHab

2018-12-14 17:08:19.267 [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) ~[237:org.openhab.binding.enocean:2.4.0.201812121631]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.initTransceiver(EnOceanBridgeHandler.java:197) [237:org.openhab.binding.enocean:2.4.0.201812121631]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.access$2(EnOceanBridgeHandler.java:184) [237:org.openhab.binding.enocean:2.4.0.201812121631]
	at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler$4.run(EnOceanBridgeHandler.java:176) [237:org.openhab.binding.enocean:2.4.0.201812121631]
	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 Ralf (@shotte),

as you can read here there is already a discussion ongoing how to handle calls to enableReceiveThreshold for a rfc2217 connection. I would have expected that this exception is handled silently in the lib. However this is not true.

I will do a PR this weekend. Meanwhile you could use the jar from my repo, issue28 branch. The official version cannot be used in parallel with this jar. With the following ser2net config, I was finally able to connect through rfc.

3335:telnet:600:/dev/ttyUSB0:57600 8DATABITS NONE 1STOPBIT remctl

Sorry for the problems.

Best regards
Daniel

Hi Daniel (@fruggy83),

you are welcome, but same issue as before. I activated your new jar and followed your suggestion regarding the ser2net settings, but no chance to get it up right working.

237 │ Active   │  80 │ 2.4.0.201812141820     │ EnOcean Binding

ser2net registers a connection but nothing more happens:

2018/12/14 21:43:27 CLOSE netcon (network read close)
2018/12/14 21:43:27 CLOSE port (All network connections free)
2018/12/14 21:43:27 OPEN (::ffff:192.168.8.10:33838)
2018/12/14 21:44:27 CLOSE netcon (network read close)
2018/12/14 21:44:27 CLOSE port (All network connections free)
2018/12/14 21:44:27 OPEN (::ffff:192.168.8.10:33862)
2018/12/14 21:45:27 CLOSE netcon (network read close)
2018/12/14 21:45:27 CLOSE port (All network connections free)
2018/12/14 21:45:27 OPEN (::ffff:192.168.8.10:33888)

Still the same exception within openHab.

Do you think it will take you some time to fix it? In that case I will try to go back to OH2.3 version with your previos jar I was able to use.

Best regards,
Ralf

HI Martin (@martink2),

another stupid mistake :man_facepalming: I will do a PR this weeking. I will do a PR this weekend. Meanwhile you could use the jar from my repo, issue30 branch. The official version cannot be used in parallel with this jar.

Sorry for the problems.

Best regards
Daniel

Hi Ralf (@shotte),

are you sure that you are using the correct jar? Please try this one. You have to choose the right branch in my repo.

Best regards
Daniel

Hi Ralf (@shotte), sorry my fault, I was on the wrong branch while building the jar. Just try it again.

Hi Daniel (@fruggy83), which of your branches?