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

Yes, I think it would be better in the core since that’s where the config description gets populated. The UI is just doing what OH says - in this case, showing and limiting to the options.

1 Like

done:

2 Likes

I think that needs to be fixed in the bindings, I have left a comment on the issue.

1 Like

I think we’ll let @Kai and @chris fight this one out. (in a friendly manner, of course) :wink::popcorn::popcorn:

Is there an open issue we can track? Convert ZWave binding to use ESH SerialPort classes by cdjackson · Pull Request #1152 · openhab/org.openhab.binding.zwave · GitHub Is in state “Merged” and I cannot find a replacement issue or indication of the revert itself.

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: