If I have several functionally different automations that need to be triggered by the same criteria, for example at the same time, are there any benefits/disadvantages in having them all in the same automation with a single trigger or multiple automations with the trigger duplicated in each one?
Thanks
Donât know of any âbest practiceâ, but I like to keep most of my automations separated between âtriggerâ-automations that only send one or more âeventsâ when something happens (like âmotion detectedâ or âsomeone came homeâ) , and âactionâ-automations that listens for different events and do pretty simple actions (âturn on light Xâ, âclose cover Yâ).
That again allows me to make simple âmetaâ-automations which can either enable or disable a trigger or an action.
For instance all my motion sensors have an automation that sends two events. On common âmotion detectedâ, and one specific âmotion detected by sensor Xâ
Then I have some automations that listens for âmotion detectedâ (like âsend alarmâ) , which will trigger no matter what motion sensor detects motion, and some automations that do actions based on specific motion detectors. Like âturn on lights in the bedroomâ.
And I then run the âmetaâ-automations to disable the âturn on lights in the bedroomâ at 22:00 and enable it again as soon as someone manually turns on the light switch after 05:00. And another to enable the âsend alarmâ when we want to activate the alarm.
This avoids overly complicated âconditionsâ and makes it fairly simple to add new sensors or actions into the mix without having to rewrite and rethink every complex automation already running.
If I want one more thing to happen when motion is detected in the kitchen, but only on certain times of the day, I simply make another âactionâ-automation that listens for the âmotion detected in the kitchenâ event (which is sent by two different motion sensors due to the shape of our kitchen), and I create a new âmetaâ-automation that enables and disables the new âactionâ-automation based on the time of day and day of the week. All without interfering with any other actions that might also be listening to the same event.
And if I need to replace or add another motion detector, I just ensure that the new one sends the same events, and all my âactionâ-automations will keep on working as expected.
Each trigger you define will create a listener for that event/state that increases the CPU use. However, unless you have thousands of automations on really crappy hardware it will be unlikely to be an issue. So do what suits your way of thinking.
The methodology that you described Olen is very interesting, I think I may have to look into that.
Tom_I, that is what I was wondering, if there was any overhead having multiple automations triggered by the same criteria. As you have explained it is likely to be negligible, so I will just go with whatever will require the least maintenance.
Even less overhead with 0.113 apparently. Before you update have a look at your available events (and number of listeners for each event) on the developer tools events page. Compare and contrast after updating.
@Olen
Yea, your thinking looks interesting. Can you sure your codes with motion sensors regarding the bedroom?
Just started tidying up my Hue Dimmer automations. Used to have 1 automation for each button and for click/hold. Now with 0.113 and the new âchooseâ functionality I can merge into a single automation and can also see the number of listeners for âdeconz_eventâ going down. 
Iâm on vacation right now, so I donât have easy access to the config (I only use yaml, and even though ssh is possible from the phone, it is a hassle to copy and paste the config etc.
But I can give you a bit more details, and you should be able to interpret and adapt the exact config suitable for your use I hope.
So letâs use the living room as an example, just because it has a few more interesting bits than the bedroom.
The living room has two motion sensors (fibaro zwave, but that is not important), a couple of lights and a TV (and other stuff of course, but again out of the scope right now).
I want everything to be as automated as possible, no apps, no messing around with the phone or a tablet to turn on lights or other basic stuff.
So I have two âtriggerâ-automations. One for each motion sensor.
#1
Trigger:
#2
Trigger:
No conditions, no complexity. These events are always sent, no matter what (as long as the automations are enabled).
Then I have a few âactionâ-automations:
#livingroom_lights_auto_on
Trigger:
#tv_auto_on
Trigger:
But I obviously donât want both the lights and TV to always turn on, every time motion is detected.
So I add all my âconditionsâ as separate automations that turn those two automations on and off.
#1 - If the TV was just turned off, donât turn it back on immediately
Trigger:
#2 - Same for the lights if someone turns them off using the wall switch.
Trigger:
On the other hand. If someone turns the lights on manually, we can safely re-enable the automation
#3
Trigger:
This gives the least amount of surprise to anyone using the switches, while still keeping stuff as automatic as possible.
And we can disable and re-enable the TV auto on at reasonable times:
#4
Trigger:
#5
Trigger:
There are plenty more, also for turning the lights off etc.
So one of the important ones is that it should not turn off the lights automatically as long as the TV is on (while watching a movie, we frequently do not trigger the motion sensors for a long time).
Trigger:
Trigger:
Of course this gives me a_lot of automations, but as they are all extremely simple, it is very easy to understand exactly why something happened. And it is very easy to see whether lights should be turned on or off at any point in time, and it is easy to add debug messages or notifications as the action-automations are enabled or disabled.
And I can enable and disable them based on all kinds of conditions, like the weather outside or who is home.
To top it off, I also use "input_number"s for stuff like dimmer levels, timeouts before lights are turned off again etc. And these inputs are also controlled by automations, so I have a shorter timeout and lower dimmer levels at night than in the morning of workdays etc.
Trigger:
Trigger:
Trigger:
Trigger:
Etc. You get the ideaâŠ
I donât say that this is the way to do it, but to me, the simplicity of each automation and how easy it is to monitor and mange exactly why something happened, outweights the issue with the number of automations.
@Olen
Thank you for very much for the write-up and having to do that all by memory. I will need to reread this in my quiet time. Loads to digest. 
It become pretty logical once you âreverseâ your logic. Instead of creating a complex condition to decide when an automation should run based on a lot of external factors, I simply say that âif this condition is true, the automation should not runâ, and the easiest way to achieve that, and to ensure that it does not run even if some other trigger would want to run it is simply to disable the automation.
Now, I have not studied the new features for scripts and automations in 0.113, so there might be some useful stuff there as well. But I have done quite a few rewrites and iterations of all my automations, and this is what I currently like best.
@Olen
This makes so much sense to me as I try to figure out how I want stuff to work and be able to scale it in the future.
Read your blog post and wondering how you organise everything in the yaml, maybe obvious, but Iâm a beginner:)
PÄ forhÄnd takk:)
#1
Trigger:
binary_sensor.living_room_motion_1 to âonâ
Actions:
Send event âmotion-sensor-livingroom-1â
Send event âmotion-detected-livingroomâ
Send event âmotion-detectedâ
#2
Trigger:
binary_sensor.living_room_motion_2 to âonâ
Actions:
Send event âmotion-sensor-livingroom-2â
Send event âmotion-detected-livingroomâ
Send event 'motion-detected
Can you provide the yaml code for this? I am unable to find examples.
Example Triggers.
Triggered by a sensor, and sends multiple events.
- id: motion_on_livingroom_1
alias: Motion on - livingroom sensor 1
trigger:
- entity_id: binary_sensor.fibaro_livingroom_motion_1
platform: state
from: 'off'
to: 'on'
action:
- event: motion_on_home
- event: motion_on_livingroom
- event: motion_on_livingroom_1
- id: motion_on_livingroom_2
alias: Motion on - livingroom sensor 2
trigger:
- entity_id: binary_sensor.fibaro_livingroom_motion_2
platform: state
from: 'off'
to: 'on'
action:
- event: motion_on_home
- event: motion_on_livingroom
- event: motion_on_livingroom_2
Example Action
Listens for a bunch of events that should all cause the same ultimate action.
- id: lights_on_livingroom_sofa
alias: Lights On - Livingroom sofa
mode: single
trigger:
- platform: event
event_type: motion_on_livingroom
- platform: event
event_type: lights_on_livingroom
- platform: event
event_type: lights_on_livingroom_sofa
action:
- service: switch.turn_on
data_template:
entity_id: light.fibaro_dimmer_livingroom_sofa
And then I have âMetaâ-automations, that will enable or disable the âActionâ-automations (but never the âTriggerâ-automations.
For instance, disable all the âLights On Livingroom *â-automations when we turn on the TV:
- id: livingroom_tv_on
alias: TV on - disable auto lights
trigger:
- entity_id: binary_sensor.stue_tv
platform: state
from: 'off'
to: 'on'
action:
- service: homeassistant.turn_off
data_template:
entity_id: automation.lights_on_livingroom_sofa
- service: homeassistant.turn_off
data_template:
entity_id: automation.lights_on_livingroom_dining_table
And also disable them if there is enough ambient light:
- id: stue_brightness_adjust_high
alias: Justere brightness pÄ stua high
trigger:
- platform: template
value_template: "{{ states('sensor.fibaro_livingroom_luminance') | int > states('input_number.lux_daylight') | int }}"
action:
- service: homeassistant.turn_off
data_template:
entity_id: automation.lights_on_livingroom_sofa
- service: homeassistant.turn_off
data_template:
entity_id: automation.lights_on_livingroom_dining_table
Etc. etc.
And similar âMetaâ-automations to reenable them based on other inputs.
So this way I can avoid most of the conditions and choosers that makes the automations hard to debug. A trigger is always triggering (no conditions). An action is always acting (no conditions). And if I donât want the action to happen, I simply disable the action-automation.