Reading zwave-js logs -- why is switch turning off?

Configuration Z-Wave
1

I have a Zooz Zen15 switch that is (sometimes) unexpectedly turning off and I’m trying to figure out why.

You can see from the logbook that it was turned on by an automation at 12:44:05 and then then turned off just six seconds later at 12:44:11.

image
image1058×370 36.3 KB

Am I correct that because there’s no context in that “turned off” logbook entry that it didn’t originate from Home Assistant?

There is a context id in the states table:

sqlite> select state_id, state, last_updated_ts, datetime(last_updated_ts,'unixepoch', 'localtime') as updated, hex(states.context_id_bin) from states  where state_id = 48713440;
                  state_id = 48713440
                     state = off
           last_updated_ts = 1744400651.13597
                   updated = 2025-04-11 12:44:11
hex(states.context_id_bin) = 01962661937F865430130091B5129FC4

but I don’t see any events (assuming that’s how the state and event are linked):

sqlite> select * from events where context_id_bin = (select context_id_bin from states where state_id = 48713440);
sqlite>

(See background info below for extra details about the switch config)

Can I look at the zwave-js logs to determine what turned the switch off?

The zui logs show that the targetValue for the binary switch was changed false => true at 12:44:05. Then at 12:44:11.131 went true back to false that matches the logbook entries.

2025-04-11 12:44:05.344 INFO Z-WAVE: [Node 067] Value updated: 37-0-targetValue false => true
2025-04-11 12:44:05.349 INFO Z-WAVE: [Node 067] Value updated: 37-0-currentValue false => true
2025-04-11 12:44:05.474 INFO Z-WAVE: [Node 067] Value updated: 37-0-duration 0s => 0s
2025-04-11 12:44:05.478 INFO Z-WAVE: [Node 067] Value updated: 37-0-targetValue true => true
2025-04-11 12:44:05.482 INFO Z-WAVE: [Node 067] Value updated: 37-0-currentValue true => true
2025-04-11 12:44:09.008 INFO Z-WAVE: [Node 067] Metadata updated: 50-0-value-66049
2025-04-11 12:44:09.012 INFO Z-WAVE: [Node 067] Value updated: 50-0-value-66049 0 => 92.503
2025-04-11 12:44:09.168 INFO Z-WAVE: [Node 067] Metadata updated: 50-0-value-66817
2025-04-11 12:44:09.172 INFO Z-WAVE: [Node 067] Value updated: 50-0-value-66817 0 => 0.756
2025-04-11 12:44:11.127 INFO Z-WAVE: [Node 067] Value updated: 37-0-duration 0s => 0s
2025-04-11 12:44:11.131 INFO Z-WAVE: [Node 067] Value updated: 37-0-targetValue true => false
2025-04-11 12:44:11.134 INFO Z-WAVE: [Node 067] Value updated: 37-0-currentValue true => false

The zwave-js logs are more detailed (and much longer), but I don’t see anything to indicate what triggered the turn off. (UTC is +7h for me)

2025-04-11T19:44:09.194Z DRIVER   all queues idle
2025-04-11T19:44:11.116Z SERIAL .. 0x012300a80000010043159f037500b02ef816956f54c75183780528161f6b3d00a (37 bytes)
                                  9007f7fa2
2025-04-11T19:44:11.121Z SERIAL .. [ACK]                                                                   (0x06)
2025-04-11T19:44:11.125Z CNTRLR   [Node 067] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2025-04-11T19:44:11.130Z CNTRLR   [Node 067] [~] [Binary Switch] targetValue: true => false         [Endpoint 0]
2025-04-11T19:44:11.132Z CNTRLR   [Node 067] [~] [Binary Switch] currentValue: true => false        [Endpoint 0]
2025-04-11T19:44:11.135Z DRIVER .. [Node 067] [REQ] [BridgeApplicationCommand]
                                  ... RSSI: -87 dBm
                                  ......[Security2CCMessageEncapsulation]
                                    ... sequence number: 117
                                    ... security class:  S2_Authenticated
                                    ......[SupervisionCCGet]
                                      ... session id:      40
                                      ... request updates: false
                                      ......[BinarySwitchCCReport]
                                          current value: false
                                          target value:  false
                                          duration:      0s
2025-04-11T19:44:11.138Z DRIVER   one or more queues busy
2025-04-11T19:44:11.140Z DRIVER .. [Node 067] [REQ] [SendDataBridge]
                                  ... source node id:   1
                                  ... transmit options: 0x24
                                  ... callback id:      0
                                  ......[Security2CCMessageEncapsulation]
                                    ... sequence number: 225
                                    ......[SupervisionCCReport]
                                        session id:          40
                                        more updates follow: false
                                        status:              Success
                                        duration:            0s
2025-04-11T19:44:11.141Z SERIAL .. 0x011f00a900010043119f03e10084432893670096bc8e09cf85952400000000002 (33 bytes)
                                  a
2025-04-11T19:44:11.149Z SERIAL .. [ACK]

Does any of that offer an idea of why it is turning off?

Additional background info I have a Zooz Zen15 switch that runs a small pump. It is turned on via an automation. An automation triggers when the pump turns on and sets a 2 minute timer to turn it off again. Been working perfectly a very long time.

The Zen15 is configured to turn off after 6 minutes, so that’s not the issue:

image
image1272×328 6.56 KB

And it did not turn off due to overcurrent:

image
image1116×542 27.5 KB

2

I’m kind of guessing here, but my guess is that the event in the logs where it looks like it is turning the switch to “on” is just an “attempt” to turn it on, but after a few seconds, ZWave decided it was not successful so updated itself to reflect the actual (i.e. not turned on thus “off”). Maybe go over to where the switch is loacted and take a look at the switch itself to see if it actually turned on when it was suppose to.

3

I think you are correct. This looks like the request to turn it on:

