Been building out my system and noticed some erratic behaviour related to turning on dimmer switches as an action in a rule. Using Zooz Zen77 (dimmer) and Zooz Zen32 (scene controller) devices.
I had a rule that the action was turn on dimmer A to 100% and then dimmer B to 100%. I found through experiment sometimes only one device turned on when the rule was run. It had a randomness to it so I was exploring ZWave issues and RF Link concerns. I had great signal and single hop back to Hubitat so I doubted that was the problem. I was about to re-pair the devices with S2 encryption (I followed Hubitat's recommendation to not turn on security when I originally paired the devices).
Dim: Kitchen Island: 100
Dim: Kitchen Ceiling: 100
Then I changed the rule to turn on switch dimmer A and dimmer B, Then I followed it with the action dim
On: Kitchen Ceiling, Kitchen Island
Dim: Kitchen Island: 100
Dim: Kitchen Ceiling: 100
Now the rules seem to run perfectly. I haven't been able to get it only turn on one of the lights and not the other which regularly happened before.
So while I am happy my problem is fixed I'd like to understand why. Is it possible you shouldn't issue a Dim: set_level without knowing the current state of the switch? Is dim:0 the same as switch:off? I had assumed switch:on just returns to prior dim set level. Something subtle here but I am not seeing it. Is switch:on the same as a single tap on the upper switch paddle? Is switch:off the same as a single tap to the lower switch paddle? Is dim:100 the same as a double tap on the upper switch paddle? Just wondering if there are subtle differences here.
Any help appreciated.
With most drivers, no. A "Set Level" would also turn it on if off. The big exception (besides a possible device or driver problem) is if you have any "level prestaging" options on the driver that are enabled. This is not common.
Normally yes, though it's a bit of an odd case and some devices or drivers might do odd things in response. I'd use "Off" if that's what hi really want just to be sure.
Some devices have options you can use to change this, but this is also normal behavior.
Both sets of these can be different in that one works via Z-Wave from the hub while the other is an on-device feature (and the double-tap thing in particular a device-specific feature, not anything standard). But the outcome might be the same, or supposed to be.
If none of this explains what you're seeing, it might be helpful tonshare what driver you're using and any options you may have configured on the device (e.g., device detail page preferences).
This is the driver I am using. It is quite nicely tailored to the ZEN77. The author (jtp10181) made a tweak at my request (hence 2.0.3) that fixed a dashboard issue I was having.
/*
Changelog:
[2.0.3] - 2024-04-XX (@jtp10181)
- Added singleThreaded flag
- Added option to set level to 0 when turned off
- Updated Library and common code
With my driver both On and SetLevel send switch multilevel commands. The only difference is that "On" sends the value 0xFF (255) which is a special value telling it to turn on to its default/last level (depending on firmware config). Using setLevel(100) obviously will send that value instead of 0xFF.
So, you should not need to turn it on before the level. I am guessing just sending the device two commands is getting it to pay attention. Happens sometimes with z-wave if you dont have a strong mesh. If I get the supervision support built out better that might take care of it.
I am not thinking it is zWave signal related. The Hub is 6'-8' from the switches in question, path stats are good, its a C8 Pro with external antenna, and I don't see similar rogue behavior with other rules that run on those same switches. I think it is a logic flaw somewhere such that the command to turn on gets dropped for one of the devices being controlled.
I am just surprised Hubitat doesn't have a more robust retry scheme such that it end to end confirmation of actions occur. Or at a minimum a flag/indicator to say the action failed.
My work around doesn't cost me anything so I'll just leave it in for now.
Your advanced drivers for all the Zooz products are terrific!
It is left up to the drivers and it is more complicated than you would think. Especially when you possibly have multiple command queued up. I have been kicking around some better ideas in my head. You can turn on the Supervision option in the driver to try out what I have in there, to see if that helps at all. Its not great but it makes an effort.
