Currently, you can pause and resume a rule from within another rule but you cannot start or stop a rule from another rule. And as I understand the difference between pause and stop is that when a rule is paused, it still has to respond to bound events whereas stop unbinds the events so it's sort of like the rule doesn't exist. So a pause rule still takes some processor time and likely memory.
I have rules such as, I have sets of rules that are active when I am working here at home while other outside work hours rules are paused. Then at 5, the rule sets switch so it keeps work-related rules from trying to run during off hours.
So I would like to see the option to also start or stop a rule from another rule. I would think this would save resources on the box. Is this possible? I realize that a rule that is stopped may not show up in the In Use By list of the properties of a device but personally, I can live with that if it improves performance
It would still show as "In use by." That's determined by references to a device in the app's settings, which generally include device selectors in the UI, and those selections would remain (otherwise, the rule wouldn't know what to do when re-started--or when you're creating it in the first place).
I can't speak to whether this request will or won't happen, though the means to do it doesn't appear to exist in the public Rule Machine API (just pause/resume), so it's possible there's also not an easy way to do it internally (or even if it does, perhaps there is no desire to add even more options to the UI). But for the use case you described, there is something you can do today that would already address your specific concern: a required expression. If you add one that determines whether you're at work or whatnot, the same criteria you'd use to pause or stop the rule, that would have effectively the same outcome. When the required expression is false, the trigger events are normally un-subscribed to, so the rule will not wake.
That being said, none of this woud actually normally be on my list of concerns. Are you actually having problems, or do you notice high resource usage by a particular rule in App Stats? If not, this probably isn't even worth pursuing in the first place.
Wouldn't another way to simply build a variable to populate based on the primary trigger rule? So that if the variable is populated with X then the secondary rule would look at that rule and exit rule and continue that way till the variable is no longer X?
Yes, if I'm thinking correctly, even if you have a restriction, the event is still triggered, the restriction prevents the actions from being run, similar to the way pausing works. By stopping the rule, the rule is completely ignored taking 0 processor time.
"Restrictions" haven't been a thing since the inital release (shortly thereafter removed) of Rule 4.0, but I assume you mean "required expression" (formerly called predicate rule or predicate condition)? If so, no; they work as I described above:
You can test this by creating a rule with one and examining the App Status page for event subscriptions. But again, I'm not sure this is something I'd bother with unless you are noticing problems (or high app stats usage and are concerned regardless) or maybe have a particularly chatty device as a trigger.
I will check that out, there are still some interface and reporting things in Hubitat I'm getting familiar with.
I do use required expressions (restrictions is the WebCore term ) quite a bit. And I do have motion detectors in the areas where they can get 'chatty' as you say. So I like to manage that so the processor isn't spending time on unnecessary things. When the CPU is spending time on unnecessary things it can be doing the necessary things so it affects performance. And while a single rule may not take a lot of cycles, when you multiply that by a number of rules being fired frequently, it adds up.
I have a bunch of rooms with lights in them. All of them have motion sensors.
I however want the ability to be able to 'manually override' the motion rules.
However I also want to be able to 'reset' manually overridden rooms back to motion rules.
Here's how I implemented it using 2 global variables for every room:
One indicating the room light status as set by the motion rule, and another for the room light status as set manually (be it directly in HE or via HUE app/switch):
-1 = lights set off using this ruleset
0 = rule inactive (room set using the OTHER rule set (motion vs manual))
1 = lights set on using this ruleset
So whenever motion is detected, the motion rule first checks the variable for the manual rule. If it's set to 0, it will do it's thing... but if it's set to -1 or 1, it will stop executing the motion rule.
The manual rule is a bit more complex, as it's triggered every single time the room lights turn on or off (be it via the motion rule, or manually). So it has to check:
-> was the light set by the motion rule? -> stop rule execution
-> was the light set manually? -> set manual rule variable & disable motion rule
-> was the light set manually twice in 5 seconds (my current 'reset' timer)? -> re-enable motion rule
It only works using CoCoHue with push events enabled.. because otherwise you might set the switch ON/OFF manually in Hue.. but Hubitat won't receive a switch status changed event for another minute when it polls the Hue bridge for switch statuses. Or ofc you could have your manual switches & lights directly linked to Hubitat.
Here's my motion rule for room 'CR' and the manual rule for that same rule.
(note it isn't perfect.. I still have some tweaking to do. for example toggling the switch manually 3x (or any odd number beyond 1) witin 5 seconds does something different than toggling it 4x (or any even number) within 5 seconds.. and also WHAT it does differs depending on whether motionrule or manualrule was active prior to your toggling. I ideally want to make it so that a single manual toggle always enables manual mode, and ANY amount of toggling beyond 1 within 5 seconds (re)enables auto mode.)