That should work! "Wait for event" waits for the specified event to happen (I know, I know, circular definition--but hang on), whereas "Wait for expression" waits for the specified expression (condition or combination of them--it used to be called "Wait for condition(s)," if you remember that) to become true. In some cases, they can achieve the same outcome, but they are looking for different things; a "Wait for expression" will proceed if the specified expression evaluates to true at the moment when it is reached or any time in the future if it is still waiting (usually as the result of an event that makes it true), but "Wait for event" is looking for the actual event to happen and does not care about any current states. I normally suggest "event" unless you have a reason not to use it.
You can achieve a similar effect with "Delay," though you'd have a harder time making that happen at 11:59 PM (you can only specify some quantity of time, not a specific time to delay until; it's really similar to "Wait for event: elapsed time"). The biggest difference besides that is that trigger events cancel all waits, whereas delays must be explicitly cancelled if that is the behavior you want. That much likely doesn't matter for your rule, which should only trigger once a day and be done with any waits or delays long before it triggers again. I also think "Wait for event: elapsed time" fits what most people want most of the time better than "Delay," but "Delay" has been around (or at least easier to get to) for longer, lots of examples still use it, and in some cases you can use them interchangeably, though in most you probably need to pay attention to the differences in cancellation (and I normally recommend "Waits" because, again, they tend to be what people want--cancellation on re-trigger--without extra effort).
I would have a virtual switch called ChristmasTime (have the switch controlled by the hub variable via RM). This would let you use the virtual switch as a Restriction in the Simple Automation.
I should add: as long as the hub/platform is running when the "off" is scheduled, how you do it won't matter. But if the hub is off at this time, the job will simply be missed. If this is important for you, you can create a "startup rule" (rule triggered on system start) and do whatever you want there, like checking the time and turning off a device if the condition matches.
Using Basic Rule or Simple Automation Rules will not affect this, either--even if they are good suggestions if they meet your needs (which with a variable, they do not; you could certainly create a virtual switch, but I assume you have a preference not to).
Most times the simplest solution is the best. If you want to absolutely make sure the lights go off regardless of whether the hub has been rebooted during your “delay” time or after your event has been triggered, simply make a separate rule that turns your lights off at the specified time (in your case at midnight). This way the time serves as the trigger and will always trigger a long as the hub is operational at the time of the trigger event (midnight).
This would be effectively the same outcome as the rule written above. A hub reboot does not clear scheduled jobs. The only thing that should make them not run is the hub being off at that time, and that has an equal (hopefully low--you have control over when this happens) chance of happening with either implementation.
The only way to really account for that possibility is my suggestion above, a rule that triggers on the location systemStart event, checks states (e.g., time), and does whatever you want in response. Personally, I haven't found this worth the effort for anything--my hub is rarely off for long periods of time and rarely off at all in the first place, basically just for updates, and I try to avoid doing those when I know I have things pending that might be "up" during those few minutes.
Thanks for the clarification. So if a rule (5.1) has been triggered say at sunset, then there is a power outage prior to the rule being “completed” (prior to midnight in this case) and the hub reboots, the hub will know to continue the rule that was triggered at sunset and complete the action at midnight? This is good to know. I may have just misinterpreted what happens when there is a power outage/reboot or system update since I had a similar situation occur recently and my outdoor lights stayed on all night (did not turn off at the designated time in my single turn on/turn off rule). I just assumed that this was because the rule only ran when it was triggered (my bad) and did not realize that once triggered, it would continue to run even if the system had to be rebooted after an update. Thanks.
I have them dim at a certain time. The go off at a certain time. Then a back up go.off when the house arms for night which can happen.at any time after 12:02 when there is 20 minutes of no motion. Then.I have.other rules that turn lights back.on dim for 3 minutes when it senses you walking around at night or a hue light dim.purple.when you.go.into the bathroom.
Sorry that's backwards . On at sunset -30 dim at 10:00 ..off when.house arms and backup off at 1:30.am regardless.
"Run" is a bit vague, but in a general sense, it will continue to perform future scheduled actions after a reboot. Not just for rules, but at a platform level in general, reboots do not clear scheduled jobs in apps or drivers. (How an app or driver implements things that are delayed is up to the author, but there are limited options, so it's probably a scheduled job, especially for things longer than a second or two.)
Along these lines, with waits or delays, the rule doesn't really remain "running" in the active sense; it creates a scheduled job, then goes to sleep until the scheduled job (or something else--e.g., a trigger) wakes it. Most apps work similarly. You can get some insights with the "App Status" page, particularly the "Scheduled Jobs" section, but not all of these will necessarily make sense unkess you wrote the app (so can see what it's doing) or are familiar enough to make reasonable guesses.
This question comes up a lot, so you aren't alone!
Thank you for the detailed explanation. Involvement of people like you on this forum is one of the reasons I decided to go with Hubitat in the first place. I really appreciate all the help I have been given on this forum. Although I am relatively new to all this, it has allowed me to “program” Hubitat to accomplish just about everything I wish have it do for me in terms of HA. Thanks.
It is nice to have "smart" people on a "smart" home platform, (I'm so "smart"). Not really. All joking aside, I have been on this forum for many years and have yet to be disappointed with the help I get on this forum. Sometimes even I can help someone with their HA issues. It is nice to give back.
You can avoid the delay and still have a single rule by adding two (OR'd) triggers -- one in the morning and one at night. Then, in the rule, just create if-then-else actions, such that if its in the morning, turn the lights off, and if it's night time, turn the lights on. You can still adjust on-off times, required expressions, etc.
I like to call rules like this "controllers". In this case, "Christmas Light Controller" so that I visually know that the complete set of actions are handled in a single rule.
This will also create a scheduled job, and the outcome will be the same as the above (which, again, will survive a hub reboot just fine--unless the platform isn't running when the scheduler is supposed to execute the job). Just to bring things back to the original question in case this was a response to that and not just another alternative suggestion.
I'd also argue that the wait (or delay) is easier to set up--there's no need to use a conditional then, and it's also a tad less work for the hub, though in real life that difference shouldn't matter.
OK, I'm still shifting out of a very old paradigm so please excuse this RFC (request for clarification).
So a RM rule, say one set to trigger on a motion, listens for that trigger at all times the rule is active and takes the prescribed actions each and every time that trigger occurs....but if a WAIT X minutes or a DELAY X minutes is put at the end of the list of actions the rule "holds up" for that duration and it ??? a) hears but ignores the trigger, or b) isn't listening, or rather ALIVE, to hear any triggering until some spawned job is out of that "hold up".
Sure, a "DO LOOP" really isn't how to think of this is it LOL.
Nothing will prevent a rule from triggering if an event happens that matches the trigger event, exept in Rule 5.0 or later where you can specify a "required expession" (formerly a "predicate condition" or "predicate rule"), which will do just that--not trigger the rule unless the expression is true at the moment just before the trigger event.
A wait or a delay will not prevent a rule from triggering. In fact, waits and triggers interact in a specific manner: a trigger event will cancel any in-progress waits. (It will not cancel a delay automatically, but you can get that outcome by specifying it as cancelable and using a "Cancel Delayed Actions" action as the first action in the rule actions or wherever it makes sense for your use.)
Given the above, it is important to carefully consider what events you want to use as a trigger for your rule. In general, the fewer and more specific triggers you have, the easier it will be to avoid problems you might run into with "re-entrant" execution, a concern that pops up from time to time (though not the specific concern of the OP).
So a DELAY (even without cancel-ability) just backs up triggered actions where, in the example below, the DELAY would not stop a backlog of repeating this rule's actions? I thought the DELAY was how you prevented this when you do not want the actions repeated for a few minutes despite continued triggering.
If a delay is the last action in your rule, it has basically no effect. It's just a pause between actions. (You could also put a delay on an action, which schedules that one for the future and proceeds with the next immediately as opposed to pausing there.)
Yo prevent retriggers, I'd recommended a "required expression" in Rule 5.x, or some sort of conditional action despite the trigger (in 4.x or any version).
May or may not be On Topic to OP but thought I'd throw in this use of Predicate and Private Boolean in RM 5.0 to limit the re-trigger of a Rule for 5 min. Hope I did this right as I have a feeling there are probably many ways to achieve this end, and Private Boolean may not be the best.
