This is a pretty basic automation. I noticed the light not coming on a couple of days ago and got around to checking the logs just now. Here is the RL rule.
Here are the combined logs for the switch (A Zen77) and the RL rule. The entries for the switch are highlighted yellow. I had turned debug logging on first.
So it seems to be sending the off command but not the on command. I think that is because despite this, when I look at the device page, it shows the current state as on.
From the device page, I clicked the On button and got this in the log
It says not changed, and maybe that just means the reported state, but the light did actually turn on. While the light was on, I walked into the room and it did turn off 2 minutes later like I expected. I waited a couple of minutes and walked in and it now turns on like I expect.
So all it took to fix it was manually toggling the state via HE through the device page... but that's really annoying. I thought the zwave protocol had a process to send ACKs and retransmit? I get that process might not be 100% perfect but in that case, why does the hub not ask "Hey, I didn't hear back last time. What's your current state?" occasionally or at least before sending the next command? Or maybe ignore the state and just send the next command anyway since you don't know if the current state is correct. I feel like I should just turn this on for everything, but for some of my rules that might create to much zwave traffic.
Maybe @jtp10181 can shed some light on what happens "behind the scenes". I don't think it's an issue with the driver, but I figure you understand the protocol pretty well. I also feel like it might have been a zwave network issue that created the initial problem... but the HE was still clearly trying to turn off the light each time. I have a hard time believing that command and ACK were missed every time motion was detected for the last 3 days or so. Though... I'm guessing the device just ignored the off command since it was off and didn't even bother with an ACK, but that just leads me back to the train of thought from the last paragraph.
If the off command gets sent, and the device turns off, but the message that it actually turned off never makes it back then yes this will cause issues with anything that tries to optimize things by skipping devices in the correct state. It can also mess up RL getting it into the wrong Active/Inactive state. The Force option in RL might fix it.
The root issue is with the device. Is it paired with or without security? The option in my driver for Supervision might help.
There also features in the upcoming 2.4.1 release (in beta) that may help.
You sure it was? You saw that in logs?
The device should have been responding that it was off even if you send duplicate commands. Device may have gotten into a weird state somehow.
I guess I'm not sure, but I think so. The logs for the device shows an off event (highlighted part of 2nd screenshot) but I suppose that is just the driver saying "Hey, I'm sending an off command" and not indicative of if the device got it. But still... there was no equivalent for an on event being sent.
I may have figured out more of what's going on, but it's made me even more confused. I noticed this morning the light had stopped coming on again. I checked the events tab for the device, and I see this
Now it appears I have two separate problems. As far as I know, nothing should be setting the level on this switch. I only recently (as in a few months ago) put the Zen77 in to replace a Zen21 that started malfunctioning. The LEDs in the socket are not dimmable. I have the light configured for instant on and a minimum level of 99%. I have no idea how the level got set to 12%. There is an entry for the 21st that shows the level being set to 6%. It could not have been the Everything group or the Goodnight scene. The only thing either of those do to this light is turn it off and never on or set a level. I did not use Google Home for anything this morning and I don't have any automations setup through it (that control devices directly anyway). Logging for Google Home was disabled in HE (turned on for now) and there seems no way to see the history in the Google Home app, which is a bit odd imo.
So I suspect the light is actually on but set to a level that doesn't actually allow the LED light to light up. This does not actually solve the issue with it not turning off after 2 minutes though. That is clearly not happening. So, a separate issue.
Unfortunately I can't do any testing right now because I accidentally got it unstuck. I realized that turning on the "command devices irrespective of state" option in the means to activate lights doesn't actually do anything by itself. It adds a checkbox to the device control table for "force". Turning this on and saving it seems to have triggered the switch to actually turn off. So it's currently working again.
I need to figure out how the level is getting set though. Can anyone explain what the "triggered apps" section in the event log means? A single event couldn't have been caused by multiple apps simultaneously.
Triggered Apps is what apps got triggered FROM the state change.
Produced By is what the hub thinks caused the state change (it is a best guess).
A little more info... still confused! In the events tab for the device, I had searched for "level" so I didn't notice this.
It could be a total coincidence. The command off and set level commands are called 35 seconds apart. But the Everything group is setup with metering and a delay of 75ms. That should still be nowhere near 35 full seconds though. And... because I used the zwave replace possibly, when I look in the group, the laundry room light actually shows in the list for switches and not dimmers. And all that should be happening here anyway is the switch being turned off. So I was not even home when the level got set to 12%.
But scrolling down to the last time it happened, I see this.
In the group for Everything I clicked the refresh button. It made the laundry room light disappear from the switch list and reappear in the dimmer list and I had to re-check it.
All the rule does is trigger when the presence sensor reports departed and turn the group off. But hopefully this fixes it. Don't know what would have caused this to start all of a sudden.
But then down a little further is this
The level was set to 6% and the Everything group has nothing to do with it. You can see where I physically turned it on hours later because the automation had stopped working. So I really have no clue.
Looks to me like the device is just reporting those level values on its own. Nothing is sending it a level command from Hubitat.
In RL the switch designation should not matter, in fact you can force a dimmer to act like a switch by clicking on that and changing it. However in this case I would maybe set them as a dimmer and make sure the level is 100%.
You could either have a defective dimmer, or some sort of configuration problem since these Zooz devices have 20+ different settings.
Supervised command improved reliability for me (excellent feature) and tracking in RM solved some weirdness with my voice integrations not knowing the state of my dimmers.
