Those are the new 800 series? I built that driver based on that device. Anything not working is probably due to broken command classes in Js. I think I did test that device and driver during beta though, and it worked fine.
Thanks for your reply. They are the 800 series ZW6HD dimmers. They were working great until ZWJS was enabled. After I read your reply and before I am posting this, I re-installed the universal driver to test. Sad to report that in the Current State window of the driver, on,off, and level are not updating. The driver is able to command the switch though. But since the "Current State" does not update the rule logic is unable to make the correct decisions. What ever the problem is, I am sure it is what you described. A broken command class. However the Generic system version of the driver does update the Current State window. Once again, Thanks for all the effort. Your Apps and Drivers have contributed greatly to the Hubitat ecosystem.
I don't have any of these and I have no idea if it would help for this, but are they on the latest firmware? 1.1.0.9 appears to be latest.
Thanks. According to device firmware updater, that device is on 1.0.1. Seems I recall a while back trying to update the firmware using that app. After 20 minutes it was up to a whopping 2%. I didn't have two days to wait. Hopefully things are improved since then.'
Since it;'s a GBL file, it should work well with the built-updater.
I only ever install the updater app when I need it -- otherwise, I don't keep it on my system. Each time, I purge the update file before removing the app (I keep my own copy of the update file elsewhere).
In my recent experience, the updater can't be used more than once back-to-back without a hub reboot in between. An immediate second update attempt will take forever (12+ hours) and may or may not actaully complete. But reboot in beween updates, and it goes pretty fast & smooth. I have never tried to update multiple devices simultaneously -- I suspect that would also bog it down.
1.01 is what the current version will show. Unfortunately Leviton labels their versions with more slots than Zwave allows. So both the original and current firmware both report 1.01 back to the hub, as there is only a major and minor versions in the zwave version report. So you have no idea if it is updated or not, you just have to flash it to know for sure.
I see the issue, it only happens if you command the device from the hub for some reason. The duration comes back as "null" and my driver checks to make sure the duration is 0 before changing the state, otherwise the message is dropped because the device is still in transition. The duration should not be allowed to be null.
If you are in beta I reported it over there: https://community.hubitat.com/t/2-4-1-154-zwavejs-duration-null-on-switchmultilevelv4-switchmultilevelreport/152343
This new observation may help. re-include the device. Universal driver is automatically installed. If I use the switch itself to control the device, The driver works as it should. The status will update. But as soon as I command it with a rule the status stops updating and once that happens, the device physical controls also stop updating.
Yes I found the same thing and reported it all in detail in the beta section with trace and zwave logs. It is due to a value coming over as null which never should be null, so it breaks my driver.
I have a Zooz ZEN30 where the "child device" can't be controlled from Hubitat, the on/off button doesn't work. It does report status correctly if turn on/off manually. This was working correctly before ZWJS.
The main dimmer portion of the ZEN30 works fine.
I've tried a re-interview and a different driver and it doesn't seem to help. Not sure if its related to the previous zooz issues in this thread
I have two of them and they are both working manually and digitally from the hub. I am using @jtp10181 awesome driver.
Try using the ZEN30 driver I have here and see if that helps: [DRIVER] Zooz ZEN Switches Advanced (and Dimmers)
Already using that, still not working. It's security is s2_unauthenticated, could that be the issue? It's the only one of my devices using that kind of security
No the security should not matter as long as it is correct, what firmware is yours?
Do you know if that's the security it had before? There have been reports of the security getting messed up in the transition causing issues.
A re-interview followed by a hub reboot may possibly fix the security.
It seems my Homeseer switches noted earlier are experiencing the same behavior as the Zooz devices- they seem to report correctly until a rule is used to control them, then they stop reporting status.
I'm hoping for a fix without having to exclude and re include them, as i have 7 different rules for each switch to control the individual status leds.
IMO the fix it to make a new thread specific to the issue, provide details such as detailed steps to reproduce, logs, screenshots, etc...
Then if it is a critical function for you, switch back to legacy ZIP until they get it sorted out.