Automation Trigger - Best Practice

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. :grinning:

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:

  • 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

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:

  • Event ‘motion-detected-livingroom’
    Action
  • Lights turn-on livingroom

#tv_auto_on
Trigger:

  • Event ‘motion-detected-livingroom’
    Action
  • TV on

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:

  • TV to state off
    Action:
  • disable automation tv_auto_on

#2 - Same for the lights if someone turns them off using the wall switch.
Trigger:

  • Living room light switch to off
    Action:
  • disable automation living_room_lights_auto_on

On the other hand. If someone turns the lights on manually, we can safely re-enable the automation
#3
Trigger:

  • Living room light switch to on
    Action:
  • enable automation living_room_lights_auto_on

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:

  • time is 23:00
    Action:
  • disable automation tv_auto_on

#5
Trigger:

  • time is 18:00
    Action:
  • enable automation tv_auto_on

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:

  • TV to state ‘on’
    Action:
  • Disable automation livingroom_lights_auto_off

Trigger:

  • TV to state ‘off’
    Action:
  • Enable automation livingroom_lights_auto_off

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:

  • workday at 05:00
    Action:
  • set input_number.livingroom_dimmer_level to 100%
  • set input_number.livingroom_lights_off_timer to 10 minutes

Trigger:

  • workday at 09:00
    Action:
  • set input_number.livingroom_lights_off_timer to 2 minutes

Trigger:

  • workday at 17:00
    Action:
  • set input_number.livingroom_dimmer_level to 75%
  • set input_number.livingroom_lights_off_timer to 10 minutes

Trigger:

  • time 23:00
    Action:
  • set input_number.livingroom_dimmer_level to 10%
  • set input_number.livingroom_lights_off_timer to 2 minutes

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. :slight_smile:

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.