Basic usage A single light controlled (turned off) by a single motion sensor in the same room. Means to turn off is all motions stay inactive (for X minutes).
Choosing 'Don't Activate' as the means to activate will not cause the lights to turn off as the RL app believes the lights are already off.
Choosing 'Don't Activate' as the means to activate along with the option 'Turn Off even if already partially off' the lights will turn off as expected as the RL app doesn't care about the state of the lights.
Choosing the motion sensor as the means to activate and unchecking the 'Act' column for the light will also turn off the light as expected. No 'Turn Off even if already partially off' option required.
Choosing the light switch 'on' to activate and unchecking the 'Act' column for the light will also turn off the light as expected. No 'Turn Off even if already partially off' option required.
More complex use case. Using #4 pattern above as the starting point.
Using the light switch 'on' as a means to activate, add elapsed time after last activation as means to turn off. This covers a somewhat rare case when a light is turned on from outside the space and no motion is ever sensed; the light will still go off.
The issue is that the means to turn off ('all motions stay inactive' and 'elapsed time') are OR triggers. If the motion sensor activates and never deactivates the elapsed time event will turn off the lights. The issue becomes more likely when used with multiple sensors that are not in the same room and are only used to keep lights on (not to activate).
To get what I want I need to get the motion and elapsed time evaluated as AND triggers. In the same way that 'all motions stay inactive' means to turn off works. The way I figured is to use a virtual timer device that has motion sensor capabilities. To activate the timer, I add the timer device to the devices being controlled and include it in the 'Act' column.
There are no out of the box virtual drivers that have all the required capabilities, user or built-in. Any of the built in drivers with auto-off are limited to short pick lists of time options and none are switch/motion combos. The one user contributed driver I found that comes closest is from @armand. It allows for an arbitrary time, but doesn't have motion capabilities. A simple addition of 3 lines of code fixes that.
Summary: this last use case is rare enough that I don't think that I would ask for 'means to turn off' be made any more complex*. At the same time, timers can be useful in this and other cases, so it might be useful to have a system virtual timer driver that is similar to the user driver.
* Maybe an exception: add 'All switches turn off' (and on) options (a general consideration, not related to vacancy).
That is, if the lamp turns on and no motion ever occurred, the timer turns it off after 10 minutes. If motion occurs, that's a new activation event and resets the 10 minute timer. If motion ceases, the 10 minute timer is ignored because there's now a stay pending for the motion sensor.
So hypothetically, the only thing that leaves this on is the motion sensor sending an "active" message and never sending any further readings at all. Presumably continued activity will continue to send "active" messages, retriggering the lights and resetting the timer.
You are right! I had actually used it in another RL app that I had forgotten about.
But there is an issue to be aware of. Stays pending may not be sufficient to achieve the desired behavior.
That is true only if the RL app includes a 'Motion Active' restriction that includes the motion sensor. The 'Stays pending' restriction timer only activates after the motion sensor sends an inactive message. If the motion sensor does not send inactive in the elapsed time timeframe, then the light will go off after the elapsed time setting (assuming that the motion sensor was the last activation event).
Any active messages will re-trigger the elapsed time timer. But I think some sensors will send active messages only if coming from an inactive state. Inactive messages trigger the stays pending timer.
I'm trying to avoid someone turning lights off at the switch, walking out of the room, and having the lights triggered again by the motion. I've crafted Button Rules around the Room Lighting activator to handle this, but it might be nice to consider building it in.
We already have "Don't Activate if Turned Off manually" and an option to reset that state on mode change. Currently, I have the Button Rule turn off the Activator, pause the RM instance, then re-enable RM two minutes later. This also means any Button Rule that turns on the Activator also needs to un-pause the RM instance first.
It might be worth adding an option to reset "Don't Activate if Turned Off manually" with a timeout as well as a mode change.
(I presume that explicit use of the Activator already bypasses this option, though I haven't tested it. I also wonder whether button presses count as "manually" for this restriction.)
Depends on how you set it up in the app. You can have a button press disable activation if you want.
If the button itself is not in the app but the switch it controls is then when the switch state flips outside of the app that's where the "if manually turned X" comes in.
I also have a feeling there is a elapse timer in the app, not sure where though as I haven't used it yet.
Open door (contact) and turn on a switch. That switch is setup in simple automation to turn on/off 4 other devices. Turn off if there's no motion for xx minutes, door contact closed for xx minutes, or if the switch is manually turned off.
I have it mostly working but now it's turning the switch on an hour after it's turned off by the Room lighting automation. There is no "lighting periods" set. WTH?
I dug a little more and the hub thinks the "basement Light" switch was physically pressed. The log is only showing the one other switch because text logging was disabled on all the others. I was also getting a "paired/follow" switch/light rule in another room that was flapping so I restarted the hub and also pushed the very latest FW to the offending switch. Seems to be OK this morning.
However, I still don't trust this basement light (Zen26) switch as it's been acting flakey/bouncing on command so I'm just going to replace it. Just another Zooz switch down for the count.
I found the problem with the switch turning on. Zooz's infinite wisdom sets the auto off/on default to 1 hour in the latest firmware using the built in Hubitat Zooz central scene drivers.
ETA: It appears the issue with the populated default on/off are Hubitat's built in drivers. The custom drivers are set to disabled.
Got a weird issue here not sure if it is room lighting or if the lightstrip is deciding to turn itself off and on at it's leisure. Rule is set up to turn it on at sunset and turn it off at sunrise. However in the logs it is randomly turning off and back on multiple times through the day although the times don't seem random they are usually similar.
Problem is that it seems to result in the light being on (or thinking it is on) but not actually being on. If I go into my dashboard it says it is on but there is no light. If I turn it off then on again or adjust the brightness then it comes on.
So simple question is it the lightstrip or room lighting?
From the logs you posted, most of those events have nothing to do with the RL app at all. All of the ones after 11:45 are caused by something else, as are the ones at 8:59. You might take a look at the device page for the light strip, at the bottom under In Use By, and see if any other app might be turning it on/off.
Only exposed to google home community but log shows something. Not really sure what it means I don't have it in any routines but I will try remove it from GHC and see if it fixes the behavior.
I'd really like an "earlier of two times" added as an option for when to start a time period. Sunset and sunrise varies a lot depending on the season. I have not been able to move most of my lighting rules over to RL from RM and I would really like to.
Being able to use a variable for a start time would be a nice option too. This would allow me for example to have a time period that starts when the mode becomes sleeping, since that is a different time every night.
Would also like variable time added to the elapsed time option of "means to turn off lights" so that under certain circumstances the lights will stay on longer.
Maybe this can already be done easily, I'm not sure. An option to have a "cooldown period" after a RL instance is turned off before it can activate again. Even though most of our lights are automated, it's been drilled into our heads to turn the light off when leaving a room for nearly 35 years. Mostly this bugs my wife, that sometimes she turns off the lights as she leaves and the motion sensor turns them back on almost immediately. Also sort of an edge case because it only happens if the motion sensor is retriggering at that time too, but it happens enough that it gets complained about.
It might look like I'm basically recreating mode manager inside of RL, but pretty much every room has different times that are considered morning, night, etc. Mode manager has an "earlier of two times" and a "later of two times" option when creating a time period but RL does not.
It's not showing you the option for Variable time because you don't have any DateTime variables. My screenshot above is what you get when there are DateTime variables to select from. Exact same context you are describing (my Dawn time set for 5:15, but selecting Variable time instead below):
