Entire Z-wave network died for > 1hr - all channels at -128 dBm (ZWA-2)

Earlier today, I came home at night from an errand to non-responsive ZEN76 switches, which are used as scene controllers to turn Wifi lights on or off. None would respond. The ZSE18 motion sensor in my office also did not trigger, and the light remained off.

I had to pull my phone, open the HA app, and turn on my entire light group. Once I did so, I was surprised to see that the Z-Wave switches all immediately started responding.

I just inspected the Z-wave JS log, and I see the following starting at 18:37. Nobody was home at that time :

2025-11-15 18:37:34.163 DRIVER « [RES] [GetBackgroundRSSI]
                                   channel 0: -128 dBm
                                   channel 1: -128 dBm
                                   channel 2: -128 dBm
                                   channel 3: -128 dBm
2025-11-15 18:37:34.163 DRIVER   all queues idle
2025-11-15 18:38:04.057 DRIVER   one or more queues busy
2025-11-15 18:38:04.058 DRIVER » [REQ] [GetBackgroundRSSI]
2025-11-15 18:38:04.058 SERIAL » 0x0103003bc7                                                         (5 bytes)
2025-11-15 18:38:04.520 SERIAL « [ACK]                                                                   (0x06)
2025-11-15 18:38:04.521 SERIAL « 0x0107013b80808080c2                                                 (9 bytes)
2025-11-15 18:38:04.522 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 18:38:04.522 DRIVER « [RES] [GetBackgroundRSSI]
                                   channel 0: -128 dBm
                                   channel 1: -128 dBm
                                   channel 2: -128 dBm
                                   channel 3: -128 dBm
2025-11-15 18:38:04.522 DRIVER   all queues idle
2025-11-15 18:38:34.059 DRIVER   one or more queues busy

This continues over and over. There is no other activity at all, just repetitions of the above. The last entry is

2025-11-15 19:46:04.629 DRIVER   all queues idle
2025-11-15 19:46:34.198 DRIVER   one or more queues busy
2025-11-15 19:46:34.199 DRIVER » [REQ] [GetBackgroundRSSI]
2025-11-15 19:46:34.199 SERIAL » 0x0103003bc7                                                         (5 bytes)
2025-11-15 19:46:34.328 SERIAL « [ACK]                                                                   (0x06)
2025-11-15 19:46:34.329 SERIAL « 0x0107013b80808080c2                                                 (9 bytes)
2025-11-15 19:46:34.330 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 19:46:34.330 DRIVER « [RES] [GetBackgroundRSSI]
                                   channel 0: -128 dBm
                                   channel 1: -128 dBm
                                   channel 2: -128 dBm
                                   channel 3: -128 dBm
2025-11-15 19:46:34.331 DRIVER   all queues idle
2025-11-15 19:46:36.667 DRIVER   one or more queues busy

I just checked my HA log, and noted that I turned on my light group at 19:46:36, which is right after that last entry above . This is the time when I got impatient with the Z-Wave switches not responding, and pulled out my phone.

The next entries in the Z-Wave JS log are :

2025-11-15 19:46:36.668 DRIVER » [Node 296] [REQ] [SendDataBridge]
                                 │ source node id:   1
                                 │ transmit options: 0x25
                                 │ callback id:      76
                                 └─[Security2CCMessageEncapsulation]
                                   │ sequence number: 21
                                   └─[SupervisionCCGet]
                                     │ session id:      2
                                     │ request updates: true
                                     └─[BinarySwitchCCSet]
                                         target value: true
2025-11-15 19:46:36.668 SERIAL » 0x012200a900010128149f031500473e9d3c3267d2e1fda15105608209032500000 (36 bytes)
                                 0004cf6
2025-11-15 19:46:36.682 SERIAL « [ACK]                                                                   (0x06)
2025-11-15 19:46:36.684 SERIAL « 0x010401a90152                                                       (6 bytes)
2025-11-15 19:46:36.684 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 19:46:36.685 DRIVER « [RES] [SendDataBridge]
                                   was sent: true
2025-11-15 19:46:36.701 SERIAL « 0x011d00a94c00000100a77f7f7f7f0303010000000004010000fe80feb49809    (31 bytes)
2025-11-15 19:46:36.702 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 19:46:36.703 DRIVER « [REQ] [SendDataBridge]
                                   callback id:                           76
                                   transmit status:                       OK, took 10 ms
                                   routing attempts:                      1
                                   protocol & route speed:                Z-Wave Long Range, 100 kbit/s
                                   routing scheme:                        Direct
                                   ACK RSSI:                              -89 dBm
                                   ACK channel no.:                       3
                                   TX channel no.:                        3
                                   TX power:                              -2 dBm
                                   measured noise floor:                  -128 dBm
                                   ACK TX power by destination:           -2 dBm
                                   measured RSSI of ACK from destination: -76 dBm
                                   measured noise floor by destination:   -104 dBm
2025-11-15 19:46:36.721 SERIAL « 0x011f00a80000010128119f0344009c7e1058861d0e4bee7d4112f300a400fa982 (33 bytes)
                                 8
2025-11-15 19:46:36.723 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 19:46:36.724 DRIVER « [Node 296] [REQ] [BridgeApplicationCommand]
                                 │ RSSI: -92 dBm
                                 └─[Security2CCMessageEncapsulation]
                                   │ sequence number: 68
                                   │ security class:  S2_Authenticated
                                   └─[SupervisionCCReport]
                                       session id:          2
                                       more updates follow: false
                                       status:              Success
                                       duration:            0s
2025-11-15 19:46:36.725 CNTRLR   [Node 296] [~] [Binary Switch] currentValue: false => true        [Endpoint 0]