2025-04-11T19:44:05.290Z DRIVER » [Node 067] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      170
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 221
                                    └─[SupervisionCCGet]
                                      │ session id:      13
                                      │ request updates: true
                                      └─[BinarySwitchCCSet]
                                          target value: true
2025-04-11T19:44:05.291Z SERIAL » 0x012200a900010043149f03dd001472cd510e201d7a45a52cf655437aa22500000 (36 bytes)
                                  000aaab
2025-04-11T19:44:05.300Z SERIAL « [ACK]                                                                   (0x06)
...
2025-04-11T19:44:05.347Z CNTRLR   [Node 067] [~] [Binary Switch] currentValue: false => true        [Endpoint 0]

But soon after there’s an invalid payload and Duplicate command:


2025-04-11T19:44:05.354Z DRIVER   all queues idle
2025-04-11T19:44:05.360Z SERIAL « 0x011f00a80000010043119f037100babbadce08ad02eb9f2d4995e300a9007f7ff (33 bytes)
                                  c
2025-04-11T19:44:05.363Z DRIVER   Dropping message with invalid payload
2025-04-11T19:44:05.364Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -87 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Duplicate command (sequence number 113)
2025-04-11T19:44:05.364Z SERIAL » [ACK]                                                                   (0x06)
2025-04-11T19:44:05.449Z SERIAL « 0x011f00a80000010043119f037100babbadce08ad02eb9f2d4995e300ad007f7ff (33 bytes)
                                  8
2025-04-11T19:44:05.452Z DRIVER   Dropping message with invalid payload
2025-04-11T19:44:05.453Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -83 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Duplicate command (sequence number 113)
2025-04-11T19:44:05.454Z SERIAL » [ACK]

I haven’t quite learned how to read these logs – I can’t always tell what logs are related to a given node.

And I’m not clear what these mean. Why is the targetValue going from true to true?

2025-04-11T19:44:05.473Z CNTRLR   [Node 067] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2025-04-11T19:44:05.476Z CNTRLR   [Node 067] [~] [Binary Switch] targetValue: true => true          [Endpoint 0]
2025-04-11T19:44:05.480Z CNTRLR   [Node 067] [~] [Binary Switch] currentValue: true => true         [Endpoint 0]

It’s hard because I’m not that familiar with Z-wave protocol.

4

What’s happening is the switch is turning on, but then it turns off after a few seconds. The switch (Zen15) isn’t reporting overcurrent, and it’s not running a heavy load. Nothing in configuration that would shut it off, and most of the time is works as expected.

root@a0d7b954-zwavejs2mqtt:/data/store/logs$ cat z-ui_current.log | grep 067 | grep targetValue | grep 10:39:5
2025-04-21 10:39:50.965 INFO Z-WAVE: [Node 067] Value updated: 37-0-targetValue false => true
2025-04-21 10:39:51.036 INFO Z-WAVE: [Node 067] Value updated: 37-0-targetValue true => true
2025-04-21 10:39:57.400 INFO Z-WAVE: [Node 067] Value updated: 37-0-targetValue true => false

There’s a gap in time (about 6.8 seconds) and then the node just reports that the switch is off. That makes me think that the device is turning off for some unknown reason. Just out of the blue the node sends a BridgeApplicationCommand report saying the current value is false. I.e. there’s no BinarySwitchCCSet sent first to the node to turn the device off:

2025-04-21T17:39:56.411Z DRIVER   all queues idle
2025-04-21T17:39:57.385Z SERIAL « 0x012300a80000010043159f03c80085418ad95eb07d020955aa139e9bd1f04800a (37 bytes)
                                  d007f7f55
2025-04-21T17:39:57.391Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:57.394Z CNTRLR   [Node 067] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2025-04-21T17:39:57.398Z CNTRLR   [Node 067] [~] [Binary Switch] targetValue: true => false         [Endpoint 0]
2025-04-21T17:39:57.402Z CNTRLR   [Node 067] [~] [Binary Switch] currentValue: true => false        [Endpoint 0]
2025-04-21T17:39:57.404Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -83 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 200
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCGet]
                                      │ session id:      9
                                      │ request updates: false
                                      └─[BinarySwitchCCReport]
                                          current value: false
                                          target value:  false
                                          duration:      0s

Am I reading the correctly?

One thing of note (in the logs below) is that node 067 apparently sends a duplicate BridgeApplicationCommand message – or at least the driver reports a duplicate message. I think the node might do that if it didn’t receive and ACK from the first one. But, the duplicate message is reported only 0.049 later, which doesn’t seem long enough for the node to wait to send it again. Have to wonder if there really was a duplicate sent.

Here's all the logs, from initially turning it on until it turns off.

This shows the driver sending the command to the node to turn on the binary switch.

2025-04-21T17:39:50.907Z DRIVER » [Node 067] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      174
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 182
                                    └─[SupervisionCCGet]
                                      │ session id:      22
                                      │ request updates: true
                                      └─[BinarySwitchCCSet]
                                          target value: true
                                                                  (0x06)
2025-04-21T17:39:50.908Z SERIAL » 0x012200a900010043149f03b600bc058c95f6cf6a31c2b5ee68d48c9c702500000 (36 bytes)
                                  000ae04
2025-04-21T17:39:50.916Z SERIAL « [ACK]                                                                   (0x06)
2025-04-21T17:39:50.920Z SERIAL « 0x010401a90152                                                       (6 bytes)
2025-04-21T17:39:50.921Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:50.923Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true

The request was queued for transmission on the stick.

Then next the stick tells the driver that the transmission (for ID 174) was OK – successfully sent.


2025-04-21T17:39:50.939Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            174
                                    transmit status:        OK, took 10 ms
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 100 kbit/s
                                    routing scheme:         LWR
                                    ACK RSSI:               -83 dBm
                                    ACK channel no.:        0
                                    TX channel no.:         0
