I have at least 100 Zooz devices controlled by Home Assistant. All work great, except for the Zen30 double switches. I use them in each bedroom where the dimmer controls the pot lights and the switch controls a wall receptacle for a lamp. Every few days or so, one of my Zen30 800LR double switches will not respond to scene or other UI control. Ping of the device also fails. It is not always the same device that fails. They all are in fairly close proximity to the Zooz Z-Wave USB stick so range is not the problem. The Z-Wave USB stick is on a USB extension cable so interference is not the problem. And all other types of Zooz devices work well. As soon as I press the dimmer paddle or switch button on the “failed” Zen30, communication instantly resumes and everything works great for a while (I’m not sure which of the two presses fixes the communication problem).
Details:
ZEN30 800LR, firmware 4.40.0.
Multiple ZEN30s exhibit the same behavior.
Other Zooz devices (ZEN32, ZEN71, ZEN72, relays, etc.) are completely reliable.
When the issue occurs, the node is unreachable and Ping fails.
Operating either paddle or button immediately restores communication.
Mesh rebuild and firmware updates did not change the behavior.
Home Assistant with ZST39 LR 800 Series Long Range USB Controller
@JustinTime That is a really unusual issue, and we appreciate you taking the time to report it.
We haven’t seen or heard of similar behavior with the ZEN30 running the latest firmware (v4.40), which was released nearly a year ago (August 2025). We also haven’t received any similar reports from other customers, so we’d like to gather a bit more information to help narrow this down.
Could you let us know:
Were the ZEN30 switches included using a standard Z-Wave mesh network or Z-Wave Long Range?
Is your ZST39 controller running the latest firmware (v1.70)?
Are both Home Assistant and Z-Wave JS fully up to date?
The ZEN30 800LR switches (and every other Z-Wave device) appear to be included using standard Z-Wave mesh, not Long Range. In Z-Wave JS UI, each ZEN30 shows only the blue Z-Wave icon in the Protocol column. Only the ZST39 controller shows both the blue Z-Wave and purple Z-Wave LR icons.
The ZST39 is on firmware 1.70
Home Assistant and Z-Wave JS are fully up to date.
@JustinTime Thanks for the additional information!
Out of the roughly 100 Zooz devices in your network, how many are ZEN30 dimmers? Do all of the ZEN30 units exhibit this behavior, with a different one acting up each time?
Since we haven’t seen this issue reported before, and your Z-Wave network is quite large, it would be interesting to see if reducing the mesh traffic makes any difference. If possible, try including a couple of the ZEN30 dimmers using Z-Wave Long Range instead of mesh and monitor their behavior for a while. This will help us determine whether the issue is related to the mesh network or something specific to the devices themselves.
Please let us know what you find. The more details we can gather, the easier it will be to narrow down the root cause.
I have 15 Zen30 devices. I haven’t kept track but just thinking back at least 5 of them have locked up once or twice in the last few months. An idea I had was to ping each of them once a day to keep them “alive”. But I will try the LR option first and monitor.
Is there a way to convert an existing ZEN30 from Mesh to LR while preserving the Home Assistant entities and automations, or do you recommend excluding and re-including the device?
You can establish a ZWLR or Mesh connectivity at inclusion only so you would need to exclude and re-add any device that you’d like to switch over to ZWLR from Mesh.
I think that depending on if your home assistant automations refer to the entity_id it may be possible to retain the ‘link’ to the device even through an exclude/include.
I talking about your automations, dashboards, etc referencing “entity_id: light.familyroom” for example.
(Not via the device_id which would be like “device_id: 8d2a5d4d0b514…”)
The entity_id can be set on the ‘new’ device instance (after you rejoin as LR) to be the same as the previous mesh instance and things might work. If your automations use the device_id, then I believe you’d have no choice but to edit all the automations.
Most of the automations made via the UI tend to use the device_id so this may not be helpful depending on how they were built.
This is a bit of a guess rather than solid advice but worth investigating/ testing.
I have not had a chance to switch to LR. But I have had two ZEN30 devices enter this unresponsive state, and I have captured logs of how they reconnect. I’m sure these logs will shed some light on the issue.
Here is a summary:
Problem
Occasionally a ZEN30 becomes unreachable from the controller.
When this happens:
The physical switch continues to operate both the dimmer and relay normally.
Home Assistant cannot control either load.
Ping fails.
Refresh Values fails.
Re-interview fails.
The node is marked dead in Z-Wave JS UI.
Recovery
As soon as I press either paddle locally:
the node immediately becomes alive again,
the interview resumes automatically,
and the switch functions normally again.
I have now captured logs of this behaviour on two different ZEN30 switches.
What the logs show
For both switches the sequence is essentially identical:
Node is marked dead.
Ping receives No ACK.
Refresh Values receives No ACK.
Re-interview also fails because the node does not respond.
A local paddle press causes the switch to transmit.
The first received packet cannot be decrypted:
Security2CC_CannotDecode
Message authentication failed
Requesting a nonce…
Z-Wave JS sends an S2 Nonce Report.
The node is immediately marked alive.
The interview resumes and completes successfully.
All communication then works normally again.
The recovered connection has excellent RF quality (approximately -59 dBm RSSI), so this does not appear to be a weak signal or routing issue.
Observations
The controller cannot recover the node on its own.
Only a locally generated transmission from the switch causes communication to resume.
This makes me wonder whether the ZEN30 occasionally enters a state where it stops processing incoming Z-Wave frames until a local event occurs, or whether there is an issue with S2 session handling after a long idle period.
I have complete driver logs and UI logs showing the failure and recovery sequence and would be happy to email them to Zooz engineering if that would help.
This afternoon I updated my Home Assistant installation:
Z-Wave JS (1.6.1 → 1.7.1)
Matter Server (9.1.1 → 9.2.0)
Home Assistant Core (2026.8.1 → 2026.8.2)
Shortly after the updates completed, two additional ZEN30 800LR switches were shown as dead in Z-Wave JS UI.
Like the previous two switches they would not respond to Ping, etc.
I repeated the same logging procedure as before.
For both switches:
Started driver logging.
Pressed the local paddle once.
The node was immediately marked alive.
Normal communication was restored.
The driver logs again show the same recovery sequence as the previous two devices:
First incoming frame after the paddle press cannot be decrypted (Security2CC_CannotDecode).
Z-Wave JS requests a new S2 nonce.
The node is immediately marked alive.
Communication resumes normally.
So I have now observed the same behaviour on four separate ZEN30 800LR switches, all running firmware 4.40.0.
I’m not claiming the software updates caused the problem. It’s entirely possible the nodes had already become unresponsive and the restart of Home Assistant/Z-Wave JS simply exposed the issue because the controller attempted to communicate with every node again.
If it would help, I now have protocol logs showing this complete sequence for four different switches and would be happy to send them to Zooz engineering.
Hi @JustinTime, thank you for the additional details! Can you please reach out to our support team directly with all available logs? We’d like to coordinate our efforts with the Z-Wave JS team to investigate the issue in depth.