Node 296 is a ZEN76 800LR switch, which is used to control a traditional load - bathroom fan and regular (not smart) light on the same circuit. There is a corresponding “Light” device in HA for this switch. And it is part of the “Downstairs lights” light group that I turned on using the HA app.

It appears that the Z-Wave network completely died at 18:37:34 . Input from all the Z-wave devices I tried - multiple ZEN76 switches, both LR and non-LR, and a ZSE18 (non-LR) motion sensor - did not get to Z-Wave JS at all.

However, when I turned on the light group in HA at 19:36:36, Z-wave JS was able to successfully turn on my ZEN76 800LR bathroom fan switch. And from then on, Z-Wave started working again as it did before.

This is the first time I have ever had this experience, in about 3 years of using Z-Wave - first with a Zooz ZST10 controller, then ZST39, and now with the ZWA-2 .

I’m using the ZWA-2 with GA firmware v1.1 / SDK v7.23.1 . Z-Wave JS UI is 11.7.0 . Z-Wave JS is 15.16.0 .

The ZWA-2 is connected to a thick 10ft USB 2.0 extension cable, and resting on a shelf.

Edit : just looked at what happened immediately before all channels went to -128 dBm . The last node that communicated was 113 . This is a Zooz ZAC38 plug-in repeater.

2025-11-15 18:36:04.502 DRIVER   all queues idle
2025-11-15 18:36:11.738 SERIAL « 0x011d00a800000100710f9f0365005a512ae036f88b85be37ce00aa007f7f20    (31 bytes)
2025-11-15 18:36:11.740 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 18:36:11.741 CNTRLR   [Node 113] [~] [Battery] level: 97 => 97                          [Endpoint 0]
2025-11-15 18:36:11.742 DRIVER « [Node 113] [REQ] [BridgeApplicationCommand]
                                 │ RSSI: -86 dBm
                                 └─[Security2CCMessageEncapsulation]
                                   │ sequence number: 101
                                   │ security class:  S2_Authenticated
                                   └─[BatteryCCReport]
                                       level: 97
2025-11-15 18:36:34.054 DRIVER   one or more queues busy
2025-11-15 18:36:34.054 DRIVER » [REQ] [GetBackgroundRSSI]
2025-11-15 18:36:34.055 SERIAL » 0x0103003bc7                                                         (5 bytes)
2025-11-15 18:36:34.097 SERIAL « [ACK]                                                                   (0x06)
2025-11-15 18:36:34.097 SERIAL « 0x0107013b979595a1f4                                                 (9 bytes)
2025-11-15 18:36:34.098 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 18:36:34.098 DRIVER « [RES] [GetBackgroundRSSI]
                                   channel 0: -105 dBm
                                   channel 1: -107 dBm
                                   channel 2: -107 dBm
                                   channel 3: -95 dBm
2025-11-15 18:36:34.098 DRIVER   all queues idle
2025-11-15 18:37:04.055 DRIVER   one or more queues busy
2025-11-15 18:37:04.055 DRIVER » [REQ] [GetBackgroundRSSI]
2025-11-15 18:37:04.055 SERIAL » 0x0103003bc7                                                         (5 bytes)
2025-11-15 18:37:04.457 SERIAL « [ACK]                                                                   (0x06)
2025-11-15 18:37:04.457 SERIAL « 0x0107013ba293939dfd                                                 (9 bytes)
2025-11-15 18:37:04.457 SERIAL » [ACK]                                                                   (0x06)
2025-11-15 18:37:04.458 DRIVER « [RES] [GetBackgroundRSSI]
                                   channel 0: -94 dBm
                                   channel 1: -109 dBm
                                   channel 2: -109 dBm
                                   channel 3: -99 dBm

I am now suspecting that this ZAC38 repeater is misbehaving. I had one ZAC38 in the past that completely killed my ability to add non-LR devices. See Z-Wave woes - defective Zooz devices wreaking havoc .

I see a fair amount of “duplicate command” on the mesh nodes, and those might be caused by problems with the ZAC38 repeaters. But of course, it could be other devices acting as repeaters, too.

2025-11-15 07:18:36.284 DRIVER « [Node 121] [REQ] [BridgeApplicationCommand]
                                 │ RSSI: -76 dBm
                                 └─[Security2CCNonceGet] [INVALID]
                                     error: Duplicate command (sequence number 124)

I still have 6 of these ZAC38 plug-in repeaters on my network. Given what happened before, I think it’s time to exclude them all and unplug them. I will try to convert a few of the ZEN76 switches from LR to mesh, and use them as repeaters instead. I hope that works, as they are not in the same locations as the outlets that currently have the 6 ZAC38 plugged in - there is a fair amount of space between the wall switches. When I originally got the 7 ZAC38, I only had about 30 ZEN76, though. I now have 94 of them, as well as two ZEN75, and one ZEN32, as far as hardwired switches go.

A review of the Z-Wave JS log also showed bad MAC on multiple nodes. Three are First Alert ZCOMBO fire alarm/CO detectors. Two are Zooz ZSE18 motion sensors . One is a Zooz ZAC36 water valve actuator.

I will replace the ZSE18 with Yolink 7804. I have many spares. The hardware is much better than the ZSE18. They take take standard AAA batteries, including Eneloop rechargeables. The mount is superior. And they are far more responsive than Z-Wave - no lag problem with them, unlike all my Z-wave sensors and switches, which all take up to 3 seconds for HA to receive the input. Yolink is proprietary, though, and devices can’t be added without their app or Internet access. They can operate offline with Matter, though.

Not sure about the MAC errors with valve actuator or the fire/CO alarm yet.

There are also many intermittent problems with the LR switches as well, but they don’t show up as bad MAC .

[Node 271] failed to decode the message, retrying with SPAN extension...