I've been running a Zooz ZST39 and very small Z-Wave network (a motion sensor, 4 light switches and a door lock) since September 2024. I've made no changes to my Z-Wave network since March this year when I added 3 light switches (increased from 1 to 4). I've been very happy with it and had zero issues until Z-Wave JS HA Core Addon 0.18.0. Since that update my network is happy for some time (between 12 and 24 hours - not sure exactly) and then goes into an unresponsive loop. I need to remove and replace my ZST39 for it to start working again. I started opening a discussion topic on the Z-Wave JS github, but the instructions there pointed me to HA Core github, which seemed wrong, so I'm asking here - where should I open this issue?
#ZST39 Unresponsive loop
haughty storm
ruby haven
Which firmware version is it on?
Zooz have recently released a firmware update 1.60, based on SDK 7.23.2, which fixes a bunch of the unresponsive issues:
https://www.support.getzooz.com/kb/article/1158-zooz-ota-firmware-files/
haughty storm
It's still on the version it shipped with - 1.30. I've been loath to touch the firmware because it has been working fine and there are so many stories of people having issues with the update and/or the update process. I've read the various threads on the Z-Wave JS github, including the "jammed" one and it's a bit hard to keep up with it all.
Is it possible something changed in a recent Z-Wave JS update that is now triggering a bug in 1.30?
If you're saying go to 1.60 I'll do it. Do you have a recommendation for current best update method - HA updater or Simplicity Studio? I'm running HAOS in a manually configured LVM on Ubuntu 22.04.5. If I install Simplicity Studio it will be on Linux - OpenSuse Tumbleweed.
ruby haven
Hard to say what's triggering it now. Happy to take a look at Z-Wave debug logs first - the above snippet isn't super helpful to diagnose.
FWIW, the update process in HA should be more stable now. Most issues people were having were caused by some unexpected commands being sent during the update. This is a) less likely for small networks, and b) should have been fixed by recent updates.
haughty storm
I turned on debug logging and re-plugged the controller about 4 hours ago. I'll let it run until it goes unresponsive again and upload the file.
haughty storm
My automation to alert me when it goes Unresponsive didn't work so there about 2 hours of it trying to recover at the end. The failure seems to have been triggered by my Google automation, that controls some Home Assistant managed lights via the Home Assistant Matter Hub, to turn on a bunch of lights at sunset - which appeared to work just fine. When this happens the controller is visibly "dead" - the little blue LED is off.
Edit to add: I had a theory - 3 of my light switches are for my outside lights. I have a helper defined to group them as 1 light switch. This group gets passed to Google, via Home Assistant Matter Hub, along with the individual light switches, so when I ask Google to turn on/off all lights it turns on/off the group as well as the individual lights. As it was the automation that turns on all outside lights at sunset that seemed to trigger the outage I suspected it might be these multiple requests at the same time causing an issue. But then this morning it failed again - I didn't have debug logging on but according to the high level Logbook the only thing happening was a single "manually locked" event sent from my front door lock.
ruby haven
The log does not include Z-Wave logging. See https://www.home-assistant.io/integrations/zwave_js#how-do-i-access-the-z-wave-logs
I'm a bit confused though - you mention Google and Matter all the time. Where does Z-Wave come into this?
haughty storm
I'm confused too. I followed those instructions to generate that log. And I see 11,227 lines with DEBUG and zwave_js_server??
Maybe I should not have mentioned Google and Matter 🙂 I run the https://github.com/t0bst4r/home-assistant-matter-hub which exposes Home Assistant devices to Matter so I can add Home Assistant devices to my legacy Google automations. I also run a small Zigbee network on the same server.
Z-Wave comes into it because my Zooz ZST39 keep going unresponsive.
ruby haven
I'm confused too. I followed those instructions to generate that log. And I se...
The lines I'm looking for look like this:
2025-07-17 08:21:36.422 DRIVER « [Node 002] [REQ] [BridgeApplicationCommand]
│ RSSI: -78 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 125
│ security class: S2_Authenticated
└─[MultilevelSensorCCReport]
sensor type: Illuminance
scale: Lux
value: 2250
It's there in the beginning, but the interesting part in the end does not have them. Not sure if you changed something there
haughty storm
I changed nothing during the "test". I followed those instructions to turn on debug logging. When I noticed that my ZST39 had gone unresponsive I went back to the Z-Wave panel where it displays the nice "Debug logging enabled" banner, clicked on "DISABLE" and my browser downloaded a log file. I didn't modify, or even look at, that file - I just uploaded it here. I can't explain why the DRIVER stopped logging after 08:44:20.247.
haughty storm
@ruby haven I'm assuming the lack of logging that you need means there's nothing more you can do, and I should go ahead and update to 1.60 and hope?
Is there anything we can do to try to find out why the driver stopped logging debug data despite debug logging being on, or are you assuming user error and moving on?
Edit - I've updated to 1.60 with the Home Assistant updater. Process was smooth, so far, so good.