There is a workaround which first needs to be removed for RFC2217 to work with that binding. See:
The binding will probably also need to catch a few exceptions for it it to work.
1 Like
Unfortunately due to the problem with nrjavaserial, I don’t want to remove the workaround. If the USB port is removed, the JVM will crash.
Just note that the TCP connection to ser2net is there on port 3000.
DSMR and Enocean work fine.
Bridge dsmr:dsmrBridge:SagemDSMRDevice [serialPort="rfc2217://myhost:3001"]
Bridge enocean:bridge:gtwy "EnOcean Gateway" [ path="rfc2217://myhost:3002" ]
3000:telnet:0:/dev/ttyACM0:115200 8DATABITS NONE 1STOPBIT remctl
3001:telnet:0:/dev/sagemcom:115200 8DATABITS NONE 1STOPBIT remctl
3002:telnet:0:/dev/enocean:57600 8DATABITS NONE 1STOPBIT remctl
Found these errors on the Pi:
pi ser2net[8414]: Could not turn off break for device /dev/ttyACM0 port 3000: Broken pipe
pi ser2net[8414]: Could not turn off break for device /dev/ttyACM0 port 3000: Broken pipe
https://sourceforge.net/p/ser2net/patches/10/
It seems there is a NOBREAK flag, will try that next week. Other tips / ideas are welcome.
The NOBREAK flag makes no diff. Are there any success reports with Zigbee? I know the cc2531 is not ideal today.
Update:
The problem is the rfc2217 option exchange. I have compared the cc2531 USB stick handshake with the DSMR handshake. I have found the following differences:
Received by ser2net -->
Sent by ser2net <–
DSMR exchanges these options in separate TCP messages:
Telnet -->
Won't Suppress Go Ahead
Telnet <--
Won't Suppress Go Ahead
Telnet -->
Client Requests Signature
Telnet <--
Server Signature: ser2net
DSMR driver sends these options:
Telnet -->
Client Signature: jvser v1.0.48
Baud Rate: Client Baud Rate: 115200
Data Size: Client Data Size: 8
Parity: Client Parity: None
Stop Bits: Client Stop: 1
Client Set Linestate Mask: Overrun Error, Parity Error, Framing Error, Break Detected
Client Set Modemstate Mask: CTS, DSR, RI, DCD
Control: Client Stop: Input Flow: None
Control: Client Stop: Output Flow: None
Control: Client Stop: DTR: OFF
Control: Client Stop: RTS: ON
cc2531 zigbee driver sends these options:
Telnet -->
Won't Suppress Go Ahead
Client Requests Signature
Client Signature: jvser v1.0.48
Baud Rate: Client Baud Rate: 115200
Data Size: Client Data Size: 8
Parity: Client Parity: None
Stop Bits: Client Stop: 1
Client Set Linestate Mask:
Client Set Modemstate Mask: CTS, DSR, RI, DCD
Control: Client Stop: Input Flow: None
Control: Client Stop: Output Flow: CTS/RTS
Control: Client Stop: DTR: OFF
Control: Client Stop: RTS: OFF
ser2net answers to the DSMR driver:
Telnet -->
Server Signature: ser2net
Baud Rate: Server Baud Rate: 115200
Data Size: Server Data Size: 8
Parity: Server Parity: None
Stop Bits: Server Stop: 1
Server Set Linestate Mask: Overrun Error, Parity Error, Framing Error, Break Detected
Server Set Modemstate Mask: CTS, DSR, RI, DCD
Control: Server Stop: Input Flow: None
Control: Server Stop: Output Flow: None
Control: Server Stop: DTR: OFF
Control: Server Stop: RTS: ON
After receiving this answer, the DSMR driver logs:
2020-09-29 10:54:11.922 [INFO ] [internal.device.DSMRSerialAutoDevice] - Start receiving telegrams on port rfc2217://myhost:3001 with settings: Baudrate:115200, databits:8, parity:none, stopbits:1
ser2net answers to cc2531 zigbee driver:
Telnet <--
Don't Suppress Go Ahead
Server Signature: ser2net
Server Signature: ser2net
Baud Rate: Server Baud Rate: 115200
Data Size: Server Data Size: 8
Parity: Server Parity: None
Stop Bits: Server Stop: 1
Server Set Linestate Mask:
Server Set Modemstate Mask: CTS, DSR, RI, DCD
Control: Server Stop: Input Flow: CTS/RTS
Control: Server Stop: Output Flow: CTS/RTS
Control: Server Stop: DTR: OFF
Control: Server Stop: RTS: OFF
After receiving this answer, the cc2531 zigbee driver logs:
2020-09-29 10:54:12.542 [ERROR] [ding.zigbee.handler.ZigBeeSerialPort] - Serial Error: Unsupported comm operation on Port rfc2217://myhost:3000.
2020-09-29 10:54:12.542 [ERROR] [.cc2531.network.ZigBeeNetworkManager] - Failed to open the dongle.
2020-09-29 10:54:12.543 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.initialiseZigBee(ZigBeeCoordinatorHandler.java:425) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.lambda$2(ZigBeeCoordinatorHandler.java:543) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_265]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_265]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_265]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_265]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
There is something the cc2531 zigbee driver doesn’t like, howto find out what it exactly doesn’t like. Is there a way to tweak these option values in the cc2531 driver?
I was temped to this on my remote installation. The problem for me is that it’s not only zwave/zigbee devices, regular ones as well. With that said eventbus via mqtt is really working great, I recommend it!
/S
Zigbee & Z-Wave are standardized, regular devices.
You misunderstood me. I’m saying I have other types of Items which are not tied to Zigbee and Zwave which I want to share state between different OH installations. Eventbus is a universal solution that works for all items.
/S
When digging some more:
This might happen in the zigbee driver too. Comparing with DSMR:
org.openhab.binding.dsmr/src/main/java/org/openhab/binding/dsmr/internal/device/connector/DSMRSerialConnector.java
try {
serialPort.enableReceiveThreshold(SERIAL_TIMEOUT_MILLISECONDS);
} catch (UnsupportedCommOperationException e) {
logger.debug("Enable receive threshold is unsupported");
}
try {
serialPort.enableReceiveTimeout(SERIAL_TIMEOUT_MILLISECONDS);
} catch (UnsupportedCommOperationException e) {
logger.debug("Enable receive timeout is unsupported");
}
org.openhab.binding.zigbee/src/main/java/org/openhab/binding/zigbee/handler/ZigBeeSerialPort.java
localSerialPort.enableReceiveTimeout(100);
} catch (UnsupportedCommOperationException e) {
logger.error("Serial Error: Unsupported comm operation on Port {}.", portName);
return false;
So I guess that needs to change to:
try {
localSerialPort.enableReceiveTimeout(100);
} catch (UnsupportedCommOperationException e) {
logger.debug("Enable receive threshold is unsupported");
}
Anything against changing this?
Trying to run the modified Binding:
Previous “Unsupported comm operation” exception error is gone.
2020-10-01 14:45:34.697 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Failed getDeviceInfo for 1 due to null value
2020-10-01 14:45:40.723 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Failed getDeviceInfo for 5 due to null value
2020-10-01 14:45:46.226 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Failed getDeviceInfo for 6 due to null value
2020-10-01 14:45:51.229 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Failed getDeviceInfo for 7 due to null value
2020-10-01 14:45:57.235 [ERROR] [.cc2531.network.ZigBeeNetworkManager] - Failed to start zigbee network.
LED on cc2531 is off, while normally on. CPU is normal.
After restarting openhab:
2020-10-01 14:39:41.604 [WARN ] [.cc2531.network.ZigBeeNetworkManager] - Dongle reset failed. Assuming bootloader is running and sending magic byte 0xef.
2020-10-01 14:39:47.632 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.initialiseZigBee(ZigBeeCoordinatorHandler.java:425) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.lambda$2(ZigBeeCoordinatorHandler.java:543) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_265]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_265]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_265]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_265]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_265]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
2020-10-01 14:39:48.634 [INFO ] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee dongle inactivity timer. Reinitializing ZigBee
Now the CPU load goes 100%.
When stopping openhab, replugging the cc2531 and restarting openhab, the process starts over.
Opened an issue:
Would it also work to run ser2net on the local host and connect through rfc2217 rather than direct via device name file ?
The advantage would be you would then be able to fire up another software such as Z-Way to access the zwave controller without taking OH down and without that the binding would need to reinitialize as it does on startups.
Z-Way is the vendor tool for the UZB and RaZberry stick that you can use to backup your controller contents or to heal the network so we could take backups without taking OH down.
Is someone here of you to have success in using rfc2217 willing to create a writeup of this and place it as a tutorial in the solutions category ?
Would it also work to run ser2net on the local host and connect through rfc2217 rather than direct via device name file ?
Honestly, I don’t see a reason why this should not work from the network perspective 
I’d assume this would be helpful for containerized setups too as well for migration approaches …
But have to admit:
Even though I’ve started this thread, I still have no working rfc2217 setup yet 
I’m still on ser2net/socat …
EDIT: Regarding your idea of accessing the serial device from a second programm:
The advantage would be you would then be able to fire up another software such as Z-Way to access the zwave controller without taking OH down and without that
I doubt this will work simultanously.
I’d assume (even though the serial port is accessed through a network connection) that the first software (e.g. openHAB’s ZWave binding) has to close the serial port before the second programm “Z-Way” can access it. I’m afraid, in that case, the openHAB ZWave binding need to be stopped before the Z-Way is used and restarted afterwards.
This is not exactly what you want - right?
Right, that’s what we have today. But in my envisioned setup the two programs each will access a virtual (device name) file of their own, provided by ser2net hence no locking competition.
I don’t want to use both programs simultaneously but ‘park’ the first connection.
The open question is if ser2net (or any other tool?) can put a connection “on hold” and switch over and talk to the other one, then get back to resume the initial connection. And if the binding would run into a timeout or some such.
I’m preparing myself for moving some openHAB to 3.0.0-milestone. Therefore I’ve been checking, which changes regarding serial/rfc2217 made it into the core…
Doing so, I noticed a very exciting conversation on github regarding
RFC2217 Discovery Service
@wborn, @riturrioz were discussing mDNS for rfc2217 discovery and they even got the author of ser2net Corey Minyard involved for enhancing his ser2net to support it.
This sound to me, we may get autodiscovery for remote serial devices in the near future:
See:
2 Likes
If you use Z-Wave either download the latest snapshot or wait for Milestone 2. Z-Wave is broken in Milestone 1.
Thanks, and yes - this was my intention 
Learning upfront about obstacles to expect is the reason why I’m reading that much before upgrading…
1 Like
Can anyone please summarise for me if the ZWave binding works (yes/no) with a stick connected on remote RFC2217 serial port on OH 3 RELEASE version?
@wborn from a serial perspective do you expect this to work in OH3? If so I may be able to set up a test with the Z-Wave binding.