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.
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.
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…
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.
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.
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.
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.
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
Did you not read this?
Yep. And, I certainly see where SeanM is coming from but for the reasons I (and DavidFW1960 and SylvainGa) mentioned, I feel it would be nice to have the ability to customize things a bit more easily.
If this just needed a one-time static set-up then this would not be anything to argue about. But what is in default_config has changed over time–which is not a bad thing! But, if you manually set up the components, you might unwittingly miss out on new features later on.
I just think that it does not hurt anybody to add the ability to ‘exclude’ or ‘ignore’ things you do not use. That type of customization is already there for other integrations like recorder, google assistant, etc. And, if the goal is to get people away from YAML then you could put it in the UI.
And did you read this?
https://community.home-assistant.io/t/ability-to-ignore-components-in-default-config/194144/17
Yes, no need to quote yourself.
Well, it answers your question.
Nope. It ignores the raison d’être of the default config.
You have two options, managed or unmanaged. If you want to manage your config don’t use the default_config.
This Feature Request is for a third option:
If next week’s default burger includes a pickle, the Tailored Managed option will also include it (minus the mayo). You don’t get that convenience with the Unmanaged option.
Sigh, back to square one.