My understanding is that he modified the Z-Wave binding and offered this special version as a download for testing purposes. So I downloaded the jar from the post above an dropped it in the addons folder and it worked (for the first time ever). However, if I install the latest Snaphot and the Z-Wave binding via PaperUI it does NOT work. So there must be a significant change within that version of the Z-Wave binding by @wborn .
@chris only added 1 of the 3 fixes in my commit @vossivossi. The fix for not limiting serial ports in the UI.
All I’ve changed is to allow you to type in any serial port name - as we discussed above.
Well, but this seems to be not enough. If I use my .things file (which works perfectly with the version from @wborn) with Snapshot 118 is does NOT work (the 2 controller things remain offline) :
If I try to add the controller via PaperUI I can type in the address (with the rfc2217 prefix) but I cannot confirm my entry so I am stuck in the UI.
So as the textual configuration works perfectly with the version from @wborn there MUST be a difference. Here the screenshot with exactly the same .things file:
It would be awesome to have these changes included in the distro as it opens new architectural options for a deployed Z-Wave network.
EDIT:
This is the version from @wborn:
This is the version from Snapshot 118:
This sounds really promising, but I need to ask as a newbie…How exactly do you setup a remote z wave controller with this? Still need another Pi or something? Socat stuff never worked for my main OH setup as a docker container
You configure ser2net on another machine like described in Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide. You then won’t need to configure socat because openHAB will take care of that. Instead of a normal serial port /dev/ttyUSB0 you configure a rfc2217 port: rfc2217://hostname:port
It’s really simple and you can even run ser2net in a Docker container. That’s how I tested it. 
2 Likes
Thank you for your work, @wborn, much appreciated. Unfortunately, I did not manage to connect over rfc2217. I wonder if the issue might be FreeBSD-related. The updated zwave binding starts (version 2.5.5.202005131628 according to Karaf), but it produces only one message in the logs:
Attempting to add listener when controller is null
This is using the original nrjavaserial-3.15.0.OH2, not the version that you have most recently recompiled. Should I have tried with the “hacked” version?
I have also checked with the current nrjavaserial-5.1.1 and the one with support for rfc2217. In those cases I get the following message:
check_lock_status: device is locked by another application
check_lock_status: device is locked by another application
check_lock_status: device is locked by another application
check_lock_status: device is locked by another application
The “hacked” nrjavaserial version is the same as nrjavaserial 5.1.1 but with a different version so it can be easily tested with OH 2.5.x without having to update the core. It don’t think it should be required for Linux users but maybe it does for FreeBSD because those libraries haven’t been recompiled in a long time.
Do you see a lock file in the dirs that nrjavaserial is checking? Maybe it is stale and has troubles removing it?
No, there are no lock files in /var/spool/lock other than “clean_var” which seems to be created by openhab2 or nrjavaserial.
$ l /var/spool/lock
total 10
drwxrwxr-x 2 uucp dialer 3B 16 May 11:04 .
drwxr-xr-x 9 root wheel 9B 5 Jul 2019 ..
-rw-r--r-- 1 root dialer 0B 16 May 11:04 clean_var
I removed it, but it made no difference. /var/spool/lock is the only directory that exists out of the ones in the code you pointed out.
What I have done next is to revert my system to a clean snapshot of the OH2 installation, before I started compiling etc. I have then replaced nrjavaserial with the “hacked” one, which I can see has loaded:
215 │ Active │ 80 │ 3.99.9.REVERSIONED511 │ nrjavaserial
I cleaned the cache and tmp, made sure to have your ZWave binding snapshot and restarted. After it repopulated the cache, I am afraid it is not trying to connect over RFC2217. I see nothing in netstat on either side of the connection, while, at the same time, RFXCOM binding is connecting happily:
2020-05-16 13:24:30.642 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2020-05-16 13:24:30.816 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2020-05-16 13:24:30.892 [INFO ] [openhab.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2020-05-16 13:24:31.087 [INFO ] [nternal.connector.RFXComTcpConnector] - Connecting to RFXCOM at openhab-relay:2002 over TCP/IP
2020-05-16 13:24:32.653 [INFO ] [nternal.connector.RFXComTcpConnector] - Connecting to RFXCOM at openhab-relay:2002 over TCP/IP
2020-05-16 13:24:33.502 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2020-05-16 13:24:38.891 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2020-05-16 13:24:38.891 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
Paper UI says: Status: OFFLINE - BRIDGE_OFFLINE Controller is off which is progress, because it used to reject the port as “No such port”. I guess we have definitely moved forward a bit, but I feel I am running out of options… I don’t think I am ready to set-up a full-on Java+Eclipse dev environment to step through the code. 
Stop 
the presses. I think it may be working. After doing the reset to the old snapshot I noticed I had an old IP address in the ZWave config. After fixing it I can see communications have started! I will report back in a little while when ZWave had a chance to trawl through all the data. Fingers crossed!
1 Like
@chris: Is there a chance that you also add the other fixes from @wborn ? Then we finally would all have a working RFC2217 solution.
I think there is still testing going on and I’m not sure it is fully working. In any case, I’ve not followed these changes, but if there is a PR submitted I will of course look at adding it.
It would be very helpful for me and a few others. So far it is working well, and I plan on a longer term test next weekend.
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.