I’m finding the current choices for managing automations a little frustrating.
With a single automations.yaml file, I can edit automations directly in the Home Assistant UI. However, once you have 100–150 automations, the file becomes quite large and saving changes in the UI starts to feel noticeably slow.
On the other hand, splitting automations into multiple YAML files works much better for maintenance. I can organize them by function, use VS Code, search across files easily, and keep the configuration much more manageable.
The downside is that automations stored in separate YAML files cannot be edited directly in the Home Assistant UI. Even for a small change, I have to go back to the YAML files.
What I would really like is a combination of the two approaches:
Keep automations in separate YAML files.
Continue using VS Code to maintain them.
Still allow the Home Assistant UI automation editor to edit an individual automation.
Ideally, the UI would only load/save the relevant automation rather than processing one huge automations.yaml file.
Is something like this already possible with the current automation/YAML configuration, perhaps through includes or another configuration option?
If not, would this be a reasonable feature request for Home Assistant? It seems like it could provide the benefits of both approaches without requiring users to choose between UI editing and a maintainable YAML structure.
This is not possible. Only the single file is supported when editing via the UI.
I cannot say. The dev team will have their reasons for or against. My guess is that someone inclined to use the UI isn’t typically inclined to use the files directly, and there are other ways to organise automations in the UI (e.g. using labels).
Some people run “Dev” and “Production” instances of HA, hence you could strip down your dev instance to just the automations you are working on.
Multiple HA Instances
Depending upon what devices/automations you have, splitting up the house into separate areas and using multiple HA’s to control different areas might be an option.
In Dev mode I have connected two instances of HA to the same MQTT broker - I am not sure what issues that might cause long term - for my short term development, it didn’t seem to have any side effects - so that might be an option if you don’t want to divide your Zigbee network.
Build Process
Not sure if this one is practical, since automations.yaml is YAML
You could probably create some scripts that break it up for editing purposes.
Simply concatenating the parts back together should be enough when deploying the new version.
Consider an external workflow
Some people use Node Red, there are probably other products that would replace the need to create automations in HA.
Refactor Automations
You may be able to refactor your automations:
You can offload some of the work from automations into scripts or trigger based templates.
Scripts are still editable from the UI, TBTs are not.
Similarly other UI elements such as groups can reduce the overall complexity of automations.
Merging of automations can help with overall maintenance burden.
I particularly like using variable declarations as “Lookup tables” so that I can have similar functionality for many rooms handled by the same automation.
I make heavy use of automation refactoring (per my suggestions above) that keeps my actual automations to between 15-20 total - if I wasn’t doing that refactoring my total number of automations would probably ballon to 2 or 3 times that - I know thats still smaller than your current installation, but you might be able to reduce your total significantly.