My controller had been in a perpetual not-responding loop on
zwave-js-ui: 9.14.3
zwave-js: 12.12.0
even when I pulled out the stick and re-inserted it, it would immediately get spammed with events in the logs.
I finally plugged it into my PC and used Simplicity Studio to downgrade my ZST39 from 1.30 to 1.20, put it back in my HA box without downgrading zwave-js/ui and everything is stable now.
going on day 2 just fine
I did also remove the Minoston devices. I’ll wait another day or two and then plug them in. I’m still suspicious of them.
I have disabled the long range setting in the zwave-js ui.
Upgraded to the latest versions of the addon-zwave-js (3.8.4) which has the latest zwave-js-ui and node-zwave-js versions.
Everything has been smooth since I updated this morning. No drop offs and everything just works.
The true test is to see if it survives the night. But looking much better than before.
BTW I also have the 1.20 firmware on the stick. Sticking with this as I’ve had it since last year.
Does anybody know what is a source of incompatibility between firmware v. 1.3 and latest zwave js ui? New features or bug on either of the sides?
The answer I got from Zooz:
The SDK library from Silicon Labs, provider of the Z-Wave chip is affected by the bug - controller lockup issues. This has started on SDK 7.19.x and our ZST39 was already affected.
Since then Zooz skipped many updates SDK from Silicon Labs since July 2023, but finally, we have decided to update our stick to 1.30 firmware with the latest SDK 7.21.3 - since there are many other bug fixes and NVM backup should work as expected now. However, the controller lockup issue is still existing on that firmware.
It is currently unclear why in some cases it showing worse symptoms on HA than 1.20. Generally, there should be fewer issues. We are still investigating it since our firmware was released only 10 days ago. At this time is unclear if this is an SDK issue, Zooz custom firmware issue, or HA/Z-Wave JS issue.
Anyway, our firmware was made that way so that you can downgrade it to 1.20. We would recommend a PC Controller from Silicon Labs for that because HA/Z-Wave JS has another issue with updating/wongrading firmware on the stick. In some rare cases, the stick can be even bricked.
Also, our Z-Box hub is based on Fibaro Home Center 3 Lite with SDK 7.21.0 and has also controller lockup issue, however, we are not seeing that many issues like HA users.
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.
Had to unplug it and plug it back in to get it going again.