Hmmm… OK. so I think that removes 50% of the socat/ser2net solution in that nothing is needed on the OH2 side now. Does this allow the binding to recover without a restart if the binding looses access to the rfc port?
No - as stated above - if you disconnect the port, then the binding needs to be restarted. It’s not an insignificant change to the binding to change this.
OK. So what does converting to the RFC actually do?
My hope and wish, was an ability to have the binding not be restarted when loss of the TCP/USB port. Sounds like this DOES allow a native connection via TCP to the Stick on another machine, so thats a big step forward.
It allows the system to use an IP connection rather than a serial port.
That’s exactly what is implemented here - yes.
Ill test it out when its available in the snapshot, or is it already?
No - it’s not available. Please refer to the PR I posted above. At the moment, I’ve tested it on my machine, but I’m not 100% sure if this feature has been ported over from ESH so I’m trying to clarify that (as you should see in the PR).
I was about to ask if the Z/IP ZIPR IP to Z-Wave RF bridge might work with a RFC2217 redirected port without further development, but after a quick bit of searching it looks unlikely as RFC2217 adds encapsulation for all serial signals (e.g. RTS, RI…), not just TX/RX as raw TCP would.
Personally, I’m happy using a RPi2b with a RaZberry directly connected, but there could be use cases that a remote server and local radio could be useful.
It’s a standard to control Ethernet to Serial ports, such as to allow control of a serial device remotely via Ethernet rather than a very long serial cable.
What’s a Z/IP ZIPR?
A couple of years ago, Sigma Designs released a Z/IP ZIPR Ethernet to Z-Wave radio bridge which apparently was deployed in large hotels to manage Z-Wave devices in each room.
Basically, instead of one server per room, there is one IP to Z-Wave bridge.
No - it is a completely different beast and it operates in a completely different way to the current serial API.
This looks amazing! Vegas hotel with 68,000 nodes!! Jaw drop
Having Controller with a Ethernet plug instead of USB adds so many possibilities. Being PoE powered, even better!
There are other such systems around, although not using ZWave -:
I am just testing openHab and using this release of zwave. I am having a bit of an issue with the z-wave start. Is it normal for it to take an age at start? I only have 30 nodes just now and it is taking an age to sort out at start up.
Cheers for any advice.
What do you mean by sort out? There may be ~15-30 minutes of reduced performance with 30 devices. It takes an hour or two before performance is back to normal for 125 devices.
Thanks Scott that confirms that it is normal. I am just getting used to the difference from what I am used to. 3 to 4 mins for 150 nodes to get back up and running providing the network was all good.
So a restart with 150 nodes is going to be a couple of hours to come back to normal but it does soldier through which is good news.
I think I will avoid restarts from now on and leave it running.
It is the only thing I am not enjoying. Everything else is working well. Very good job.
@chris: How can I put the String for a remote rfc2217 port for the Z-Wave-Binding?
I am using Snapshot 1557 for testing on Windows. I tried Habmin and PaperUI but both only accept COM-Ports which are members of the dropdownlist in the UI (only the physical local Com Ports are listed). So I tested to do a file based thing configuration for the stick like this:
Bridge zwave:serial_zstick:controller "ZWave Controller" [ port="rfc2217://192.168.178.21: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" ]
However the controller remains offline and only shows up in Habmin with an error
What am I doing wrong?
At the moment this is not merged (please check the PR I posted above). The CI is currently failing and I’m not sure if these classes have been migrated from ESH.
It compiles locally on my system, but not under CI so until that’s resolved I can’t merge.
Ok, sorry I thought it was merged already.
@chris I have been using the zwave binding for several years. Upgraded to OH 2.4 stable last year. My server runs Ubuntu 18.04 (also installed last year). Zwave interface is an Aeon Z-Stick gen 5 (used for many years).
Just recently, I have found that on startup sometimes the zwave binding starts receiving many duplicate notifications from devices. This can be 5, 10, 17 or more messages received from one node in a second or so. All devices seem to do this, and so the binding is swamped with messages… Restarting OH does not help, the only thing that fixes it is if I power down the server and re boot.
Having read some of your other posts about issues with the 2.4 version of the binding, I just updated to the latest 2.5 SNAPSHOT version (March 17th), but no difference. Everything works fine from a cold start, but then I’ll reboot the server (I’m upgrading it with new hardware/software etc), and the problem starts. It only goes away from a complete power off.
The result of all these duplicate messages is that zwave runs really slowly. I have waited (overnight) to see if it “sorts itself out” but it doesn’t. After a cold start, zwave binding comes up, and after the initial set up, settles down within a few minutes or so and works normally - response is instant.
I have attached a log of starting OH from warm (just zwave, my zwave log is separate) which shows the problem. if you pay attention to nodes 27 and 30, you can see many repeated messages being received in a very short space of time 9after initial set up). These are Aeon G6 multi sensors, mains powered, and set to report every 30 seconds. There are other nodes that do this as well (I have several of these sensors).
If we look at node 27
NODE 27: Updating channel state zwave:device:controller:node27:sensor_luminance
The messages start at
19-Mar-2019 14:39:10.561 in the log. Should not get another message for 30 seconds after this, but the next one is at
19-Mar-2019 14:39:10.638, then at
14:39:10..667 and so on. There are 19 of these messages in the space of 3 seconds. Then it starts again at
19-Mar-2019 14:39:38.899 (the next 30 second update).
After a cold boot, I just see one of these messages in the log every 30 seconds - exactly as expected.
I don’t know how long it’s been doing this (usually the server runs for weeks at a time or more), but I’m updating some drives, and moving to a new rack, and I just found out that this happens after a warm reboot/OH restart.
Any ideas what is happening?
Here is the log:
There are two general reasons for duplicate notifications - either associations are being configured multiple times (ie you have configured the lifeline, and another group). You should normally only have lifeline configured.
The other possibility is that there is a problem in the network, and messages are being duplicated due to retries.
Given that in the log the binding isn’t requesting anything, I think it’s likely to be one of these two things, so I’d suggest to check associations as the other option isn’t so easy to find.
I just checked the associations, and there was nothing in any group, not even the controller. So I updated group 1 to be the controller (which is what it should be) and we’ll see what happens.
@chris, Just to let you know, I let everything run overnight, and today tried a few warm restarts - all of which worked OK. That’s not conclusive, but seems to be an improvement/difference.
So it looks like it probably was the associations that was the issue.
Thanks for the help.