Oops. My bad.
Chris, Bruce,
Thanks for the replies. I’ll try to clarify. I’m not seeking a feature addition; rather, I’m trying to understand how to use my own pty based virtual serial ports, or to leverage the rfc2217 port capability provided by the core, with the zigbee binding as-is. The zigbee binding performs a check, before trying to open the configured serial port, for there to be at least one serial port ‘registered’. I think the serial port I configure probably must also exist in this registry for the binding to use it, but not sure there. I gather, from comments, that actual serial port devices, and those created for USB dongles, are discovered at startup and so are in the registry when the binding starts, but, of course, the registry used by the SerialPortManager will not contain any entries for arbitrary remote rfc2217 serial ports I may want to use. Is there a way register the existence of such ports or, for that matter, any custom pty based port I might create (i.e., so that they are in the list provided by the SerialPortRegistry to the SerialPortManager)?
refs:
I think I found my answer here (from RFC2217PortProvider.java):
@Override
public Stream<SerialPortIdentifier> getSerialPortIdentifiers() {
// TODO implement discovery here. https://github.com/eclipse/smarthome/pull/5560
return Stream.empty();
}
Recently I did some testing with RFC2217 and it is possible to get it working with bindings. 
The issue isn’t that there is no discovery implementation in the RFC2217PortProvider. The issue is that the ZWave binding has a workaround which results in that only discovered ports can be used. I’ve created issue #1332 for that.
Another issue is that some methods throw exceptions when used with a RFC2217 port.
It also helps to not limit serial port options in UIs so users can enter RFC2217 port details.
I made some changes for all of that in this commit.
Since I don’t have a ZWave controller, maybe someone can help testing if these changes make it possible to use RFC2217 connections with ZWave by testing this org.openhab.binding.zwave-2.5.5-SNAPSHOT.jar?
3 Likes
Thank you Wouter, I have installed the binding modified by you in my test environment. I have a z-wave dongle connected and exposed by ser2net on a spare server. What would I fill in as serial port for the z-wave controller configuration if for example the serial port is pointed to port 3001?
It’s configured by adding the rfc2217 protocol in front of it like an HTTP URL:
rfc2217://1.2.3.4:3001
1 Like
It works 
remote z-wave stick “online” without using socat!!
Configuration at the system with the z-wave controller connected (/etc/ser2net.conf):
3001:telnet:0:/dev/ttyACM0:115200 8DATABITS NONE 1STOPBIT remctl
and as serial port for the z-wave thing in openHAB I entered (my server is called “meterkast”):
rfc2217://meterkast:3001
Major step for me and many other openHAB users I think who use multiple or remote z-wave controllers!!!
I will test reliability over the next days, thanks again!
3 Likes
Thanks a lot for helping to test it @mvbergen! 
I hope it keeps working reliable as well.
At least it’s a good step in the right direction. 
Thanks Wouter for your updated binding.
I’ve tested in my setup and it works fine. You need to define the ser2net connection as mvberger describes above
3001:telnet:0:/dev/ttyACM0:115200 8DATABITS NONE 1STOPBIT remctl
Otherwise you get communication errors in OpenHab
1 Like
Wow, thank you very much @wborn for the great work and the clarifications!
I can confirm that it also works on Windows (OH on Windows) together with an RFC2217-Server on Windows (using Hub4com software) and another RFC2217-Server on Raspi (using ser2net).
That’s really awesome!! 
1 Like
Nice to hear it’s working for you all! Now we just have to find a way to remove the workaround. A workaround for the workaround that will probably work is to check if the portname starts with rfc2217 and then skip the workaround. 
That’s indeed a good point. So far I was only able to get it to work with a .things file and text configuration for the Z-Wave stick. It was still not possible to do it in PaperUI or Habmin.
@chris : Could you perhaps have a look into this?
I’m not really sure that there’s much I can do - both UIs are now deprecated I think. Maybe in OH3 this will be possible, but I don’t know what is planned for OH3.
Ok, then the only way will be via .things files? The only problem in the UIs seems to be that you can only select the detected COM ports in the dropdown list…if a manual entry of the COM Port was possible then it should work.
I will add the “limit to option” configuration in the thing. This might work - the issue is that somewhere else in the core the options are added and I don’t know what happens then. If it doesn’t mess with this, then it just might allow the user to enter free text in the UI.
I thought you could add to EXTRA_JAVA_OPTS
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?