Why the heck is default_config so difficult to customize?

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

And when they change the ingredients in the default burger you’ll never know! And if you then ask on the forum, people will say you should order the default burger… etc…

3 Likes
42

Which is what’s being requested.

2 Likes
43

Yes I know and the reason I voted for this months ago…

1 Like
44

So say we all (all 16 and counting).

1 Like
45

I’m hungry

2 Likes
46

And I want to watch Battlestar Galactica

1 Like
47

I have disabled default_config: to get rid of cloud:, zeroconf and other things, which would clutter my HA with useless sensors, back in the 0.90s

It took me the whole evening to find out, that I have to add

input_boolean:
input_datetime:
input_number:
input_select:
input_text:

to the config file to be able to add new inputs in the helper section…

Please add the ability to ignore certain components from the default, as you can already do for example with

history:
  exclude:
    entities:
      - sensor.timeSensor
3 Likes
48

Woulda been a good thing to include in month of WTH. There’s always next year.

49

Since custom components can override the included ones, it’s possible to keep the default_config: directive and just add completely empty mock custom components for the ones you don’t want.

While this is certainly a hack, it does seem to work surprisingly well

You can find samples for the updater and cloud component here:


It’s sad that one has to resort to hacking around the issue.
I hope that this will be resolved in a proper way soon

3 Likes
50

Excellent idea!!

Unfortunately I think this component is going to have a long life…

51

That is not simpler than removing the default config and adding back a few simple yaml lines of the options you actually want.

52

It saves you the hassle of having to update those when there are changes to default_config.

As you said though, you don’t have to use it :^)

3 Likes
53

Let’s consider the case of a responsible user who reads the release notes before updating and notices there is an addition to the default config.

Case 1: wants new feature and uses default config, action: none required.

Case 2: wants new feature and does not use default config, action: add the text new_feature: to configuration.yaml.

Case 3: does not want the new feature and does not use default config, action: none required.

Case 4: does not want the new feature and uses default config, action: create a dummy non functional custom component.

Disregarding the trivial cases 1 and 3, which is the easiest remaining option out of 2 and 4?

1 Like
54

Case 5: wants to use default config while excluding existing feature A

Anyways. It solves my needs and I figured that I might as well share it so if someone too would like to do this then now they can

3 Likes
55

to create extra work for themselves.

Sure, if that’s what you want, go for it.

And before anyone mentions it:

Case 6: irresponsible user who does not read the release notes: is going to have a bad time, default config or not.

56

C’mon Tom it’s way more simple. I remember stuff that has been added to default_config that was never explained in release notes eg system health… I have been caught with this and have always read release notes. I started using default_config because I didn’t want to have to keep up with it anymore but always wanted to be able to ignore cloud for example. This is a great hack for me.

9 Likes
57

We are going to have to disagree on this one.

58

Yes, it would be nice to have the option to exclude some modules from default_config.

For example recently dhcp module was added to default_config and now I’m getting UAC requests every time I start HA just because I have winpcap installed on my machine in UAC mode.
Would be nice if I could just use something like this:

default_config:
  ignore:
    - dhcp

instead of adding all the modules I might need but I don’t know anything about.

Also adding modules manually will force me to monitor default_config and search for modules I might need in the future instead of specifying modules I’m sure I don’t need at the moment.
I hope this will be added eventually.

3 Likes
59

You missed categories.
-Wants/Does not want to keep up with release notes.
-Wants/Does not want to perform manual configuration on each new feature.

Those categories break #2 into several smaller categories where it starts to make sense to add this feature. Remember that Home Assistant is a hobby for most people, not everyone in #2 treats this as a job.

Personally, I want the new features but I don’t want to have to perform manual configuration and reboot HA each time because that takes extra work. Let me explain my user stories. I am very engaged in new features.

  1. I don’t want to perform unnecessary configuration work because I’m lazy.
  2. I don’t want to have to reboot/restart more than once per update because that takes my services offline and resets timers. Also my wife gets upset.
  3. I don’t want to spend time troubleshooting why a feature I am reading about is inop only to find out it’s because I haven’t added it to my config.
  4. I disabled 2 options because I dislike their functionality and due to that, I must reluctantly perform 1 , 2, and 3 because there is no alternative way to disable these 2 options.

It’s nice to get new features you aren’t aware of from time to time. But if you want to remove any of the default features you miss out on that experience all together.

There are a lot of reasons to apply a disable option.

5 Likes
60

I would suggest that it goes a step further and is toggled on and off through UI. That way you are aware of what’s in default config anyway.

5 Likes