Not really. It’s certainly not impossible, but it’s not a “tiny watchdog”. I don’t know what the RFLink does - my guess is this is a simple device - probably stateless. The ZWave connection to the controller is not so simple, and is not stateless. This means that if the link goes down, then the controller connection really needs to be restarted - it’s not just a case of closing and opening the serial port (although this might work at least some of the time, it will not work in all cases).
I might look at this in future, but it does require some restructuring of the binding.
Hi Chris. I understand that it may not be similar easy as with the dump RFLink binding. I also understand that the ZWave controller is stateful. But that shouldn’t mean the binding needs to be stateful as well, doesn’t it? I mean, the current solution is to
restart the binding, which pretty much means we destroy it’s state…
Yes, this is my point - we need to restart the binding - not just restart the serial connection. The binding has not been written to do this internally and it would require some work to catch all the cases. Eg - people want to remove the dongle to allow them to exclude devices, or include devices - so the binding needs to destroy all internal data, and reinitialise.
As I said - it’s not an impossible task, but it’s just not so simple either if you want it to work properly in all different use cases. It’s certainly not just a “tiny watchdog” - that’s the easy part.
Hi Chris, I cannot find any open issue on github for this behavior. Is this correct or am I blind?
Shall I create one so it’s not forgotten? I also could create a fork and experiment on my own and create an according PR in case I found a solution.
Greetings, Wolfram
For anyone that wants to use the ser2net/socat solution with a docker container: I have it working with the docker-compose.yaml file quoted below. I run openHAB in a docker container on my synology NAS. I use socat to add the device /dev/ttyZWave which is linked to a Z-wave stick in a raspberry pi. I first tried to access the /dev/ttyZWave via devices in docker, but that does not work (although the device is visible). When using a simple volumes: mount of the device, it works (although it is a symbolic link to a /dev/pts/xx). I hope it helps someone because it took me some time to get it working.
The latest binding has support for the rfc2217 features added. As I’ve said in the past, I don’t personally use this, so I’m not really able to help with configuration and you should check the ESH discussions I’ve referenced previously.
Unfortunately it still doesn’t work. I am on Snapshot 1567(?) (at least that is the one I downloaded, but is displays 1566).
There is some progress, if I put my Z-Wave controller in a file based configuration as a thing
Bridge zwave:serial_zstick:controller "ZWave Controller" [ port="rfc2217://192.168.178.80:7000", 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" ]
then I can see in the logs of my rfc2217 server that a connection is established and communication takes place (so far, so good).
However, the controller is always shown as offline in OH (PaperUI and Habmin) and it is not possble to start a device discovery for my Z-Wave nodes
So at the moment it is still not possible to use a controller connected via rfc2217 ip connection.
It is also still not possible to specify the comport in the UI based configuration as both UIs (Paper UI and Habmin) will only accept the physical COM ports in the dropdown list.
A slight parallel to this so I hope you do not mind.
As the 700 series is looking like it will be a bridge only controller (certainly no static controller in the SDK), is anyone working or interested in working on Z/IP or zware bindinging for the future?
Of Course you could also try to convert some of the serial calls to the bridge version but it may get more difficult if Silicon labs only pursues Z/IP or zware and breaks the serial interface even more as it is not an intended integration point.
A binding on Z/IP or Zware would solve the underlying issue that triggered this thread. i.e. have the zwave usb in a remote raspberry pi and openHab in a virtual server with communication over IP.
I am sure there is not any need to rush to do this as the current binding works well but at some point it will be hard to get hold of zwave static controllers.
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?
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.
