As I said above, if there is a PR submitted once testing is done, then of course I will look at it.
What exactly means “once testing is done” ? For my part, I use the modified binding from @wborn now since 7 days (7x24) in my productive environment with 3 ZWave-controllers via RFC2217 directly and 130 nodes. Everything works perfectly.
So I would really like to see the RFC2217-capability finally also in the normal branch.
@wborn: Could you submit a PR with all of your changes?
Well, there are still tests being done by people. I’ve not followed too closely, but from what I see it doesn’t look like it’s working 100% (but I could be wrong as I’m not following it). Anyway, that’s what I meant by “once testing is done”.
So where would be this “follow-up” if not in this thread? So far in this forum there are ONLY positive results. I could not find a single post with a problem. What are we really waiting for?
Github.
1 Like
See -:
It’s probably best for now to only do the workaround when the port name doesn’t start with “rfc2217://” . That should prevent crashes with physical ports while it will still be able to use the RFC2217 ports. Updating the nrjavaserial library will be difficult anyways on OH 2.5.x since the core is frozen.
That sounds reasonable to me. It is really a shame that noboby can use RFC2217 functionality until now (except with the @wborn version of the binding) although it was “officially” introduced so long ago. From a functional point of view this is a really important enhancement, so please do not overengineer these blocking architectural discussions. I think no one expects any autodiscovery of RFC2217 ports, but would be happy to type in the address manually. But please make at least this doable.
I’ve created a PR for the changes, they are very small now, the PR even got number #1337!
5 Likes
I hope you wrote it in 1337 sp33k. 
Thank you, @wborn, @chris and everyone else. I can add that I have been using RFC2217 for the last few days to migrate my OH1 to OH2—this was the stumbling block, as I needed to move the server away from the ZWave antenna, and while socat USB did not work under FreeBSD due to locking issues, RFC2217 is working quite well.
I would like to propose one further improvement to it. In case the connection drops for a while and comes back later, ZWave binding does not recognise that and stays offline (it does resume after a shorter outage, but not after longer ones). It would be good to have logic that verifies every 10 minutes or something else, perhaps, if the RFC2217 port is live, so as to resume. This will save from having to write external checking logic that reboots OH2. I have noticed that the RFXCOM binding does that over TCP.
Feel free to improve my work once it’s merged. 
I don’t have a Z-Wave device so I have no means to test changes.
1 Like
This supports my observation. When rebooting or interrupting the remote system running ser2net with the zwave USB stick attached nothing seems to be detected, the zwave controller “thing” remains to be shown “online” in PaperUI. When operating a connected zwave device (in my case a fan switch, node3) from openHAB the binding finds that the serial device is absent. Shortly after the binding is re-establishing connection to the rfc2217 serial device.
2020-05-25 10:51:16.766 [ome.event.ItemCommandEvent] - Item 'Fan_Switch' received command OFF
2020-05-25 10:51:16.776 [nt.ItemStatePredictedEvent] - Fan_Switch predicted to become OFF
2020-05-25 10:51:16.784 [vent.ItemStateChangedEvent] - Fan_Switch changed from ON to OFF
2020-05-25 10:51:18.791 [WARN ] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Broken pipe (Write failed) during sending. exiting thread.
2020-05-25 10:51:18.805 [hingStatusInfoChangedEvent] - 'zwave:serial_zstick:6ee013eb' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Controller is offline
2020-05-25 10:51:18.809 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node3' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-05-25 10:51:18.810 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node2' changed from ONLINE: Node initialising: REQUEST_NIF to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-05-25 10:51:42.699 [hingStatusInfoChangedEvent] - 'zwave:serial_zstick:6ee013eb' changed from OFFLINE (COMMUNICATION_ERROR): Controller is offline to ONLINE
2020-05-25 10:51:42.702 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node2' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-05-25 10:51:42.716 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node3' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-05-25 10:51:42.742 [me.event.ThingUpdatedEvent] - Thing 'zwave:serial_zstick:6ee013eb' has been updated.
2020-05-25 10:51:42.743 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node3' changed from ONLINE to ONLINE: Node initialising: PING
2020-05-25 10:51:51.210 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node3' changed from ONLINE: Node initialising: PING to ONLINE: Node initialising: REQUEST_NIF
2020-05-25 10:53:02.516 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node3' changed from ONLINE: Node initialising: REQUEST_NIF to OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller
2020-05-25 10:53:18.161 [hingStatusInfoChangedEvent] - 'zwave:device:6ee013eb:node3' changed from OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller to ONLINE
You can see that when the zwave binding communicates with the controller, the controller is detected after a while and the connected nodes (in my case a battery powered sensor, node 2, and a mains powered switch, node3) re-appear. When a device connected to the remote zwave controller and the remote zwave controller sends data over rfc2217 these do not get detected by the zwave binding.
My conclusion for now is that a disruption of a remote serial zwave controller can be recovered reliably using @wborn’s proposed modifications when the binding actively communicates to the device and not the other way around. As a temporary workaround a rule that updates a device at a regular interval could be set up.
Future improvements like autodiscovery and a polling interval would be nice, but for now this is a huge improvement for me over using socat with regards to reliability and recovery.
This sounds like a workaround I would like to try out. Could you clarify, @mvbergen, please: would it be sufficient to send a status updated, or issue a command, on a regular basis to a device to force the binding to talk again to the remote stick? Thank you.
I needed to send an ItemCommand, ItemUpdate didn’t trigger the binding to contact the serial port.
Thanks. How often do you do that?
I made a quick node-red flow that reads the item state and sends it as command to the item. Currently this is done every 10 minutes. I’m sure there is a more elegant way, this was just a quick hack. The change node is configured as “set msg.payload to msg.payload.state” and the output node is configured to send the payload as itemCommand.
1 Like
Thank you very much for your very constructive work, highly appreciated! 
So I hope that @chris will merge the PR soon.
openHAB 2.5.9 Release Build
Trying to move my cc2531 stick to a Pi using RFC2217. Does anyone have an idea what might cause this error:
2020-09-26 16:14:47.133 [ERROR] [ding.zigbee.handler.ZigBeeSerialPort] - Serial Error: Unsupported comm operation on Port rfc2217://myhost:3000.
2020-09-26 16:14:47.133 [ERROR] [.cc2531.network.ZigBeeNetworkManager] - Failed to open the dongle.
Just scanning the thread quickly, I am not sure anybody tested with the zigbee binding. @chris should remember.