Being able to Categorize automations is nice for visuals but not helpful with actual automating.
If we could enable / disable entire Categories (manually, in scripts, in automations) we could use categorization for much more.
One example is House Modes when in one mode we may need a set of automations enabled, but in a few other modes those same automations should be disabled.
… The automation action tells HA to disable the entire category. So only 1 action, vs 10 or 20 actions, per house mode automation.
I swear someone has already asked for this capability and the short answer is you shouldn’t design your automations to work like that.
Use conditions to control when the automation should/shouldn’t execute its action. This is a best practice that’s been recommended for longer than I have been a member of this community (> 6 years).
Its all personal preference. There is no downside (technical or performance) reason not to disable them… but there are several of those benefits to disabling them.
An automation that becomes part of an automatic enabling/disabling scheme effectively loses the ability to be manually disabled for other purposes such as for maintenance (disabled for debugging at a later date) or testing (disable older version while newer version is tested). Manually disabling it may interfere with the automatic system’s logic and/or be re-enabled automatically (and possibly unexpectedly) thereby countermanding the manual command.
FWIW, this subject has come up now and then for many years and the pros and cons haven’t changed; you stand to lose functionality by programatically enabling/disabling automations. FRs that ask to make the practice even easier are effectively promoting a flawed design pattern; volunteer and staff developers are aware of it.
Taras, I understand what you are saying. Things you are referring to are purely cosmetic. HA has multiple ways to do cosmetic identification (name, label, category, icon, etc). Thus, identifying something under maintenance or testing, is literally the least important and least effort thing to do in HA.
Without an exact example, I don’t know of any ‘automatic system logic’ that would interfere with disabling a user created Automations? We are talking about automations, not add-ons or integrations.
I really appreciate your input but baffled why you are so adamant on this point, in multiple threads – which in reality, makes zero difference either way if you or I disagree on the use case and value.
There are no technical problems created by disabling Automations; but there are performance benefits. The HA system is checking fewer triggers in the same amount if time. Unless it is checking them anyway, which is kinda dumb to spend cycles on to check something that is disabled.
If you have info or evidence showing or explaining how it is technically detrimental to disable Automations, please present that.
Cosmetic or not is not opinion… if there its not required for technical reasons, its cosmetic. If a feature causes a technical problem/issue, that is really not good since then the devs did something without proper implementation or user facing warning like… “You can do this but know it may cause XYZ issues”
That’s true. The core dev team are the final arbiters of what does/doesn’t get into the product.
My only aim was to report why some features are never implemented (example: avoid promoting non-optimal design patterns). If you didn’t find them to be sufficiently “technical”, be advised that not all PR rejections are based exclusively on technical objectivity .
