Is there a list of which integrations support multiple top-level !include statements or keys?

Configuration
1

In the documentation about Splitting Up the Configuration, specifically this section here, we are invited to modularize the configurations for certain integrations by adding a space after the key and then some discriminating text, for example (in configuration.yaml):

light groups: !include light-groups.yaml
light switches: !include light-switches.yaml

…so that the extra text after “light” is there to keep the YAML parser happy, but the light integration is smart enough to pull in any dictionary element whose key starts with ‘light’.

The problem is that the aforementioned documentation page tells us that “Some integrations support multiple top-level !include statements”, and lists a few, but it doesn’t tell us how to tell whether any others support it.

Alas, it appears that the helper integrations still do not, because I tried:

# A few inclusions to make sure that '<key> <modifier>: !include ...'   is working
input_number telltale: !include telltale_input_number.yaml
input_text telltale: !include telltale_input_text.yaml
input_datetime telltale: !include telltale_input_datetime.yaml

where the included files would look something like:

telltale:
  name: "Telltale - Datetime"
  has_date: true
  has_time: true

and those just don’t work at all (even though Developer Tools says that the configuration looks fine). After a day of trying every variation I could think of, I finally gave up and went with Packages… which, arguably, is the better was to go about it, but it would have been nice to have known that it was the only viable route 12 hours ago.

So… is there some wiki page, somewhere, which details which integrations support this trick and which don’t?

2

All of those support !includes.

3
  1. I’m not asking about plain !includes. I’m asking about multiple top-level includes where a single integration is able to pull from multiple included files and/or multiple sections of YAML by adding a distinguishing suffix to the integration name, as in “light groups:” and “light switches:”.
  2. I’m not asking whether certain integrations support this, because it’s probably quicker to just check by trying them in my local config than it would be to post here and wait for an answer about that particular integration. I’m asking if there’s a reliable list somewhere which lists which ones do and don’t.
4

To my knowledge, that section you pointed out in the documentation is all that is officially documented about multiple top-level includes.

If you’re interested, here’s an alternative for other integrations like Input entities. Basically, you create a sub-directory to hold multiple files (for example input_number files) and then use the appropriate !include directive to merge the files (such as !include_dir_merge_named) .

1 Like
5

Yeah, I saw that part. The only downside to that is that it requires you to break up the pieces of a solution and put the pieces in different places. To adapt the example from the section you linked to, imagine this for some solution which required some definitions for lights, sensors, and helpers in order to work:

.
└── .homeassistant
    ├── automation
    │   ├── lights
    │   │   ├── turn_light_off_bedroom.yaml
    │   │   ├── turn_light_on_bedroom.yaml
    │   │   └── my_automated_light_solution_lights.yaml
    │   ├── helpers
    │   │   └── my_automated_light_solution_helpers.yaml
    │   └── sensors
    │       └── my_automated_light_solution_sensors.yaml
    └── configuration.yaml (not included)

Notice how the various parts of “my_automated_light_solution” have to be broken up and stuck in various folders, which makes it a little bit of a problem when you want to go yank it out, deploy it, or just get a holistic picture of how it all interoperates.

What I think would be nicer is being able to do something like

# Main HA inclusions
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

# Inclusions for my automated light idea
automation my_lights: !include my_automated_light_solution/automations.yaml
scene my_lights: !include my_automated_light_solution/scenes.yaml
script my_lights: !include my_automated_light_solution/scripts.yaml
input_text my_lights: !include my_automated_light_solution/input_text.yaml

That way, the inclusions are in one place in configuration.yaml and the files you’re including are all in one folder, so it’s easy to understand the entirety of the solution. What’s currently frustrating is that the above approach works for some integrations, so, when you try this, some of it works and some of it doesn’t, which causes one to look for typos or other syntactical mistakes, when, in reality, the integration just silently neglects to support it.

So, it looks like packages: is the way to go, here.

6

Every single integration that can be configured via yaml accepts all variations of include as long as the data structure matches the include type.

7

There is a short list of integrations that support multiple keys:

image

8

Because it’s not designed for grouping all the different types of entities that comprise a specific application (a.k.a. a “solution”); packages is meant for that.

That’s a novel idea but unlikely to be implemented given that the package concept was designed for this purpose.

1 Like
9

That’s what inwas thinking sounds like they want packages… Not a simple include.