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?
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.
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.
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.
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.
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.
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.