Did you get it up and running?
I was a bit overwhelmed but the vast difference in how to handle this so I ended up breaking the one rule into three and it seems to be working correctly.
Itās frustrating because I was trying to streamline the process and I thought one rule would have been a good choice.
One rule to rule them all isn't always a good choice. Honestly you're not saving any processing and you risk a timed even being pooched because of a reboot when all in one. Remember, KISS always applies.
A good example of this is a rule that I was fixing and ended up having to do completely differently. Basically if rain/mix/hail turn on virtual switch that has app check all windows contact sensors and send message to phone/speak to echo. Being that I am now using a virtual switch as part of this rule for trigger, it was easier to simply create a secondary rule that says if the sensor changed to none then turn virtual switch off. Writing it all into one could be problematic so two it was and now I can work on other stuff without worry.
1 Like
It is worth noting that this concern is often overblown; a reboot does not clear scheduled jobs, which is what specific time triggers, periodic triggers, delays, waits with timeouts or specific times, and similar actions in rules (and similar concepts in other apps) create. So, a rule triggered at one time with a wait for another time will continue as usual when the hub comes back up--no concerns.
Of course, if the hub is off at the exact time of the scheduled job, that scheduled execution will be missed, and there won't be any "catch up." However, that is generally true no matter how you schedule the job (though if they are "chained" as might be done with a specific time trigger and then a wait, missing one of those would affect the next, unlike separate triggers or separate apps/rules--but that's the only concern, not reboots per se).
In almost all cases of problems I've seen here, either the rule itself is working fine and there are some problems with the devices or configured actions, or the user hit "Done" or something in the middle of execution and cleared all the schedules (which "Done" or "Update Rule" will do). Reboots...usually not. 
Logs are your friend in any case to figure out what's happening if something doesn't work--something I'm still not sure we ever saw for the above rule (again, we want the app/rule, not the devices).
1 Like
The other main difference you are overlooking is if the main trigger fires again or multiple times.
I believe in this case the behavior will change as when the compound rule is re-entered any existing scheduled waits will be canceled.
Sure, but the "main" (only) trigger here was one specific time a day, and the waits were for other specific times later in the day, so not really a concern. This concern is also specific to waits, whereas my comments are referring to scheduled jobs in general (though waits are probably my favorite now!).
Never said it applied to this case . Just in general something to remember for one vs multiple rule approach.
