If you have to redo this after every core update it is more work than managing integrations yourself, where you only have to add a new integration if one is released and you want it.
It would be nice to see this in the UI at some point. Perhaps a list of checkboxes listing each component with a top level defsult_config which will enable all and automatically enable new ones in the future.
That way those of us without default config enabled could easy see the new ones and enable in the future. The yaml mode could remain unaffected.
2 Likes
I mean it only takes a few seconds and you know beforehand what you need to remove (and it can be scripted). If you include manually into the yaml, you will always have to read the release notes first. Itās not only about adding the odd new integration you might want to use. You need to check at every new release if something was added to default_config that would break essential functionality if omitted from your manual config.
Or zero seconds with the official method.
That is not the only reason you should always read the release notes before updating.
1 Like
And what exactly is the official method to exclude unwanted integrations from the default config ?
2 Likes
I donāt understand how that would take, I quote, āzero secondsā. You will need to make sure that your manual config includes everything that is expected on a new version, or you might break essential functionality from omitting something vital. And that implies not only going through the release notes, but possibly even through the commit history of the default_config component on github to check if something important changed.
Excluding unwanted integrations, rather than including, is a much much better approach for situations like this. And in the absence of official UI or yaml support for exclusions, patching the json is a very good alternative approach. Might not be for everybody, but at least it works really well for me.
2 Likes
Because you are building on what you have. No new integrations in the release? Nothing to do.
New integration you dont want? Nothing to do.
New integration you do want? Type one word.
Your method requires updating your cludge no matter what.
ok. If you say soā¦ 
Until some component that wasnāt in default_config earlier suddenly gets moved into it for whatever reason. Then hell breaks lose for you and youāll have to sift through commits to find it and add it. Itās not like HA wouldnāt have a track record of random breaking changesā¦ But hey, you do what works for you. I do what works for me.
1 Like
āSuddenlyā, like publicly announced in release notes?
Then you (or programmers) are missing the real need (not requirement or implementation).
The need is to exclude selected component. not to manage default integrations on my own.
Itās obvious thar the latter require unwanted, periodic and repeated infinitely effort. Itās not wise to propose it as effective sollution
4 Likes
Thatās never happened. Is there really a need for whataboutisms? Iām all for arguing your case, but fear mongering doesnāt help anyone.
Look I have avoided this today but this statement is bullshit. There is nothing in release notes telling you a new entry has been made to default_config and thatās pretty much the point here. I get why you are opposed to user configuration of thisā¦ kindaā¦ but this would be a good feature for lots of users.
8 Likes
The design intent was built around making default_config easy for beginners and force non-beginners to manage the configuration when default_config is absent.
And before you flame me like you are @tom_l, Iām not saying Iām for or against this feature request, Iām just stating the design intent of the original default_config.
1 Like
More that I can understand the devs point of view.
but what is the point to force not beginners to do more work. Why non-beginners cannot just disable unwanted integration and forget about it?
3 Likes
Can you elaborate more about their point of view? there are not known reason to maintain this way. the only reason I can imagine is additional programming of interpreting config to allow exclusions (btw programmed already for other features)
No. It has all been said before. Iām done with this.
Again, I explained the design intent. Iām not here for an argument. I couldnāt care less about adding a few lines of code to yaml.
Not sure I understand your answer correctly. But itās not about lines of yaml but about need of tracking HA future changes (to infinity) in order to be up to date with components added to default config in future. This fact makes the design intent missing the mark
2 Likes