Can I keep automations separate?

Configuration
1

Hi All,
I find the automations.yaml file a bit hard to read and to navigate through.
I have created the directory for automations and moved the automations.yaml in there but also extracted some of the more problematic automations to separate yaml files.
I changed the config so HA is looking for automations in there however now I cannot edit them using the UI.
Moreover the automations seem to be working intermittently and it feels the whole system is in degraded state which upsets me.
Is this way of doing things supported or is it not and should be avoided?

I admit I used AI to help me with the automations but now not sure if the automations are buggy or the system is not happy reading these individual yaml files.
Please advise

2

Yes, you can keep automations separate.

3

Do the automations run reliably after you put the configuration back to the way it was?

In other words, you have the following line in configuration.yaml and the automations.yaml file is located in the same config folder as configuration.yaml.

automation: !include automations.yaml

By default, automations created using the Automation Editor are automatically stored in automations.yaml and nowhere else.

Automations created using a text editor (like VS Code) can be stored elsewhere in a separate file, or in multiple files within a sub-folder. However, an additional configuration entry is need in configuration.yaml in order to instruct Home Assistant where to find these additional automation files (see documentation for details). Be advised that these automations, created using a text editor and stored outside of automations.yaml, can be viewed but not edited with the Automation Editor.

1 Like
4

If yaml for an automation isn’t read then that automation isn’t there at all. If AI made it then it is buggy. If it is made by AI and its yaml is not read, then it is less buggy :wink:

But on a more serious note, you can only edit automations in automtions.yaml. Organising those is done in the GUI.

2 Likes
5

Why would you read/edit the automation.yaml directly ?
Most things you can do from the gui, but if needed, you can just open any automation from the gui, and then use the 3 and hit ‘edit in yaml’

By doing so, you will only see/edit the yaml for that specific automation (and reduce the change yoy corrupt the whole automation.yaml file :wink:

2 Likes
6

Thank you for coming back to me

I have this in my configuration.yaml

#automation: !include automations.yaml
automation: !include_dir_merge_list automations/

I moved the automations.yaml into automations dir.

FYI, there were some syntax issues along the way but the custom yamls all pass the checks.
I reload them and restart the HA without issues.
The automations that

It could be I am dealing with a different issue.
I have replaced some of the batteries in the sensors and some of them e.g. a PIR sensor flashes red light on movement but another time looks completely dead same with one of the Sonoff buttons I have. It feels like they developed some fault or the new batteries I have put in were expired or something.
I installed this extension for low battery notifications but this does not work, notification automations are enabled but no notifications nor items on the to-do list.

As an infrequent HA operator I don’t know where to check if a device is faulty, powered or not.

7

In your first post, you wrote this:

In your second post, you wrote this:

So what you originally reported, 2 hours ago (“cannot edit them using the UI”), is no longer a problem?

8

no, since I used AI to help with these automations I didn’t reimport them back to automations.yaml for editing in UI.
Once I save them I reload them in Developer Tools and they pass the checks.
The problem I am facing is these automations not executing properly or at all and not sure if this is to do with these automations or problems with the devices themselves.
As you can imagine if two issues are going on at the same time it is easy to go in circles when troubleshooting.

9

Then I suggest you do what I had suggested in my first post. Put everything back the way it was and see if the problems disappear.

  • If they do then it means they were caused by the configuration change you made.
  • If they don’t then it means they are caused by something else, possibly the devices themselves.
1 Like
10

Tried to restore from a backup but the task fails with

‘BackupManager.do_restore_partial’ blocked from execution, no supervisor internet connection

I can see that HA for quite some time has not been updated.
Some 3rd party updates have popped up but no more updates for the Core etc.
The updates list is empty.

* Core 2025.6.3
* Supervisor 2025.06.2
* Operating System 15.2
* Frontend 20250531.4

Logged in to the OS and I can ping Google and Github so not sure why it stopped getting updates.

11

There’s your problem. I am old school- YAML makes more sense to me than the UI, but do not mix your YAML automations with the automations from the UI in automations.yaml - you will have issues.

Keep them separate.

In my configuration.yaml:

automation ui: !include automations.yaml
automation manual: !include_dir_merge_list automations/

The first is where the UI places the automations it generates. Don’t touch these. The second is a directory where my various (manually edited) automations files are stored.

If you make automations using AI, just put the new automation into a new .yaml file in your automations directory. If it doesn’t work, simply delete the file and start over.

1 Like
12

In the same way like you split up your automations into UI and manual, you have to do the same with scene (also merge_list) and script (here you need merge named).

This is how I am splitting it up, but there are many different ways.

automation: !include gui/automations.yaml # this is only for GUI-Automations, do not touch this file!
automation manual: !include_dir_merge_list manual_automations/

scene: !include gui/scenes.yaml # this is only for GUI-Scenes, do not touch this file!
scene manual: !include_dir_merge_list manual_scenes/

script: !include gui/scripts.yaml # this is only for GUI-Scripts, do not touch this file!
script manual: !include_dir_merge_named manual_scripts/

Unfortunately this is not part of the Onboarding Guide, so many users are doing it wrong.

1 Like
13

It’s an Advanced concept, but it’s still linked in the Onboarding Guide if you follow the breadcrumbs:

Onboarding > Next Steps > Configuration.yaml file > Splitting up the Configuration

You’ll find a reference to your specific example above right there on that page.

1 Like
14

I know that it’s there and I could find it, but I also know that many users do not find it and will make it wrong. So it would be a good idea to make this a little bit more prominent.

15

Where are the backup files stored?

16

For some reason the HA was not able to detect new updates. I restarted the whole thing then the update has popped up. I was able to update the Core and OS. In the end I did not restore from a backup just replaced some of the automations with the ones I had in the old backup files.

17

So after doing all of that, are the automations working properly now?

18

I’ve never used the UI to make a script, but I will need to move all 150 of my scripts to

script manual:

I don’t use scenes (yet), but from your tip I will go ahead and make a blank manual_scenes folder.

19

I agree. It’s better to have empty files and/or folders from the beginning, than to start with a “wrong” structure and having problems later.

For me it’s not an advanced concept to have a future prove file structure from the beginning, even if some of the files will never be touched.

I do not understand why there are so many best practice examples available in docu and forum, but default installation is not following any one of them.

1 Like