Why the heck is default_config so difficult to customize?

Archive Month of "What the heck?!" (2020)
61

I agree with Sylvain.
This feature request isnt solve.

If new feature is include in the default_config into the next release, I will have to manually add them.
What Sylvain need, and he is not alone, is the ability to ignore a single or multiple integration.

+1 for this

1 Like
62

I ended up here looking for the same feature. It would be great to exclude map: from default_config: vs. having to (find and) list out all the individual features: that default_config: includes minus map:.

I have a old install that Iā€™ve been carrying forward since before default_config:. There were SEVERAL features I didnā€™t even know I was missing until I added the default_config: item including Nabu Casa and, ironically, map:.

4 Likes
63

Flip thatā€™s exactly what i came here for and need. I need to stay up to date with HA, but just exclude the map from HA, because of some privacy issues around my setup.

So sad to see disagreements here and leave with unanswered problem for some weird hacky solutions :confused:

4 Likes
64

You can now edit the GUI to not show the map even if the map component is loaded. Itā€™s not exactly what you are chasing, but then HA still had location data as per your entities whether the map component is loaded or not

1 Like
65

Iā€™m all for the ability to have an ignore or exclude map for the integrations that are not to be loaded through default_config.

2 Likes
66

+1 this would be a handy feature.

2 Likes
67

My proposal is to have a n option at UI configuration (maybe in config/core) that allows users to choose whether or not they want to use the default_config

It would also be nice if all the integrations activated by the default_config are shown. It could be displayed as a nested list of checkboxes so this way users could disable the default_config and select which integrations to activate. It would also serve to know which integrations are included with the default_config

Also, the helpers config, can address users to this config to activate any disabled helper.

This check (active by default) could be offered to user during onboarding proccess.

3 Likes
68

@tom_l can you please remove the solved tag, since itā€™s clearly not solved.
I think we can agree that this feature is something user need/want.

3 Likes
69

No. That is the solution.

70

ā€œYourā€ solution.
You seems to only listen yourselfā€¦

Regards.

1 Like
71

Mate, I didnā€™t mark it as the solution. The original poster did.

Also this is not my decision. Iā€™m not one of the developers who designed it this way. Though I do agree with it.

I have removed the solution tag as it upsets you so much. Itā€™s unlikely to change anything though.

1 Like
72

What solution? Iā€™m the one who started this thread and I donā€™t recall flagging any post as a solution.

73

It doesnā€™t matter if a solution is marked on feature requests. Feature requests are closed when they are added into the software.

1 Like
74

Oh! They added it? Cool!

1 Like
75

No they didnā€™t, thatā€™s why this isnā€™t closedā€¦

76

You had marked it as solvedā€¦ one of Tomā€™s posts but Tom removed the solved flag which is why itā€™s not marked now

77

Well, if I did, it was by mistake. Sorry if it brought all that confusion and some name calling :frowning:

1 Like
78

hahaha. itā€™s all good mate.

79

The fact remains the developers have indicated that the options are:

  1. use default_config,

or

  1. manage integrations yourself.

And for the present time there is no plan to change this.

80

or

  1. go into components/default_config, edit the manifest json and remove the entries you donā€™t want.

Youā€™ll have to redo this after a core update. But I find it quicker and easier to exclude the stuff I donā€™t want than to include everything in the yaml and hope I donā€™t forget something. You could even write a script that does it automatically after an update, as the stuff you want excluded will likely stay the same.