Thanks. I had a suspicion that was what was happening, but I couldn't find any documentation on that anywhere.
Hi all, I am not sure where to post this, but I am in a spot of trouble with this driver!
I had my ZW6HD-1RW working fine, but decided to try out this new driver. Something very wrong happened. The Switch buttons seem to have come decoupled from the actual light relay!!
The physical buttons, nor remote commands will no longer turn off or control the lights. I can see the side LEDs operate when i send remote commands, but again the command do not operated the actual lights either.
How did I break this?
I have tried changing back to the generic driver, and pressing configure, but am having no luck with that either. It there a way to recouple the buttons? Engage the relay?
I can not linger turn off my lights.
Thanks in advance.
Edit: the current states show my number of buttons at 0...?
Edit 2: When I press a button, top or bottom (dimmer buttons do not appear in the log for some reason), I get this in the debug log:
[dev:1]2025-01-14 10:36:22.083 PM debug
Basement Dimmer - Main: level is set to 95% (physical) [NOT CHANGED]
[dev:1] 2025-01-14 10:36:22.081 PM debug
Basement Dimmer - Main: switch is turned on (physical) [NOT CHANGED]
[dev:1]2025-01-14 10:35:59.124 PM debug
Basement Dimmer - Main: level is set to 95% (physical) [NOT CHANGED]
[dev:1]2025-01-14 10:35:59.121 PM debug
Basement Dimmer - Main: switch is turned on (physical) [NOT CHANGED]
Power cycle the dimmer at the circuit breaker.
If that does not work, check the preferences using this driver and set everything to defaults.
Hi Jtp10181, This did the job! Sorry for the panic, but I am trying to ensure the WAF in this house. And lights not working at all is one way to shoot that dead.
Really appreciate the help! Thank you
Every once and a while even the most basic IoT devices will lock up or malfunction and need a reboot. If it happens frequently it would be worth looking into more but otherwise I just reboot and move on. Always one of the first things to try is a power cycle.
Like any electronic device, sound advice! A hardwired switch? Not easy to think about how to reboot it. The breaker... of course! To be honest, it didn't even cross my mind. haha. Thanks for the learning moment!
The Leviton dimmers can cut power to the load by lifting up the bottom of the dimmer bar. Not sure if that reboots the electronics of the dimmer itself.
I have 5 of those Leviton dimmers. changing drivers has on occasion confused them but I am starting to think they were confused a little before the driver switch. Remember those switches can be configured from the toggle as well and I had. The universal driver made it very easy to set the minimum dim level of the LED bulbs once I figured out what I was seeing in the driver settings.
Lifting the dimmer bar usually corrects them but I have used the circuit breaker at least once.
Changing all 5 from the generic z-wave plus dimmer to the Universal z-wave dimmer caused two of the 5 to need a little extra attention but they did get sorted out and run fine now.
Jeff, I can confirm this is working with the new ZEN75, in case you want to add to your OP.
Good idea, added, in case someone is searching. I knew it worked, Zooz tested it before it even came out.
Assigned to a Minoston Dimmer Plug (MP21ZD) just now and things seem to work normally, no issues controling the light from the Device page or automations. Nice work!
During initial setup, I hit Configure and then Refresh, sync completed and then prompt appeared w/something like "Refresh the page and then Save." Since I had just done a command Refresh I assumed that "refresh the page" meant reload the page, so did that, and then since the only "Save" option is on the Preferences page, went there and did a Save (though didn't change any of the default settings).
Wanted to post logs as had a couple of Error messages during the driver's initial configuration. I think those are due to the fact that the plug is included w/out security, no S2.
It's an issue with Z-Wave JS and how the platform code handles Z-Wave payloads coming from ZWJS. Had the same, it's not an error in @jtp10181 driver, but it needs fixing on the platform side.
My suggestion is to switch back to zipgateway (legacy Z-Wave) for the time being.
Thanks for the info.
I'm not having any actual problems using the Universal Dimmer driver (and this is the only device I'm currently using it with)...plug turns on/off directly or via automations w/out issue. All things Z-WaveJS appear to be working normally on my hub at the moment (plug actually seems to be responding faster). So rather than fall back to Zipgateway if some action is required I'd just switch to a different driver on the plug.
But at this point from a device & general hub function perspective I don't see any issues w/letting things ride as they are...am I missing something?
The errors are when trying to get the association group names from the device. The command class I am using must be broken on JS. Also someone else found associations in general are totally broken. Everything else should work fine.
Possibly related to my previous report of issues with the switch to Z-Wave JS
, I had six Z-Wave mesh devices that became unresponsive to Z-Wave commands. All six devices are Leviton ZW6HD 800 series dimmers, in mesh mode. One other dimmer of the exact same model came across and continues to work fine (I have seven of the Leviton ZW6HD in total).
I was using the Universal Z-Wave Dimmer
driver and the interesting info from the driver's query/information capability is that the Leviton device is suddenly unknown ("Device Model UKN00"). This happened to all six problem devices but was not reported as unknown for the one working Leviton ZW6HD Dimmer.
Any attempt to interact with these "broken" dimmers through Hubitat resulted in an effective total loss Z-Wave on the hub (Hubitat went into a endless loop of reporting all devices timing out in the Z-Wave JS logs). I would have to reboot Hubitat to "calm" the network.
Broken:
Working:
The initial resolution was to exclude and re-include the six dimmers, but there was a "rub". Once re-included the dimmers worked as expected except that the Universal Z-Wave Dimmer
driver could not correctly update state. It would cause device to turn on and off as commanded, but the reported switch state was always "On". Note, the one dimmer that was not broken is still using the Universal Z-Wave Dimmer
fine. It's only the re-included dimmers that do not work correctly with UZWD
The fix to the switch state issue was to go back to using the built-in Generic Z-Wave Plus Dimmer
driver. Using the built-in driver the dimmers work as expected - correct reporting of state as (de)activated.
The one thing I didn't think to do early on was try the built-in driver in the initial 'broken state' to see if that would also work around the original issue.
Standard trace logs for UZWD, post re-include but not correct state tracking:
You are not the only one with that issue using ZWJS and the universal driver. There is another thread dealing with this driver. The short story is... Your only hope is to switch to the generic z-wave plus dimmer driver
Issue was reported to @bcopeland, I asked if this would be fixed or if it was a breaking change and I would have to fix my code. I did not get a response…. [2.4.1.154] ZwaveJS: duration null on switchmultilevelv4.SwitchMultilevelReport - #6 by jtp10181
I would just switch back to ZIP for now until more bugs get worked out.
What’s odd and the main reason I posted is that one ZW6HD dimmer is working as expected using the UZWD driver. It came across the transition clean and reports state correctly.
¯_(ツ)_/¯
Fortunately, despite the state issue, the universal parameters query and settings works as expected. General operation after that is fine with the built-in driver.
The issue is the 'null' duration that gets reported. Does the one thats working happen to have a 0s transition time set? That might cause the duration to be reported correctly, I have not tested it. Otherwise, maybe just luck and ZWJS somehow configured that one correctly. Would need to see the trace logs from the working one to confirm what is going on.
Ok, I stand corrected, the one that I thought was working fine is not actually working fine. While it didn't come across breaking the Z-Wave network like the others, apparently it's state won't update either, but unlike all the others, the "stuck" state was off
instead of on
. I should have done more validation.
With a little more testing, the device reporting state remains in whatever condition it was when the UZWD driver is selected which I suppose make sense since it's a data reporting/parsing issue.
I see the duration in the trace logs and I assume that maps to the "Fade on/off times". I've now tried 0-2 and the setting has no effect on the null. I normally use 0 (my wife hates the fade).