Why the heck is default_config so difficult to customize?

[Jokerigno]

UP! Any update on this?

[ralong (Oskar Gawlik)]

So how is this feature going?

[123 (Taras)]

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.

[mateuszdrab]

I need this too, I wanna exclude energy and media browser as it’s totally unneeded in the docker container.
Upvoted

[nima]

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.

[SylvainGa (Sylvain Gagnon)]

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.

[tom_l]

Just don’t use default_config. Review the list of what is included and add them to your config directly.

[finity]

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.

[123 (Taras)]

FWIW:

Tip: default_config contains a lot!

I don’t use default_config because I don’t want ssdp and zeroconf to monitor and report devices it might find (or logbook, history, and updater). The consequences of this decision can be quite impactful. default_config is shorthand for a lot of other options. For example, if you overlook to include input_boolean, input_text, etc then the Helpers feature will be unusable. Case in point, if you only add this to configuration.yaml: input_text: input_datetime: input_boolean: Then this is how t…

[SylvainGa (Sylvain Gagnon)]

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.

[123 (Taras)]

@SylvainGa

every update I have to check if now components have been added

Are you referring to the auto-discovery feature performed by SSDP and zeroconf?

[SylvainGa (Sylvain Gagnon)]

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’.

[SylvainGa (Sylvain Gagnon)]

See the post I just left

[123 (Taras)]

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.

[SylvainGa (Sylvain Gagnon)]

See my updated first post why this ‘include from the default’ can create problem.

[tom_l]

@SylvainGa

7 components (like all the ‘helpers’ like input_text, input_boolean, etc) have been added to default_config since then!

All of which should have been in a functional config anyway.

[SylvainGa (Sylvain Gagnon)]

I’m glad you can predict the future, because I can’t.

[tom_l]

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.

[123 (Taras)]

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.

[finity]

Yeah, after thinking about the other posts I can see your point…