Help with Canceling Delayed Timer

I have a motion sensor in my office that I want to turn on in the evening and turn off after it there's no motion for X minutes. I made a rule that cancels the delayed event each time it detections motion and starts a new delayed action... however, it seems to trigger the delayed action the moment the sensor no longer detects motion. As soon as the sensor goes to "inactive" my lights in the office turn off. What am I doing wrong?

Here's a snippet of the log... note that the first action is the last executed, and that action clearly shows the Hue Office Lights being turned off immediately (80ms) after canceling and setting a new delay of 3 minutes...

dev:142020-12-01 03:50:53.212 pm infoGroup Hue Office Lights was turned off
app:422020-12-01 03:50:53.132 pm infoAction: Off: Hue Office Lights --> delayed: 0:03:00 (cancelable)
app:422020-12-01 03:50:53.106 pm infoAction: Cancel Delayed Actions
app:422020-12-01 03:50:53.104 pm info<strike>Action: END-IF</strike>
app:422020-12-01 03:50:53.102 pm info<strike>Action:     Toggle color: Hue Office Lights ->Daylight  ->Level: 50</strike> (skipped)
app:422020-12-01 03:50:53.098 pm info<strike>Action: ELSE-IF (Time between 9:00 PM PST and Sunrise(F) [FALSE]) THEN</strike> (skipping)
app:422020-12-01 03:50:53.018 pm infoAction:     Toggle color: Hue Office Lights ->Daylight  ->Level: 75
app:422020-12-01 03:50:53.015 pm infoAction: IF (Time between Sunset-30 minutes and 9:00 PM PST(T) [TRUE]) THEN
app:422020-12-01 03:50:52.974 pm infoOffice Light Manager Triggered
app:422020-12-01 03:50:52.967 pm infoOffice Light Manager: Office Motion Sensor motion active
dev:302020-12-01 03:50:52.878 pm infoOffice Motion Sensor is active

Any feedback is gratefully appreciated! Thanks in advance!

Edit - I'm using HE 2.2.4.148

First, your rule actions are a bit unusual and look like a common mistake, so I'll confirm the behavior as written: this will turn on the lights for three minutes when motion becomes active, then turn them off. It will not turn them off three minutes after motion goes inactive, which is what most people want, and if motion stays active the entire time, they will still turn off after three minutes (technically you might not notice that every time since there would likely be bouts of inactivity during that time that reset the timer, but for most sensors that still won't happen for 30-60 seconds or more).

What most people really mean to do is turn on the lights with motion, then turn them off after a delay when there is no longer motion. There are several examples of that in the Rule 4.0 docs, which I'd recommend reading--or, if nothing else, mirroring the examples. :slight_smile:

A newer (since the docs were written) paradigm has also emerged that you could also use. Rather than the IF THEN/ELSE structure with a "changed" trigger as in the docs, you could do something like:

Trigger: Motion active

Actions:

Cancel Delayed Actions
On: Lights (or a bit more complicated in your case, but same idea)
Wait for event: Motion inactive
Off: Lights --> delay 0:03:00 (cancelable)

That being said, I don't think the behavior you describe for your rule regarding the timing of the delayed event's execution is expected, even as written. My guess is that the delayed action's time simply happened to have been up at the same time as the rule triggered but just before it happened to get to that "Cancel Delayed Actions" line, making the delayed action indeed happen. (A trigger matching and the actions starting to run again won't cancel a delay on its own, so you are correct to do so. It should be noted that this contrasts with the behavior of "Wait" in my example above, though it is still necessary to cancel the delay, which that rule still uses.)

I use the new method mentioned above but have a conditional at the top of the rule that simply exits the rule if the mode is "Day". This prevents my motion activate lights from coming on during the day when they are not needed. Actually I also have a virtual switch which is called "lights on during the day" which can override this setting too. This way I get complete flexibility.

Thanks bertabcd1234! I appreciate the feedback. I did look at those, but I obviously missed some nuances. And you're right that I need to change it to create the delay after the motion becomes inactive. I'll try your recommendation out.

