I have a rule that I trigger at night called Sleep. This rule turns off all the lights, TV, and locks the doors. One of the switches that gets turned off is for my garage. The switch actually controls outlets in the ceiling that power the garage door openers. My intent is to turn this switch off and then back on which effectively cuts the power and restores the power to the garage door openers. This results in the lights turning off on the openers that might have been left on.
Sometimes the switch to the garage door opener turns off but does not turn back on. I am looking for ways to troubleshoot this. I could create a routine to check if this was turned back on to work around the issue but am interested in solving it if possible. Below is a the list of events that are defined. As you will see the Garage Interior Light has a delay between the off event and the on event. In looking at the events for the device, the Garage Interior Light does not always see the on event.
Start by enabling all logging for the rule (events, triggers, actions). When the rule fails to do what it should, filter the past logs to show only that rule and post a screen shot of those logs from the trigger (sleep turns on) until the rule completed.
Are the devices Z Wave or Zigbee? It may be that your mesh isn't great and the off command is not being received by the device (albeit intermittently)
I will turn on the logging as suggested and will report back when it fails again.
All of the physical switches are zwave. The other devices are harmony controlled devices and some wifi devices controlled via Amazon Alexa.
I would say my mesh may have some issues as it contains the Schlage lock which has S0 security which I have read I know can be chatty. I do have a handful of non plus Zwave switches as well.
S0 is reputed be 3x the traffic as a device using no security. In other words pretend to add two more devices to your total device count. Locks require some sort of security, and if S2 isn't an option, then S0 is all you can pick. The Lock itself is not chatty... it just sends the occasional Battery level and then responds to Lock and Unlock. In other words as a device, it's no more chatty than a Door/Window Sensor. But when it does communicate, it's 3x the packets vs a no security Door/Window sensor. Just pretend you have two imaginary Door Sensors there next to the Lock and you'll have a sense of the impact potential.
The advice around here is to not use S0 if at all possible, and of course for many many locks, that's just not possible. The advice also implies that if you have 20 devices and all of them are S0, that you should expect your hub to function as if there were 60 devices with no security. That's where the multiplication of S0's chattiness gets extraordinary.
Thanks for the clarification on the S0 traffic. Now I have a better understanding of the impact.
My switch did fail to turn on last night, but unfortunately I had not cleaned up one of my drivers that was logging debug information once a minute. So I was not able to go back far enough to find the debug information for the Rule. I cleaned up the driver this morning so I will hopefully be able to capture the logging in the near future.
Try increasing the 2 second delay to 10 seconds. I had a similar problem with an older Zooz wall switch.
Also, can’t you just make another simple rule to test that off/on timing!
Sometimes I am very myopic when approaching issues so I miss the obvious. Yes indeed I can create another routine to test the timing and will do so. Thanks.
