Splitting up the config

[ashscott (Ash)]

In an attempt to create some order in my system, I have begun splitting it all up:

group: !include groups.yaml
automation: !include_dir_merge_list automation/
script: !include scripts.yaml # script: !include_dir_merge_list scripts/
scene: !include scenes.yaml
switch: !include switch.yaml
cover: !include cover.yaml
sensor: !include_dir_merge_list sensors/
notify: !include notify.yaml
input_boolean: !include_dir_merge_list booleans/
binary_sensor: !include_dir_merge_list binary_sensors/
input_number: !include_dir_merge_list input_numbers/
input_select: !include input_select.yaml
input_text: !include input_text.yaml
light: !include lights.yaml
rest_command: !include rest_configs.yaml
timer: !include timers.yaml
zone: !include zones.yaml
counter: !include counters.yaml

The split up automations work fine, but nothing else. I don’t get any errors but scripts, input_numbers etc. are not available to me when split using !include_dir_merge_list.

Is there a reason for this that I am missing?

[m0wlheld (Christoph Dahlen)]

IMHO It’s not worth the effort. HA developers decided to drop YaML configuration files in favour of a hidden .storage directory, integrations and UI editors. For example input_* can easily be created using the UI (“Helper”) and AFAIK not make it into your input_numbers/*.yaml files.

So, what’s the advantage?

[Holdestmade]

Lets see you directory structure

Also, yaml isn’t being scrapped:

The future of YAML

Recently, comments and questions in the community have been posted, about the announcement of integrations becoming available via the frontend and the removal of YAML support from some of them. This raises questions and opinions that need addressing. It mainly comes down to this single question: “Is YAML going away?” The answer to this question is: “No!, but…” Realizing you may not like that loose answer and, in that case, you are possibly looking for a hard and simple “NO” answer to this…

[ashscott (Ash)]

Here you go.

[petro]

You have to use the correct include type based on what the field expects. Then inside your files, you have to make sure your yaml is correct as well.

input_booleans are not a dir_merge_list. They would be a dir_merge_named.
input_numbers are not a dir_merge_list. They would be dir_merge_named.

tbh, I think you should manage your input_* through the UI.

As for the rest, it’s going to be a case by case basis and I can help you with which include you should use. I can also help you identify which one to use, but the docs also tell you this info as well.

[m0wlheld (Christoph Dahlen)]

@Holdestmade

Also, yaml isn’t being scrapped:

Actually, it is, as mentioned in the blog post:

@system

• Any new integration that communicates with devices and/or services, must use configuration via the UI. Configuration via YAML is only allowed in very rare cases, which will be determined on a case by case basis.
• Existing integrations that communicate with devices and/or services, are allowed and encouraged to implement configuration via the UI and remove YAML support.
• We will no longer accept any changes to the YAML configuration for existing integrations that communicate with devices and/or services.

[petro]

Yaml isn’t being removed.

[m0wlheld (Christoph Dahlen)]

True.

But deprecated for configuration. Which is okay (especially as i don’t contribute to the project), but it renders efforts in splitting up (obsolete) configuration useless IMHO.

Now, back to topic.

[petro]

@m0wlheld

But deprecated for configuration.

what are you talking about? It’s not deprecated for configuration. Read the ADRs please, stop spreading this wrong information.

[ashscott (Ash)]

Thank you, Petro.

That explains a lot.

If the ‘helpers’ could be filtered and sorted, like scripts are, I probably wouldn’t need to do this.

I’m also migrating, bit by bit, to a new server, and with the UI there’s no easy way to this.

[petro]

@ashscott

If the ‘helpers’ could be filtered and sorted, like scripts are, I probably wouldn’t need to do this.

There’s a bar at the top of he UI where you can type. It will filter them. You can also use the entities list and apply the same filters that scripts have. So I’m not really sure what you mean by this comment.

Either way, take the time to look at the tutorial on splitting up your config to learn which one to use.

Splitting up the configuration

[ashscott (Ash)]

This:

Doesn’t exist for helpers:

This means that I can’t filter helpers by area.

[petro]

Ah, only area would apply there, probably an oversite. In that regard, you’d go in via the area itself and look at the attached entities.

[ashscott (Ash)]

Yes, not ideal.

That’s my main motivation for splitting it up. Searching the helpers only works for the entity, not the area, so doesn’t act as a filter.

[petro]

you can still apply these filters on the entities page. Type input_number in the entities list and sort by area.

[ashscott (Ash)]

@petro

input_numbers are not a dir_merge_list. They would be dir_merge_named

Thank you. This works for input_numbers.

@petro

but the docs also tell you this info as well.

Please can you point me to the docs with this info?

[petro]

I did

Splitting up the config

There’s a bar at the top of he UI where you can type. It will filter them. You can also use the entities list and apply the same filters that scripts have. So I’m not really sure what you mean by this comment. Either way, take the time to look at the tutorial on splitting up your config to learn which one to use.

[ashscott (Ash)]

Yes, I’ve read that but couldn’t find that info.

I’ll read again.

Thank you.

[petro]

If you don’t know types you aren’t going to know what to use. You have to be able to distinguish between a listed configuration (list) and a named configuration (dictionary). The docs do not tell you how to distinguish them, it tells you which ones to use.

listed configuration (list)

some_field:
- internal_contents1:
  internal_contents2:
  internal_contents3:

- internal_contents1:
  internal_contents2:
  internal_contents3:

named configuration (dictionary)

some_field:
  name1:
    internal_contents1:
    internal_contents2:
    internal_contents3:
  name2:
    internal_contents1:
    internal_contents2:
    internal_contents3:

[ashscott (Ash)]

OK. I’m getting it.

How do I determine the ‘type’?

I appreciate you taking the time with this. It’s been holding me up.