I had an idea to use the Labels feature to manage when automations are enabled/disabled, such as turning on seasonal automations, disabling automations while we’re sleeping (like motion sensors), or changing behaviour when we’re on holidays.
Here’s a write-up on the approach, which uses automation.turn_on/automation.turn_off action against labels.
Programmatically turning automations on/off as a means of controlling when they should/shouldn’t operate is considered an anti-pattern. The automation ought to be self-contained and determine when it should/shouldn’t execute its actions.
The main reason it’s an anti-pattern is because it effectively makes the disabled state a part of its normal condition (temporarily suspended but will be automatically revived later) as opposed to an abnormal state (deliberately turned off for maintenance purposes). One loses the ability to take an automation ‘offline’ because ‘offline’ is now a normal part of its operation.
The act of manually turning off an automation is reserved for maintenance purposes such as when an automation is misbehaving (and you’ll fix it later) or when testing a new version of the automation (but need the old one available as a fallback). When viewing the list of automations, disabled ones are recognized as undergoing maintenance as opposed to possibly just being in ‘suspended animation’.
With an appropriate condition (by time or the state of other entities, etc), an automation can determine, all by itself, if it should execute its actions or not.
I disagree, as your point is about how you observe information presented and what disabled means in your case.
If I have an automation that’s only valid for 1/4 of the year, why have it always on and then put in a condition like if season == summer? Then you have to repeat that pattern every time you want to add a new seasonal automation. Compound this problem if you decide you want to expand the seasons to be summer and spring, now you have an or nesting in your condition.
I use this same pattern with our house sitter automations. Originally, I had dozens of automations which I then had to copy the same set of conditional checks into to ensure they ran or didn’t run, depending on whether we had a house sitter or not. Then invariably one would not be configured correctly because I missed a condition and the person would get annoyed.
An automation’s condition is a useful and powerful feature. Your post makes it sound like you have difficulties using it.
I have plenty of automations with conditions, I have no problem using them.
I don’t find that embedding continually repeated logic in multiple automations to be an efficient approach. What if I decide the conditions need to change due to some external factor. Here’s a different example, I disable motion-sensor automations at night, either when we hit a certain time of day or when the end of day routine is triggered. I have an automation that runs and disables all those other automations based on their label.
Say that I decide that I want the time part of the trigger to be an hour later. Well, now I have to go and edit n number of automations conditions to respect the new “if before time” condition. Or, you build a helper and do a templated condition. Or you build a helper that sets the “end of day” flag and you condition on that. Or you have a schedule helper that is the schedule for when motion sensors are activated. Or, or, or…
Home Assistant is a highly flexible piece of software and you can tweak it to suite your needs and mental model. For some (like me) having automations disabled when they aren’t applicable makes sense. For others, having conditional decision trees makes sense, and others will have everything in helpers/template entities to represent any possible state as simple on/off flags.
The problem with your idea is what happens when you have conflicts, like an automation that has label “no-sleep” and label “autumn”.
There needs to be some logic that decides whether such automation should be on or off. But there is no good support for that that I can see.
Taras is right, it’s better to use standard HA techniques.
If you want code reuse/abstraction, then helpers are the right way to go.
True but, as you later pointed out, common conditions can be centralized in a Template Binary Sensor. Then there’s just one place to edit in order to influence the behavior of multiple automations. Easy peasy.
On a separate but related note, your technique employs labels to identify multiple automations slated for suspension. Currently there are no actions available to programmatically add/remove labels. Therefore adjustments to membership require manually editing each automation’s labels. That’s manually labeling “n number of automations”.
Lastly, one important point is the ability to disable an automation for maintenance purposes. That’s effectively lost because “disabled” is now a normal state of the automation’s operation; it’s automatically re-enabled at some point in the future (when exactly isn’t self-evident unless the label is suitably descriptive).
I suppose one way to mitigate that would be to use a label named “offline” (or similar) to indicate, despite whatever other labels it has, exclude this automation from being programmatically enabled.