In the motion lighting app, you can delay turning off a light for X number of minutes after no motion is detected. I want to recreate this in RM.
In RM, there is a "wait for event" action and you can choose motion sensor inactive as an event to wait for, but then the rule will immediately jump to the next action the very first time there is no motion detected. How can I make RM wait for no motion for a set time?
I'm trying to be general about this but if I need to I can post about what I'm trying to do.
Lots of ways of doing it but this is how I do mine.
I'm using a virtual switch for the lux level to be below before the light will turn on.
As an alternative to the above (which is a very common way of doing this and found early on in the docs, which I'd recommend reading before you dive into Rule Machine), there is a "new" paradigm staff have been suggesting for this recently. It looks like this:
Trigger: Motion active
Actions:
Turn on light
Wait for event: motion inactive
Wait for event: elapsed time --> 0:05:00
Turn off light
The outcome here would be the same as above (aside from a few extra things that rule does that this one doesn't, like possibly exiting based on a virtual switch state), but the structural difference is that you only need to trigger on "active" since your in-rule "Wait" handles the "inactive" event, and you don't need to cancel delays or mark them as such because you're using a "Wait" for time instead. All waits (not delays) are automatically cancelled any time a rule re-triggers.
5 Likes
wouldn't you want some kind of check to see if the device did not return to a active state and a then a loop to check if it again. this could end up triggering turning the light off after a set even if someone is in the room and moving around. This also depends largely on your motion detection device and it's cool down period.
I don't think so because the rule starts over again at the very beginning every single time motion is detected.
With what rule? Neither mine nor the one by @bobbles would have that problem. As I mentioned, with my rule, a re-trigger cancels any "Wait" (and all actions after it), and motion active is the trigger--so not a problem. With the "changed" trigger in the other rule, the "IF THEN" section in the conditional handles the "active" case, which cancels the delayed "off" action, so also not a problem. I'll again suggest the docs for more examples and explanations of how this works.
3 Likes
So here's what I came up with. I already had most of this in place, but wanted to tweak it and move some of the functionality from motion lighting app to RM because what I wanted was just a little to complex.
So what this should do is...
If my son is in bed and the motion sensor under his bed becomes active
- turn on the light strips under his dresser and bookshelf, turn on the hall light, and turn on the bathroom exhaust fan that has a nightlight built in
- Wait for above motion sensor to become inactive. This just gives him a little extra time to amble out the door when tired.
- After a 1 minute delay, turn the lights back off
In the meantime, here's the rule for the bathroom
If motion is detected in the bathroom, and If the PB is true (which the first rule sets) then every time motion is detected in the bathroom it just re-runs the first rule, which should keep all the lights on. If the PB is false, it turns on the normal light instead of the night light.
The last check to see if the PB is true is for a situation in which we might go in to check on him or something, therefore setting the PB to true, and then we walk into the bathroom. It basically acts as a timeout to make sure the lights turn back off after all the waiting.
Does anyone see any problems with this logic?
Well this didn't really work, but I think it's because I was using delays in the first rule still from when I had it mostly working the way I wanted. I also realized I don't think I need the "Wait for motion sensor to be inactive" part just before the "wait for 2 minutes" part because if the rule retriggers every time it detects motion, then it's redundant. If I want, I could add 15 second to the wait because that's how often my motion sensor will retrigger and it will wait the same amount of time.
So now the first rule looks like this
and the second like this
And after testing several scenarios, it seems to work perfectly.
This is really dependent on your sensors (and their driver), and I suppose there may be some that let you get away with this, but none that I've used personally. Normally, events (like "motion active" that would re-trigger your rule) are not generated on Hubitat if the previous value of the attribute (so "active" for "motion") is the same as the "new"/current value, so with most sensors/drivers this might get you into trouble eventually.
Another way to understand this, I believe, is that the Wait schedules an event to resume after the Wait. The re-trigger unschedules the event, which, conceptually, cancels the Wait, and, because the resumption after Wait never occurs, also cancels all actions after the Wait.
Multi-threaded execution takes a bit of contemplation to grasp the concurrency that is happening.
1 Like
