I need this too, I wanna exclude energy and media browser as it’s totally unneeded in the docker container.
Upvoted
Agree with the sentiment here. There was a previous entry with the same request. Hate to beat a dead horse but this would be great. I LOVE everything the developers are doing and that they are doing it for free is remarkable. Not here to crap on anyone or make insults. I just think this would be a great add.
1 Like
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.
4 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:
1 Like
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.
3 Likes
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’.
1 Like
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.
3 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.
3 Likes
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.
7 Likes
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.
5 Likes