Could someone kindly explain the difference between the two following examples when referenced to a split config? I have my automation files saved in a folder named ‘auto’ and the configuration file has automation: !include_dir_merge_list auto.
Both examples below pass all three online YAML testers I’m using, but the top entry does not work, obviously because of the way I’ve defined my inclusion of the automation files (copied from ‘devdelay’).
alias: 'Update Available Notifications'
trigger:
platform: state
entity_id: updater.updater
action:
service: notify.pushetta
data:
message: 'There is a new Home Assistant release available.'
- alias: 'Update Available Notifications'
trigger:
- platform: state
entity_id: updater.updater
action:
- service: notify.pushetta
data:
message: 'There is a new Home Assistant release available.'
I’m trying hard to learn YAML and making progress albeit very slowly but these formatting anomalies are testing me.
Have a look at the Advanced Usage section here: https://home-assistant.io/topics/splitting_configuration/
Especially try to understand the difference between include_dir_list and include_dir_merge_list - the examples and annotations are quite helpful.
It took me a while too…
Thank you Sebastian. I suppose what I’m looking for is some ‘best practices’ guidance. Unfortunately, all of the GitHub example files differ in the way they are formatted from user to user. This makes learning YAML really difficult. If you copy an example from one user, it may not work depending on what method of inclusion you’ve chosen. It also seems that the configuration examples given on the HA website only reference formatting pertaining to inclusion in the configuration file which is not practical. Can the online examples be copied and pasted in a split config if the !include_dir_list method is used?
That’s the reason why it is best to understand the different inclusion methods, so you can adapt the examples you find on the net.
I’m using:
automation: !include_dir_list automation
In my automation/ directory, I have one file per automation (each file can only have one automation).
Your first update check example should work that way without any needed changes.
To be a little more specific: include_dir_list will basically take every file in the specified directory, add a single “-” at the beginning and indent everything by 2 spaces. Every file’s contents become one entry in a list:
That is super helpful Sebastian, thank you. One last question.
devdelay is using: automation: !include_dir_merge_list auto script: !include_dir_merge_named script
Teagan42 is using: automation: !include_dir_list automation script: !include_dir_named scripts
Their methods are both different. Are scripts handled differently than automation and is it best to standardise on the same method for both? e.g. Is one of the above methods the preferred one?
The difference is how automations/scripts are “named”.
For automations you provide an alias: xyz and then you can refer to it as automation.xyz from other automations/scripts/whatever inside HA.
The name for scripts is specified explicitely:
scriptname:
sequence:
- service: a
- service: b
by using include_…_named the file name is used at the top level, i.e.:
filename:
file content line 1
file content line 2
...
It’s the same as with the include_…_list methods, if you replace “-” with “filename” (or “list” with “dictionary”).
Thx for the helping hand! In the same spirit that down the rabbit hole it really helps understanding the syntax, I shared a ready-to-use sample text for the templating module, a way for me to understand macros, loops and splitting values.
I also wonder what made you choose this path of including files? Especially you mentioned the key point for me, having different scripts in the same file…
I wonder because, last I tried, your way will also include subdirectories and files without extensions (which I use as a disabling feature, the only way for me to find which automation is messing up).
At least with the current release, only *.yaml files are included and I think hidden directories (i.e. names starting with a dot) are not included either.
So that helps quickly enabling/disabling automations (personally, I rename a file from *.yaml to *.yaml_ to exclude it from being parsed).
To locate which file/automation causes an error, I usually use hass --script check_config.
That check has improved a lot over the last few releases.
I really stick to the “one file, one task” approach, so I don’t have multiple scripts or automations in one file.
If you want multiple scripts/automations in one file, you’d need to use the include_*_merge_* directives and take care of the correct formatting inside the file by keeping in mind how it would be parsed in conjunction with the rest of the directory’s contents.
Both are correct in this regards. In normal yaml, you’d always use a dash on a item in a collection. Home assistant has a modification to yaml in 3 places that allows you to not use the dash if you only have 1 item in the collection. Thats trigger, condition, and action. All others require a dash for any number of items in a collection. So both of these are correct:
action:
- service: notify.pushetta
data:
message: 'There is a new Home Assistant release available.'
action:
service: notify.pushetta
data:
message: 'There is a new Home Assistant release available.'