Yeah if you have a use for them, the extra buttons are nice. I had a few but ended up taking them back out and just using more ZEN77 instead. I didn’t really have a great use for the extra buttons in the end and partner likes the hold to dim up/down functionality anyways. Also sometimes the buttons would stick in my ZEN32s which was mildly annoying. I originally had planned to leverage the extra buttons and multi-color LEDs on them for things like controlling and showing status of alarm system, light automations, etc. but never found a great way to implement that. Plus having low reach light switches and a toddler made me abandon that idea altogether. Now I just use ZEN77/ZEN76 nearly everywhere and heavily rely on scene control and smart switch mode for controlling Hue bulbs (and for an easy way to temporarily disable switches in a room to combat the terrorist toddler fingers lol). There’s a nice blueprint that let’s me do quite a bit of advanced extra actions from 2x/3x/4x/5x presses.
Yep, my whole house is Hue and love all my ZEN77 switches.
The wife thinks the 4 buttons would be better for fan speed controls… I somewhat agree.
We have wall tablets, so don’t use switches much or often at all with all the automations going on anyway, but she likes poking at them sometimes…I guess.
Back on topic, think I’m going to give the ZST39 800 a whirl if I’m going to order some stuff.
I have Home Assistant running on a raspberry pi, with Z-Wave JS installed. The HA GUI offers and “update” button. How risky is it? For example, will it automatically detect my ZST10-700 is not US?
(I have the latest version of HA and the stick is still running 7.16.0)
I saw it’s officially recommended by Zooz themselves since HA 2023.3.0, hence I went ahead with the EU firmware file I had downloaded myself.
Worked like a charm, really cool not having to plug that into a Windows PC (which I don’t have), etc.
Anyone with ZST10-700 on firmware v7.18.3? Do you see any reliability improvements versus v7.17.x?
I have read this https://www.silabs.com/documents/public/release-notes/SRN14889-7.18.3.0.pdf but it’s hard to decipher.
P.S. My ZST10-700 is currently on v7.17.2 and some zwave devices goes offline once in awhile. I would love a firmware update that improves this situation.
I’ve been running x.18.3 for a few months now.
I still get the occasional dead node…
A noob question: when we say “get dead nodes”, what exactly do we see, or how exactly do we find out when a dead node happens?
Would Z-Wave JS UI somehow show you: “you have a dead node here”, or you would not notice until something is off?
- If you have a “dead node”, your activation (automation, command… etc.) will fail.
- You’ll raise an error in the logs.
- In JS-UI you will see a red ‘frowny face’.
Unless something is truly wrong with the node, sending a ‘ping’ brings the node back to life in HA. In my case it’s extremely rare that the node is actually down.
It’s always perplexed me why HA doesn’t handle this situation very well.
After over a year seeing this issue, I’m leaning toward (and confident) this is a Home Assistant issue, not a Z-Wave stick or device issue.
For instance, I don’t see anyone complaining about this on forums of another automation platform which I previously ran for many years with a Z-Wave 500 stick. Meanwhile HA folks are also seeing nodes go unresponsive with their 500 and 800 sticks (ping to bring them back).
You just need to slap a big arse antenna on it.
In all seriousness, I’ve been on 7.18.3 since moving to HA and I’ve had one switch show as dead twice. A ping brings it back.
I’m now doing this to automate the whole thing so I don’t even notice anymore.
Hey @freshcoast
It will be surely a total newbie question… I know I’m supposed to stop all other instances who are using the stick before OTW the firmware, but… I don’t know how to do it 
I’ve stopped homeassistant container (I’m working on linux docker environment), but as I’m using zwavejs/zwave-js-ui:latest image container to execute the command:
npx -y @zwave-js/flash /dev/zooz-hub /usr/src/app/store/ZST39_SDK_7.19.3_EU_V01R20.gbl --verbose
I cannot stop it… this is the output of the command above:
22:29:56.399 DRIVER version 12.2.0
22:29:56.400 DRIVER
22:29:56.400 DRIVER starting driver...
22:29:56.400 DRIVER opening serial port /dev/zooz-hub
22:30:05.425 DRIVER Failed to open the serial port: Error Resource temporarily unavailable Cannot
lock port
22:30:05.427 DRIVER destroying driver instance...
The Z-Wave driver could not be started: Failed to open the serial port: Error Resource temporarily unavailable Cannot lock port (ZW0100)
Any help will be more than appreciated, as actually the stick only starts on bootloader mode, and thus is not accessible by home assistant (so I cannot use it to upload the firmware) and the other option that Zooz Support indicates, is Simplicity Studio, which recognizes the stick, but is not able to mount the device.
So actually it’s innoperative 
Thank you in advance! 
Did you forget to include the output?
totally right
By the way, I’ve tried stopping Home Assistant container (which doesn’t have any z-wave hub configured), and disabling any Home Assistant config in zwave-js http interface, with same result
Is ZUI running while you are trying to do this? The error usually means the serial port is in use by another program.
Yes, I didn’t know what else to turn off… then I tried to change the port from zwave-js config (it was also pointing at /dev/zooz-hub into -for instance- /dev/tttACM0).
And then it began to upload the firmware.
But I got “the same” error I got when I tried updating the firmware from Home Assistant: Timeout:
output without verbose:
Flashing firmware... 100%
Firmware update failed: Error_Timeout
and output (trimmed) with verbose:
22:57:28.998 DRIVER opening serial port /dev/zooz-hub
22:57:29.005 DRIVER serial port opened
22:57:29.007 SERIAL » 0x15 (1 bytes)
22:57:29.016 SERIAL « Gecko Bootloader v2.01.02
1. upload gbl
2. run
3. ebl info
BL >
22:57:29.017 CNTRLR [BOOTLOADER] version 2.01.02
22:57:30.010 DRIVER Controller is in bootloader, attempting to recover...
22:57:30.011 SERIAL » 0x32 (1 bytes)
22:57:30.048 SERIAL « Gecko Bootloader v2.01.02
1. upload gbl
2. run
3. ebl info
BL >
22:57:30.049 CNTRLR [BOOTLOADER] version 2.01.02
22:57:31.013 DRIVER Failed to recover from bootloader. Staying in bootloader mode as requested.
Flashing firmware...
22:57:31.016 CNTRLR Beginning firmware upload
22:57:31.016 SERIAL » 0x31 (1 bytes)
22:57:31.019 SERIAL « begin upload
22:57:31.019 CNTRLR [BOOTLOADER] begin upload
22:57:31.024 SERIAL « 0x43 (1 bytes)
22:57:31.025 CNTRLR [BOOTLOADER] awaiting input...
22:57:31.027 SERIAL » 0x0101feeb17a603080000000000000301010000fa0606fa100000004cf801001a (133 bytes)
...
ffffffffffffffffffffffffffffffffffffffffff588f
23:02:05.214 SERIAL « 0x06 (1 bytes)
23:02:05.215 SERIAL » 0x04 (1 bytes)
23:02:05.216 SERIAL « 0x06 (1 bytes)
23:02:05.235 SERIAL « Serial upload complete
23:02:05.235 CNTRLR [BOOTLOADER] Serial upload complete
23:02:05.235 SERIAL « Gecko Bootloader v2.01.02
1. upload gbl
2. run
3. ebl info
BL >
23:02:06.238 CNTRLR OTW update failed: The bootloader did not acknowledge the end of transfer.
Firmware update failed: Error_Timeout
23:02:06.239 CNTRLR Leaving bootloader...
23:02:06.239 SERIAL » 0x32 (1 bytes)
23:02:06.239 CNTRLR Restarting driver after OTW update...
23:02:06.240 DRIVER destroying driver instance...
23:02:06.286 DRIVER driver instance destroyed
Dunno what else to try… 
That’s a known issue with the Zooz 800 controllers (or perhaps the fw, not sure). It succeeds but reports timeout, for example seen here or others might have reported it here. Glad it worked.
Currently running a Zooz ZST10 stick with 7.17.2, want to upgrade to at least 7.18.3 since I’m planning to add an 800 series Zen72 dimmer.
HA tells me the update was aborted by the bootloader. So I tried running the npx command above, but I am getting the message:
The Zwave driver could not be started: Failed to open the serial port: Error Resource
temporarily unavailable Cannot lock port (ZW0100)\
The add-on log shows:
OTW update was aborted by the bootloader. file error 0x50
Fortunately this has no effect on ZWaveJS and the network continues to work. I noticed instructions about disabling bootloader below but I am running ZWave JS, not the UI, so I don’t see any way to do this for ZWaveJS.
You have to stop the add-on to run the npx command. The serial port is locked according to the message.
You also may have a bad Zooz stick that won’t update, based on the 0x50 error. See this comment.
Thanks for the quick reply. Since it’s working now I’m thinking I just may leave it. Sounds like there is some risk in proceeding unless I follow the official Simplicity Studio approach, and some risk even then.
UPDATE: I did a backup in Silicon Labs PC Controller and tried the official Zooz firmware update procedure, no joy there either. Same 0x50 error. I opened a ticket with Zooz, supposedly the 7.18.3 update would solve this but 7.18.3 is exactly what I’m trying to install.