I can now say since I made the changes yesterday morning things have been rock solid and nothing has dropped off. I have it setup to notify me if any device stops responding so I would see it even if it came back online again.
I consider it a success now.
Just to recap. I have firmware 1.20, the latest version of the addon 3.8.4 and have disabled the long range stuff.
I don’t know if the disabling of the long range had something to do with it but I’m not going to switch it back now before the long weekend. Maybe next week.
I just received a brand new ZST39 which shipped with the 1.3 version of the firmware
I am running it on a laptop (PC) using the latest Z-WAVE JS UI exe version 9.14.4 and have my HA linked using the websocket. This lets me add another instance of the Zwave JS UI to the HA for testing.
I swapped over 10 non-critical nodes around the house from stick with the
1.1 firmware on my HA NUC to the stick with the 1.3 firmware on my laptop. To be clear, I excluded them from one network and then included them in the other, building the new network from scratch.
So far (8 hours), the 1.3 controller has been rock solid; however, any node that makes more than 2 hops still returns real poor health checks just like before. Moving around with the laptop definitely helps improve things by reducing the number of hopes.
It’s real disappointing that Z-wave cannot cover on a house with 120 nodes all within 70 ft of the hub and no more than 15ft between nodes. I hope this is still caused by bugs in the controller firmware that will eventually be resolved.
For now, my plan is to split the nodes by location using second NUC HA hub and link the two hubs in the same way I am doing with the laptop.
I’ve been on 1.20 for about 3-4 days now, and with LR enabled, and no issues.
I decided to add back the Minoston dimmer plugs this morning. It’s OK. I did have one node just drop, so I need to check on it. How did you set up the alerts when a node dies?
I also was having the same issue with ZST39. I downgraded to V1.1, but I was still having the unresponsive issue (had to unplug & replug to make it work again).
But then I upgraded to the latest ZWave JS UI, which includes ZWave JS V12.12.1. Since then I’ve had zero issues. Looking at the documentation, watchdog functionality was added in 12.12.0, and a fix happened in 12.12.1:
I’m keeping my controller at v1.1 for now, but I might try upgrading it in the future.
I have LR disabled, but I’m running 1.30 and and still seeing instability. I’m going to roll back to 1.20 as well as see if this solves my problem too.
I didn’t see anything that jumped out at me in the Silicon Labs release notes about the issue we’re seeing, but I also don’t know exactly what the root cause is.
Any brave testers that want to give it a run? I will probably give it a shot over the coming weekend when I’ll have time to revert if it breaks.
I flashed mine from 1.2 to 1.4 on the 30th of July using the PC Controller tool of Simplicity Studio. So far, my controller has been much more stable and responsive. The “jammed” and “unavailable” statuses have been greatly reduced to once or twice a day and then for very short time (few seconds). On 1.2, there were multiple times a day where the controller was jammed and/or unresponsive for significant lengths of time.
I received an email last night from Zooz saying that Silicon Labs had just released 7.22.1.0 and Zooz now has a version 1.5 that supposedly fixes this issue. In the SiLabs release notes, it previously showed issue number 1227385 as “The 700/800 controller can lock itself up. The controller is not able to send acknowledgements and the data transmitted is corrupted”. Now in these new release notes, that issue is listed as “While the controller stability has been greatly improved in Z-Wave Classic, the workaround implementation is still recommended on the host side”. Not sure why they changed the wording, nor do I understand why that is still listed under known issues if it is “fixed”. However, under the list of fixed issues, you can find number 1321606 which is “Fixed an issue causing a controller to be locked in a constant beaming pattern. The behavior was caused by an incorrect configuration entered in the controller NVM” which sounds like the issue we were all seeing.
Oddly enough, while you can download the 1.5 firmware from Zooz here and this is the actual file link. Interestingly, their own release notes do not yet list the 1.5 version or the changes. Still it’s something. Anyone wanna roll the dice and update to see if it is fixed??
I’ve been running v1.4 and running on zwavejs for easily a month with great success. Just upgraded today to v1.5 and will hopefully see no negative impacts.
I’m trying to get this controller up and running, current version 1.5 with 7.22.1.
However it seems to get unresponsive every minute for about 5 seconds. In between the controller works fine, but this is not really usable.
2024-11-24 14:12:57.444 INFO STORE: Controller status: Controller is unresponsive
2024-11-24 14:13:02.673 INFO STORE: Controller status: Controller is Ready
2024-11-24 14:14:27.441 INFO STORE: Controller status: Controller is unresponsive
2024-11-24 14:14:32.670 INFO STORE: Controller status: Controller is Ready
2024-11-24 14:15:57.448 INFO STORE: Controller status: Controller is unresponsive
2024-11-24 14:16:02.683 INFO STORE: Controller status: Controller is Ready
Can we get confirmation homeassistant implementation resets controller on crash like suggested by silabs? Appears silabs pushed out faulty hardware and doesn’t want to admit it.
Can anyone here tell me what to do exactly in ZWaveJS UI to disable long range? I am having issues with the same device and devices randomly dropping. Zit never happend before when I still used my older Gen 5 stick without S2 support.
I am trying to figure out what is causing the random drops. Wonder if it is the stick and should switch back to an Gen 5 with S2 support (Aeotec has one) or that it is an software issue.
Had to unplug it and plug it back in to get it going again.