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

Since quite a while now (openHAB 2.4M… ???), rfc2217 remote serial ports seem to be supported. Theoretically, this should give the option, easily connect to remote telnet-serial ports (provided by e.g. ser2net on a remote RaspberryPi) directly from the bindings configuration.

Up to now, I’ve been using remote serial ports it like many others via

<physical serial port> -> ser2net (on remote Pi) -> network -> socat -> <virtual serial port (on local openHAB)>

This works quite stable as long as nothing gets disconnected (e.g. remote serial port unplugged/pi boots/network gets interrupted etc.)
Sure, most of the issues can be circumvented by some scripting which restarts the socat processes etc…

But is this still required? Is it probably the right moment to move to rfc2217?

Does rfc2217 remote serial ports bring us robust serial-to-ip connection to our Zigbee/Zwave/…/dongles? And: How to configure it?

Has somebody a working setup which can be shared here?
How to configure the rfc2217://… serial ports in the bindings?

I’ve found the following in another thread (see: Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide ):

Bridge zwave:serial_zstick:controller "ZWave Controller" [ port="rfc2217://", controller_softreset="false", controller_master="true", heal_enable="true", security_networkkey="11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 00" ]

Is this the way to use it? Does it mean, rfc2217 requires text file configuration? Fair enough. Can live with that… :wink:

Or …
Is there another way to make openHAB aware of remote serial ports which can be offered by the common serial port selection drop-down list later?

Or …
Can the drop-down-list get modified to accept manually entered serial ports which have not been discovered yet? AFAIK - not the case currently…

Any advice welcome :wink:

That sounds to me like a feature that would need to be added to the bindings.
Currently, the primary developer s trying to successfully use the new system.
It might be a good idea to open an issue on GitHub for this.

As long as the binding uses the “right” serial port classes, it’s independend.
For the Zwave @chris has confirmed that it has changed that way
EDIT: @chris has reverted the implementation of it.

The ZigBee binding supports this, but we removed it from the ZWave binding a long time ago as it caused a load of problems with stability. I forget what it was, but IFRC it was removed before 2.4 was released due to lots of issues.


Well, that would be a good start to play with…
But requires textual configuration right?

I don’t think so - it should work the same way as any other serial port, you will just need to type in the port name.

Yes, that was my expectation too. But the selection is limited to the pre-populated ports listed in the dropdown. No manual edit possible.

Or is there some trick to…

Hmmm, I don’t really know how that works. It might be only applicable to some systems as on my system (OSX) I don’t have any pre-populated ports…

What UI? HABmin?

EDIT: for Z-Wave, at least, HABmin is restricted to the dropdown.


It will be UI independent since it’s populated by OH Core, and not the UI.

Well, might be the case. My Debian shows perfectly all (socat-provided) serial ports.
When I click on the port configuration, it opens the list and let me choose from the existing entries. No add possible… :frowning:



For completeness, my PaperUI


Anyway: Back to the main questions from above:

Answer: At least partly not (yet?). For the Zwave I have to stick with the socat stuff anyway due to the reverted implementation. Thanks Chris for pointing this out!

Remain open:

Would still appreciate to see some working setup as an example.

I guess I should skip rfc2217 for now.
Thanks guys, I think you saved me a lot of spare time :+1:+1

1 Like

FTR: I’ve opened an issue for the “non-editable” drop-down list:

Maybe it should go to openhab-core too according to Chris:

1 Like

And that is likely pulled from the OS.

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



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? https://github.com/openhab/org.openhab.binding.zwave/pull/1152 Is in state “Merged” and I cannot find a replacement issue or indication of the revert itself.