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 ). 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.
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?
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.
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.
But you still have all the protocol specific hardware etc - you just change to using a single binding, and you loose the additional, protocol specific functions that a protocol specific binding provides you (eg ZWave healing).
Anyway - if you prefer MQTT, then fine. Your system has advantages and limitations, but please also understand that others prefer the flexibility etc that other configurations affords.
After further testing, I’ve learned while socat allows multiple connection (telnet, nc, etc), the byte stream from the serial port will be divided among the clients, so no one client receives the entire stream. An alternate solution is using nmap’s ncat like this:
ncat duplicates the incoming stream among all connected clients simultaneously, and concentrates any outgoing bytes (command to alarmdecoder) from any clients back into the serial port. This allows troubleshooting the alarmdecoder while the binding is still running, though the binding gets confused when the datastream stops. I still have issues with the binding getting hung, whether reading the serial port directly or via tcp. Is anyone else seeing this issue?
Although I am not using socat myself but a similar tool in my Windows environment (com0com) I just noticed that you seem to use a baudrate of 115200. With com0com I also encountered some hangers at 115200. I am currently running with 38400 and it seems to be more stable. I don’t know if this might help with socat as well.
I think this thread was more about debugging zwave dongles, but the techniques apply to any serial device sharing over network. I don’t know if the windows versions of socat / ncat / nmap will work but the 115200 baudrate is correct for the alarmdecoder serial device. You are right though, I have some experience in windows serial devices and slower baud rates seem to help. I might try that with alarmdecoder.
I have also tried using it with Home Assistant, and have experienced no hangs there, so my suspicions are in the OpenHab AlarmDecoder binding hanging.
Thanks for the feedback.
). 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).
