New openHab2 EnOcean binding

openhab2-addons
enocean
binding
Tags: #<Tag:0x00007f0147c0b120> #<Tag:0x00007f0147c0aae0> #<Tag:0x00007f0147c0a860>

(Daniel Weber) #342

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


(Ralf) #343

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


(Martin Klein) #344

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


(Ralf) #345

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


(Daniel Weber) #346

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


(Daniel Weber) #347

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


(Martin Klein) #348

@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?


(Ralf) #349

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


(Daniel Weber) #350

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


(Ralf) #351

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


(Daniel Weber) #352

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


(Daniel Weber) #353

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


(Daniel Weber) #354

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


(Ralf) #355

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


(Daniel Weber) #356

Hi Ralf (@shotte) just use link from my last post. It is branch issue28_rfc2217. Pushed the new compiled jar 2 minutes ago.


(Ralf) #357

Hi Daniel (@fruggy83), ok, I just downloaded it. How to make sure that it is loaded instead the version of the milestone pre-release?


(Daniel Weber) #358

Hi Ralf (@shotte),

it should be enough to uninstall the milestone pre-release version of the binding in openHAB. You could also stop openHAB, clear the cache (sudo openhab-cli clean-cache) and restart.


(Ralf) #359

Hi Daniel (@fruggy83), I feel like a bloody beginner… I followed your instructions by deactivating the binding in PaperUI, placing the downladed jar into /usr/share/openhab2/addons/ , stopped OH, cleaned cache and finally started OH again. Now the bundle is not listet in karaf console and the things are not active (of course).

Is there a console command to activate the jar from addon folder avoiding to install the milestone version?


(Daniel Weber) #360

Hi Ralf (@shotte), you just have to activate the esh.transport.io.serial features (incl. rfc) manually in the karaf console. These features are activated automatically during installation from openHAB, but deactivated when you clear the Cache.


(Ralf) #361

Hi Daniel (@fruggy83), I feel like getting steps back instead in front…

I activated these features:

esh-io-transport-serial-rxtx                x 0.10.0.SNAPSHOT  x          x Started     x distro-2.4.0-SNAPSHOT                x
esh-io-transport-serial-rfc2217             x 0.10.0.SNAPSHOT  x x        x Started     x distro-2.4.0-SNAPSHOT                x
openhab-transport-serial                    x 2.4.0.SNAPSHOT   x          x Started     x distro-2.4.0-SNAPSHOT                x Serial Transport

The jar is copied to /usr/share/openhab2/addons/

It was necessary to activate Enocean Binding in PaperUI to see any reaction at enocen communication and having it listed in karaf.

255 │ Active   │  80 │ 2.4.0.201812141820     │ EnOcean Binding

But what I’m not able to figure out is, if your jar is loaded or the one from snapshot release. As I still have the same problems it seem to me that the snapshot version is running and not your patched one. Again I’m at the end of my knowledge and hope to get very detailled instructions how to proceed successfully. I’m sorry botheriing you with my limited system/openhab knowldge.

Kind regards,
Ralf