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.
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?
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 ?
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
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.
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
really strange . 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.
@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:
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
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.
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.
another stupid mistake 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.
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.
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?
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.
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.