2025-04-21T17:39:50.957Z SERIAL « 0x011f00a80000010043119f03c400ffb816f23dae2ae0c93d0ffe8800ad007f7f9 (33 bytes)
                                  9
2025-04-21T17:39:50.960Z SERIAL » [ACK]

And finally the node responds with a BridgeApplicationCommand, showing the RSSI and Success:

2025-04-21T17:39:50.962Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -83 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 196
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCReport]
                                        session id:          22
                                        more updates follow: false
                                        status:              Success
                                        duration:            0s
2025-04-21T17:39:50.968Z CNTRLR   [Node 067] [~] [Binary Switch] currentValue: false => true        [Endpoint 0]
2025-04-21T17:39:50.972Z DRIVER   all queues idle
                                  4

Now an error occurs. Looks like the DRIVER now receives a duplicate BridgeApplicationCommand from the device (sequence 196 was received already above).

I can’t really tell from the logs if the DRIVER ACK’d message 196, but it seems like the Zen15 resent the message 0.049 seconds later, which seems unlikely if it was waiting for an ACK.

2025-04-21T17:39:51.010Z DRIVER   Dropping message with invalid payload
2025-04-21T17:39:51.011Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -80 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Duplicate command (sequence number 196)
2025-04-21T17:39:51.011Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:51.025Z SERIAL « 0x012300a80000010043159f03c50062db411fa1dede8c7e9c80977da7c2a4c700a (37 bytes)
                                  f007f7f91
2025-04-21T17:39:51.029Z SERIAL » [ACK]

I’m not sure what the follow represent CNTRLR message mean:

2025-04-21T17:39:51.031Z CNTRLR   [Node 067] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2025-04-21T17:39:51.034Z CNTRLR   [Node 067] [~] [Binary Switch] targetValue: true => true          [Endpoint 0]
2025-04-21T17:39:51.037Z CNTRLR   [Node 067] [~] [Binary Switch] currentValue: true => true         [Endpoint 0]

Next the driver receives another BridgeApplicationCommand from the node with a new sequence number reporting the switch is on.


2025-04-21T17:39:51.041Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -81 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 197
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCGet]
                                      │ session id:      6
                                      │ request updates: false
                                      └─[BinarySwitchCCReport]
                                          current value: true
                                          target value:  true
                                          duration:      0s

Now the DRIVER asks the node for a report of the node’s status with callback ID = 175, and receives a response from the node.

2025-04-21T17:39:51.046Z DRIVER » [Node 067] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x00
                                  │ callback id:      175
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 183
                                    └─[SupervisionCCReport]
                                        session id:          6
                                        more updates follow: false
                                        status:              Success
                                        duration:            0s
2025-04-21T17:39:51.047Z SERIAL » 0x011f00a900010043119f03b700ad784015f3ce1e2c6d1928f0a70000000000af1 (33 bytes)
                                  a
2025-04-21T17:39:51.055Z SERIAL « [ACK]                                                                   (0x06)
2025-04-21T17:39:51.058Z SERIAL « 0x010401a90152                                                       (6 bytes)
2025-04-21T17:39:51.059Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:51.060Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2025-04-21T17:39:51.070Z SERIAL « 0x011d00a9af000001007f7f7f7f7f000003000000000301000000000000009b    (31 bytes)
2025-04-21T17:39:51.071Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:51.072Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:                           175
                                    transmit status:                       OK, took 10 ms
                                    routing attempts:                      1
                                    protocol & route speed:                Z-Wave, 100 kbit/s
                                    routing scheme:                        LWR
                                    ACK RSSI:                              N/A
                                    ACK channel no.:                       0
                                    TX channel no.:                        0
                                    TX power:                              0 dBm
                                    measured noise floor:                  0 dBm
                                    ACK TX power by destination:           0 dBm
                                    measured RSSI of ACK from destination: 0 dBm
                                    measured noise floor by destination:   0 dBm

Now that the Zen15 switch is on, the node (067) starts sending power reports (Watts, Amps).

I’m curious why it seems like every time the node sends a report the driver then asks for a SupervisionCCReport. I’m not clear why that is needed after every report.

Anyway, here’s those power updates, although nothing very interesting.

2025-04-21T17:39:54.269Z CNTRLR   [Node 067] [Meter] value[66049]: metadata updated                 [Endpoint 0]
2025-04-21T17:39:54.273Z CNTRLR   [Node 067] [~] [Meter] value[66049]: 0 => 92.184                  [Endpoint 0]
2025-04-21T17:39:54.280Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -81 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 198
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCGet]
                                      │ session id:      7
                                      │ request updates: false
                                      └─[MeterCCReport]
                                          meter type: Electric
                                          scale:      W
                                          rate type:  Consumed
                                          value:      92.184
                                          time delta: 0 seconds
2025-04-21T17:39:54.284Z DRIVER   one or more queues busy
2025-04-21T17:39:54.287Z DRIVER » [Node 067] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x00
                                  │ callback id:      185
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 184
                                    └─[SupervisionCCReport]
                                        session id:          7
                                        more updates follow: false
                                        status:              Success
                                        duration:            0s
2025-04-21T17:39:54.288Z SERIAL » 0x011f00a900010043119f03b8004cb96895238b76b9dd9205db3b0000000000b94 (33 bytes)
                                  2
2025-04-21T17:39:54.299Z SERIAL « [ACK]                                                                   (0x06)
2025-04-21T17:39:54.302Z SERIAL « 0x010401a90152                                                       (6 bytes)
2025-04-21T17:39:54.304Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:54.306Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2025-04-21T17:39:54.313Z SERIAL « 0x011d00a9b9000000007f7f7f7f7f000003000000000301000000000000008c    (31 bytes)
2025-04-21T17:39:54.315Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:54.316Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:                           185
                                    transmit status:                       OK, took 0 ms
                                    routing attempts:                      1
                                    protocol & route speed:                Z-Wave, 100 kbit/s
                                    routing scheme:                        LWR
                                    ACK RSSI:                              N/A
                                    ACK channel no.:                       0
                                    TX channel no.:                        0
                                    TX power:                              0 dBm
                                    measured noise floor:                  0 dBm
                                    ACK TX power by destination:           0 dBm
                                    measured RSSI of ACK from destination: 0 dBm
                                    measured noise floor by destination:   0 dBm
