ZWave Network Issues - Switch Goes Dead, Sensor Sends Duplicate Messages

Sadly, I’m having a bunch of issues with my ZWave network. I am using a Zooz ZST39 stick on about a 6ft USB 2.0 extension cable. It is plugged into a USB 2.0 port on my Pi 5. The stick is mounted on the edge of a wooden door frame. I have a Zooz ZEN71 about 6ft away from the stick. It is turned on and off a lot of times during the day. It used to be included through ZWave, but I was seeing a lot of dropped RX for it (easily 50 a day) and really high round trip times (above a second). So, I excluded it, and included it through ZWave LR. Now the switch goes dead in ZWave JS UI about one out of 5 times it is turned on (off). It turns on (off), but the controller marks it as dead, because it does not receive acknowledgement from the node (260). The controller sends the 3 commands in a span of less than a second. However, the node sends the controller a BinarySwitchCCReport. When I ping the node once or twice, it comes back online.

Relevant Part of the Log

2025-06-17 01:47:53.489 DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -108 dBm
channel 1: -109 dBm
channel 2: -109 dBm
channel 3: -104 dBm
2025-06-17 01:47:53.490 DRIVER all queues idle
2025-06-17 01:48:16.492 DRIVER one or more queues busy
2025-06-17 01:48:16.494 DRIVER » [Node 260] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 96
└─[Security2CCMessageEncapsulation]
│ sequence number: 125
└─[SupervisionCCGet]
│ session id: 2
│ request updates: true
└─[BinarySwitchCCSet]
target value: false
2025-06-17 01:48:16.508 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-06-17 01:48:16.588 DRIVER « [REQ] [SendDataBridge]
callback id: 96
transmit status: NoAck, took 70 ms
routing attempts: 3
protocol & route speed: Z-Wave Long Range, 100 kbit/s
routing scheme: Resort to Direct
TX channel no.: 3
TX power: 0 dBm
measured noise floor: -100 dBm
2025-06-17 01:48:16.589 DRIVER » [Node 260] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 96
└─[Security2CCMessageEncapsulation]
│ sequence number: 125
└─[SupervisionCCGet]
│ session id: 2
│ request updates: true
└─[BinarySwitchCCSet]
target value: false
2025-06-17 01:48:16.603 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-06-17 01:48:16.729 DRIVER « [REQ] [SendDataBridge]
callback id: 96
transmit status: NoAck, took 120 ms
routing attempts: 3
protocol & route speed: Z-Wave Long Range, 100 kbit/s
routing scheme: Resort to Direct
TX channel no.: 3
TX power: 6 dBm
measured noise floor: -99 dBm
2025-06-17 01:48:16.730 DRIVER » [Node 260] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 96
└─[Security2CCMessageEncapsulation]
│ sequence number: 125
└─[SupervisionCCGet]
│ session id: 2
│ request updates: true
└─[BinarySwitchCCSet]
target value: false
2025-06-17 01:48:16.744 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-06-17 01:48:16.884 CNTRLR [Node 260] [~] [Binary Switch] duration: {“value”:0,“unit”:“secon [Endpoint 0]
ds”} => {“value”:0,“unit”:“seconds”}
2025-06-17 01:48:16.886 CNTRLR [Node 260] [~] [Binary Switch] targetValue: true => false [Endpoint 0]
2025-06-17 01:48:16.889 CNTRLR [Node 260] [~] [Binary Switch] currentValue: true => false [Endpoint 0]
2025-06-17 01:48:16.890 DRIVER « [Node 260] [REQ] [BridgeApplicationCommand]
│ RSSI: -54 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 251
│ security class: S2_Authenticated
└─[BinarySwitchCCReport]
current value: false
target value: false
duration: 0s
2025-06-17 01:48:16.905 DRIVER « [REQ] [SendDataBridge]
callback id: 96
transmit status: NoAck, took 160 ms
routing attempts: 3
protocol & route speed: Z-Wave Long Range, 100 kbit/s
routing scheme: Resort to Direct
TX channel no.: 3
TX power: 12 dBm
measured noise floor: -100 dBm
2025-06-17 01:48:16.905 CNTRLR [Node 260] The node did not respond after 3 attempts, it is presumed dead
2025-06-17 01:48:16.906 CNTRLR [Node 260] The node is now dead.
2025-06-17 01:48:16.910 DRIVER all queues idle
2025-06-17 01:48:23.481 DRIVER one or more queues busy
2025-06-17 01:48:23.481 DRIVER » [REQ] [GetBackgroundRSSI]
2025-06-17 01:48:23.489 DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -108 dBm
channel 1: -110 dBm
channel 2: -110 dBm
channel 3: -104 dBm
2025-06-17 01:48:23.490 DRIVER all queues idle

I am also facing an issue with a Zooz ZSE11 Q sensor (node 35). It sends a lot of duplicate messages. My network has 6 main powered devices, and one sensor included through ZWave, and 1 switch and 1 sensor included through ZWave LR. When I run a diagnosis of the main powered nodes I obtain mixed results (for the same node) - either 7/10 (due to the lowest power level without errors) or 2/10 due to high latency (in seconds). I’ve tried rebuilding routes, moving the controller, etc.

Relevant Part of the Log

2025-06-17 01:07:23.315 DRIVER « [Node 257] [REQ] [BridgeApplicationCommand]
│ RSSI: -92 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 119
│ security class: S2_Authenticated
└─[MultilevelSensorCCReport]
sensor type: Illuminance
scale: Lux
value: 1
2025-06-17 01:07:36.060 CNTRLR [Node 035] [Multilevel Sensor] Humidity: metadata updated [Endpoint 0]
2025-06-17 01:07:36.061 CNTRLR [Node 035] [~] [Multilevel Sensor] Humidity: 55 => 54 [Endpoint 0]
2025-06-17 01:07:36.063 DRIVER « [Node 035] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 165
│ security class: S2_Authenticated
└─[MultilevelSensorCCReport]
sensor type: Humidity
scale: Percentage value
value: 54
2025-06-17 01:07:37.600 DRIVER Dropping message with invalid payload
2025-06-17 01:07:37.600 DRIVER « [Node 035] [REQ] [BridgeApplicationCommand]
│ RSSI: -79 dBm
└─[Security2CCMessageEncapsulation] [INVALID]
error: Duplicate command (sequence number 165)
2025-06-17 01:07:38.895 DRIVER Dropping message with invalid payload
2025-06-17 01:07:38.895 DRIVER « [Node 035] [REQ] [BridgeApplicationCommand]
│ RSSI: -76 dBm
└─[Security2CCMessageEncapsulation] [INVALID]
error: Duplicate command (sequence number 165)
2025-06-17 01:07:50.282 DRIVER one or more queues busy
2025-06-17 01:07:50.283 DRIVER » [REQ] [GetBackgroundRSSI]
2025-06-17 01:07:50.288 DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -109 dBm
channel 1: -95 dBm
channel 2: -95 dBm
channel 3: -105 dBm

Has anybody else been experiencing something like this?

Switching a device that is 6’ away to use LR likely isn’t the right solution. Try reincluding it in mesh mode as you have a very small network and need to make it a strong a possible. Once reincluded go repair the routes one by one to each mains powered device. Once that’s done shutdown, remove power, restart.

Next check the firmware version of the stick, and compare that against the Zooz release notes to see if a firmware update is needed.