FWIW, official resistance to the concept of a configurable default_config has always been high.
It’s a small miracle the PR was allowed to progress for as long as it did before it was summarily rejected.
wtf? what more complexity do you mean?
Isn’t suggested way to manually maintain default config list more complex and less reliable?
So instead of simply exclude some integration (because I don’t use it, because is poorly written etc) I have to create my own integration overriding original one?
And of course such component might stop working properly over time due to core changes.
Pure beauty of architecture design. And ignorance shown to users.
I could have understand no will of developing this extension (though I would expected such a feature from beginning). But blocking it after someone provided PR?
4 Likes
Quoting from the closing comment:
If you want such functionality, you can create a custom component that reads the default config manifest and sets up what you want.
You see with code it’s often not a one-time payment of time. A PR of course reduces the initial investment but after that maintaining the code and everything it introduced becomes the burden of the maintainer.
As you yourself said:
So you’re definitely aware that there is a cost of maintainership to this feature. With a PR merged, the core team would have to pay that cost. With a custom_component someone else has to.
no, there is cost of maintaining gimmicking of this feature. especially while core architecture is changing. Excluding components from fixed list will work until such a list exists (I guess forever). If happens, a potential change has to be made at single place in code, not in hundreds of fake components on thousands of installations.
The reasoning that the default_config should be the default config and not some random subset is pretty solid considering how much anything else would drastically increase time required for supporting users as they will surely configure things in a weird way but also forget to mention that in a bug report.
That said, there could’ve definitely been a bit more effort from the core team.
Currently, it’s still unreasonably hard to replace default_config: in the configuration.yml with the full set of its dependencies, as there is no easy way to figure out what those even are.
You can look at the docs for that Default Config - Home Assistant , however you will have to painstakingly select, copy and paste every single one listed there.
Having a formatted block of yaml there ready to be copy pasted would’ve been much more helpful.
Nonetheless, the custom_component approach to filter the list is clearly superior to that as it will gracefully handle changes to default_config without requiring you to touch your config.
1 Like
Then maybe there are other bad decisions in the game. My need is to disable Shelly integration. Personally I don’t want to dig in system things increasing risk of breaking something or make the system differ core functionality wise. Just want’t to make this component not bothering me anymore. Really.
Someone from devs decided this integration must be in default config. Not my fault they have all those things mixed together up.
Not sure I understand correctly. Till now I live with impression that to disable shelly integration I have to create my own shelly custom integration which just override original one providing no functionality at the same time.
From the quotation it sounds like possibility to create custom integration allowing to control everything from default config ‘on the fly’?
Would be nice (I doubt it’s possible) but how it resolves the ‘would drastically increase time required for supporting users’ issue?
But I’m glad you also see the cons of current situation.
I think you’re talking about 2 different things. Shelly isn’t apart of default config… unless I’m miss understanding your direction.
Yeah. Basically the idea is to take the filtering feature proposed with the PR and instead move that into a custom_component if I understand it correctly. So from a user-standpoint it should be pretty much the same.
Every custom component will generate a logline like this one:
[homeassistant.loader] We found a custom integration garbage_collection which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
That makes it easy to see that something might be odd and also shifts the responsibility to further debug the issue to the user who is running a non-standard setup.
I’m only here because I too want to customize the default_config 
2 Likes
I though it is default config. But maybe it’s zero config (which is part of default config).
Just looked at docs but hard to find exact information about it
Yeah, no clue. Got my first shelly em a month ago. My config is so old that it never had default config or zero_conf so I have no idea if they conflict.
But it’s logged only at ha start, right? So it might be thousands lines away from analyzed ones. But now I’m just nitpeaking
Custom components are also listed in the generated diagnostic download file.
I think the idea is to create your own ‘default_config’ component and put it into custom_components. Like everything in custom_components, it will then override the original default_config component (which won’t load) and leaves you with implementing your own (editable, includable, excludable, etc) default list. That’s a pretty interesting alternative.
I wouldn’t call it Interesting but seems it’s doable. What worries me is that overwriting deep-core parts must not end any good.
This is why imo this approach is inferior comparing to potentially built in option.
Interestingly, they could have done the same to recorder. I mean never implement exclusion of entities, instead asking users to write custom components on their own.
1 Like
Yes of course a built-in exclude option would have been far superior, no doubts about that. I find this dogmatic approach of flat out dismissing this because ‘default means default’ really strange and questionable.
But in the absence of native support, this is the next best thing. Default_config isn’t really deep core at all, it’s a very simple component actually. It doesn’t even contain any code, it leverages the dependency system in the manifest json to load the default stuff. Overriding it with a custom component could be seen as a kind of customization of the default config. The (closed) PR mentioned something about parsing the original default_config manifest and implementing the exclude option in the custom component, rather than a static override (which would not be much different than listing out the individual components in configuration.yaml).
1 Like
What I find interesting, and I voiced this years ago when it happened, is that Cloud is part of default but, at least early on,. HA stressed local control to be most secure. Those making this decision have a conflict of interest due to being involved with Naba Casa. It profits them monetarily to force a default config it it encourages more people to subscribe,
4 Likes
I’ve talked with a few of the main devs, and part of the problem is that some of these integrations require other integrations in that exclude list and maintaining that would be a pain in the ass. They simply don’t want to do that either. Unfortunately, we have to respect that decision.
cloud is required for more than just nabu casa. I think that’s overlooked in these cases. If you circumvent nabu casa with your own dns service, cloud is required to hook up with specific integrations like alexa smart home skill or google home.
Those are not local control though. Some like the convenience & it should be a choice, Other may consider the security implications of cloud,
right, but they need to be in configuration.yaml in order for you to set them up for use. Just because they are loaded doesn’t mean they are used. It’s like importing a python library and then not using any of the objects. Only impacts your startup.
FWIW, I’ve been doing my own poor-man exclude for default_config for a while now, by automatically running a script after each HA update that removes integrations I don’t want from the manifest.json. It removes quite a bunch, including things like zeroconf, cloud, dhcp, ssdp and others. I haven’t run into any dependency issues so far. But I can see the problem if someone starts to remove default integrations such as script or the entire frontend. Oh well.
4 Likes