Simple Automation Rule Log and Device History Differ
I am trying to debug a Simple Automation Rule that is supposed to turn on a Zen21 switch 15 minutes before sunset and off an hour later at 45 minutes after sunset. The switch turns on correctly but never turns off. The device history shows on and off events according to this rule . However, the Past Log shows the on events but not the off events, which is what actually happens. Does this discrepancy between the two reports indicate a SAR problem, a hardware error, or something else?
Here are partial screen shots of the SAR, the device history, and the Past Log.
If the light is turning off when it should, as evidenced by you device events, this is probably a logging bug for SAR. I will look into it.
The light (controlled by a Zen21 switch) does not turn off. It turns on when told to by the SAR but it does not turn off. Only the on commands show up in the Past Log. The on and off events appear in the device history. As a work around I use the switch's automatic turn off option, but it would be good to understand why the Past Log and device event history disagree and why it won't turn off.
Does it turn on/off from its device page?
Would you please look at the App Status page for this SAR rule, in the Event Subscriptions sections, and see if it looks similar to this (or better yet, post a screenshot):
Please tell me how to find the event Subscription section and the App Status page.
Cog wheel next to the App on the Apps Listing, or the Cog wheel in the App…
Screen shot taken at few minutes ago.
When is sunset there? Is that right for 15 before sunset, 8:18?
Local Sunset (Sausalito CA) 8:33. Should turn on 15 min earlier at 8:18. It did, in fact turn on then. It should turn off at 40 min after ss, 9:13. Since SAR turn off has not been working, device is set for 1 hour automatic turn off, 9:18 as work around.
Since it is now past sunset, please take another look at the Scheduled Jobs at the bottom of the App Status page, and see if there is one for 9:13. Better yet, take another screenshot like you did a while ago,
Yes, there is a 9:13 scheduled job. I'll watch for it to execute.
OK, the doAntiAction is the method that turns off the light.
I just looked at the code, and it checks to see if the light is actually on before sending an off. So, one possibility is that the light is not accurately updating its state. Unless the current state says 'on', it will not turn it off.
Look at the device page for the light, and see what it shows on the right side for the state of the switch.
What kind of device is this?
If this SAR rule fails for you, it would most likely be because of this issue where SAR is checking the switch state. If so, use a Basic Rule like this one for this automation:
The device is a Zen21 on/off switch. It turn off on schedule at 9:13, which it has not been doing in the past. The status currently shows off, which is correct. I tried turning it on manually (via dashboard), and the status shows on, which is correct.
Is it also possible that the device itself is malfunctioning? The switch vendor thought the switch was OK since it responds to the dashboard.
The SAR operation is erratic. It will turn on but not turn off for several days. Then it will work for a while, as it did last night. If this is because SAR is not checking switch state, is there a way to force it to check, or better still to force all SARs to check? Are Basic Rules more reliable than SARs generally?
SAR does always look at switch state. If this is failing for you sometimes, it's because of the device. So you may want to look into that. Basic Rule is not "more reliable", but it does not look at the switch state before it turns it off. So if you have an unreliable device, as the evidence suggests, that's the underlying issue, and Basic Rule will work better for you simply because it doesn't check the switch state (which could be wrong).
