As it is if you want to remove a single integration from default_config: (History, Map, logbook, etc), you need to remove default_config: and manually add every other included integration EXCEPT the one you would like to get rid of.
The most obvious solution to me would be to add the option to exclude entries from default_config: in the configuration.
Example:
default_config:
exclude:
- Map
But knowing how default_config works, that’s not really viable. I suggest we go back to the way things used to be before default_config existed. Each entry was added to configuration.yaml individually, and users could modify/remove items as needed. Lumping everything together doesn’t make very much sense to me.
There’s a Feature Request for the ability to exclude (ignore) options from default_config.
The principle argument against it is that default_config contains all the options the development team believes every user needs. It’s meant to simplify things by just specifying default_config and not having to list all the options it represents. In addition, they reserve the right to include more options within default_config so that, after an upgrade, you automatically get the additional options.
This all seems like a fair argument except it overlooks the fact that it’s actually inconvenient for anyone who needs only 90% of what default_config provides. For example, I don’t want updater (because it sends telemetry). As a result, I have to list the balance of all the other options (~17?) just because I don’t want one of them.
The counter-argument is that’s just a minor inconvenience that you only have to suffer once: list the other 17 options and you’re done. Not quite. In the next upgrade, default_config may contain an additional option or two (it’s happened). If you missed that little detail in the release notes, then your config, with its 17 options, is missing the new ones and your system may behave a bit strangely (I experienced this myself).
The convenience of using default_config would be greatly enhanced for everyone by simply allowing for this:
default_config:
exclude:
- updater
Done! Now if I upgrade and default-config contains new options, they are automatically included and only updater continues to be excluded.
doesnt matter how many votes it gets. read the disclaimer about WTH
"Is everything reported going to be fixed/addressed?"
There is no guarantee that will happen. The goal is to lower the barrier to
reporting things for one month. Home Assistant still relies on contributors
to address or improve the project. However, we do think collecting feedback
this way can tremendously help with the upcoming Hacktoberfest .
Please do! They can always use more help, even for small stuff (bug fixes, or minor improvements like what are contained in this or the feature request forum).
Feature Requests are nothing more than a wish. Just like a wish, you never know if it will come true.
Feature Requests are not formally analyzed, evaluated, prioritized or scheduled for inclusion in a future release by the development team. They’re posted here in the hope that someone with appropriate software development skills thinks it’s a good idea and takes the time to implement it and submit as a Pull Request in Home Assistant’s GitHub repository.
Only then will it be evaluated by someone on the team. They might suggest improvements before it can be accepted or they might reject it (typically due to non-conformance with design rules).
tl;dr
The only thing anyone can say with reasonable confidence is that this Feature Request has not been implemented yet.
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.
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.
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.
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.
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’.