2025-04-21T17:39:54.387Z SERIAL « 0x012800a800000100431a9f03c700866b45679c935b05bc0bf500bd241c4ed0e1b (42 bytes)
                                  83799ef00af007f7f0c
2025-04-21T17:39:54.391Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:54.394Z CNTRLR   [Node 067] [Meter] value[66817]: metadata updated                 [Endpoint 0]
2025-04-21T17:39:54.399Z CNTRLR   [Node 067] [~] [Meter] value[66817]: 0 => 0.754                   [Endpoint 0]
2025-04-21T17:39:54.403Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -81 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 199
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCGet]
                                      │ session id:      8
                                      │ request updates: false
                                      └─[MeterCCReport]
                                          meter type: Electric
                                          scale:      A
                                          rate type:  Consumed
                                          value:      0.754
                                          time delta: 0 seconds
2025-04-21T17:39:54.822Z DRIVER » [Node 067] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x00
                                  │ callback id:      186
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 185
                                    └─[SupervisionCCReport]
                                        session id:          8
                                        more updates follow: false
                                        status:              Success
                                        duration:            0s
2025-04-21T17:39:54.823Z SERIAL » 0x011f00a900010043119f03b90002b1b9a93066d3760942f5e1130000000000ba9 (33 bytes)
                                  9
2025-04-21T17:39:54.832Z SERIAL « [ACK]                                                                   (0x06)
2025-04-21T17:39:54.834Z SERIAL « 0x010401a90152                                                       (6 bytes)
2025-04-21T17:39:54.836Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:54.837Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2025-04-21T17:39:54.845Z SERIAL « 0x011d00a9ba000001007f7f7f7f7f000003000000000301000000000000008e    (31 bytes)
2025-04-21T17:39:54.847Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:54.848Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:                           186
                                    transmit status:                       OK, took 10 ms
                                    routing attempts:                      1
                                    protocol & route speed:                Z-Wave, 100 kbit/s
                                    routing scheme:                        LWR
                                    ACK RSSI:                              N/A
                                    ACK channel no.:                       0
                                    TX channel no.:                        0
                                    TX power:                              0 dBm
                                    measured noise floor:                  0 dBm
                                    ACK TX power by destination:           0 dBm
                                    measured RSSI of ACK from destination: 0 dBm
                                    measured noise floor by destination:   0 dBm
2025-04-21T17:39:55.132Z SERIAL « 0x012800a800000100521a9f03760053f8528ea3cf56e3ed05a19773ee9b135ddc7 (42 bytes)
                                  b11718500af007f7f09
2025-04-21T17:39:55.137Z SERIAL » [ACK]

Then, out of the blue, it appears the node sends a BridgeApplicationCommand saying that the node has turned off. The DRIVER follows with another SupervisionCCReport request:

2025-04-21T17:39:56.411Z DRIVER   all queues idle
2025-04-21T17:39:57.385Z SERIAL « 0x012300a80000010043159f03c80085418ad95eb07d020955aa139e9bd1f04800a (37 bytes)
                                  d007f7f55
2025-04-21T17:39:57.391Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:57.394Z CNTRLR   [Node 067] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2025-04-21T17:39:57.398Z CNTRLR   [Node 067] [~] [Binary Switch] targetValue: true => false         [Endpoint 0]
2025-04-21T17:39:57.402Z CNTRLR   [Node 067] [~] [Binary Switch] currentValue: true => false        [Endpoint 0]
2025-04-21T17:39:57.404Z DRIVER « [Node 067] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -83 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 200
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCGet]
                                      │ session id:      9
                                      │ request updates: false
                                      └─[BinarySwitchCCReport]
                                          current value: false
                                          target value:  false
                                          duration:      0s
2025-04-21T17:39:57.407Z DRIVER   one or more queues busy
2025-04-21T17:39:57.412Z DRIVER » [Node 067] [REQ] [SendDataBridge]
                                  │ source node id:   1
                                  │ transmit options: 0x00
                                  │ callback id:      189
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 186
                                    └─[SupervisionCCReport]
                                        session id:          9
                                        more updates follow: false
                                        status:              Success
2025-04-21T17:39:57.413Z SERIAL » 0x011f00a900010043119f03ba00a3ae5fdddea494b06e877282c50000000000bd8 (33 bytes)
                                  c
2025-04-21T17:39:57.421Z SERIAL « [ACK]                                                                   (0x06)
2025-04-21T17:39:57.424Z SERIAL « 0x010401a90152                                                       (6 bytes)
2025-04-21T17:39:57.426Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:57.427Z DRIVER « [RES] [SendDataBridge]
                                    was sent: true
2025-04-21T17:39:57.435Z SERIAL « 0x011d00a9bd000001007f7f7f7f7f0000030000000003010000000000000089    (31 bytes)
2025-04-21T17:39:57.437Z SERIAL » [ACK]                                                                   (0x06)
2025-04-21T17:39:57.438Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:                           189
                                    transmit status:                       OK, took 10 ms
                                    routing attempts:                      1
                                    protocol & route speed:                Z-Wave, 100 kbit/s
                                    routing scheme:                        LWR
                                    ACK RSSI:                              N/A
                                    ACK channel no.:                       0
                                    TX channel no.:                        0
                                    TX power:                              0 dBm
                                    measured noise floor:                  0 dBm
                                    ACK TX power by destination:           0 dBm
                                    measured RSSI of ACK from destination: 0 dBm
                                    measured noise floor by destination:   0 dBm

And that’s everything.

5

This kind of sucks. I replaced the Zen15 Power Switch with a new one and the problem went away for many weeks. Now it is back. I still cannot figure out if the Zen15 it turning itself off, or if Home Assistant is telling it to turn off.

