Hi all, I've read some threads here about the usage of RM's 'Exit Rule' and it appears to me that all the examples given didn't really need an 'Exit Rule' but just better written rule in general. Exit Rules appear to be a lazy way of stopping a rule from doing something that it should not have been doing in the first place, had it been written 'properly.'
I hope I am wrong and there are genuinely valid cases where an Exit Rule should be called. Could someone please give me some examples of a good usage of an Exit Rule..? TIA!
Sometimes, if you have a long, complex, multi-page Rule, it’s clearer ((in my opinion) to bail out with Exit Rule rather than try to follow nestlings in and out of conditionals that end up not being satisfied.
OK fair enough. So essentially to save the rule writer from a massive headache. But apart from that, are there situations where an Exit Rule can achieve something that otherwise cannot be achieved with properly written conditional statements?
I can't think of any, but as noted above, it does save you from needing to write those conditionals. For example, an actions section like:
IF (NOT Mode is Evening) Exit Rule
// do stuff
is a bit easier to write (in that you don't have to use a full conditional) than:
IF (Mode is Evening) THEN
// do stuff
END-IF
...and even more so if you have additional things you'd like to test later. I think it's also easier to read since you don't have to deal with potentially multiple levels of indentation, too. So, I guess I just agree with the above. As with lots of things in Hubitat, there is not usually only one way to achieve the same outcome, so some of it may come down to personal preference if there isn't a specific need.
But you definitely don't need Exit Rule where you see a lot of people use it (e.g., as the last action that would run in that particular execution of a rule anyway). There are also times you'll see people assume it does more than it does (e.g., cancel scheduled jobs like repeats or delays). Besides delays, it seems to be one of the most widely misunderstood actions.
Maybe a bad or basic example, but one to start the thought process. Maybe I have a button device with 2 buttons. And I am using one button for a different rule, or just don't want to process something.
If button 1 pressed, exit rule.
If button 2 pressed, do XYZ.
Being this simple I probably didn't have to do the exit, but if I had multiple buttons or more likely I had something like temperature that was triggered all the time, I don't want to process and do something every time temperature changes.
So then it would turn into
If temperature below 70 degrees, exit rule.
If temperature is above 71 degrees, turn on fan low.
If temperature above 80 degrees turn on fan high.
Etc, Etc.
Again, maybe an oversimplification, but it saves me from having to analyze every temperature below 70 degrees.
Sure, definitely not done to be lazy. A simple conditional as the first action of a rule (not to be confused with a non-simple conditional) followed by an Exit Rule is a good method for reducing the load RM places on your hub.
I would disagree with you on your interpretation of:
If by properly written, you mean write them in such a manner so as never have to use "exit rule" then obviously you write them as such. But, if your objective is to write the rule to execute as efficiently as possible while placing the least amount of processing load on the hub, then "exit rule" is a valuable strategy. You need to define what you mean by "properly written conditional statements".
Consider a rule you want to trigger every 15 minutes, you also have a temperature sensor that is reporting temperature every 1 minute, and you want a heater to turn on (only during nightime hours) if the temperature is below a certain threshold, how would you write the rule?
1st possible way to write the rule:
Trigger: Every 15 minutes
Actions: If Daytime - Exit Rule
If Temperature is below X then turn on Heater
2nd possible way to write the rule:
Trigger: Every 15 minutes
Actions: If Nightime and Temperature is below X then turn on Heater
If you have a hard time understanding why the 1st method results in less processing load on your hub, you need to review how RM works. Either method above is fine and will result in the rule doing what you want, but one is more efficient and will result in an overall reduction of processing load RM is placing on your hub. If you think it would be better to have temperature as a trigger, than you really need to review how RM works (the temperature sensor in the example above reports once a minute).
There are many ways to write a rule to do an automation. I just looked at my rules that use Exit Rule, I could rewrite them not to use "Exit Rule" and they would still work fine and I doubt I would notice any difference. But, as a person that cares about writing the rule in a manner that will result in its most efficient execution with the least processing load placed on the Hub, "Exit Rule" is a strategy I use to achieve this objective.
Thanks guys for some great examples. I suppose my brain just doesn't quite work in such a way and my starting point is always to write out a conditional statement.
@Stephan.J -- in the example that you gave -- sure, I can see the benefit of doing #1 vs #2. But isn't there a 3rd way that is less computationally demanding and more similar to #1, yet doesn't use 'Exit Rule'?
Trigger: Every 15 min
Actions:
If Nightime then
If temperature is below then
Maybe that's still more computationally demanding than your #1, I don't know. But you are right, I certainly don't think that my #3 would be more efficient than your #1.
I will have to go through my rules and force myself to think through the lense of 'Rule Exit' to see if it makes any of them any more efficient.
Yep, it is. But it is important to realize that in all likely it doesn't matter, the computational demands RM places on the hub do exist, but can often be greatly exaggerated. So either way, it is going to work and you probably would never realize any difference in performance.
This place is full of people that really know their logic (way better than me, lol). Maybe they just put in "Exit Rule" to keep all those people happy. Instead of the rule taking an average of 400 milliseconds to execute, now it takes an average of 270 milliseconds.
Probably not. Especially if it isn't a rule that needs lots of filtering like the couple examples Stephan.J and I gave above.
Maybe going forward, see if you think it is needed.
And as always, I suggest cloning the old rule, pausing it, and only working with the new rule if you are making changes like this. You can always revert back if you don't like what happens.
i've used exit rule to stop a rule from running multiple times. i would turn a private boolean on (TRUE), and while that private boolean is TRUE, it would have a conditional to exit the rule. at the end of what i was doing, i would flip it back to FALSE so i could run the rule again if needed
There is another cost to consider: the cost of developing, testing, maintaining, and changing the Rule over its lifetime. Processors have gotten so much more powerful over the years. When I started designing computers back in the late 1960s, they couldn’t do much, had 4K of RAM, and assembly language was a luxurious step up from machine language.
Perhaps I could spend hours tweaking the last bit out of a Rule, but I have to ask myself when the Rule is “good enough”, reliable, and will be maintainable when/if I revisit the Rule months down the road.
Ok you guys got me thinking about a couple of rules I use to turn on ceiling fans in my kids room when it gets too hot at night in their rooms when their doors are closed.
Maybe this will also provide another example.
This rule is obviously running everytime the temperature sensor reports a new temperature, even in the winter when the rooms aren't hot and the fan is never going to run.
Yes, absolutely. My initial question in this thread focused on functionality, i.e. whether Exit Rule offered any incremental functionality that wouldn't be handled by what I would call 'more traditional ways'. It quickly transpired that while there are probably no real functionality benefits, there might be computational benefits. But as you say, if we are talking about saving milliseconds, then the question must be asked -- what is the 'opportunity cost' of trying to save these milliseconds. I am not saying there couldn't be a be good reason to try to do that, but at the end of the day we are not building engines for NASA here to really care about that sort of efficiencies...
I have to say I would like to have more 'intelligent' / sophisticated rules, but I feel like I am limited by a couple of factors:
Size / complexity of my house -- I live in a circa ~1500 sqft townhouse in London. I have a tiny backyard and a one-car driveway. No property gate to open, no need for extensive outside lighting, etc. The house is two storey plus converted loft, in total 4 bedrooms, my office that can turn into a guest room, lounge with dining area and small kitchen, conservatory integrated with the lounge; master bathroom, en-suite, a downstairs toilet. It's England so we don't have AC or massive ceiling fans.
In terms of smart devices all talking to Hubitat -- contact sensors on all windows & doors, motion sensors scattered in a few places, all smart bulbs (apart from bathrooms), some smart plugs, buttons / switches / dimmers scattered around the house, smart blinds, heating with each room controlled by its own TVR, Harmony Hub, a few exterior Blink cameras (and a proper wired camera system that doesn't talk to HE as well as alarm system that is smart but doesn't talk to HE), Eufy doorbell, and a couple of Alexa devices. We are a small family -- my wife, my 3 year old, and myself -- so we don't have too many people moving around the house and doing things.
My imagination -- this is probably the biggest limiting factor. I just can't think of complex automations. I literally go through my days now trying to imagine my 'dumb' routines replaced by Hubitat automations and only come up with relatively simple things. I've tried to watch some YouTube channels to get inspiration and they either rely on kit that I don't have and don't need (e.g. water leak sensor, garage door, etc.) or are just silly and an overkill in my opinion.
How do you guys come up with your automations? Do you draw inspirations from somewhere or are just that creative and can think of 'the art of the possible' more so than I can?
The only rules I have ever come up with ( I have 42 RM rules) have all been created due to an automation I wanted to have happen. I never actually think of rules or rule machine until I have thought through the automation and what exactly I want. Some of the automations I desired sound simple, but when trying to write them in RM it became difficult. I enjoy the challenge, to me it is like doing a logic puzzle, sometimes I get stuck and ask for help. I review all the suggestions and I am thankful to everyone who provides a suggestion. I also take note of people who have elegant, creative, and really intelligent solutions to problems that come up when creating difficult rules. I send a personal note of thanks to these members and keep them in mind, if I ever run into difficulty again.
Some of the automations, that required (for me) rules that were difficult to create:
HSM will speak out windows that are open, when you go to arm the system and if a window(s) is open it will fail to arm. I wanted the same automation, but I wanted the system to arm regardless, so I created the rule in RM.
I live in Canada, and it can get COLD, (at this moment it is -34 degress Celsius), so I wanted a GV that would have several possible states (Extreme Cold, Very Cold, Cold, Chilly, Brisk) all for temperatures below freezing, LOL. I wanted the GV to represent different temperature ranges. Sounds simple, but it wasn't, thanks to @napalmcsr, who showed me an elegant and efficient way to do it with nested if statements. I then use this GV for things like what time to turn my block heater on in the morning.
I wanted tiles on my dashboard that update daily with the amount of days left before I need to change my filters. I also wanted to reset these from another tile. Sounds like a simple thing to do, until you try to make the rule, LOL.
Some automations that sound simple, can be really complex to create in RM.
@Stephan.J - I can certainly appreciate that although an automation might sound simple, it can be pretty hard to implement. And yes, I treat the whole home automation experience as a hobby that keeps sucking me in -- it's the logical puzzles, but also as I mentioned earlier, thinking of ways to translate my 'physical routines' with 'Hubitat routines'. And the community of people I've found on this forum is truly fantastic -- everyone I've met is super helpful and takes the time to explain things to me. It's really refreshing to be on a forum where people don't scream at or insult each other.
Could I ask where in HSM this feature is available? I created my own 'check windows & doors' RM that does that, but it's separate from HSM. If that's something that HSM can do, I would rather keep it all integrated.
Oh boy, that's indeed cold. I spent Christmas in Montreal once and thought that was cold, but I don't think it ever got to less than -30C.
Earlier today I thought of an automation that just like you said -- sounds simple, but I think might be reaching the limits of my RM rule writing skills (I will probably post another community forum question dedicated to it).
I also have a young one and when she was born I was determined to that we would do everything we could to make sure she was a good sleeper. We have a RGBW lamp as her pendent in her room and when it was bed time I wanted the light to be red. This would help with setting up her natural rhythm that baby's basically don't have. I also wanted black out blinds and for all things to be automated. So when I did her room I fitted what I needed, then did this.
But apart from that, are there situations where an Exit Rule can achieve something that otherwise cannot be achieved with properly written conditional statements?
