Chris is working on a total rewrite of the binding. I think it is based more off the official standard rather than reverse engineering. It may be best to wait on that before adding features to the existing binding.
If you do wish to proceed you could start an issue on GitHub and receive help there.
Either way though, this is should not be related to the binding I think. The theory is that this abstraction means that bindings don’t need to worry about the specifics of different transport layers (that’s the theory anyway ).
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)?
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.
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?
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!!
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?
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.
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) .