I have a legacy rule that turns on several outside lights at dusk, off at 11pm, on at 5:30, and off again at dawn. I can't even see how to get play off this in the new rule 5.0. What happened to the options to turn things off again based upon rule conditions?
Here is an RM5.0 rule I use to do just that.
Change the times accordingly.
Summary
I see that. Thanks. But doesn't it add overhead to the Rule Machine to keep the rule running for hours during the delays? I have a few of these type rules (like a fan when it's too hot, etc) and don't want to have the Hub really slow down.
I am not an expert, but my understanding is that all it does is setup a subscription to an event, condition, etc. When it's waiting for that it isn't really running in the sense that it is doing anything. I have lot's of rules that do similar things to the above posted one, that might wait for hours for something to happen. My hub seems to run just fine.
1 Like
No, the "Wait" in this rule creates a subscription to the event, as @kyroha suspects above. The rule goes to sleep, then will wake when that event (sunrise, in this case) happens and continue with the next action. (So, for example, it does not mindlessly "spin" and constantly check whether the time is sunrise.)
This isn't a "Delay" per se (if we take that term to mean this specific Rule Machine action, which is called that), but delays work similarly: they create a scheduled job for whatever time in the future, then either wait for that (if using a standalone "Delay" action) or continue with the next action in the list (if using the "delay" option on a particular action).
This sounds like pre-Rule-4.0 rules (also part of what is now Legacy Rule Machine), so it must have really been a while. 
Rule truth is no longer a thing; everything can be done based on triggers and (in the actions) conditions, or new with Rule 5.0, predicate conditions (but I wouldn't rush to use them just because they're there). This post may be helpful for catching up on some of the history, including how to "translate" Rule 3.x logic:
Thanks. The event driven aspect sounds appropriate, I think I was thrown off by the term "delay" which sounds like it's still active and waiting. But that architecture is good to know. I find the simplicity of 5.0 appealing over the rather confused interface of its predecessor - I'm used to programming and its logic, not the interface that it used to have. I guess its just going to take time and creativity to program new Rules that implement some of the "features" of the old system.
You have to be very careful when setting up a lighting routine that incorporates sunrise/sunset events and specific times in the same routine. Of course, if you lived on the equator and sunset and sunrise occur at the same time each day, that would not be an issue. However, where I live near Chicago, sunrise can vary from 5:15 CDT at the summer solstice to 7:19 CST at the winter solstice. That represents a three hour difference in sunrise including the daylight saving time offset. Likewise, there would be a corresponding three hour swing in the sunset times.
If I were to set my lights to come on at 5:30 am and turn off at dawn, but dawn came at 5:15 am, then the lights would not turn off until nearly 24 hours later. Be sure you take this into account to avoid unexpected results.
Thanks. Already calculated the times, been working great for a couple of years - just trying to update things.
1 Like
