I am using Home Assistant with YAML-based configuration and would like to combine the UI automation editor with a structured file layout.
My goal is to use the Home Assistant UI to create and edit automations, have them initially stored in automations.yaml, and once they are tested and stable, move them into a subdirectory (for example automations/) with room-based files such as kitchen.yaml, living_room.yaml, etc. Each file would contain only the automations relevant to that room.
When I configure Home Assistant to load automations from a directory (e.g. using !include_dir_merge_list automations/), the automations are loaded correctly, but the UI automation editor no longer allows me to create or edit automations. At that point, the UI editor becomes read-only or unavailable.
Is this a limitation of Home Assistant’s automation UI, or is there a supported way to combine:
UI-based creation/editing of automations, and
a modular, directory-based YAML structure for long-term maintenance?
A single automations.yaml file with 100+ automations quickly becomes difficult to manage.
How should configuration.yaml be structured to support this workflow, if it is possible at all?
I learned somewhat recently that mixing UI-generated automations with YAML-edited automations leads to character building.
Here is what I have in my configuration.yaml
automation: !include gui/automations.yaml # this is only for GUI-Automations, do not touch this file!
automation manual: !include_dir_merge_list manual_automations/
This is by design. HA owns automation.yaml in the config folder, you own the rest. HA will not touch those files, and the people using comments and special formtting in those files would not want it any other way.
You can categorize, label, filter etc. in the list in HA to organize the automations. Personally I don’t think it is much of a problem. I have 444 automations all in automtions.yaml. But you may of course feel different about that.
They are all in automations.yaml. I use a mix of editing types. GUI, yaml in the automation editor, yaml using Visual Studio Code. But keep in mind that in automation.yaml, HA reformats all yaml and removes comments. It simply writes the data it read back to the file.
That’s the problem, you use your own ways of handling this because that’s how it is.
For me, it’s the same if HA had decided that everything should be in a single file and then it was read in when the program started, and if errors occur where to start and where to end.
It may well be that historically HA is made for the average person and he should be able to figure it out without being a programmer, but when you start messing with yaml files you start playing professional and things should be in order from the start, I can only dream that it will be so that it can be done without problems.
It is more the opposite. At the start HA was designed for yaml. Then GUI editing became the goal to be more friendly towards non technical people.
For automations, scrips and scenes they opted to write GUI input data to yaml. It ishard to impossible to edit hand written files without destroying formatting. Yaml is a data representation language, not a programming language.
For other things you no longer get to see any yaml, e.g. integrations, helpers, etc. There it is either full hand written yaml (if you even can) or GUI ending up in storage.
For automations, scenes and scrips you can have a mix of full h d written and gui built automatically formatted yaml. Stevemann posted how a few posts earlier. But if they would allow GUI to edit hand written files, all contents would need to be overwritten, losing the original formatting. It is just dumping the data to a file automatically.
We are not talking about the GUI as such, but about how it stores the YAML files. It does this very conservatively by removing everything superfluous, such as comments, when the file is checked for errors. It is completely understandable if you choose the single-file solution; otherwise the file would become very long, but you do sacrifice the overview.
I only use the GUI to create automations so I can immediately test in Home Assistant whether they work. Then I use VS Code Server to edit the automation afterwards and add my comments and changes there.
If the automation works, it is moved to a subdirectory called config/automations and, for example, saved in a file called kitchen.yaml, which only contains automations for my kitchen. When Home Assistant starts, all automations are loaded from this subdirectory, but that is a matter of taste.
What I explained is: HA is not ‘conservative’. It uses a library to read data in the yaml. By doing so only the data itself ends up in HA and nothing about formatting, comments etc. So the only thing it can do is write the data in a generic format, without structure.
That is why the solution mentioned splits it in two: automations.yaml, maintaned by GUI, and a folder using user maintained files that cannot be edited by the GUI, because that operates on pure data, not files with comments and formatting. This is why it is a hard limitation that you cannot edit manual yaml in the gui, part two of your question.