Cancel Timed Actions -- 2 problems

[user5516]

I wrote a simple rule to turn off a light that was left on for a certain length of time (e.g., garage light after being left on for an hour). For debugging purposes I set the time for 15 seconds (see rule below). I am experiencing two issues: (a) the light automatically turns off any where from 18 to 25 seconds; and (b) if the light is manually turned off and then back on, it is prematurely turned off at the original delayed time (not ~15 seconds after the 2nd On). Problem (a) isn't a big deal, but I'm surprised that it isn't more precise (on my C-8 Pro hub); why have such precision in specifying the delay time?

[sburke781]

What sort of devices are the garage lights?

Ah, Cancel Delayed Actions....

[bertabcd1234]

Can you provide Logs, likely ones filtered to just this rule, that demonstrate the issue?

Your rule is a bit unusual but should work. But note that:

• Typically, you'd use "Cancel Delayed Actions" for delays, which will cancel all cancelable delays
• If you want a "delay" canceled on re-trigger, a "Wait for events: elapsed time" doesn't need explicit cancellation and so is a bit less clicking
• "Cancel Timed Actions" is a fairly drastic action that will cancel not just all delays (cancelable or not) but also any schedules you have in the rule, like waits that include time, periodic triggers, repeats, and other things that may matter for more complex rules.

But regardless, the schedule is normally pretty precise. Likely, your bulb just isn't reporting the "on" event for a few seconds after it happens, causing the apparent delay -- but logs would make this clear. If your hub load is elevated, that's the only other reasonable explanation, but you normally get notifications for that (or could check app/device stats).

[user5516]

OK...

1. The switch is a Lutron Caseta connected through a Lutron Hub, so the delayed delay schedule is probably due to a Lutron delay;
2. I didn't realize the difference between "Cancel Timed Actions" & "Cancel Delayed Actions" -- I changed the rule to use the latter. However, I'm still getting the same, erroneous behavior (i.e., if the light is manually switched OFF and then back ON, it is prematurely turned OFF at the original delayed time). A screen shot of revised rule is at bottom of this post.

So, I performed and observed the following:

• Switch manually turned ON;
• Switch auto turned OFF after ~18 (wall clock) seconds;
• Switch then manually turned ON & then OFF after ~10 seconds, then back ON after ~3 seconds;
• Switch auto turned OFF after only another ~8 seconds;

The light device and rule log for the above is below. It appears to me that it doesn't show the physical OFF then ON events of the switch. I'm guessing that this is because the OFF-ON duration (~3 seconds) was too short for the Lutron hub to observe/report those events.

Thanks for your help & sorry for the fire drill!

Rule & Switch Log:

Rule:

[willythekid]

Good to learn about the 'Cancel Delayed Actions' and 'Cancel Timed Actions' differences, is there any more official explanation post or source where I could learn even more?

Like OP, I have a similar rule to 'Cancel Timed Actions' for the rule itself, but it is not cancelling the timed action of a prior iteration of that rule... see below for two rules and logs.

My goal is to turn off a light that shines in my child's eyes when they are placed on a changing mat (Presence = Arrived), then turn the light back on when they've left (Presence = Departed). It's linked through a presence status virtual device, so that could complicate things.

My experience is that the delayed (cancelable) Presence status change to Departed fires even though a subsequent iteration of the rule has run and reports the vibration sensor as Active, which should the prior rule iteration's Cancel Timed Action of reporting Departed...

Hope that makes sense with my snippets below.
I'm having similar issues with two door lock rules, but first I need to better understand what the Cancel Timed Actions and Cancel Delayed Actions can and cannot do.

Thanks in advance!

[bertabcd1234]

@willythekid

differences, is there any more official explanation post or source where I could learn even more?

Yes, most pages in the UI, including the Rule 5.1 app, have a "?" icon in the upper right you can click to find specific documentation. In this case, it will take you here, and you can find more explanations of features such as this one:

Rule 5.1

As for your rule, I don't see anything off hand, but why are you using two entirely separate IF THENs instead of one with an ELSE? (For a sensor with only two possible states, this would be enough, but ELSE-IF is also available if needed.) This will save a couple lines in your rule but I can't see why it would affect the outcome.

[willythekid]

Thanks for the feedback, good point on making the rule more efficient; as you said, that wouldn't fix my issue but I'm glad to clean it up.

I did look into the rule guidance on rule delays and it does seem to get more complicated.
Best I can tell is the 'Cancel Delayed Actions' and 'Cancel Rule Timers' would have to be within the same rule, appearing later in the same rule instance... and will not apply to a prior, parallel instances of that rule. I'm not positive, but I'll probably figure that out when I clean up my lock rules and might report back here.

Rather than work out the rule delay complications, I changed it to 'Wait for Expression' with the option to 'Use Duration' and that did the trick; it resets the timer to wait for the expression to remain true for that duration. I picked 'Ignore Trigger Events While Running' I may not need the 'Cancel Timed Actions' in there anymore after the vibration sensor reports 'Active', but I left it for good measure.

Any final feedback is welcome, I'm here to learn! Thanks for the help.