So, I have an automation that turns some lights on a little before sunset and then off around 10:30 because we usually go up to bed around 10ish. Both of these actions have a random 20 min delay on them as a feature to make them look like they were actually done by hand in case we are not home but want someone to think we might be. However, we will occasionally stay downstairs longer than that and I'd like to delay the lights turning off if we do. Last night, I tried using presence sensing on our phones and set this rule to only be able to run if both phones were away. We were out at the time it should have run, but it never did. I understand that gps presence sensing can be finicky so I have decided to scrap that idea. I have a motion sensor in the room, I am just not sure how to utilize it other than a quick instance check at 1030 when the rule triggers, the problem there is that if we were particularly still for that moment and it had reverted to inactive, the rule would fire regardless of the state 1-2 minutes later.
There are lots of ways to accomplish this. The simplest way might be leaving your existing rule alone and then use the built-in motion and mode lighting app, perhaps restricting it to after 10pm. If you set it with a reasonably long timeout it should manage even if you're very still.
And you are right about presence... it is as much art as science.
Do you think this should work? If the random delay is canceled, the next action of turning the lights off is canceled as well, correct? It won't just cancel the delay and then immediately turn the lights off, right?
Actually I think that's exactly what will happen. If you change to turning off the kitchen cabinets with a delay of 20 min that would work. Not sure you can randomize it though.
I can, unfortunately you cannot randomize the delay if it is added directly to the event. Maybe add a delay to the event that can be canceled of like 2 seconds?
I have used this pattern many times successfully. When you cancel the delayed actions, it doesn't just cancel the 20 minute delay -- the rest of the rule actions are also canceled. So it will not just cancel the delay and then immediately turn the lights off.
I am not sure why you have the If-then-else construct. I have done this many times successfully with the simple sequence of cancel-delayed-actions; delay xx minutes; turn off light.
I copied the if-then-else from another rule I had that I know works but did not also have the time trigger element. I guess I just did not see it working without it because I am using any change to the motion sensor not just active as a trigger. So it needs to check to see if the sensor is active and if it isn't, it will proceed, if it is, it will cancel.
My experience with both brands of motion detectors I use is that the "inactive" message arrives less than 1 minute of the "active" message. One of the brands has a 3 minute "cool down" period during which it won't send any messages.
I've read that some motion detectors do not deliver the "inactive" message reliably.
This is why I trigger everything based on the "active" message and ignore the "inactive" message.
Not matter what path you take, I would make the cancel unconditional. Under all circumstances, if there is a rule instance sitting on a delay, you want to get rid of it so that the most current event from your motion detector controls the outcome.
This is what I settled on. I did some quick testing with modified times and it seems to delay the way I want it to and work the way I want it to if no one is in the room. Adding the second delay directly to the actual turn off command was the only way to get that to actually cancel instead of just cancelling the delay and moving directly on to the turn off. But, this works with my sensors. I use the sonoff motion sensors, they have a cool down of 1 min, but have been super reliable for me. That is why the second delay is 2 minutes, it makes sure there is another time for someone to move and trigger the cancel, even if the random delay is 0 minutes.
