When Time of Day is 6:15 AM ...
Turn on Water Heater
Wait until Time of Day is 9:30 PM, then ...
Turn off Water Heater
But the rule never turns off the water heater. There is no event at 9:30 PM:
The only reason I can think of is because I just created this rule, and the first event "When Time of Day" hasn't occurred yet.
I am especially concerned about this rule when there's a power failure during the first event, which makes me believe the OFF event will be skipped (assuming the power is restored by the time the OFF event should occur).
If the above is true, then...
Is there (or should there be) and option to specify "When Time of Day is BETWEEN 6:15 AM and 9:30 PM, then turn ON, else OFF."
Platform: 2.4.0.151
Basic Rules: Version 1.0.4 (9/26/2022)
my understanding is that the rule is dormant until its triggered.
When its triggered it turns on the switch and then schedules the turn off event
when its the right time it actions the turn off.
In the event of power failure during the turn off event its my understanding the turn off wont run as the trigger time has passed.
i wouldn't use anything like this for safety critical.
You could create a rule in rule machine to turn it off at hubboot up i think ie
event - hub start
If time between 9:30 and 6:14 - turn off water heater
but again that making an assumption that the hubs database hasn't be corrupted by the incorrect shut down (power loss).
Given the long spread of time between on/off events and the importance of having hot water when necessary, I myself would split this into 2 rules -- 1 for On, 1 for Off.
Having a long Wait for makes me nervous -- if the hub gets shut down/rebooted (intentionally or otherwise) in between, will the Wait resume or could it potentially get lost?
If you split into 2 rules (each with its own very clear Time trigger), then execution confidence stays high.
This is the reason. Basic Rule actions run in order. The first one is basically your trigger. If that doesn't happen, nothing else will.
This not possible in Basic Rule in a single rule. The suggestion above to create two separate rules works if you anticipate this being a problem. Otherwise, the first time you create the rule, if you want to immediately "trigger" it without waiting for the first event, use the Run Actions button at the bottom. (I'd suggest Done first to make sure all your changes are saved, particularly restrictions if you're using them, or anything besides actions that are just saved as you do them; you'll need to navigate back into the rule after this since it takes you out.) But normally, you shouldn't run into this.
Nope. It creates a scheduled job, and a reboot, shutdown, etc. will not affect that. It will still be there when the hub comes up and execute at the scheduled time. (Of course, if the hub is still off at this time, it won't -- but, one app or two, you'd have that problem either way.)
That being said, two rules can still be helpful! It will help the "off" side still run if the "on" time was missed for one of these reasons, for example, and it does avoid the somewhat odd case (but clearly not impossible) case of the above.
I am going to have a similar problem with lights. Another example scenario would be sprinklers.
If a trigger is missed, I don't want my lights to come when I'm sleeping.
If a trigger is missed, I don't want the sprinklers to stay on costing me a huge water bill.
I would like Hubitat to check the between time range, or I learn how to do this better.
Then you want two separate rules or another app entirely, like Room Lighting or Simple Automation Rules (I wouldn't normally recommend that, but its sole advantage for you in this case is that it doesn't care since both the on and off parts are, for the most part, entirely separate configuration).
Since you are in control of when you reboot or shut down your hub, you can also mostly avoid this by not doing so at 8 AM if that is the trigger time for an important automation.
What happens in this scenario?
Device is scheduled/triggered to be on for the duration of the green time.
Power outage happens before the OFF trigger, and for the duration in the bracket.
Power is restored, but after the OFF trigger.
I would split your on/off rules into two, as noted above. - Short/KISS rules are better for a bunch of reasons.
If you want to deal with "missed states" during a power outage, you going to have to write a 3rd rule, that fires on the system startup event. - That rule will basically have to look at the current time, and decide the proper state, refresh the required devices, and then trigger any needed commands to update the devices.
So what you want, can be done - It's just on you, to write the startup rule, to "catch things back up" - Hopefully, your just dealing with Time-of-Day, and not specific dates, as that can get more complicated, and you may need to move to Rule Machine (RM) to be able to do the required date math, and trigger refreshes for battery type devices (as you may have missed device updates while you we're down). The beauty of rule machine is that you can develop whatever logic you want to decide to "catch up" and event, or just "skip it till tomorrow", all depend on how long you have been down, etc. You can code whatever you logic you want.
Also in RM5.1 - see the note about "Eval on Startup" - Rule 5.1 | Hubitat Documentation - Specifically, the section: * Evaluate required expression on system startup: will re-evaluate the required expression after a hub reboot or other startup. One possible use case is if any conditions in the expression use times or dates that may have been missed if the hub was offline at the time the evaluation would have changed.
But yeah, what you asking for can be done - It's basically just on you to do it, with the basic primitives that the hub supports around time/dates and device I/O. - There isn't some automagical way to do what your asking, as obviously the hub isn't doing anything while it's down, and the external state of the world is obviously changing during that time. Just be aware, with RM, your starting to "wade into the deep end of the pool", for someone that's all new to HE.
I don't want my home to look/feel like a carnival circus when the electricity is restored from a power outage (happens several times a year). Yes, getting deep, especially confusing with the different, yet similar, apps.
Your point is important "Basic Rule actions run in order". And I am interpreting what was said here is that if there's a power outage before the "wait", then the entire action is reset/nullified, and the "wait" action is no longer waiting.
Simple Automation Rules needs two triggers. So at the very least, there's two triggers, and will be activated by whichever trigger happens first (on time or off time).
Rule Machine. Did I do this correctly? Is this doing the same thing as creating two "Simple Automation Rules"?
No, that interpretation sounds like the exact opposite of what I said:
As I mentioned there, that scheduled job does need to get created in the first place. In a Basic Rule, that means the action itself needs to be reached, which it will be when the rule is saved if it's your first action (the "trigger" -- this could be a scheduled job or event subscription, and it should be noted that the persistence applies to both of these). Otherwise, it is whenever that action is reached. In your original Basic Rule, that would be basically right after the rule is "triggered" and the command to turn on the switch is sent.
If you take a look at the above, you'll see more on the nuances and possible other solutions for this, though again, you really have control over most of this so I'd expect it to be rare in the first place. (And in your original rule, unless you turn it on manually, it's never going to turn on the first place, so turning it off -- the rest of the rule -- would have no real effect. It would already be off. Do you have additional considerations like this? An entirely different approach might better if you share more about what those are.)
No, you can just (usually, depending on the device) configure two different things to happen for different states of a device. In a typical example, you could configure one thing (like turning on a switch) for motion active from a sensor and another thing for motion inactive (like turning off a switch). It doesn't matter which happens first, if one event was missed, etc., because both subscriptions are always active. But you can configure just one "side" of this automation if you want; it doesn't need both pieces.
It's "correct" in that it will do basically the same thing as your Basic Rule. It will not do the same thing as two Basic Rules. You'll need two Basic Rules or two Rule Machine rules for that (ignoring some awkward ways you could trigger the RM rule that I would not suggest) if you do not want to go with Simple Automation Rules -- or, again, just try to avoid this outcome in the first place.
The required expression is pretty much useless, though, as 6:15 AM (the trigger) is always going to be between 12 AM and 11:59 PM (and the required expression in your rule just prevents triggering if false).
I need to create two separate Basic Rules (or Simple Automation Rules, but this is less desired; I noticed Simple Automation Rules does not allow to manually run the actions).
While I can't see the contents of the rule from just the app name, the description sounds more or less like what you want.
Right, and likely for a combination of reasons: it's an older "rule" app (this feature was added to newer ones to make testing easier), there isn't a single set of actions to run (unlike Basic Rule or Rule Machine where it's an ordered list and can just start at the top), the things you can do with it are pretty simple (so the need to test in the first place is minimal: if you tell it to turn off a switch, that's what it will do -- if you want to test on/off on the switch itself, use the device detail page to try the command), and use of "Restrictions" would probably raise lots of questions about what running any "actions" means if any are in effect.
Anyway, if this particular scenario is high on your list of priorities, the approach you're likely taking seems like the simplest path to take.
It creates a scheduled job, and a reboot, shutdown, etc. will not affect that. It will still be there when the hub comes up and execute at the scheduled time. (Of course, if the hub is still off at this time, it won't -- but, one app or two, you'd have that problem either way.)
