Multiple script file includes?

Is it possible to use multiple script files in HA? By default, the configuration.yaml file has a single script include:

script: !include scripts.yaml

But I’d like to create a few different script files. I tried something like this, but only the last script include seems to be recognized to HA:

script: !include scripts.yaml
script: !include more_scripts.yaml

Is this possible? And if so, how would I format the !include lines? Thanks!

3 Likes

See here. The Advanced Usage section in particular (but the entire doc is helpful).

2 Likes

Thanks for the link! I think I get it, but I just want to make sure. Rather than using multiple !include lines, I would put all of my scripts into one directory and then use the example in your link to include the entire directory?

1 Like

Yes. You can either have one script per YAML file or multiple scripts in each file, but be sure to use the right !include option depending on what you do.

Awesome. I’ll give that a try. Thanks!

@_Mike

to give you another hint on that you need to realize that automations are entered as “lists” (using a “-” before each automation). Scripts are entered as “names” (no “-” in front of each one).

So for scripts you will use the “script: !include_dir_merge_named…” option.

1 Like

Or… You could use packages

1 Like

Thanks. I think I’m going to have to read up on packages.

:roll_eyes:

So…

what’s the advantage to using packages that requires you to have a separate “packages” directory that will get filled up with yaml files that contain scripts (and not only scripts but every other type of yaml configured domain) that you still need to reference with an “!include…” statement…

vs.

using the method discussed above in which you reference a directory with a “script: !include_dir_merge_named…” statement that will contain a bunch of yaml files containing just scripts and nothing else?

Just from an organizational standpoint a single “packages” directory will start getting pretty large and harder to find things once you start adding literally everything into that directory.

2 Likes

Don’t get me wrong. Packages do have their uses but for this kind of thing just use the method we have recommended above.

Packages work well for things that have many different domains that need to be used together and that logically forms a “system”.

If you just have a bunch of one-off scripts that don’t depend or rely on other entities from other domains that are only exclusively (or mostly exclusively) used in those scripts then use the scripts directory method.

I use both in my config and it works fairly well to organize things logically.

script: !include scripts.yaml
script more: !include more_scripts.yaml
2 Likes

you can do that?

where is that documented?

:slight_smile:

Many people do this for automations so they can have one lot for the automation editor and one for the manual ones, something like

automation: !include automations.yaml 
automation old: !include old_automations.yaml

They just don’t realise that’s what they’re doing and think ‘automation old’ is some special syntax.

8 Likes

Thanks!

I forgot all about that. I haven’t looked at that part of the docs in ages.

I still think tho that doing it that way would get way more confusing eventually than just splitting things out the normal way.

And that’s probably why I never see anybody actually using that method. Not that people don’t but I doubt it’s very common.

Consider me in that group. I never thought about it until you just pointed it out. But I don’t use that either…

Aye, just lots of different ways to split up the configuration in to manageable chunks. It’s easiest to remember that eventually it all ends up back as one long block of text before it gets loaded, so when the includes are extracted it still needs to be valid.

Using --script check_config --info all shows how it all blends back together if it helps anyone.

IMO, packages are the only way to keep track of your configuration.

That’s an interesting use case! I knew about appending strings to a primary key, but I never thought to do that.

Still gonna stick with the !include_dir_* options, but that’s good to know.

What makes you say that? I have a separate directory in my /config directory that contains directories for my automations, input_number, scripts, and sensors (template, history stats, etc.), along with files for my binary sensors and input_boolean. Works well. All my !include* references are at the bottom of my config.

Well, i like to have everything that belongs to an ‘automation’ in one file.

sensor:
  ...
  
switch:
  ...
  
automation:
  ...

script:
  ...

input_*
  ...

and so on..

I think it’s easier than to edit multiple files for one function.

(as a console junkie) :slightly_smiling_face:

1 Like