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.
That would indeed be a perfect case for the use of predicates.
Predicate: Date is between Oct 7th and Oct 15th
Trigger: Time is X
Rule: Turn on Switches, wait for time Y, turn off switch
What is RM5? I have Rule Machine Legacy. Is that the same thing?
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 assume RM5 is in the App list as merely "Rule Machine." That's what I downloaded and it has the option to create predicates.
What if I want to have this rule turn off the lights at a certain time? What would be the best way do that?
I think @Sebastien 's example is probably best for what you described in your original post:
Actually, the specific time would be a bit different.... I'll think about it...
Instead of waiting for a period of time, I'm pretty sure you could wait for a specific time of day....
Would this do what I want - turn on the lights at sunset - 15 minutes and turn off at 10:30pm every day from Oct 7th through 16?
Yes 
I was about to explain more about the difference between predicate conditions and triggers, but looks like it is sinking in...
I linked this thread to @jshimota 's thread discussing a coding question around identifying seasons. There may be something useful in what @jshimota is doing for you as well @Krishna.
I'm not sure if this helps but I created a form of rule for certain dates using a global variable and this:
I notice in your predicate condition that you have an “and” followed by nothing. You’ll want to remove that and to ensure the rule works.
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! 
Thanks in advance.
"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.
But:
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).
Just noticed this thread which is pertinent to this discussion. Posting for future folk hitting either to find.
I also feel like some of the new features in RM as part of 2.2.9 may also be useful here... Can't say that with any experience, I haven't installed it yet...
Download the Hubitat app