How do I know if the line a 07:56:25.516 is the switch turning itself off and reporting that, or if that’s HA telling the switch to turn off?

root@a0d7b954-zwavejs2mqtt:/data/store/logs$ fgrep 'Node 087' z-ui_current.log | grep -E 'target|current'
2025-07-22 07:56:21.821 INFO Z-WAVE: [Node 087] Value updated: 37-0-targetValue false => true
2025-07-22 07:56:21.828 INFO Z-WAVE: [Node 087] Value updated: 37-0-currentValue false => true
2025-07-22 07:56:21.918 INFO Z-WAVE: [Node 087] Value updated: 37-0-targetValue true => true
2025-07-22 07:56:21.922 INFO Z-WAVE: [Node 087] Value updated: 37-0-currentValue true => true
2025-07-22 07:56:25.516 INFO Z-WAVE: [Node 087] Value updated: 37-0-targetValue true => false
2025-07-22 07:56:25.524 INFO Z-WAVE: [Node 087] Value updated: 37-0-currentValue true => false
2025-07-22 08:03:56.846 INFO Z-WAVE: [Node 087] Value updated: 37-0-targetValue false => true
2025-07-22 08:03:56.853 INFO Z-WAVE: [Node 087] Value updated: 37-0-currentValue false => true
2025-07-22 08:03:56.896 INFO Z-WAVE: [Node 087] Value updated: 37-0-targetValue true => true
2025-07-22 08:03:56.902 INFO Z-WAVE: [Node 087] Value updated: 37-0-currentValue true => true

Here’s a weird log from earlier today, note that is saying the automation turned it off.

It’s the two earliest events at the bottom – note that both are switch.turn_on actions:

image
image1140×992 93.3 KB

But, here’s the traces from those two automation events:

image
image1202×558 23.3 KB

And then the “previous” trace (which is later in time??):

image
image1224×570 23.3 KB

Note that both actions are switch.turn_on, so the automation didn’t turn the switch off. Plus, the timing doesn’t match the logs. The script mode is “queued”.

I’ll dig into the z-wave-js logs when I have some free time.

6

All those state changes have context, and it points to your automation. I suggest you post the automation Single Light wall switches Scene Controller.

7

Sure. Just to show you a bigger picture of the automation flow to show it’s just switch.turn_on. It’s triggering on primary_bath_fan_zen71_scene_001 double tapped (KeyPressed2x).

image
image1650×1420 247 KB

There’s no trace from this morning with that automation that has any switch.turn_off.

Here's the context for that trace: 
this:
  entity_id: automation.100_double_tap_switches
  state: 'on'
  attributes:
    id: '1738551194806'
    last_triggered: '2025-07-21T14:57:43.724288+00:00'
    mode: queued
    current: 0
    max: 10
    friendly_name: Single Light wall switches Scene Controller
  last_changed: '2025-07-20T19:42:07.307297+00:00'
  last_reported: '2025-07-21T14:57:43.926102+00:00'
  last_updated: '2025-07-21T14:57:43.926102+00:00'
  context:
    id: 01K0PQV79BK665XE19FNQX24BM
    parent_id: 01K0PQV79A1FZ42H5D0H4R2ESG
    user_id: null
trigger:
  id: '0'
  idx: '0'
  alias: null
  platform: state
  entity_id: event.primary_bath_fan_zen71_scene_001
  from_state:
    entity_id: event.primary_bath_fan_zen71_scene_001
    state: '2025-07-21T14:57:43.721+00:00'
    attributes:
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
      event_type: KeyPressed2x
      value: 3
      friendly_name: Primary Bath Fan Zen71 Scene 001
    last_changed: '2025-07-21T14:57:43.722017+00:00'
    last_reported: '2025-07-21T14:57:43.722017+00:00'
    last_updated: '2025-07-21T14:57:43.722017+00:00'
    context:
      id: 01K0PQV79A1FZ42H5D0H4R2ESG
      parent_id: null
      user_id: null
  to_state:
    entity_id: event.primary_bath_fan_zen71_scene_001
    state: '2025-07-22T14:56:21.697+00:00'
    attributes:
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
      event_type: KeyPressed2x
      value: 3
      friendly_name: Primary Bath Fan Zen71 Scene 001
    last_changed: '2025-07-22T14:56:21.697332+00:00'
    last_reported: '2025-07-22T14:56:21.697332+00:00'
    last_updated: '2025-07-22T14:56:21.697332+00:00'
    context:
      id: 01K0SA5E61CMQTZT3GX47ZQTKS
      parent_id: null
      user_id: null
  for: null
  attribute: null
  description: state of event.primary_bath_fan_zen71_scene_001
And the "previous" one at 07:57:43 
this:
  entity_id: automation.100_double_tap_switches
  state: 'on'
  attributes:
    id: '1738551194806'
    last_triggered: '2025-07-20T20:53:45.413781+00:00'
    mode: queued
    current: 0
    max: 10
    friendly_name: Single Light wall switches Scene Controller
  last_changed: '2025-07-20T19:42:07.307297+00:00'
  last_reported: '2025-07-20T20:53:46.066632+00:00'
  last_updated: '2025-07-20T20:53:46.066632+00:00'
  context:
    id: 01K0MSTDA46015GNHYHJPGV1FP
    parent_id: 01K0MSTDA3CFVSWXSS4DV040SJ
    user_id: null
