nope … does not work… and next to that, this gives your more control over the various connections socat makes… Instead of breaking all connections when restarting a single socat instance
Hi @ArdKuijpers
I am facing exactly the same problem as you using Docker on an Ubunto server. The serial port is available and the device is online in paperUI, but it does not work.
I am spending hours on this with no luck. Therefore, can you provide more info on your precise setup, installation and configuration? Are you installing socat on the Docker host - in your case Synology NAS - or as a part of openhab Docker image?
Thanks.
Edit: I found another solution. I am using openhab RFXcom binding, and that supports both a serial end a tcp bridge. I am switching to tcp bridge, so I do not need socat.
Is it still recommended to use socat to connect the current ZWave binding over IP, or can I configure it directly without having to rely on socat? Is there any documentation that shows how to do it in OpenHAB2? I have no issues with the ser2net end of things, it is OH2 that is unclear to me.
USB over IP is working for me using RFXCOM binding which shows the necessary config in documentation as using Bridge rfxcom:tcpbridge:sunflower. I don’t see anything similar in the ZWave binding documentation. On the other hand, this thread suggest that there were issues with the implementation of RFC2217 in the Zwave binding, that the functionality was removed last year, but it seems to have been merged back according to what I saw on GitHub.
Many thanks for your help.
ZWave uses the standard serial system in openHAB so I don’t generally see the need to add this sort of thing to every binding - it should be in one place so it can easily be kept up to date, and not covered in every binding where it will no doubt be missed when updates are made.
No - I don’t think this was removed. What was removed is serial port discovery if I remember correctly (which I might not of course!).
Thank you, @chris. Could you point me in the direction of the documentation page that explains how to configure the serial over IP? The OH documentation on serial config does not show any examples of it, I am afraid, unless it is so obvious that I have missed it.
I’m not sure if it’s documented or not - sorry. I was simply stating that it should be documented as part of the serial configuration and not put in the ZWave documentation as you suggested.
Does anyone have a working example of a native configuration of the ZWave binding over IP?
By native I mean the RFC2217 functionality mentioned by @chris that does not use socat? I could not find any references to anyone having succeeded with that and there is nothing in the OpenHAB documentation.
RFXCOM binding has a nice example and was a breeze to set-up.
If RFXCOM is using the same system as other serial bindings, then I would assume it’s the same. The ZWave binding is not doing anything specific for RFC2217 - it should be part of the serial subsystem.
RTFXCOM binding documentation shows this:
Bridge rfxcom:tcpbridge:sunflower [ host="sunflower", port=10001 ] {
Thing lighting2 100001_1 [deviceId="100001.1", subType="AC"]
}
What I need is the ZWave binding version of this. Have you ever succeeded configuring this @chris? If so, could you, please, provide your bridge definition example?
No - I’ve never used or tested this. I also don’t use text files for configuration so can’t comment on this in general.
To me though, I suspect that rfxcom is not using the standard serial system here as they are specifying a host and port where if they were using the standard serial translation it would specify a serial port wouldn’t it?
Have you read through this thread?
Maybe this helps?
1 Like
Yes, but I was put off by the comment that “it still doesn’t work” followed by your comments that this functionality was removed from the binding—unless I got that wrong.
I will try.
I think my statement that it was removed was wrong - I think it was relted to the serial discovery. Remember, this thread is nearly 3 years old now so there’s a lot of different stuff in here 
That makes sense, thanks.
In any case, I have just tried as per your suggestion in the post above. I have configured things as:
Bridge zwave:serial_zstick:controller "ZWave Controller"
[ port = "rfc2217://192.168.1.1:2001",
controller_softreset = "false",
controller_master = "true",
heal_enable = "true" ]
Unfortunately, it does not work. Log shows:
Attempting to add listener when controller is null
and PaperUI shows:
Status: OFFLINE - COMMUNICATION_ERROR Serial Error: Port rfc2217://192.168.1.1:2001 does not exist
I tried replacing rfc2217 with socket, not specifying it at all, adding host parameter and nothing works.
How does your binding expect this parameter to be formatted to work over rfc2217?
The binding knows absolutely nothing about RFC2217.
As I said, all the magic happens in the serial abstraction layer - the binding is just passing the port etc through. As I understand it, that should be all that’s need - the idea of this is that bindings do not need to be modified in order to support different serial abstractions as the general serial abstraction does this.
I did some experimenting with socat and creating the port in different directories. The summary of that is that except for /dev locations I always get “Port does not exist” message unless I add a Java runtime option “-Dgnu.io.rxtx.SerialPorts=/somewhere/else/ttyUSB0” at which point the binding starts working. I cannot specify the URI-like location (rfc2217://xxxx) as that option, it seems. I wonder if that is the reason it gets rejected by the binding outright.
@chris, is there anyway that you could force gnu.io.rxtx to recognise the URI as a serial port? I know very little Java, I am afraid.
Sorry - as I think I said earlier I don’t know anything about the way RFC2217 is handled. rxtx is just the serial driver - probably there is another configuration for RFC2217.
I’d I’d suggest to do a search in the ESH repository for RFC2217 and have a read of the issues there.
For example -:
I raised that earlier though, and you said you’d read those mails so maybe you’ve already seen this. I’m sorry I can’t really help here as it’s not part of the binding and I don’t know anything about it.
Thanks, @chris, but it did not shed any new light. I am giving up on the OH2 upgrade for the week, glad that OH 1.8 is still so stable. 
I will have another look next weekend, hopefully someone else has more insight in the meantime, especially as also fighting the issue with ZWave serial dev lockfiles causing Java abort traps…
Hi Rafal i also tried with no luck. Gave up on it. 2.4 has been rock solid using MQTT to bridge to instances, no more Zwave issues and it just works so so well. 80 days rock solid.
2 Likes
For what it is worth, I have reported this as a bug related to RFC2217 on the Github openhab-core repo.