Best Practice: One rule, or two?

xkcd: Sandwich

i don't pretend to know how the rule engine works, but i can't imagine that it has to interpret its own pseudo-code more than once... that would be terribly inefficient. as for bypassing the rule engine by writing my own code, i would do that if there were no other way around my problem (and there was). that said, i have been meaning to play around with creating a parent/child device relationship and seeing if i can subscribe to events from one device driver in another device driver and trigger actions based on those events... maybe someday i'll actually have time to do that, but i wouldn't bet on it. :slight_smile:

I would definitely say 2 rules. I currently have some blinds that i'm controlling with a relay, and I control them using virtual switches. I then trigger the rules based on these virtual switches.

By having a wait, the rule will be running through the course of the day, and put unnecessary load on the hub. Just trigger it, open, done. Trigger it, close, done.


The wait doesn’t actually make the rule hang out in a waiting state. It simply add an event subscription for that action. (Like adding a second trigger to a rule) so one could say a second rule is more resource heavy as the second rule will fire any time that event occurs and the one rule will only fire if the first trigger has gone and the rule has progressed to the point of the wait action.

1 Like

Long, long ago when dinosaurs roamed the earth and I was a baby programmer and worked for a company that shall remain nameless, I was asked to make a change to a certain program on a mainframe. Now, this particular program processed data in a dataset that resided on magnetic tape... multiple volumes of magnetic tape. It was expensive to run and had a very long processing time because after each volume was processed, a human had to remove that tape and hang the next volume (this was reel-to-reel tape). And, you know, people miss console messages and take coffee breaks and whatever. Because there was so much data on these multiple tape volumes, and it needed to be processed serially (because tape), any function that needed that data had to be in that one program. Entire business systems resided in the program. There was one senior systems analyst whose entire job consisted of the care and feeding of that program. When I was asked to make a change, I was told, "Put this line of code right here. Don't touch anything else!"

Everyone knew that the data should be moved onto something a little more modern that could be read randomly, rather than serially. And everyone knew that the program needed to be torn apart and rewritten (probably as multiple systems composed of multiple programs). But everyone was afraid to do it because it was a mission critical thing and nobody knew what it actually did. Even the guy whose job was to support it wasn't sure of all its functions, and he'd supported it for years.

Anyway... when I consider whether a function requires one rule or two, it might be better err on the side of simplicity.

Having said that... shortly after RM4 was released, I created a rule that was so complex I couldn't even open it to edit it. At that point I decided I didn't really need the rule that ate my hub, and I split it up into around 10 rules, and I've been really much happier. So do as I say and not as I do. :wink:

1 Like

That is really good info and changes the way I think about building some rules. Previously I thought of the "wait for" as the rule looping a waiting state for a condition to change....which is not the most efficient. Learning that "wait for" is a subscription to an event will alter how I create rules. Thanks for the tip :+1:

What about "delayed" actions? Are those idle loops or are they subscriptions to timer events?

Delays create a scheduled Job.

Most of this info is in the docs

Rule-4.0 - Hubitat Documentation


That doc describes the ability to "wait " or "delay" but it doesn't explain how they are implemented internally as you explained they are scheduled timer events versus processor loops. It does mention that "wait for" introduces another trigger-like capability but does not say that about delayed actions . It makes a difference in the context of this thread about rule best practices and efficiency

What happens to the wait job if hub goes down between the two periods you are waiting, power blip, act of wife, pets, etc?

From my understanding the wait is essentially a cron job so it should be picked back up! @bravenel can you confirm?

Wait is either an event subscription, or a scheduled job, or perhaps both. So what happens depends on what happens (duh). If you're waiting for it to be 5 pm, and the hub is down at 5 pm, that's never going to happen. If you're waiting for a door to close, and the hub is down when the door closes, it's still going to wait for a close event. Each time a rule is triggered, any pending Wait is cancelled.


I have automations such as one that triggers at sunset, turns on some landscape lights, waits until sunrise, turns them off. I can reboot the hub all I want in between, and that has no effect on the rule. Only if the hub were down at sunset or sunrise would it not work.