trigger:
  id: '0'
  idx: '0'
  alias: null
  platform: state
  entity_id: event.primary_bath_fan_zen71_scene_001
  from_state:
    entity_id: event.primary_bath_fan_zen71_scene_001
    state: '2025-07-20T17:31:51.696+00:00'
    attributes:
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
      event_type: KeyPressed2x
      value: 3
      friendly_name: Primary Bath Fan Zen71 Scene 001
    last_changed: '2025-07-20T19:42:02.510659+00:00'
    last_reported: '2025-07-20T19:42:02.510659+00:00'
    last_updated: '2025-07-20T19:42:02.510659+00:00'
    context:
      id: 01K0MNQ38EPK944SFMV8NDMQW3
      parent_id: null
      user_id: null
  to_state:
    entity_id: event.primary_bath_fan_zen71_scene_001
    state: '2025-07-21T14:57:43.721+00:00'
    attributes:
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
      event_type: KeyPressed2x
      value: 3
      friendly_name: Primary Bath Fan Zen71 Scene 001
    last_changed: '2025-07-21T14:57:43.722017+00:00'
    last_reported: '2025-07-21T14:57:43.722017+00:00'
    last_updated: '2025-07-21T14:57:43.722017+00:00'
    context:
      id: 01K0PQV79A1FZ42H5D0H4R2ESG
      parent_id: null
      user_id: null
  for: null
  attribute: null
  description: state of event.primary_bath_fan_zen71_scene_001

The automation handles a bunch of scene controllers, so it’s a bit TMI. But, I did have a different automation for turning on this switch previously and did the same thing.

Full automation 
alias: Single Light wall switches Scene Controller
description:""
triggers:
  - trigger: state
    not_from: unavailable
    not_to: unavailable
    entity_id:
      - event.living_room_cans_scene_001
      - event.living_room_cans_scene_002
      - event.wall_splash_scene_001
      - event.cabinet_lights_scene_001
      - event.family_room_cans_scene_001
      - event.family_room_cans_scene_002
      - event.recirc_pump_remote_switch_scene_001
      - event.recirc_pump_remote_switch_scene_002
      - event.primary_bath_fan_zen71_scene_001
      - event.2nd_bath_fan_scene_001
      - event.craft_fan_switch_scene_001
      - event.craft_fan_switch_scene_002
      - event.guest_fan_switch_scene_001
      - event.guest_fan_switch_scene_002
actions:
  - variables:
      debug: false
      buttons:
        guest__001_KeyPressed:
          - switch.turn_on
          - switch.guest_fan_power
          - {}
        guest__002_KeyPressed:
          - switch.turn_off
          - switch.guest_fan_power
          - {}
        craft__001_KeyPressed:
          - switch.turn_on
          - switch.craft_fan_power
          - {}
        craft__002_KeyPressed:
          - switch.turn_off
          - switch.craft_fan_power
          - {}
        living_001_KeyPressed2x:
          - light.turn_on
          - light.living_room_cans
          - brightness_pct: 100
        living_001_KeyPressed3x:
          - scene.turn_on
          - scene.living_room_cozy
          - {}
        living_002_KeyPressed2x_see_below:
          - scene.turn_on
          - scene.living_room_all_off
          - {}
        wall_s_001_KeyPressed2x:
          - light.turn_on
          - light.wall_splash
          - brightness_pct: 100
        cabine_001_KeyPressed2x:
          - light.turn_on
          - light.cabinet_lights
          - brightness_pct: 100
        family_001_KeyPressed2x:
          - scene.turn_on
          - scene.family_room_bright
          - {}
        family_002_KeyPressed2x:
          - scene.turn_on
          - scene.family_room_off_after_tv
          - {}
        recirc_002_KeyPressed:
          - light.turn_off
          - light.kitchen_sink_light
          - {}
        primar_001_KeyPressed2x:
          - switch.turn_on
          - switch.recirculation_pump_power
          - {}
        2nd_ba_001_KeyPressed:
          - switch.turn_on
          - switch.recirculation_pump_power
          - {}
      key: >-
        {{ trigger.entity_id[6:12] + '_' + trigger.entity_id[-3:] + '_' +
        state_attr(trigger.entity_id,"event_type") }}
      the_action: "{{ buttons[key] if key in buttons else '' }}"
  - if:
      - alias: Check for debug flag on and create notification
        condition: template
        value_template: "{{ debug }}"
    then:
      - action: persistent_notification.create
        data:
          title: "{{ this.attributes.friendly_name }}"
          message: >
            The key is: {{ key }}, and the action is: {{ the_action[0] if
            the_action else "Not defined" }}
  - choose:
      - alias: Check if event is configured.
        conditions:
          - condition: template
            value_template: |
              {{ not not the_action }}
        sequence:
          - action: "{{ the_action[0] }}"
            metadata: {}
            target:
              entity_id: "{{ the_action[1] }}"
            data: "{{ the_action[2] }}"
      - alias: Check if 2x Living cans to turn off all lights
        conditions:
          - condition: template
            value_template: |
              {{ key == 'living_002_KeyPressed2x' }}
        sequence:
          - action: scene.turn_on
            target:
              entity_id: scene.living_room_all_off
            data: {}
          - if:
              - condition: time
                after: "20:00:00"
              - condition: numeric_state
                entity_id: zone.home
                above: 0
            then:
              - metadata: {}
                data:
                  brightness_pct: 10
                target:
                  entity_id: light.hallway_lights
                action: light.turn_on
      - alias: Kitchen recirc pump switch and/or light
        conditions:
          - condition: template
            value_template: |
              {{ key == 'recirc_001_KeyPressed' }}
        sequence:
          - action: switch.turn_on
            target:
              entity_id: switch.recirculation_pump_power
            data: {}
          - if:
              - condition: state
                entity_id: sun.sun
                state: below_horizon
            then:
              - action: light.turn_on
                target:
                  entity_id: light.kitchen_sink_light
                data:
                  brightness_pct: 100
mode: queued

Update: Can I get more info from the database? Looks like there’s a row written at the start and stop of each automation run. It’s interesting that the later time ran before the earlier one.

sqlite> select * from states_meta where entity_id = 'automation.100_double_tap_switches';
metadata_id = 10532
  entity_id = automation.100_double_tap_switches

