Unfortunately not for rfc2217 ports as those contain a colon which is otherwise used as a separator in the list of ports given to that option. I have tried escaping it, but that is not allowed either.
1 Like
It worked for me and it’s also part of those ZWave changes I made for RFC2217.
Recently I also migrated almost all other add-ons to the serial transport (#7573). So in theory RFC2217 ports can now be used with most add-ons.
For many it will still require catching and handling unsupport comm port operations. But still I already disabled the limitToOptions for all add-ons in #7625. This will also allow users to enter undiscovered ports which will be automatically added to gnu.io.rxtx.SerialPorts by the serial transport. So that should also simplify using undiscovered ports such as those made for udev rules.
It will still be required to add undiscovered ports manually to gnu.io.rxtx.SerialPorts for zwave/zigbee until those workarounds are removed (#1332, #577) .
Ok, good, so that is already in the changes so hopefully will work.
So will this change be in one of the next snapshots?
It should already be included in the latest binding.
Are you sure? I just tested with latest Snapshot (OH2.55 Snapshot 118 from today) but it does not work.
I think @wborn published a different version of the Z-Wave binding in this post.
To me it seems as if this version is not in the current snapshot branch?
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.