However, I do think there might be a bug in here. I had the rule paused all night and today I enabled the rule and monitored the log. I activated the motion sensor once, let it go inactive... then activated the motion again... all within 3 minutes (the delay)... but the "Off" action was triggered when the Delay from the first execution was canceled. I don't believe this is expected behavior (even if my logic is less than perfect). In this sequence of events, there's no reason "Hue Office Lights" should ever be triggered (it's within 3 minutes and the delay was canceled). Here are the logs (I broke it up to see the separate executions):

dev:142020-12-02 01:34:12.647 pm info Group Hue Office Lights was turned off

app:422020-12-02 01:34:12.570 pm info Action: Off: Hue Office Lights --> delayed: 0:03:00 (cancelable)
app:422020-12-02 01:34:12.541 pm info Action: Cancel Delayed Actions
app:422020-12-02 01:34:12.538 pm info Action: END-IF
app:422020-12-02 01:34:12.535 pm info Action:     Toggle color: Hue Office Lights ->Daylight  ->Level: 50 (skipped)
app:422020-12-02 01:34:12.532 pm info Action: ELSE-IF (Time between 9:00 PM PST and Sunrise(F) [FALSE]) THEN (skipping)
app:422020-12-02 01:34:12.447 pm info Action:     Toggle color: Hue Office Lights ->Daylight  ->Level: 75
app:422020-12-02 01:34:12.444 pm info Action: IF (Time between 12:00 PM PST and 10:00 PM PST(T) [TRUE]) THEN
app:422020-12-02 01:34:12.399 pm info Office Light Manager Triggered
app:422020-12-02 01:34:12.390 pm info Office Light Manager: Office Motion Sensor motion active
dev:302020-12-02 01:34:12.275 pm info Office Motion Sensor is active

dev:302020-12-02 01:34:02.125 pm info Office Motion Sensor is inactive
dev:142020-12-02 01:33:44.624 pm info Group Hue Office Lights level was set to 75%
dev:142020-12-02 01:33:44.619 pm info Group Hue Office Lights was turned on
app:422020-12-02 01:33:44.441 pm info Action: Off: Hue Office Lights --> delayed: 0:03:00 (cancelable)
app:422020-12-02 01:33:44.434 pm info Action: Cancel Delayed Actions
app:422020-12-02 01:33:44.430 pm info Action: END-IF
app:422020-12-02 01:33:44.426 pm info Action:     Toggle color: Hue Office Lights ->Daylight  ->Level: 50 (skipped)
app:422020-12-02 01:33:44.423 pm info Action: ELSE-IF (Time between 9:00 PM PST and Sunrise(F) [FALSE]) THEN (skipping)
app:422020-12-02 01:33:44.318 pm info Action:     Toggle color: Hue Office Lights ->Daylight  ->Level: 75
app:422020-12-02 01:33:44.315 pm info Action: IF (Time between 12:00 PM PST and 10:00 PM PST(T) [TRUE]) THEN
app:422020-12-02 01:33:44.276 pm info Office Light Manager Triggered
app:422020-12-02 01:33:44.267 pm info Office Light Manager: Office Motion Sensor motion active
dev:302020-12-02 01:33:44.167 pm info Office Motion Sensor is active

app:422020-12-02 01:33:37.403 pm info Office Light Manager: Resumed

(note, I have no other automations that touch the Office Lights, this is the only one)

I use the new method mentioned above but have a conditional at the top of the rule that simply exits the rule if the mode is "Day"

This is a good idea... using the mode instead of specific times. I considered this, I just need to work out how I want "Away" to work when it's Away/Day, Away/Evening, Away/Night. I think I need different modes than simply "Away" to make my logic work how I would want. Thanks for the suggestion of using mode instead of specific times. It would help from having to put times explicitly in each rule.

Now I have a question. While I get learning how to use RM and delays... Am I missing something in the above request that can't be done in the simple motion lighting app?

1 Like

Am I missing something in the above request that can't be done in the simple motion lighting app?

No, probably not... but I intend to make this rule more complex, just need to get the baseline started before I add complexity to it. I also want to use it as an opportunity to learn the nuances of RM.

1 Like

I didn't bother to implement Away mode for the reasons you mention. Mixing a time based mode with a presence type mode is not helpful in my opinion. You end up having to set all the various combinations. So I stick with Mode for day, evening (actually more like dusk), and night. Day and Evening come on automatically based on the average of 2 illuminance sensors. Night is triggered at 11pm. And I use a separate virtual switch for home/away (actually I use such a switch for each person and another for "everyone away"). This gives the best flexibility in my opinion.

@Angus_M Thanks for sharing how you've implemented that. Makes sense.

@bertabcd1234 - I removed the motion sensor and recreated the rule and it's working correctly now. Thanks for the feedback!

Or if you really like wait for event (I'm a big fan), you could get rid of the delay and cancel delayed actions and just do:

Wait for event: Motion inactive
Wait for event: Elapsed Time 3:00
Lights off

What I like about it is you don't need to cancel anything in the beginning, and you can add more actions after the lights off

3 Likes

What I like about it is you don't need to cancel anything in the beginning, and you can add more actions after the lights off

But if there's motion again within the 3 minutes, doesn't the Wait For Event still trigger after 3 minutes turning the lights off? Or will the Wait For Event be canceled automatically with the re-run of the automation?

1 Like

That's the whole point, wait for event is cancelled each time the rule is triggered again.

Ah... good to know. I wasn't aware of that. Definitely takes some complexity out of the automation. Thanks!

1 Like

Oh, that's excellent. Good idea. I have all my motion lighting on Node-RED because I just can't seem to achieve decent performance using HE alone, but now I want to try this new style just for fun :smiley:

1 Like

I doubt the performance would change with this, but yes, it simplifies rules a lot!

Yes, it won't change the on-performance, that's for sure.

1 Like