I agree with both your recent posts while read together.
To be fair, the times I’ve seen changes made to the default config it’s always been mentioned in the release notes.
If you read this it’ll be clear I don’t like having software that provides me with no benefit being injected into my instance of HA. It’s fine that they mention things in the release notes, but as a user of the system I shouldn’t have to take all features the developers decide to include. If you scan the forum you’ll see people looking for ways to disable auto included features all over the place.
I’ve had shelly devices since I started. At that point shelly didn’t have a good integration. The best way to integrate the devices was via MQTT. I tried the shelly integration that was under development at the time and it didn’t work on my network. MQTT worked so I went with it. At some point the developers decided the shelly integration was ready to be integrated with the auto discovery stuff. So all of my switches showed up with notification and individual integrations on the integrations page. Since this was now part of the main system I figured I’d give the integration a try. Sadly it still doesn’t work on my network, but MQTT still works. The shelly integration tells me about the switches even though they are already working and configured. I don’t need these notifications and integrations, fortunately you can tell the system to ignore the devices. This just hides them, the shelly code still runs. So if the shelly code ends up having and issue I might then have an issue with my system. I don’t need the integration, it doesn’t work for me. Don’t force me to run it on my system. If the developers want to include it then it should be easy me to disable. This doesn’t seem like too much to ask.
The ssdm integration started causing issues on my system just after the first of the year. It’s taken me since then to figure out it was the ssdm integration. My system crashes about ever 3 days with this integration running, as it has a memory leak. This integration is included just like the shelly integration to do discovery. I don’t need it, I don’t want it and forcing me to have it just causes my system to crash. I spend well over 60 hours (one of the reasons for the rant) trying to figure out this issue. An issue caused by a feature I don’t need. If an end user doesn’t need it why force it on them.
I don’t understand why auto discovery is viewed a something that has to be run all the time. Some might see it as a nice feature for a new system you’re trying to set up. However once you get your system set up and working the way you like it you don’t really need full on auto discovery. You know when you add items to your network. A button to do a scan would be better than making the system run scans all the time. Auto discovery provides very little value to the average user with the system up and running. Why does it have to run all the time? The ssdm issue I mentioned above it part of auto discovery. If auto discovery didn’t run all the time it wouldn’t have been an issue.
Got that new energy panel a few versions back. Doesn’t provide any features on my network, but it’s on the my interface why? They could have just mentioned it in the release notes and told me how to enable it if I like. Or better yet when I clicked on the “tell me what’s new on my network” button, the system could have said “You have features on your network that can be integrated with our energy component, do you want to add them?”.
Enough of a rant. I love HA. I’m thankful for all the great work done by all the software developers. I’m just hopeful someone that has the potential to change what is included in the minimal viable product reads this and is influenced.
1 Like
I understood very well what you meant. I don’t categorically disagree with what you’re saying, but things are more nuanced, in my view.
My previous message was specifically addressing your previous message, in particular the bit quoted above (and for good measure, the quote above that from your message before that). To rephrase my previous remark as a question: Did you check the release notes at the time, because every time I’ve seen changes made to default_config I’ve seen it announced?
I’m amazed every time I see a comment like this on the forum as part of a justification. To be brutally honest, if you have that much experience you would realise there can be different views, none of them necessarily wrong, because it depends on what you want to optimise for.
Here’s the thing: You don’t have to. For as long as I’ve been a user of HA (~3 years) it’s been the case that you can remove default_config and specify what you want. Why haven’t you done that, given your views and experience (I’m not being sarcastic; you pointed out the difference between new and experienced users and put yourself in the latter category)?
Also, it’s not like the selection for the default config is somehow ridiculously stupid. You may not like it, but it’s not stupid. Why not lower the barrier to entry, especially if you already have the power to change it later on?
Are you the average user (or an experienced one) and/or can you speak for the average user? Do you have any data to support this? Experience and convenience isn’t mutually exclusive.
And if the devices you want to scan for are asleep? I’m just pointing out it may not exactly be that simple.
From what I remember from the time it was announced, it seemed like a major new development direction for HA. From that point of view it would make sense to then include it as a default.
1 Like
Exactly my case.
For users who have a few devices it might be not an issue. If you have more devices (close to 100 like me) it’s really annoying to click 200 times on each integration. See the screenshot
Even after you do all this clicking, it will clutter the list of ignored integrations. And in worst case you will have to repeat in case you build your HA from scratch (not mentioning you have to ignore every single new device you are adding).
I reported it to github but after some shuffling between developers it has been abandoned. Some time after this reporting ‘disabling integration’ feature had been announced. Unfortunately it doesn’t apply to this case, since every Shelly device is treated like single integration. So ignoring or disabling requires the same rolling effort.
I don’t like to use such an argument. But sometimes it’s required to notify your interlocutor that you really know what you are talking about (in contrary mass of unqualified opinions over there)
Some of them just wrong patterns. And the best developer can to is to avoid bad patterns.
Maintaining default_config on your own just because you want to disable single integration is obviously wrong pattern.
Because once you change default_config you are effectively obliqued to check it with every release.
So instead of making the usage easier, you opting-in for additional, continuous work. As I said: bad pattern.
Mentioned support for PowerManagement is another good example. Particularily I don’t measure a power usage. Don’t have solar panels. It’s not going to change in near future. I don’t need it in main menu. I know I can remove it from the menu… From EACH device SEPARATELY (incl. all users from my house). Are you kidding if you think it’s efficient.
Removing default config fixes all those problems and the only thing you would have missed out on in the last 2 years was the energy panel, which you are complaining about. Remove default config and give up this stupid 3 year argument. I don’t run default config and I have none of these problems the both of you have and the management of default config required me to add energy about 4 months ago. Give it a rest man. It’s not asking a lot and it gives you exactly what you’re looking for. I’m in awe over the stubbornness here.
1 Like
For reference, you can find the integrations enabled by “default_config” at
e.g. nobody needs “cloud” unless they are using NabuCasa.
But for instance disabling zero-conf is far more than disabling unwanted Shelly integration
No, it doesn’t. Please stop insist what is my original need.
You also forgot about input button added recently.
I’m not going to accept any solution which in turn requires additional awareness/actions. We need those feature to save the time, not opoosite.
Disabling zeroconf, ssdp, … prevents HA from auto-discovering stuff, which is the issue at hand, isn’t it?
It doesn’t prevent you to manually configure, e.g., Shelly.
BTW, nowadays, you can ignore auto-discovery per integration via the UI (only for those configured via the UI, iirc, but Shelly is) , which makes this thread a bit moot…
Look at my screenshot in few posts above. Each shelly device is represented as separate integration. You cannot disable whole shelly integration with single click. you have go through every device and each new device you are adding to the system. which renders it pointelss.
not for me. I’m interested at disabling shelly only. Have no objections to other components yet
Yes, which is a self inflicted problem.
If you take all your posts about this (across all the threads) and summate the amount of time you spent on this, it would greatly outweigh the time you could have spent using the provided tools.
The developers have stated that default_config is for defaults, if you want to override the defaults, you configure what you want. It’s that simple.
Hopefully all the shelly icons will remind you daily that you could have solved this in under 10 minutes with maybe 20 minutes 2x a year (to figure out what might have been added).
your post is disrespectful to all users who needs this feature.
If you cannot see the issue with modifying default config then I’m really don’t know what to say.
BTW to cope with shelly I use custom component written by you as a I remember. It’ reports some bugs. to logs but effectively it kills shelly integration so I’m happy.
But it doesnt resolve OP
It’s not disrespectful at all. Stop playing victim and solve your problem by moving away from default_config. It’s not changing, that’s already been made clear in the feature request thread.
Since I’ve been using HA I’ve had two instances where an update has killed my system. The first was a push of supervisor, which updated in the background and resulted in the system being dead when I returned from a trip. I use HA for a home security system. This is not a desirable auto update. Because it’s a security system I don’t want it updating when I’m away from home. The latest was associated with this auto discovery item which has a memory leak. I do look at the release notes. They mention breaking changes, though they don’t provide much detail. I didn’t see anything in the release notes about including a memory leak. If I had I wouldn’t have updated. I’ve used default_config because I believed the developers felt it provided a minimal viable product. It’s clear that’s not the case as there are a number of items that are not required for the system to operate being included in the default load. My experience tells me the team really does need to look at the impact of what they include for the user base. People wishing to have easy control over their system to minimize the software included without becoming an expert should be a consideration. A stable product should be job one.
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.
Two issues:
- 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.