Are you sure that the bug has been reported and found? You may be the first. In open source communities, people who have issues will bring this up with the developers so they can fix the problem.
Yes, sometimes it not ideal when you run into things like this. You’ve been in software for 40 years, memory leaks are always the hardest to reproduce, find, and fix. You should know that. We are just people here, getting overly upset about mistakes like bugs is not the way to handle situations.
default_config is just a set of defaults. That’s it. It’s what they think beginners should use. It’s suggested to move away from default_config if you want to deviate from the defaults. Just like you would in any software.
I’m generally curious because I see this thrown around all the time with default_config. How is copying and pasting configuration names provided by default config hard? It may be time consuming, but it’s not hard.
It it was about copying once and forget, it wouldn’t be problem. But it’s not that the case.
By overriding defaults you loose default settings for components you don’t want to touch (incl future ones). In result defaults changed by developers in future will be not automatically reflected in your defaults (see recent addition input_button).
To answer on your question: overriding defaults is inefficient because require constant monitoring of default config content on github (or in changelog), in order to add new components when they come. In fact clicking 200 times on Ignore Shelly component is more efficient than tracking potential default_config changes infinitely.
Why is it so hard to understand the difference between ability of disabling single component and overriding system defaults? Not sure you missing this point or just rejecting it intentionally. It’s fair to treat your proposal as a workaround. But not as a solution!
I completely understand. That’s what this comment is referring to
That’s the yearly overhead cost of managing default_config yourself. And that number is very forgiving. In reality, for someone who manages default_config, that 20 minutes 2x a year is literally 1 minute of me adding energy: to my system when helping someone else on the forums (and the additional minute to remove it again).
So yes, I understand.
What I don’t understand is the amount of effort put into making posts about a feature when you can take that same amount of time and apply it to solving the problem.
It’s mind boggling how anyone can sit, take hours to make posts about their displeasure instead of applying that time to rectifying the situation.
change which adds future effort (whatever amount) cannot be called an improvement by definition. Actually it’s opposite.
your math takes number of changes into account. But you forget about number of look-ups into changelogs… It’s ok for someone who upgrades system 2-times a year. For users who updates with every version it means tents of lookups a year *). Then multiply it by number of people who would go for that.
As I said. It’s good as (short-term) workaround. Existing workaround doesn’t mean lower interest for requested feature.
*) I know you can say they have to look at changelog anyway. My answer is: no, they don’t. Adding feature which adds hard dependency on reading changelogs nor checking diffs in github is more than suboptimal.
You know what… This is called user feedback. Be happy that anyone still do. Without that no software is going forward.
What boggling me is why people like you spend so much time arguing against features which would never impact them.
There’s feedback, and then there’s beating a dead horse.
I’m not arguing against any features. I enjoy new features and new ways to do things.
The developers have made it clear that they have no intentions of changing default_config. Ever. I’m just telling you that, I’ve told you that a month ago when they made that clear in the PR. I eluded to that 2 years ago when you first brought this up through the feature request. I don’t know how else I can make it clear.
Anyways, the feedback has been heard and the decision was made (not by me). So, the question is… Will you continue this for years to come or will you use the tools that the devs have supplied?
Good argument to not use default_config.
If I still used it and not checked the history for this thread, I would have wondered why updater would have suddenly disapeared in 2022.3
But the OP is not about changing default config. OP is about option to disable selected integrations.
The way of doing it through default config is often proposed by devs and by you (which is kinda in opposition to devs intention).
I don’t want to make changes to default_config neither. I want to have option to disable integration. What is not clear in it?
I respect and appreciate the development team for their great effort on HA. I did post a bug report on this issue. I spend well over 60 hours tracking down the issue. My post here are about product management. I’m simply looking on influencing things towards what I believe would be a product improvement. It seems to me a lot of development effort over the last year was expended to get people out of yaml. Seems like a good thing. So my solution for a simple approach would be to include modification of default config in the web interface. So with a simple check box I could disable items I don’t desire. The interface could provide notification if I disabling a depend integration. Any integration included in default config that was fundamental to the correct operation of the system would not be available for disabling. If a user could disable items from default config in the GUI then when new integrations were added into default config they would be easily seen in the web interface. No yaml editing required. The user wouldn’t be disabling default config, so the user would be tracking with new items the development team felt should be included in a default system. Anything not required for a MVP could be disable without diverting too far from the path put forth by the development team. Hopefully the product management input is useful.
I know it has been a long time since this post was originally started. Sorry for dredging up old requests, but I have need to do EXACTLY as the OP has asked.
One of my Integrations is Shark IQ. Every 24 hours, it goes unavailable. The only solution I have to restore it currently is to DISABLE the integration, then ENABLE it again. If this happened only a few times a year, I would deal with it, but… every morning? NOPE, thus I would like to find a simple programmatic solution to disable and enable the integration automatically. I wouldn’t mind doing it in Node-Red if that option existed, but it’s not there either. So, anyone have a solution that doesn’t open another can of worms?
I also need this. Gree Climate integration has a bug that loses the connection once a day. Nothing (reload integration etc) works but disabling/enabling the integration. Something like a python script integration that is able to call HA functions direcly should do the trick.
Looking forward to this approach if someone knows the heart of the system.
This is to work around bugs in an integration. I also need to insert a delay in between the time the integration is disabled and the time it is enabled again.
homeassistant.reload_config_entry does not allow for a delay.
I have a similar use case. I have certain entities that are behind a switch.
My idea is to automate and try to load those entities when the switch is on, and disable when the switch is off.
As an example, i have my 3d printer behind a switch, so when HA starts, it will try to search for the octoprint integration which wont be available unless the 3d printer switch is on.
Any idea ?
Being late for sure but I thouhgt to give it a try. I can enable/disable an integration programmatistically by just changing “disabled_by” property in core.config_entries file. I run ha on docker on a raspberryPi 4 and I built a react+nodejs app from which I send a request to node server and change that property by altering the file and restarting homeassistant just after change
