Hopefully a simple question. With holidays time coming up, I want to create a rule that will automatically turn on certain holiday lights during certain hours of certain dates. Let's say from Oct 7th through Oct 15th for now.
How does one go about doing that in Rule Machine? If it's obvious to others, I admit I've missed how to do it.
Looks like you can do conditions that are between two dates, so 1st October to 31st October. Looks like they are not specific dates in the fact they don't include a year, I'm assuming that is so they can be recurring each year. I haven't installed RM5 yet, but hopefully you could include these as predicates as well.
I would also expect you could do something with variables if you wanted to make it a little smarter, but not sure how to do that exactly.
Another avenue you could take you be to look at some of the Calendar integrations that can allow you to turn on switches when a calendar event comes up. You could then use the related switches to drive your rules.
Legacy is Rule Machine version 4 / 4.1 (or perhaps earlier versions are also labelled like that as well). You can have each installed at any one time, so you can install RM5 alongside your existing legacy install, just go to apps and select Add Built-In App and choose it from the list.
I was JUST thinking about this kind of thing.
And I would love to hear from the respondents about "system burden" or possible risks.
If one did a bunch of these "seasonally active" apps, where all you'd have to do is make sure the end device(s) were in place (w/ full battery) at the right time of year and the app would just go about doing what it was set to do with no manual HE system lid lifting:
a) what would the burden difference be on the HE system manually PAUSING vs manually DISABLING that app <--by the way does that matter much which of those one uses) ...or would it even matter for less than 20 such apps to be sitting there waiting for specific date ranges. [Note: Edited from previously worded "STOPPING" vs reworded to read "DISABLING" ]
b) which of the ways to accomplish this are most efficient (Predicate or otherwise), not just coding-wise but resource-wise as per concerns in "a" above.
It might be helpful if you did leave a brief on that here!
"Pause" and "Stop" are not universal app features in Hubitat, so the answer really depends on what app. I assume you are talking about Rule Machine in particular, since that one such place I'm aware of where this terminology is used. In that case, there is a difference: for one, the "Stop" (and "Start") tasks must be run manually, i.e., from the admin UI yourself. This cannot be performed from another rule like "Pause" and "Resume." Therefore, the former aren't really useful for full automation, though it can be a sort of substitute for it if you don't mind manual intervention.
In terms of outcome, there is a difference: "Stop" is basically as good as uninstalling the rule. All schedules, subscriptions, etc. are erased. "Pause" keeps all of these, but if the rule is triggered, it will just wake up, realize it is paused, and go back to sleep. Thus, there is still some cost here, albeit minimal. (I'm pretty sure it also used to be that "Pause" would not affect timed actions like repeats that were in progress--they'd keep going--but in the latest version of Rule, that isn't the case, and they will indeed truly pause.)
Then there are predicates. Usually, the predicate becoming false will cause the rule to un-subscribe from the trigger events (similar to a "Stop") and just subscribe to whatever event(s) could make the predicate true again. In some cases, this could happen less often than the trigger event. In some, it might happen more, and in that case you might be better off with a conditional action (e.g., as the first action) rather than a predicate--if this is truly a concern.
For pretty much any real-world case, my guess is no. If you really suspect a rule is a problem, you can check the "Runtime Stats" page to be sure none of yours are running for excessively, by either total amount of time, number of executions (this alone isn't necessarily a problem; some apps do wake in response to an event, then realize they don't really need to do anything, but if there's no other way that subscription could work, then it is what it is), or whatever other metric you might be concerned about.
I'd just avoid things that tend to be bad ideas when writing rules. For example, every once in a while you'll see someone asking how they can write a rule that will run (trigger) every so many seconds, check if a switch is on, and then do something in response. In nearly all cases, it would be a better idea to just trigger based on the switch turning on, then do whatever you might need to. (Hubitat is event-driven, and it's usually best to respond to events in your apps/rules, even though you can write things almost any way you need to.) Beyond that, I'm not sure details like the above matter too much--and if they do, you now have some tools you can use to identify cases where it might be so (those being runtime stats; previously, this was a guessing game for end users).