Why the heck is default_config so difficult to customize?

The votes were removed from there and added here. If I’d merged them the other way around the same would have happened.

I understand regarding the votes. I guess I just expected them to be merged in to the feature request section (as all the votes are technically for the feature request), rather than the WTH section which I assumed would be used less as it was originally for the month of WTH last year.

Although I am feeling a little disheartened right now, after seeing the comment below from one of the moderators, so it probably wont make a difference where the votes ended up :slightly_frowning_face:

Not that I think it will help. I don’t think I’ve ever seen a feature request get implemented.

There have been some… (New templates being implemented into packages recently as an example) and the whole month of what-the-heck saw a bunch of them being implemented last year although those are not technically FR’s.
What I DO find ironic however is that the (now deceased) starter of this thread was one of the devs himself…

1 Like

Feature requests get implemented all the time, moderators have no sway in that unless they dev and add it themselves. People need to stop thinking moderators are anything but moderators. We moderate the forums, that’s it. We aren’t voices for HA.

And I have seen them implemented - but like anything else, it’s up to the people developing stuff. People could vote for a tea platform as much as they want, but if nobody steps up to do it, the votes don’t matter.

On the other side, if a few dozen people vote for something and somebody interested sees that, they may pick it up and make it happen.

Ultimately they’re a way of people saying we’d like this and bringing to the attention of devs who’re looking for something to do.

1 Like

Also voted as by chance I asked a question that lead me here.

I also believe that it is much more convenient for 90 % of the users to add an ignore line than constantly monitor release notes.

We must not forget that the dev team does an amazing job at constantly improving home assistant and provides multiple new release per month. As much as I’d love to, I simply don’t have time to track everything that is going on and if I miss one new default integration it might break something else.

So I too think that an override/exclude/disable would be great.

2 Likes

An exclude functionality would be amazing, I do not use the map nor want it included, which means I’m having to ensure I keep all of the ‘default_config’ entries listed manually and updated.

default_config:
    exclude:
        - map

Would be so much easier.

4 Likes

To all who voted for this Feature Request:

18 Likes

Great news. At least now the addition of new integrations can be automated in my HA setup, in which I’ve removed integrations I don’t want.

And remains waiting for merge, missed two HA releases.

1 Like

This is normal for any PR…

you forgot to add: …in HA development.

Since it’s really awaited feature I really hoped it will be pushed to see a light of day quicker.

It’s waiting on a reviewer. This is a normal software process. There was 1000 PRs added in October and 1000+ in November. Quit acting like a know it all armchair developer. The process exists for a reason. Be patient and wait for a review or review it yourself.

2 Likes

I’ve noticed it has changed state from Needs review to Incoming, remaining in the recent one for a month. I didn’t considered it as another state representing waiting for the review.
If it’s waiting for reviewer then obviously there are no reasons to complain.

Incoming is prior to needs review and it’s a draft. You’re welcome to say something in the PR to spark a conversation. It could very well be in limbo, which typically gets caught when things go stale.

3 Likes

Unfortunately the PR has been closed by the developer.

Things are moving forward

6 Likes

Unfortunately, it seems that the HA core team has decided that they are not willing to accept this feature (see latest comment on this PR).

2 Likes

Tbh I think it’s fine this way, given that they suggested a valid alternative approach, which doesn’t involve the use of hard-to-maintain hacks while giving all parties what they want.

custom_components are a quite powerful and more importantly officially supported tool.
You can override basically everything with them without having to recompile code/rebuild a new docker image etc. Just drop the files into a folder and you’re good.
And - as they can be easily kept up to date using HACS - it’s not even causing a noticable maintainance overhead for the user.

Sorry to hear this PR was rejected. Thanks for the developer’s efforts to try and get it included. I really liked the simplicity of the “I want the default_config, just without these things” approach. This concept is easy to understand for the average user, and matched existing exclude functionality available in other components.