Automations multiply very quickly, and although it may seem obvious what you are trying to achieve while you’re writing one, three months later, when you come to make a change, it won’t be obvious at all. The sooner you adopt a systematic approach to organising them, the easier your life will be.
How you organise them is up to you - everyone has their own system - but consistency is important.
Categories and Labels
Release 2024.4 added several new tools for organising elements in HA.
Of these labels and categories can be used with automations.
In practical terms, the main difference between them is that an automation can have several labels, but only one category. If you like hierarchical structures, you might have a category Lighting containing automations labelled Motion sensor, Switch, Timer, etc. Some automations might involve motion sensors and switches, and would have both. When searching for them, you could then filter for automations in the category Lighting which had both Motion sensor and Switch labels.
An advantage of labels is that they can be used as targets of actions in automations - turn on and turn off, for example. Unlike groups they have no collective state - they are simply lists of entities. If your labels might include different types of entity - say switches and lights - make sure you use the generic homeassistant.turn_on and homeassistant.turn_off services rather than switch.turn_on or light.turn_off.
If you haven’t updated yet, here are a few other options. You can, of course, use them as well as labels and categories if you wish.
Naming
Give automations names that include a bit of context, and bear in mind that you may often use the UI search box to find them.
For example, a naming scheme based on Function - Location - Method would give you search results like…
Lights on - Bedroom - Motion sensor
Lights on - Bedroom - Switch
Lights on - Kitchen - Motion sensor
Lights on - Kitchen - Switch
Lights on - Living room - Motion sensor
Lights on - Living Room - Switch
…grouping automations with a similar function together and giving you a good idea of what they do.
An alternative approach is to devise a system of tags and include them in automation names. This works particularly well with the UI search - very few automations do only one thing:
Note: The entity ID of an automation will be based on the name it has when you first save it. It’s a good idea to save it initially with a simple title - Lights on BR, for example, which will resolve to automation.lights_on_br - and then rename it. If you don’t do this you will get some very long entity IDs.
The description field
It’s good practice always to add a description of what the automation is supposed to do. You have the option of filling in the description field when you save an automation for the first time:
After than you can edit it through the rename option.
Comments
You can’t add comments to automations if you edit them in the UI.
If you’re absolutely certain that you will only ever edit them in automations.yaml, then you can add comments preceded by a # character in the usual way:
- id: '1711923237878'
alias: Test
# This a test of a comment in an automation
description: ''
trigger:
- platform: state
entity_id:
- input_boolean.away_mode
to: 'on'
…but it’s risky. If you save the automation in the UI even once, they will be stripped away.
You can, however, rename individual automation blocks in the same way as you can the automation as a whole:
These “comments” will also appear in automations.yaml:
- id: '1711923237878'
alias: Test
description: ''
trigger:
- platform: state
entity_id:
- input_boolean.away_mode
to: 'on'
alias: Away Mode is turned on when Alarmo is armed. When this happens...
condition: []
action:
- service: light.turn_on
target:
entity_id:
- light.bedroom_lights
- light.cooker_lights
data: {}
alias: Turn on lights in the bedroom and in the kitchen
mode: single
Trigger_IDs
Trigger_IDs are a handy item when doing choose statements and other things, but they also provide a name for your trigger. A longer name can be crafted to provide details about the trigger. As a bonus the trigger_id is also visible in the automation trace so you can use the information there to clearly identify it. You don’t have to use them elsewhere in the yaml.
Trigger_ID is available for adding within the UI editor and is fully compatible with those tools.
Don’t forget the “Related” card
There’s a great deal of information about how your automation interacts with the rest of the system in the Related card.
It can be accessed through the ⓘ button which appears in many of the “three dot” menus in the UI.
