I have problem with z-wave stick in OH3. After each restart from cron (weekly) of after each karaf bundle restart - my one or even all three z-wave stick go offline.
Recently I’ve Symlink a try in order to fix it. But it seems that it just do nothing in my case.
It’s extra frustrating to restart it again and sometimes twice to be able to see all z-wave stick online again. I’ve start DEBUG logging to be able to find out what is happening but tbh - my lack of knowledge goes up here and the only thing I can do is ask for help here…
Hopefully someone will jump into it and help me solve this issue.
Logs as zip file are on cloud here (just click direct download): Logs.zip
PS: It’s started with summer time change - I’m not sure that is only a coincident or actual case
PS2: Please skip modbus errors - PLC unit has been disconected form LAN.
While there is likely some problem here that needs to be looked at, you can mitigate the problem some by addressing the reason you are rebooting weekly. As you can see, reboot can be risky and disruptive and should be used rarely and only in certain situations (e.g. kernel upgrades, unresponsive systems, stuff like that). Rebooting weekly on a schedule is, at best a temporary bandaid that only masks a problem most of the time. At worst it is completely unnecessary and only enforces outages and risks of creating additional problems.
It’s far better to solve the root problem that causes you to reboot weekly than to schedule a reboot on a weekly basis.
The main reason for reboots are slowing down z-wave network.
All system has been organised on 3 z-wave sticks - 1 direct usb and 2 socat over LAN.
What I’ve noticed there is a huge difference approx 20 min after restart system works like a harm - super fast.
I’ve did all my best at least thats what I think to make it work as fast as it is possible.
Check if there is no death nodes / unsued nodes in the system
Eliminate battery PIR Multisensors - put them on constant power supply and change parameters according to manufacture guidance (for constant power supply).
I’ve used direct association - which increase the speed but it cut me out form more advance rules.
comment all channels which are unnecessary for me - like power, amperage, etc.
Let’s say it’s now between 1-3 second between Aeotec multisensor motion alarm and actual light ON.
But sometimes very rarely PIR does not start the light - once per 1-2 months.
I know there were reports of problems with the nightly heal. Have you disabled that? Assuming you have disabled that, have you run it manually since then? Perhaps the binding runs a heal when the binding boots in which case you could just reenable the heal instead of needing to restart OH.
It’s not really clear why a restart of OH would change the behavior of the Zwave network though.
Commenting items/channels you are not interested in will not reduce traffic in the Z-Wave network. Only the representation of the channel on a programming level is omitted that way, the data will still be transported.
To reduce traffic in the network you may want to disable all reports you are not interested in or reduce the frequency they are sent if you cannot disable them.
Healing the network - as far as I know - is only needed when devices change their physical location so their neighbors are no longer correct. When the devices are not moved around, a network heal is no longer needed once is has been performed successfully.
As you have more than one controller, maybe you can schedule a heal at different times for each one. That way the amount of traffic is spread over time (wireless communication is done on a shared medium, so the controllers “see” the traffic of other controllers within their own range).
Still that will unload the quantity on programming level.
Commenting items/channels you are not interested in will not reduce traffic in the Z-Wave network. Only the representation of the channel on a programming level is omitted that way, the data will still be transported.
I’ve turn off all unneeded report as well. It’s a 101-103 and 111-113 parameter. In my case its 0 and report its 3600 - Here I can increase as far as I know up to 7200? Correct me if I’m wrong but that’s all I can do regarding reports from setting menu?
For now I have set the healing at 4am for all of z-wave sticks - I will change that and put 1h break. good idea. The best time for disable the healing is the day that whole system works like harm - I will wait for it (I’m not moving the devices - they are all the time in the same spots).
That is not strictly correct. The binding will not poll any channel that is not linked, so there will normally be a reduction in traffic - but in the grand scheme of things it isn’t high unless the user has set the polling period high.
This error is normally caused by some sort of low level problem in the serial communications. It indicates that the binding and controller have got out of synchronisation - in theory, it should resync, but given you don’t know the root cause, it may be that the resync doesn’t work due to some underlying problem.
I can’t help on your problems, but I have used a Zniffer to see the actual traffic and found zwave traffic that I did not think was happening, noisy devices and surprising routes. Zniffer also shows the delay between nodes on hops. Could be more complicated with three sticks. I have only one stick with 47 nodes and the zniffer is right by the stick. I’m down to about 4 frames a minute, including Acks, just the essential info. Was only $35 here in the US.
I used the UZB from Silabs. I’m not an expert, but think any other 500 chip zstick can be flashed, if you have a spare. I and followed the instructions on the web and the free Silabs firmware.
Personally I doubt that this will help you. The problem seems to be with serial communications between the controller and the binding, or possibly the computer is too busy and it’s dropping frames. Normally if there is a problem on the network, this would manifest in other ways - typically when sending data the frames would be rejected by the controller due to lack of buffers - you typically would not see the Out Of Frame errors that are in the logs here.
Agree Zniffer may not help with this specific problem, but with an 3 Zsticks network, I can guarantee you will learn a few things and it is only about the cost of one new device.
I don’t disagree that it’s interesting to use the sniffer, and it’s possible to learn stuff - just that I had assumed the main drive was to solve the problem reported here, and I’m not sure it will help for that.
My context was the initial post indicated a weekly reboot using a cron rule, having the network in three parts and three nightly heals on each zstick was the going-in (“working”) situation. And now all that no longer works. IMO (I know this is your area of expertise- not mine) all that is not indicative of stability and a cause of lot of network traffic and possibly, however unlikely, caused the reported problem. If not it will be useful anyway trying to streamline what he/she has.
Other possibilities. There were issues with the OH3 nrjavaserial discussed elsewhere. Your error message is not the same, but it was related to serial ports. Might want to look through the conversations. Also here.
Also don’t know if you have the IP camera binding, but there is an active thread about a conflict between Zwave and IP camera.
