Splitting up the config

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

[petro]

See above, do you notice the differences between listed and named?

[ashscott (Ash)]

Yes, I can see the difference, but understanding it is another matter entirely!

[petro]

read this

What is YAML? A beginner’s guide

[petro]

or this

YAML tutorial: Get started in 5 minutes