[SOLVED] [Zwave, Zigbee, ...] RFC2217 remote serial port HowTo?

The ZWave binding doesn’t support the RFC2217 classes - these were removed from the ZWave binding a long time ago.

Just did a code dive and seems like the OHC serial transport is used by the zigbee binding, so trying to get it to work with "rfc2217://ip:port’ but can’t get past the check in the binding that 0 or more serial ports exist. A how-to would be great, as I’ve spent some time searching on relevant keywords but not turning up anything explanatory.

In the meantime, can anyone help me out with a point in the right direction? Given the code that I’ve examined so far, I speculate that I would need to register my port somehow for it to be in the SerialPortManager’s list at the time that the binding checks for ports, but I haven’t yet managed to puzzle out where to do this.

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.

I think this post is asking about ZigBee?

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 :wink: ).

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. :slight_smile:

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 :grinning: 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! :+1:
I hope it keeps working reliable as well.
At least it’s a good step in the right direction. :smiley:

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!! :smiley:

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. :wink:

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