Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide

I’m not super sure what to say - the binding uses the ESH framework for the RFC2217 functions - all that has changed is to use these new classes.

I’ve looked at this, and also discussed this with Silabs in Austin at the end of last year. IMHO Z/IP is not so nice, and I was hoping that now that they have an M4 rather than the 8051, that they could do something different. Unfortunately I suspect it’s heavily driven by the Sigma work that was done prior to Silabs takeover.

The first problem is that Z/IP requires Linux, so it makes a Java application difficult as it forces a distributed system which becomes more difficult to maintain for the majority of users.

This is probably the direction I’ll need to take as ZWAs statement is that they won’t be certifying any products that don’t go down this path. Maybe this will change, but I’m not hopeful.

That doesn’t really matter - the bridge controller is fundamentally the same - there are a few small changes, but nothing major.

That is sad as it does seem a lot of work for little gain. I looked at Z/IP a while ago and was not that impressed with how it ran. I have been testing again with a UZB-7 and even with local install on a RPi 3+ and three nodes there is a lag. I know they think this is TLS overhead but it does seem slow.

I was thinking the same but can not get it to be reliable. I thought if I changed the calls from sendData to sendDataBridge etc as a starter but there is something more fundamental with how UZB-7 behaves compare to UZB-3 bridge. Possibly just early firmware glitches. Have you had more luck?

Thanks for the feedback.

Has anyone successfully used the Zwave Binding with the new serial/esh changes to remove socat from the solution now?

Did you ever try it yourself and got it to work?

No - this was something that was written as part of ESH. I believe it is working, but can not test it myself. What I have tested is that the serial port functions work correctly - the RFC2217 part is embedded within that so is totally outside of the binding and I can’t test this part.

Please see -:

Yes, I can confirm this part. The normal serial ports work fine and also the “virtual” serial ports as long as I use other third party tools for the COM-to-IP-Part. I do have one Aeon Gen5 stick connected via RFC2217 protocol which actually works fine if I use com0com and hub4com on Windows (com0com emulates the COM port on my OH machine so it acts like a local COM port).

However, if I try to directly connect to the RFC2217 stick via OH I can see some traffic in the RFC2217 logs (so something seems to happen), but the Z_Wave stick thing will always be displayed as offline by the Z-Wave binding.

I’m not really familiar with the different incarnations of serial-over-ip, so I’m not really able to comment on this (or even understand the differences :wink: ). This is all managed external to the binding and in a centralised way, so if there are improvements that are required, it needs to be done there (and will then benefit all users of the serial system).

That said, I’d be interested to learn more about the exactly how this all works under the hood, so I’ll see what I can find out.

1 Like

I am aware of that. But I would really be interested to know if anybody got it to work as I read no success stories so far.

Thank you for any help on this. I would also be interested to know how you would do the configuration for the RFC2217 COM Ports as a user. I can NOT define/select it in Habmin or PaperUI. So is it intended to have it only by thing config files? How do other bindings with support for RFC2217 handle this?

I wonder, why even bothering RFC2217? It’s just a memo and still experimental. Just because it’s there?

https://tools.ietf.org/html/rfc2217

Beacuse it is working very stable and at least standardized. I am using it with com0com/hub4com on a Windows Platform. I am running 3 RFC2217 servers for my Z-Wave sticks. At the moment I still need to run additional client software on the OH machine to map the remote stick to a virtual local COM Port. It would be nice to just link to the remote stick via RFC2217 directly from OH.

1 Like

It’s still an internet standard, published as in the same way as other standards you may have heard - eg TCP, IP, UDP :wink:

Sure thing, Chris. However, those are standards and not experimental memos.

Generally, RFCs remain unchanged - if people adopt and use them, then they are standard, if not, they fall off the radar.

I’m not aware of any list that states that any RFC is standard, or experimental etc - can you point me to this please?

Easy, Chris. Just follow the link to the RFC I provided above and read the header and status of the memo. Compare this to other standards and you’ll see there’s a difference. But fact is, that many in the “communities” just don’t care about those tiny things. Far too often the “communities” do not even care about existing erratas… This leads far too often to incomplete and incompatible realizations (libraries, frameworks, …).

But again, standards are only standardised when people use them. I’ve been involved with a number of RFC publications, and mostly they stay in this state until there are more users.

Are you instead suggesting that we should not use a standard such as RFC2217, but instead define our own system? To me, this is a bad idea which is why I pushed for this standard approach - even if it is not formally published it is still extensively used.

I’m happy to hear your alternative suggestion though?

Na, I would suppose this. However, I just wonder what the original purpose was. I use this setup on my own, but after discussing it with myself I came to the conclusion that my use case was to be able to abstract from the specific protocols (zigbee, zwave, 433Mhz,…) and to decouple the specific controllers from my home automation engine.
I do not like this tight binding of home automation controllers to protocol controllers. Thus, I decided for myself to give MQTT a try and will setup my home automation on that. I also like the idea of “zero trust”, specifically when it comes to home automation involving home security.

To allow people to locate their HA controllers in parts of their property that are more appropriate to their use.

I don’t really understand. This is inevitable - you still need the ZigBee controller, and the ZWave controller - nothing changes other than using IP allows these controllers to be located somewhere that is not directly in the HA box.

The idea is to collect those specific controller inside one component which uses MQTT publish/subscriptions to the outside. That’s all about it. So, instead of using RFC2217 and the controller specific protocols I intend to use MQTT as som kind of unifying interface. Thus, I’ll skip all those protocol specific bindings on the side of the home automation controller. Additionally, I can make use of the data published to the broker for different things as well. And it’s easier to realize HA for those components.