Do you define that? Your fact?
Start by searching the forum for examples of a Regular (an experienced user who regularly assists others) who recommends, as a solution to others, to use your favorite (anti)pattern.
Since 2018, I have never recommended it to the thousands of users I have helped. I don’t recall any other experienced user recommend it either. The advice has been the exact opposite, to avoid it.
However, seeing that you disagree it’s an anti-pattern, I suggest you volunteer your time to help others implement it as the preferred solution whenever the opportunity arises.
Use actual conditions to control whether actions are executed. For your lights example, in automation #2, you could add a Numeric State condition to check that the state of zone.home is above 0, meaning there is at least 1 person entity in the home zone.
In my opinion disabling an automation should be reserved for when there is a serious issue with the automation or one of it’s related devices. If you have automations enabling and disabling other automations what do you do when you really, absolutely need to disable one of them?
House modes and presets.
House Modes
I have an input select (drop down list), with four values:
Day- Normal daytime operation.Sleep- Nighttime / actually asleep not just in the bedroom.Away- No one is home.Off- Turn off most of automations.
Most automations either always run or only need to run in one of the house modes, for example:
- If away and the front door is opened turn on the hallway light - I actually group the door and a motion sensor, so the light initially comes on when the door is opened but then stays on because of the motion sensor - hence when I leave the light is on until the door is closed and the sensor is no longer detecting presense.
- If Day activate the bathroom light (on presence) at full brightness.
- If Sleep activate the bathroom light (on presence) very dim.
Initially I defined a bunch (around 8) different modes - but I discovered it was not worth it, I kept thinking automations weren’t working when the problem was the house was in the wrong mode.
The Off setting is a catchall for rare situations - it turns off most of the motion activated lights, hence you can still use the switches in the rooms to set the lights how you want them and the automation won’t mess with them - I don’t need this much, but is useful to have once in a while.
Presets
TL;DR - Is where all the additional house modes ended up.
Its just a script with a big chose statement.
- The Sleep case turns off most of the lights and switches to
Sleephouse mode. - The Away case turns off all lights and heating and switches to
Awayhouse mode. - Most of the other modes are for
Dayhouse mode and just activate lights and other automations for that particular preset.
Summary: Some people tie an automation to (a change in) the house mode itself, I don’t instead I do the prep in the preset and activate the mode, that way I can flip presets without any side effects occurring.
The other thing to note is that presets have no state - it doesn’t matter what preset was activated you can make it the same as a different one simply by turning things on and off (only house mode has state).
Some presets I activate manually - I have a button next to the bed to tell HA I am ready to sleep.
Some presets are activated automatically - if house mode is Sleep and there is movement in the kitchen/living room between dawn and noon activate the Day preset.
Hmmm… thank you guys. So both of the recommendations are indeed (& in short) merging automations into one. Think I will devise a plan to implement.
I would say it differently, specifically there are two things I would avoid doing:
- Don’t have automations enable and disable other automations.
- Don’t have automations try to interrupt other automations.
How you split up your automations is a matter of preference, I would recommend focusing on clarity/readability.
I also avoid:
- Usage of timers.
- Delays in automations longer than 1 second (I do have a few very specific use cases such as gaps in sequences of IR commands - but they are all in milliseconds).
The reason for this is it means that every automation “comes in cold” there will typically never be something else running.
I do have longer delays (in minutes - to hold lights on) however those are implemented as delay_on/off on template binary sensors, so every change of state on those is the start of a new automation run.