Tinkerer
(aka DubhAd on GitHub)
September 12, 2021, 7:45pm
121
The votes were removed from there and added here. If I’d merged them the other way around the same would have happened.
allan
(Allan)
September 13, 2021, 1:37am
122
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
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
petro
(Petro)
September 13, 2021, 11:34am
124
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.
Tinkerer
(aka DubhAd on GitHub)
September 13, 2021, 6:36pm
125
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
AleXSR7001
(AleXSR700)
October 9, 2021, 9:35am
126
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
123
(Taras)
October 17, 2021, 4:55am
128
To all who voted for this Feature Request:
home-assistant:dev
← LouisMT:default-config-exclude
opened 08:03PM - 16 Oct 21 UTC
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.
maxym
December 9, 2021, 1:09pm
130
And remains waiting for merge, missed two HA releases.
1 Like
petro
(Petro)
December 9, 2021, 1:12pm
131
This is normal for any PR…
maxym
December 9, 2021, 1:16pm
132
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.
petro
(Petro)
December 9, 2021, 1:19pm
133
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
maxym
December 9, 2021, 1:26pm
134
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.
petro
(Petro)
December 9, 2021, 1:35pm
135
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.
home-assistant:dev
← LouisMT:default-config-exclude
opened 08:03PM - 16 Oct 21 UTC
## Proposed change
The `default_config` integration enables a set of default … integrations. Each integration in this set can still be configured by the user by simply adding it after `default_config`. For example:
```yaml
default_config:
automation:
# override config here
```
So while it's still possible to change configuration for each default integration, it's currently not possible to disable any of the default integrations.
This could be useful, for example I'm having an issue with the `dhcp` integration in Docker. I don't need it. But to disable it now, I must remove the `default_config` integration and keep track of all the default integrations myself. I've done this in the past, and it resulted in me missing out on a lot of new features in new Home Assistant releases. :smile:
I'm creating this PR to get some feedback. I'll add docs & tests if you like my suggestion!
## Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [X] New feature (which adds functionality to an existing integration)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
- This PR fixes or closes issue: fixes #57378
- This PR is related to issue: #57378
- Link to documentation pull request:
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [X] The code change is tested and works locally.
- [x] Local tests pass. **Your PR cannot be merged unless tests pass**
- [X] There is no commented out code in this PR.
- [X] I have followed the [development checklist][dev-checklist]
- [X] The code has been formatted using Black (`black --fast homeassistant tests`)
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [X] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [X] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [X] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [X] Untested files have been added to `.coveragerc`.
The integration reached or maintains the following [Integration Quality Scale][quality-scale]:
- [X] No score or internal
- [ ] 🥈 Silver
- [ ] 🥇 Gold
- [ ] 🏆 Platinum
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
Things are moving forward
home-assistant:dev
← daneget:dev
opened 10:55PM - 16 Dec 21 UTC
## Proposed change
The default_config integration enables a set of default inte… grations. Each integration in this set can still be configured by the user by simply adding it after default_config. For example:
default_config:
automation:
# override config here
So while it's still possible to change configuration for each default integration, it's currently not possible to disable any of the default integrations.
This could be useful, for example I'm having an issue with the dhcp integration in Docker. I don't need it. But to disable it now, I must remove the default_config integration and keep track of all the default integrations myself. I've done this in the past, and it resulted in me missing out on a lot of new features in new Home Assistant releases. 😄
I'm creating this PR to get some feedback. I'll add docs & tests if you like my suggestion!
## Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
- Original pr in which is based this one: Add exclude option to default_config #57871
- This PR fixes or closes issue: fixes DHCP discovery spamming DNS PTR requests in Docker #57378
- This PR is related to issue: DHCP discovery spamming DNS PTR requests in Docker #57378
- Link to documentation pull request:
## Checklist
- [x] The code change is tested and works locally.
- [x] Local tests pass. **Your PR cannot be merged unless tests pass**
- [x] There is no commented out code in this PR.
- [x] I have followed the [development checklist][dev-checklist]
- [x] The code has been formatted using Black (`black --fast homeassistant tests`)
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [x] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [x] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [x] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [x] Untested files have been added to `.coveragerc`.
The integration reached or maintains the following [Integration Quality Scale][quality-scale]:
- [x] No score or internal
- [ ] 🥈 Silver
- [ ] 🥇 Gold
- [ ] 🏆 Platinum
<!--
This project is very active and we have a high turnover of pull requests.
Unfortunately, the number of incoming pull requests is higher than what our
reviewers can review and merge so there is a long backlog of pull requests
waiting for review. You can help here!
By reviewing another pull request, you will help raise the code quality of
that pull request and the final review will be faster. This way the general
pace of pull request reviews will go up and your wait time will go down.
When picking a pull request to review, try to choose one that hasn't yet
been reviewed.
Thanks for helping out!
-->
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone
<!--
Thank you for contributing <3
Below, some useful links you could explore:
-->
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
6 Likes
bdr9
(Brandon Rothweiler)
February 7, 2022, 5:49pm
138
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).
home-assistant:dev
← daneget:dev
opened 10:55PM - 16 Dec 21 UTC
## Proposed change
The default_config integration enables a set of default inte… grations. Each integration in this set can still be configured by the user by simply adding it after default_config. For example:
default_config:
automation:
# override config here
So while it's still possible to change configuration for each default integration, it's currently not possible to disable any of the default integrations.
This could be useful, for example I'm having an issue with the dhcp integration in Docker. I don't need it. But to disable it now, I must remove the default_config integration and keep track of all the default integrations myself. I've done this in the past, and it resulted in me missing out on a lot of new features in new Home Assistant releases. 😄
I'm creating this PR to get some feedback. I'll add docs & tests if you like my suggestion!
## Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
- Original pr in which is based this one: Add exclude option to default_config #57871
- This PR fixes or closes issue: fixes DHCP discovery spamming DNS PTR requests in Docker #57378
- This PR is related to issue: DHCP discovery spamming DNS PTR requests in Docker #57378
- Link to documentation pull request:
## Checklist
- [x] The code change is tested and works locally.
- [x] Local tests pass. **Your PR cannot be merged unless tests pass**
- [x] There is no commented out code in this PR.
- [x] I have followed the [development checklist][dev-checklist]
- [x] The code has been formatted using Black (`black --fast homeassistant tests`)
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [x] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [x] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [x] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [x] Untested files have been added to `.coveragerc`.
The integration reached or maintains the following [Integration Quality Scale][quality-scale]:
- [x] No score or internal
- [ ] 🥈 Silver
- [ ] 🥇 Gold
- [ ] 🏆 Platinum
<!--
This project is very active and we have a high turnover of pull requests.
Unfortunately, the number of incoming pull requests is higher than what our
reviewers can review and merge so there is a long backlog of pull requests
waiting for review. You can help here!
By reviewing another pull request, you will help raise the code quality of
that pull request and the final review will be faster. This way the general
pace of pull request reviews will go up and your wait time will go down.
When picking a pull request to review, try to choose one that hasn't yet
been reviewed.
Thanks for helping out!
-->
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone
<!--
Thank you for contributing <3
Below, some useful links you could explore:
-->
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
2 Likes
Hypfer
February 7, 2022, 6:13pm
139
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.
eddyg
(Eddy G)
February 7, 2022, 6:36pm
140
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.