Leviton Dimmer DZ6HD Not Updating

[nickaggie]

Hi - I have 3 Leviton In-Wall 600W Dimmers, model number DZ6HD that are not updating in ZwaveJS correctly. These worked for ~3 years using Zwave 1.4 but since I migrated to JS have been giving me issues. I have tried repairing and re-interviewing through ZwaveJS to MQTT and nothing works. The device will update correctly for a few hours after a ping or another interaction through HomeAssistant, but it seems like after 6 hours or so the device goes to sleep and will no longer update HA.

The other 25 Fibaro, Aeotec, GE, and Inovelli work fine. The issue only seems to be with these 3 Leviton devices.

[AlCalzone]

It might be that OZW polled them regularly and hid the underlying problem. Without seeing logs I assume this is a connectivity issue. For troubleshooting I recommend these steps:

• https://zwave-js.github.io/node-zwave-js/#/troubleshooting/connectivity-issues?id=general-troubleshooting
• https://zwave-js.github.io/node-zwave-js/#/troubleshooting/network-health?id=optimizing-the-reporting-configuration
• https://zwave-js.github.io/node-zwave-js/#/troubleshooting/network-health?id=testing-the-connection-strength (you'll find this in zwavejs2mqtt on the network map, after clicking on the node there)

[devinhedge]

I noticed this happening around v10.0.0 myself on my Leviton DZ15S-1BZ switch and Leviton DD00R-DLZ dimmer. How long it has been happening I haven't noticed because I was moving my Home Assistant installation from a RaspPI to a NUC. I'll conduct the troubleshooting above and report back.

[AlCalzone]

Please re-test with v10.0.4. This version is included in: zwave_js addon: 0.1.70 or zwavejs2mqtt: 7.1.0

[devinhedge]

Please re-test with v10.0.4. This version is included in: zwave_js addon: 0.1.70 or zwavejs2mqtt: 7.1.0

Thanks. I upgraded and re-tested. Can confirm that this seems to have resolved the issue with the Leviton DZ15S-1BZ switch and Leviton DD00R-DLZ dimmer. I really appreciate the hard work.

[nickaggie]

In my case the upgrade to zwavejs2mqtt: 7.1.0 alone did not fix it. Re-interviewing (reset security class checked) and will retest to see if that helps.

[nickaggie]

Re-interviewing did not fix it. Signal is just fine as the floor directly below the controller and always responds if i make a change on the dashboard. Is there anything else I can try?

[AlCalzone]

Please make a driver log, loglevel debug of a re-interview and what isn't working and attach (drag&drop) it here as a file.

[nickaggie]

zwavejs_2022-09-12.log Its nodes 58, 59, 60.

The issue im seeing is that after not being used for a number of hours, the status becomes out of sync with HA. ex: lights actually on, but HA thinks they are off or vice versa.

The part thats odd is that if I tell HA to turn the light on or off, it wont update. However, if i tell it to set the light at any particular dimming level, that wakes up the node and causes HA and the light to become in sync again for a few hours.

[AlCalzone]

For reference for my later investigation:

2022-09-12T14:00:08.451Z SERIAL « 0x010b0004003c052603646402ee                                        (13 bytes)
2022-09-12T14:00:08.452Z SERIAL » [ACK]                                                                   (0x06)
2022-09-12T14:00:08.453Z CNTRLR   [Node 060] [~] [Multilevel Switch] duration: {"value":2,"unit":"s [Endpoint 0]
                                  econds"} => {"value":2,"unit":"seconds"}
2022-09-12T14:00:08.454Z DRIVER « [Node 060] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: undefined

looks like they are still in transition when polled for the actual status.

Also when setting to 0, the optimistic update seems to cause a log about canceling the scheduled poll:

2022-09-12T14:24:42.257Z DRIVER » [Node 058] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      209
                                  └─[MultilevelSwitchCCSet]
                                      target value: 0
                                      duration:     default
2022-09-12T14:24:42.259Z SERIAL « [ACK]                                                                   (0x06)
2022-09-12T14:24:42.264Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2022-09-12T14:24:42.265Z SERIAL » [ACK]                                                                   (0x06)
2022-09-12T14:24:42.265Z DRIVER « [RES] [SendData]
                                    was sent: true
2022-09-12T14:24:42.281Z SERIAL « 0x01070013d100000339                                                 (9 bytes)
2022-09-12T14:24:42.282Z SERIAL » [ACK]                                                                   (0x06)
2022-09-12T14:24:42.282Z DRIVER « [REQ] [SendData]
                                    callback id:     209
                                    transmit status: OK
2022-09-12T14:24:42.289Z CNTRLR   [Node 058] [~] [Multilevel Switch] currentValue: 0 => 0           [Endpoint 0]
2022-09-12T14:24:42.290Z CNTRLR   [Node 058] Scheduled poll canceled because expected value was received

yet the poll happens:

2022-09-12T14:24:47.299Z DRIVER » [Node 058] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      212
                                  └─[MultilevelSwitchCCGet]
2022-09-12T14:24:47.300Z SERIAL « [ACK]                                                                   (0x06)
2022-09-12T14:24:47.307Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2022-09-12T14:24:47.307Z SERIAL » [ACK]                                                                   (0x06)
2022-09-12T14:24:47.308Z DRIVER « [RES] [SendData]
                                    was sent: true
2022-09-12T14:24:47.323Z SERIAL « 0x01070013d40000023d                                                 (9 bytes)
2022-09-12T14:24:47.324Z SERIAL » [ACK]                                                                   (0x06)
2022-09-12T14:24:47.324Z DRIVER « [REQ] [SendData]
                                    callback id:     212
                                    transmit status: OK
2022-09-12T14:24:47.335Z SERIAL « 0x010b0004003a052603000002e8                                        (13 bytes)
2022-09-12T14:24:47.336Z SERIAL » [ACK]                                                                   (0x06)
2022-09-12T14:24:47.337Z CNTRLR   [Node 058] [~] [Multilevel Switch] targetValue: 0 => 0            [Endpoint 0]
2022-09-12T14:24:47.339Z CNTRLR   [Node 058] [~] [Multilevel Switch] duration: {"value":2,"unit":"s [Endpoint 0]
                                  econds"} => {"value":2,"unit":"seconds"}
2022-09-12T14:24:47.340Z CNTRLR   [Node 058] [~] [Multilevel Switch] currentValue: 0 => 0           [Endpoint 0]
2022-09-12T14:24:47.341Z DRIVER « [Node 058] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 0
                                      target value:  0
                                      duration:      2s

[nickaggie]

@AlCalzone - would any other debug info help while digging into this?

[zwave-js-assistant[bot]]

This issue has not seen any recent activity and was marked as "stale 💤". Closing for housekeeping purposes... 🧹

Feel free to reopen if the issue persists.

[nickaggie]

reopening as the issue still persists

[devinhedge]

Not sure if this will help. YMMV

I've come to the conclusion that I'm one of the upgrades that the authentication keys could have been corrupted. Once corrupted there is no elegant way to correct the Z-Wave JS configuration.

I solved this by:

1. Deleting the device from Z-Wave JS.
2. Hard reset the device to factory settings
3. Re-add the device to the Z-Wave network

After that, everything seems to work almost-flawlessly.

I still see devices not using S2 keys when they should be as they are home security devices (sensors). That is a separate bug, though.

[AlCalzone]

FWIW, one of the latest driver versions makes sure not to "forget" which keys a device has. This was solved suboptimally before.