sqlite> select state_id, state, DATETIME(last_updated_ts,'unixepoch','localtime','subsec') from states where metadata_id = 10532 order by state_id desc limit 7;
state_id  state  DATETIME(last_updated_ts,'unixepoch','localtime','subsec')
--------  -----  ----------------------------------------------------------
62280213  on     2025-07-22 08:03:56.897
62280205  on     2025-07-22 08:03:56.744
62279475  on     2025-07-22 07:56:21.873
62279467  on     2025-07-22 07:56:21.702
62147928  on     2025-07-21 07:57:43.926
62147908  on     2025-07-21 07:57:43.724
62044924  on     2025-07-20 13:53:46.067
8

This is the trace you should be focusing on

image
image630×130 12.4 KB

9

But there isn’t one at that time. Or not what is recorded in the states table.

Update: Looks like I have a lead. Have to dig into it later, but I see events where there’s an explicit turn_off…

Oh, no, that is the timer turning it off after 2 minutes.

sqlite> select * from state_events where event_type = 'call_service' and shared_data like '%switch.recirculation_pump_power%' and shared_data like '%turn_off%'  order by event_id desc limit 10;
event_id  parent_id  state_id  time_fired               event_type    shared_data
--------  ---------  --------  -----------------------  ------------  ------------------------------------------------------------
1272562   1272560    62280398  2025-07-22 08:05:56.009  call_service  {"domain":"switch","service":"turn_off","service_data":{"ent
                                                                      ity_id":["switch.recirculation_pump_power"]}}

1272562   1272560    62280399  2025-07-22 08:05:56.009  call_service  {"domain":"switch","service":"turn_off","service_data":{"ent
                                                                      ity_id":["switch.recirculation_pump_power"]}}

1271053   1271051    62148098  2025-07-21 07:59:43.006  call_service  {"domain":"switch","service":"turn_off","service_data":{"ent
                                                                      ity_id":["switch.recirculation_pump_power"]}}

1271053   1271051    62148099  2025-07-21 07:59:43.006  call_service  {"domain":"switch","service":"turn_off","service_data":{"ent
                                                                      ity_id":["switch.recirculation_pump_power"]}}
10

it may not be coming from a call service. You have some scenes in that automation

11

I appreciate your engagement. Thanks.

True, but there’s no scene that controls/includes the pump, and nothing I can find in the databas pointing to that.

The log entry says it was 07:56:25 when the state changed to off.

image
image994×248 39 KB

Check this out: Look at the two states, 62279494 and 62279468:

sqlite> select * from states_by_name where entity_name = 'switch.recirculation_pump_power'  order by state_id desc limit 5;
state_id  entity_name                      entity_id  state  state_updated  anything_updated         last_reported
--------  -------------------------------  ---------  -----  -------------  -----------------------  -----------------------
62280399  switch.recirculation_pump_power  1833       off                   2025-07-22 08:05:56.094
62280206  switch.recirculation_pump_power  1833       on                    2025-07-22 08:03:56.857  2025-07-22 08:05:56.089
62279494  switch.recirculation_pump_power  1833       off                   2025-07-22 07:56:25.528  2025-07-22 08:03:56.851
62279468  switch.recirculation_pump_power  1833       on                    2025-07-22 07:56:21.832  2025-07-22 07:56:25.520
62148099  switch.recirculation_pump_power  1833       off                   2025-07-21 07:59:43.094  2025-07-22 07:56:21.825

Above the swtich turns on at 07:56:21.832 with state_id of 62279468, and then turns off at 07:56:25.528, 3.7 seconds later, with state_id 62279494.

I should be able to recreate that log message by linking their contexts.

If my state_events view is correct, that “off” state is pointing to these events, which include switch.turn_on, not a switch turn off.

sqlite> select * from state_events where state_id = 62279494;
event_id  parent_id  state_id  time_fired               event_type            shared_data
--------  ---------  --------  -----------------------  --------------------  ------------------------------------------------------------
1272514              62279494  2025-07-22 07:56:21.701  automation_triggered  {"name":"Single Light wall switches Scene Controller","entit
                                                                              y_id":"automation.100_double_tap_switches","source":"state o
                                                                              f event.primary_bath_fan_zen71_scene_001"}

1272515              62279494  2025-07-22 07:56:21.713  call_service          {"domain":"switch","service":"turn_on","service_data":{"enti
                                                                              ty_id":["switch.recirculation_pump_power"]}}

BUT, those are the same event_ids as for the state_id = 62279468 for the turn on state a few seconds before:

sqlite> select * from state_events where state_id = 62279468;
event_id  parent_id  state_id  time_fired               event_type            shared_data
--------  ---------  --------  -----------------------  --------------------  ------------------------------------------------------------
1272514              62279468  2025-07-22 07:56:21.701  automation_triggered  {"name":"Single Light wall switches Scene Controller","entit
                                                                              y_id":"automation.100_double_tap_switches","source":"state o
                                                                              f event.primary_bath_fan_zen71_scene_001"}

1272515              62279468  2025-07-22 07:56:21.713  call_service          {"domain":"switch","service":"turn_on","service_data":{"enti
                                                                              ty_id":["switch.recirculation_pump_power"]}}

Somehow the switch turned off but seems to be linked to the same events that turned it on 3.7 seconds earlier.

Again, maybe I’m not following the context correctly. Here’s the view:

CREATE VIEW state_events
(event_id, parent_id, state_id, time_fired, event_type, shared_data)
AS
SELECT
e.event_id,
p.event_id,
s.state_id,
DATETIME(e.time_fired_ts,'unixepoch','localtime','subsec'),
t.event_type,
d.shared_data
FROM
events e
LEFT JOIN states s on e.context_id_bin = s.context_id_bin
JOIN event_types t on t.event_type_id = e.event_type_id
JOIN event_data d on e.data_id = d.data_id
LEFT JOIN events p on p.context_id_bin = e.context_parent_id_bin
12

Maybe it’s time to throw in the towel on this.

I think this is an issue with the Zen15.

That doesn’t quite make sense because this is the second Zen15 to turn off by itself on the small, low-current, pump. (And I have 5 or 6 other Zen15s that work fine.) But it does happen randomly which would point more to hardware than an automation.

The ugly details

Here’s z-wave-js sending the target value to the device and the response saying the device is on.

2025-07-22 07:56:21.758 DRIVER » [Node 087] [REQ] [SendDataBridge]
                                 │ source node id:   1
                                 │ transmit options: 0x25
                                 │ callback id:      88
                                 └─[Security2CCMessageEncapsulation]
                                   │ sequence number: 99
                                   └─[SupervisionCCGet]
                                     │ session id:      39
                                     │ request updates: true
                                     └─[BinarySwitchCCSet]
                                         target value: true

2025-07-22 07:56:21.926 DRIVER « [Node 087] [REQ] [BridgeApplicationCommand]
                                 │ RSSI: -77 dBm
                                 └─[Security2CCMessageEncapsulation]
                                   │ sequence number: 88
                                   │ security class:  S2_Authenticated
                                   └─[SupervisionCCGet]
                                     │ session id:      39
                                     │ request updates: false
                                     └─[BinarySwitchCCReport]
                                         current value: true
                                         target value:  true
                                         duration:      0s

A few seconds later the device reports that it is off. No other command is sent to the device between the above and here. It just reports that it’s off.

2025-07-22 07:56:25.527 DRIVER « [Node 087] [REQ] [BridgeApplicationCommand]
                                 │ RSSI: -79 dBm
                                 └─[Security2CCMessageEncapsulation]
                                   │ sequence number: 89
                                   │ security class:  S2_Authenticated
                                   └─[SupervisionCCGet]
                                     │ session id:      40
                                     │ request updates: false
                                     └─[BinarySwitchCCReport]
                                         current value: false
                                         target value:  false
                                         duration:      0s

But, that doesn’t explain why the rows in the states seem out of sequence timewise:

sqlite> select * from states_meta where entity_id = 'automation.100_double_tap_switches';
metadata_id = 10532
  entity_id = automation.100_double_tap_switches

sqlite> select state_id, state, DATETIME(last_updated_ts,'unixepoch','localtime','subsec') from states where metadata_id = 10532 order by state_id desc limit 7;
state_id  state  DATETIME(last_updated_ts,'unixepoch','localtime','subsec')
--------  -----  ----------------------------------------------------------
62280213  on     2025-07-22 08:03:56.897 <-- newest sorted by state_id DESC
62280205  on     2025-07-22 08:03:56.744
62279475  on     2025-07-22 07:56:21.873
62279467  on     2025-07-22 07:56:21.702 <-- out of order?
62147928  on     2025-07-21 07:57:43.926 <--- timestamp after above?
62147908  on     2025-07-21 07:57:43.724
62044924  on     2025-07-20 13:53:46.067 <-- oldest

Or (assuming the Zen15 is turning itself off and HA is recording that state) that the state change’s context seems to point to the automation (that does not trigger on that state change).

13

The manual says it will turn off automatically after 5 seconds if it detects the current exceeding a level. That corresponds to with the 5 seconds you are seeing. You may have some type of electrical problem with the pump.

14

Yes, there is a high-current shut-off. It’s really a small motor, and I put my current clamp on it and it draws 0.5A. Plus, there’s no z-wave Alarm notification sent.

If I load up the switch I can run it at 16A and it doesn’t trigger from over load. If I load it more the switch does shut off and I get the z-wave alarms.

It’s pretty random when it decides to turn off when running with just the pump.

Here’s what the websocket sees:

2025-07-30 14:32:36.927 WARNING (MainThread) [zwave_js_server] Received Node 087 message:
{'event': {'args': {'commandClass': 113,
                    'commandClassName': 'Notification',
                    'endpoint': 0,
                    'newValue': 21,
                    'nodeId': 87,
                    'property': 'alarmType',
                    'propertyName': 'alarmType'},
           'event': 'value added',
           'nodeId': 87,
           'source': 'node'},
 'type': 'event'}

2025-07-30 14:32:36.936 WARNING (MainThread) [zwave_js_server] Received Node 087 message:
{'event': {'args': {'commandClass': 113,
                    'commandClassName': 'Notification',
                    'endpoint': 0,
                    'metadata': {'label': 'Alarm Level',
                                 'max': 255,
                                 'min': 0,
                                 'readable': True,
                                 'secret': False,
                                 'stateful': True,
                                 'type': 'number',
                                 'writeable': False},
                    'nodeId': 87,
                    'property': 'alarmLevel',
                    'propertyName': 'alarmLevel'},
           'event': 'metadata updated',
           'nodeId': 87,
           'source': 'node'},
 'type': 'event'}

But, it’s clearly the Zen15. Home Assistant doesn’t send anything over the websocket before it turns off.

15

So it looks like it is sending you an alarm notification that something is wrong.

You could try disabling the functionality in the zwave device config parameters.

It is possible it’s detecting current leakage (meaning it monitors both line and neutral) and your pump is leaking current to ground.

16

Thanks.

Sorry if I wasn’t clear. The Zen15 sent the alarm message I quoted above when I forced it to be over current.

It’s not possible to completely disable the over-current protection in the 800 series Zen15. You can just the number of seconds to allow over-current before it shuts off. But, again, it’s not reporting over-current when it’s randomly shutting off, as well as the pump is WAY below the current load to trip the Zen15, even considering in-rush current. Over-current probably isn’t the issue.

I’ve got a ticket in with Zooz support.

17

I sent Zooz steps to demonstrate the issue and they were able to replicate the switch turning off early. Hopefully will have a firmware update soon.

I use a Zen15 for a pump, and want the switch to turn it off if, for some reason, HA doesn’t turn it off.

1 Like