I want to automatically turn off some lights after a specified period of time. That is, if a closet light is turned on, I want HE to automatically turn it off after 10 minutes. That is simple enough to do in HE.
My problem is this. After turning on the light, HE has scheduled the light to be turned off in 10 minutes. However, the same light is manually turned off after 5 minutes. Then the same light is manually turned on again in 2 minutes. The previously scheduled command to turn off the light turns off the light in 3 more minutes. Wife is now in a dark closet and not happy.
I (think) I understand that I need to write a Rule that will cancel the initial Rule that scheduled the light to be turned off in 10 minutes. Since I will be doing this with several lights, what would be a good (not too complicated) Rule format to use to do this?
I presume you are using Rule Machine for this.
You have to select the "Cancellable" toggle on the delayed action to turn off, and then add as the first action in your rule "Cancel delayed actions".
What this does is that every time the rule is run, it will cancel the actions that were scheduled before, and start counting again.
And you don't need another rule for this.
If you need further help, post a screenshot of your rule and I'll let you know what to change.
There are a couple "auto off" community apps that work really well for this. They can be found in Hubitat Package Manager if you have that installed. Might be worth trying before getting too complicated with Rule Machine etc.
Always helpful to have screenshots to see what is going on.
The nice thing about the other version (by csteele) is it can do both auto off and auto on via the flip of a switch in the app, and it uses child devices to keep things organized if you have more than one auto-off or on device, and it shows you current status. It's based on the one you installed and works the same, just has a few more features if you're interested.
How this works: The Wait is not there because we're waiting for Guest Bath Lights to turn off (harmless to wait for that), but for the timeout on the Wait. In 10 minutes, it will turn the light off. If the light is turned off, then back on, the turning on cancels the pending Wait, and starts a new one. So, net result is that the light will turn off 10 minutes after the last time it was turned on, not 10 minutes after the first time.
This could be made clearer if there was an option for Wait called Elapsed Time, and it just offered the timeout time selector.
Thank you for the reply with the Rule. I have a question regarding system efficiency. Is using this rule more efficient, less efficient, or no appreciable difference, compared to using one of the user developed "Auto Off" apps?
What could be nice would be for a conditional based on the timeout.
If the wait timed out - > do this.
I suppose you can workaround it just adding an if after the wait for the same event as the wait, so in this case it could be "if guest bath lights is on"
Dedicated apps are almost always more efficient than rule machine. Rule machine should generally be reserved for doing that’s that are too complicated to do any other way.
A Wait basically is conditional. For example Wait for Condition. So I'm not sure what you're thinking of. I am going to make Wait for Elapsed Time explicit, and here's an example of what that gets you, a basic motion lighting rule that doesn't turn off the lights until after all motion has stopped and not started again for 3 minutes:
But can wait for condition accept an else afterwards?
What I meant is that even after the timeout, the rule continues the same whether the wait for event was satisfied or not.
Say you are waiting for an event which didn't happen in the time specified - you could want to do something else in the rule instead of continuing as if it the event happened?
It would help me to better understand if you could provide a somewhat technical explanation for why apps are more efficient than RM.
My guess is that apps are written specifically to perform a single function. Therefore the code that is executed is small and specific to the need. Whereas with RM, since it is general purpose, it has a couple of orders of magnitude more code that must be processed. ???
This is correct. This can be tested to some extent by simply turning on logging in Rule Machine for Events and Actions, and putting logging in a dedicated app that performs the same function, and comparing results. It's most likely on the order of 100 to 200 msecs of difference (I have not done this recently). So, if you have an automation where that much time is critical, it might warrant using an app. But, these are uncommon.
More significant is the possibility to do things in a custom app that would just be difficult to do in Rule Machine. These come in a wide variety.
@bravenel created Rule Machine, so he's clearly the best person to answer that question, but one other thing I would note is that the flexibility of of Rule Machine gives users a lot more opportunity to cause themselves problems.
Here is a simple but not scientific test I just did for 4 variations of the same automation, a simple turn on lights from motion. Time in milliseconds is from motion active event until light reports on event:
There is some variation from doing the test multiple times. You can see that RM imposes an extra overhead of about 130 msecs.
Motion (or contact) activated lighting is the most timing critical automation I know of for general household functions, as we are very aware of the timing when we walk into a room and the lights turn on.
