Ability to ignore components in default_config

Hi, just like for ‘discovery:’, it would be nice if ‘default_config:’ would accept ‘ignore:’ so we could ignore components we don’t want to be included.

Edit: To make it clearer why I find this would be useful:

If you look at this post that is not even a year old, 7 components (like all the ‘helpers’ like input_text, input_boolean, etc) have been added to default_config since then! So with every update, you have to look if something has been added otherwise it could break your installation.

Just don’t use default_config. Review the list of what is included and add them to your config directly.

3 Likes

Yeah, being able to customize the default_config would completely defeat the purpose that it was introduced to address - the idea of “make it easy”.

If the user has the ability to edit the configuration.yaml to exclude items then they have the ability to edit it to include what they want from the default.

1 Like

FWIW:

Yeah, I know that. But this means that every update I have to check if now components have been added so I can add them as well. With the Ignore statement, it’s the other way around.

Are you referring to the auto-discovery feature performed by SSDP and zeroconf?

Yes and if you look at this post that is not even a year old, 7 components have been added to default_config since then!

I sure don’t know what’s the reticence (ie, then don’t use default_config) of adding a ‘ignore’ statement like there is for ‘discovery’ for ‘default_config’.

See the post I just left

I see what you mean now. It’s the fact they keep expanding what is handled by default_config. For example, they recently added all the ‘helpers’ like input_text, input_boolean, etc.

Now I understand why you want an ignore list.

I’ve added my vote.

2 Likes

See my updated first post why this ‘include from the default’ can create problem.

All of which should have been in a functional config anyway.

1 Like

I’m glad you can predict the future, because I can’t.

What?

input “whatervers” were around long before they were helpers. If you did not have them in your config it would have been an incredibly simple one.

I don’t have any ‘helpers’ defined in my config. So when I tried to create one via the UI, all options in the list were disabled. That’s how I learned I had to add them to configuration.yaml in order for them to appear in the list. If you look at the linked post (above) you’ll see a screenshot of what I mean.

Note:

The context here is that I was performing a new installation. Rather than copy my existing configuration files, I chose to do everything from scratch. The only tweak was to disable default_config and cherry-pick what I want. I didn’t think I needed to create an ‘empty’ placeholder for input_datetime so that the new Helper feature would permit me to create one.


Here’s another quirk I discovered accidentally. If you omit config: then the default dashboard fails to render. If you create a second dashboard, it will be rendered but not the default one. I posted it as an issue but there’s been no reply yet.

Yeah, after thinking about the other posts I can see your point…

2 Likes

The entire point of default_config: is that you don’t manage it. Adding this ability would be sending mixed messages.

If we make it easy to ignore components, we’d also be making it easy for people who don’t know what they’re doing to potentially screw up their system. Unlike ignoring something from discovery: which is harmless, here you could prevent the frontend from loading or prevent the configuration panel from displaying among other things.

And it would inevitably just lead to an influx of entirely avoidable support questions. People would ignore certain things they’ve never heard of before like ssdp: and zeroconf: thinking they don’t use or need those, and then down the road complain when mobile app setup fails to detect their Home Assistant instance or that some config flow didn’t work.

I think the current approach is fine. You have a choice between everything being done for you (best for 99% of people), or having complete control of exactly what gets loaded. But if you’re gonna mess around with which components get loaded, you should know exactly what you’re changing and have the knowledge to recover if things go wrong. So I think requiring a higher bar to manage that stuff is a good thing personally.

1 Like

But if you make it hard (like it is now) to ignore stuff, you’ll have people (like they are doing now) screw up their config because they turned off their default_config and stuff started to not work, or in the long run, want to turn on something but because its feature got moved or added to the default_config, (which he won’t have because it’s now off, remember?) and wonder why it’s not working and flood the forum with support question.

When you explicitly ignore something, it’s in a completely different ballgame because you did the exclusion and know it’s not there then when the devs decide to move or add something that now EVERYONE without a default_config will need to be aware off with every update.

1 Like

The request is for more complete control. The Feature Request protects knowledgeable users, who choose not to use default_config, from automatically being excluded from future additions to default_config.

I was affected by the recent addition of the ‘helpers’ to default_config. Because I didn’t have some of them defined in configuration.yaml, like input_select and input_text, they became unavailable in the Helpers menu. Effectively, they were automatically excluded from my system.

What protects users from missing out on future changes in default_config is the ability to exclude what they don’t require (as opposed to the current arrangement which is to include what they want).

In my case, I only use ssdp and zeroconf for the initial discovery of devices and services. Afterwards, I comment them out in addition to cloud, history, map, logbook, updater, and mobile_app. If the exclude feature were available, that’s the list it would contain. So if in the future, something else were to be added to default_config, it would be automatically included.

They can already do that now, when they decline to use default_config, and I can’t recall it coming up as a significant support issue on the community forum.

3 Likes

I don’t understand the argument against this at all.
The list of stuff in default_config continues to grow and it’s never really pointed out that you then have to add a new config option in release notes. (I remember system_health as an example)
I for instance don’t need or want cloud in my configuration but if I want to avoid just that one component loading I need to manually specify an increasing list of things manually (that I may not even be made aware of) instead of excluding just that one component.

7 Likes

I’m sorry but “just don’t use it” is not constructive. This would be a nice added feature. I don’t think this would flood the forum with support requests, either. If you were worried that it would, implement UI control instead over what default_config adds to your system.

You can’t seriously think that being able to put in the following is more prone to errors or support requests than manually configuring all the components that follow and keep up with any additions over time.

default_config:
  ignore:
    - cloud
  • Automation
  • Configuration
  • Frontend
  • History
  • Input boolean
  • Input datetime
  • Input number
  • Input select
  • Input text
  • Logbook
  • Map
  • Mobile App Support
  • Person
  • Scene
  • Scripts
  • Simple Service Discovery Protocol (SSDP)
  • Sun
  • System Health
  • Updater
  • Zero-configuration networking (zeroconf)
  • Zone
2 Likes