I'm sure this has been asked several times in the past but wanted to throw this into for consideration in rule machine and ideally for all apps.
Disabling automations by mode
Any thoughts if you would consider adding a checkbox for rules that lets me select if a rule should be disabled in some modes?
I think this would simplify a lot vs adding a conditional to the beginning of every rule to check if "mode is" or "mode is not".
In my mind i'm thinking of a similar pulldown as when you select logging on or off. "Do Not execute rule when in these modes" type of construct. By default the rules could execute for all modes but if a rule is checked then it is not executed when in that mode.
This way a new mode that is added would by default execute with any existing automations when set, but a user could go and on a per rule bases disable the rule for select modes. Best of all i don't have to go an update every rule with a new conditional
In fact, i think this would be a lovely capability for all apps, perhaps something enforced for all apps, and on a per rule basis for rm?
My use case
I would use this to disable my motion automations when i have party mode enabled (i would build a scene using RM that triggers setting lights across my house independent of movements. But as i build more and more automations i think it simplifies a lot to have a "do not execute in these modes". In fact i would love to have the "do not execute in this mode" for every app and not just for RM.
Many apps have mode restrictions built in (to address your last request). From a developer standpoint, I think it's any single-page app without dynamic pages where (I think) you also haven't specified a mode input. Many apps provide their own mode input instead, often with different options than a simple "don't execute in this mode at all," or sometimes leave it out if it doesn't make sense for that app.
Earlier versions of Rule Machine actually had this plus a few more restrictions built in. They were removed quickly after 4.0 because they were nothing you couldn't already do with your own actions, and every rule paid the price of having to make these checks even if you weren't using these features--or I seem to recall the explanation for their removal being a combination of both of these reasons. So, if you ask me, though I know you didn't, I'd say it's unlikely to come back.
But the workaround is pretty simple, as you note. It can be as simple as a single simple conditional action, like IF (Mode is Away) Exit Rule or something arbitraily more complex with a "full" conditional. Probably one more reason not expect it to come back. For other apps, there's usually something there unless the developer specifically chose something else (or, if it's a community app, maybe just didn't know how it works, and in that case the author may be receptive to comments).
i don't know what processor this is, i kind of assumed its one of the ARM processor families. Don't they mostly have shallow pipelines making the cost of a conditional less expensive?
I'm surprised at performance as the reason. if this is part of the RM4 runtime i assumed this is compiled rather than interpretated (at the very least groovy must have a Hotspot style compiler?) and it seems like the type of code that would run fast even if there are frequent pipeline stalls.
I digress, but it would be pretty nice to have. i guess i can write my own conditionals.
We know the processor is ARM, but I'm not sure any of us know specifics about the environment beyond that (and the fact that it's mostly Java plus Groovy). But my guess is that it's also a very small computational price to pay. When we hear things "simpler" in an app context here, I'm never sure if they mean "simpler for users" or "computationally less complex," so I didn't mean to imply anything there either way. But it is what it is.
One solution I've seen is to wrap the entire rule in an IF THEN whose contents will only execute under whatever conditions (mode, etc.) you want, but a simple idea I alluded to above is pretty easy and with a simple conditional only takes a few clicks (and for any combination of modes can still be a "simple condition" even if you combine multiple modes or negate the expression, as below):
I'm sure you know this, so just posting for anyone who is wondering. I don't think the previous feature is likely to return. I also found the post I was thinking about when I wrote the above in case you are curious more about the history and reasoning behind this:
You could always leave your existing rules alone and make a new rule the pauses and unpauses rules based on mode. Although that could get complicated fairly quick.
I don't think there is much chance of this request being implemented due to the fact a simple conditional is a quick and easy thing to add. Also, this goes without saying:
Could you imagine if this wasn't the default? Every user regardless of whether or not they wanted this change to RM would be required to modify most if not all of their existing rules. LOL
I understand what you mean by a "similar pulldown as when you select logging on/off". That is easier than a simple conditional, but it is one more thing that makes the RM UI more complicated.
I have around 100 devices, use 5 modes, and have around 40 RM rules (not to mention all the simple automations and button controllers) and I don't think there is a single rule where I would use this feature.
Do you find yourself writing a lot of rules where they should not execute based on mode?
Also, I think it is important to note that "Mode Manager" does not come pre-installed on Hubitat. Nothing really does. I am sure many users don't use modes, therefore they don't install "Mode Manager". A dropdown box in the RM UI that doesn't list anything would be rather odd.
I just use a conditional at the start of relevant rules. It works fine. I believe now you can also stop a rule programmatically right, using RM? So you could have a rule that triggers on mode change and stops/restarts whatever rules you want (sorry away from home right now so can't check this).
To be honest I like the idea of having the equivalency of "pause" execution of a rule based on mode and I really would like that extended to all automations.
I think the benefit is significant.
In rm I could implement this by hand but I think this is powerful when uniform across all automations.
If the argument is that a dev should write this logic themselves then why have a pause automation switch at all then? The same logic dictates that this should be implemented by the dev themselves? Ie. You could just as easily argue that a developer could put that into their automation via a variable or a virtual switch. And if pause automation is a good thing then why is it not a good thing to let that be mode dependent?
As I thought more about this i'm basically recommending that extending the pause execution logic to be mode dependent is a good thing.
Don't entirely understand your post, but just to be clear, pausing rules is already built into RM, it is there for any user to use. If you want to base it on mode (or anything else) you are free to create such a rule.
I think what you are asking comes down to the User Interface. HE already allows you to do what you are asking of it. Whether that be a simple conditional to exit the rule, a condition specified in Simple Automations, or a separate rule rule that pauses/unpauses rules based on mode. The feature you are asking for exists and there is more than one way to implement it. From the sounds of it you would like a change to the manner you need to interact with the UI to implement the feature.
I had a look at all my automations, and for me it would be much more beneficial if there was a quick way to disable automations based on HSM state. The ability to disable automations based on HSM state is already built into HE, it just involves the methods outlined above. I don't think they should change any of the user interfaces to make this simpler and quicker, since not everyone uses HSM and although this feature would have saved me some time when creating my automations, why should the UI of HE be changed to suit my personal needs as opposed to being designed to serve the widest array of users and their preferences. I would make the same argument about changing the UI to better suit the needs of users who frequently disable/enable automations based on mode.
Rule Machine used to have Restrictions, including Restrictions for Mode. These were done away with some time ago. You can see what these looked like by checking out Simple Automation Rule.
Why were they done away with?
The way restrictions work is that when the rule is triggered, or an app runs, the restrictions are checked. If a restriction is in effect, the rule exits and nothing happens. The important thing to note about this is that every possible restriction has to be checked every time the rule runs. While this is not a huge amount of computing to do, it is not zero. What we became aware of was that most rules didn't have any restrictions. But every rule was paying the price for there being the possibility of the rule being restricted. Most rules that had a restriction only had a single restriction, most often time of day or mode, but also a disable switch was common.
There was also a lot of confusion about restrictions and how they might interact or not with the actions of a rule. There were constantly questions here about 'why didn't my rule run', when it was clearly because it was restricted, although determining that meant a lot of digging in logs and events to show the user what had happened to cause the rule to be restricted.
With Rule 4.0 it became possible to implement a restriction directly in the actions of the rule. As shown above, a Simple Conditional Action that tests the restriction followed by Exit Rule does it nicely. The computational cost of such a Simple Conditional Action is roughly equivalent to the computational cost of the same test as a restriction, in fact many of them would use the exact same code (e.g. time restrictions). So this is clearly a preferable method of implementing a restriction. It becomes explicit rather than implicit, and each rule only pays for testing those restrictions that are relevant for that rule.
I can say that for the most part there has been much less confusion since restrictions were retired. The remaining bit of confusion is like yours, not having enough information to know how to implement a restriction as a conditional action. The original post that announced the retirement of restrictions gave examples of how to do each one. Here:
