Having searched around this forum a bit, it’s pretty clear this is never going to happen even if every single HA user asked for it.
@tom_l is on a rampage to close all feature requests related to customisation of default config and merges them all into this feature request (which he has also archived to pretend it’s not something people want):
Closed all these…
If you are going to passively aggressively abuse the mods at least get your facts right.
That is a WTH topic not a feature request. The whole WTH category was archived once the month was over, not just that topic - and it was not archived by me.
The reason for closing duplicate feature requests (or WTH posts) and directing people to the first request is to consolidate the votes in one topic rather than having one or two votes split all over the place. I’m actually helping you make the request popular.
Don’t passively aggressively abuse the mods. If you have a legitimate complaint against any of the forum staff please contact the forum admins or one of the other mods instead.
I’m very new to Home Assistant. Installed it yesterday for the first time. Finally made my way to this post wanting this exact feature. Since the developers are not interested in fulfilling this request, I just patched my local instance like this:
I don’t spend a ton of time in python and certainly don’t grok the entire codebase of HA but throwing a tiny breaker in that respects the config and doesn’t load integrations seems to be working for me locally. Since I won’t change the code base all too often and the patch is pretty tiny, this should work for me good enough.
Hi @Multiply9378, sorry it’s taken me so long to respond.
Your solution is incredibly elegant, and I thank you for coming up with it. I wish I had any kind of competency to implement it myself, because quite frankly it is bizarre that this isn’t a thing yet.
I am genuinely beginning to question why this situation exists. I do not believe it is by malicious design, but based on what it looks like from the outside, it really does feel like there’s a vested interest in this not being easy for the average user to do.
I still have not heard an argument for why the status quo exists, when it is so objectively broken.
Anyway, thank you again. I hope your simple solution is merged.
If it is, in fact, easy for a person like me to implement, would you mind posting a tutorial?
In short I believe the thinking is this: You can’t have respect for the user’s choice to define their own system if things keep being added automatically.
Default config loads a set of commonly used integrations for users that are new to home assistant or simply don’t want to bother configuring this sort of thing. It is also a way for the devs to automatically load new integrations into users configurations when they become available with new releases.
If you want control over this you remove default config, add the integrations you do want, and keep an eye on release notes for any new integrations you may like to add.
That second part is not onerous. It took me less than a minute to do originally and every month 5 minutes of reading release notes.
Excluding instead of including is simply a different way of doing this. However it has the disadvantage of no longer respecting the user’s choice to have control over their loaded integrations. As new integrations will be added automatically with new releases, requiring the user to explicitly exclude them.
i.e. opt-in has become opt-out if using excludes.
opt-out vs opt-in seems a different discussion than the main point of this topic: make it eay to opt out.
Why not a feature toggle? I like the idea of Android phones, where I can simple choose to switch off the newly added features/apps that send and sell my life to Samsung.
Hi @tom_l,
As always, I appreciate your willingness to engage. Thank you for your response.
I’ll quickly summarise what I want to say, and then give you a longer version if you have time.
Short version: It is possible to configure most everything via the GUI, with the notable exception of consent. Until issues of consent can be addressed via the GUI, every statement made about Home Assistant respecting user choice is objectively false.
Long version:
You wrote a thing that wasn’t true. You were reporting it, not claiming it was true yourself, but it wasn’t true. You said:
In short I believe the thinking is this: You can’t have respect for the user’s choice to define their own system if things keep being added automatically.
But things are added automatically all the time, with almost every release. Since that base statement is demonstrably not true (again, you’re reporting a statement, you didn’t say that this was your thinking), I’m afraid that nothing built on it can be true either.
This puts me in an exceedingly difficult position, because of how passionately I disagree with you - not generally, but specifically your last past. I’m going to try not to use emotive language; please excuse me if I slip, because this is very important to me.
I am a farmer in the third world, and I am old. I know what I know about technology out of desperation and necessity, not aptitude. I am in no way “good with computers”. I am a person with limited resources, a strong survival instinct, and access to YouTube.
Home Assistant was the gateway for me. Through Home Assistant, I discovered ESPHome, and realised that I could make things - real, complex things, that could work on the farm - without having to learn to write code, which had always been the barrier for me. The system enabled me to do things I couldn’t have done if I had had to be much more computer literate than I am.
I used HA to survive the last seven years of drought (mercifully ended in 2022) because, without getting into a truck and driving everywhere, I was able to monitor precisely how long it took for each borehole to run dry, and how long to refill, because it was up on a Lovelace dashboard.
That interface let me find the sweet spot for each pump, and my friend, I finessed that line. Home Assistant’s dashboard found me 12,000 litres a day I didn’t have access to before, and that matters when you need 200,000 day, and only have 40,000.
You don’t understand; how could you? When a person has such little water that they have to choose which parts of their land they will allow to die, what kind of impact do you think a technology like this has; one that so drastically lowers the barrier to entry?
That’s what HA is to me. It opened a door to a world I had only seen on TV. My house is like Star Trek now. I use HA and TTS to wake me with a voice warning in the night if an air bubble is forming in the pipe (can cause pump to burn), or if the chicken incubators are at risk because batteries are running low and I need to unplug stuff. Eventually I’ll own enough relays for it to all happen completely automatically.
In the beginning, it was hard, because default config didn’t exist, and things kept breaking every update, and then I’d have to deal with my wife telling me this was stupid, and I’d have to go watch Dr Zzs to find out how to fix it this time.
And then default config happened. Suddenly, it was all livable. She even gets confused sometimes when she goes into the guest bedroom and the lights don’t go on automatically (no tech in there).
It’s become a magic trick. I don’t even know what happens in the config anymore, not that I was particularly savvy in the yaml to begin with.
I’m telling you this because you persist in stating that it’s not onerous to expect people like me to manage a config file manually. I want you to understand that you are being tone-deaf to the fact that a big chunk of the user base cannot do the thing you think is trivial, because we didn’t grow up with this stuff. I learn, but it is HARD. Home Assistant is accessible to me because so much work has been done to make it easy.
I think what is most upsetting here is that all of us are aware that if Assist had not been turned on by default, we wouldn’t be having this conversation at all.
Instead, we’re having to look at a completely separate issue that is essentially a strawman, because the relevant discussion should be about the ethics of forcing language recognition systems onto people that don’t want them, not giving them an easy opt-out, and then behaving as if their failure to opt out represents consent.
It doesn’t mean we consent. It means we’re the people the system is built for - the ones that need the GUI. While it remains possible to configure everything except consent via the GUI, user consent is being evaded, not respected.
As a result, here we are having arguments about default config. It belittles all of us.
If I don’t accept Assist, I am being told that I’ll need to go back to what HA was before it became usable by the general public. I will need to learn to manually configure 40ish modules that I don’t understand, and update those every few weeks. I am being told that, as if it is a sane thing to say.
That is not respecting my choice. That is punishing me for disagreeing with an invasive technology that is highly topical in the world at present, and it is disingenuous to imply otherwise, because to ignore it requires cognitive dissonance.
Even if I had the aptitude, I do not have the time; I am carrying more families than my own.
I wish you well. I hope we continue talking. I hope the platform demonstrates its stated commitment to user choice by making these choices as easy as claimed. How unnecessary all of this would be then!
Hi @pwdonline
Why not a feature toggle?
That is a very, very relevant question. I would love to read an argument either on why such a GUI page would be impossible to implement, or would be too disrespectful of user choice.
The fact such a page still doesn’t exist is what makes the claim that opting out is easy so hard to swallow.
Not really, that was meant to indicate it was my opinion. That is what I think the reasoning is.
Sure, new integrations are added with every release, but they are only added to the core, they are not added to your configuration, unless included in default config or you choose to add them. That’s where the choice lies.
they are not added to your configuration, unless included in default config or you choose to add them.
Except, we all use Default Config, so there is no “your config” until something like Assist necessitates one. You are correct from a semantic perspective only, and have not engaged with the points I raised.
You are, of course, under no obligation to do so, but it would be disappointing, because it would rather support the position others have stated, here and elsewhere, that this is not a conversation you want to have.
I’m not certain what the exact reason for the request is. Is having it running even though you don’t use it negatively impacting the performance of your system or is it a desire to have the old user interface look?
No ‘we’ don’t.
I’ve pretty much explained all I understand about the reasoning for this (in my non developer opinion). I don’t have anything else to add.
No, sir. You have corrected my amateur use of your specialist jargon, for which correction I do thank you, but you have in no way addressed the substance of what I wrote.
I respectfully ask that you try again, particularly as you have marked this thread Solved without doing so. As a reminder, you said the following:
Taking control instead of using default_config really isn’t that hard. It amounts to writing (up to) 39 words in your configuration.yaml file and in future checking the release notes for new integrations you may want to add.
To claim that this statement is true is to argue that Default Config was unnecassary to begin with, because managing config, in your own words, “really isn’t that hard”. The mere existence of Default Config disproves your statement.
I await your further response.
I have already addressed that.
Apologies for my slow reply; it is peak picking season here, and I am more often on the land than at home. Avocado theft is very high, you see, and small farmers like me have to patrol at night too, or we lose too much of the harvest.
I regret that you have not addressed the issue, at all. You have instead used gatekeeping to attempt to define your way around it.
Those who don’t want to bother? I object, not just because of the rudeness of the implication, but because of the manner in which you continue to dismiss people of my competency level rather than engaging honestly.
I am not a new user; you have known me for years.
I am not a user that “doesn’t want to bother” learning how to manually configure and update 39 modules; I am literally not competent to do so.
I am a normal, everyday user, who relies on Default Config precisely because of how disastrous manual configuration is.
I request confirmation that you are stating the official Home Assistant position, because it doesn’t take a new user to see that this has become an ethics consideration.
I await your further response.
First I’ll say that I completely agree that there should be an easy way for users to opt-out of any integration from default_config. HA has become less about users controlling their own systems (a la the old Android way) and more about HA itself taking control of users systems (a la Apple).
And I’m not trying to up- or down-play your technical abilities.
But I think you may be overstating how difficult it is to manually configure and maintain the things included in default_config.
As far as I know every integration automatically added under the default_config umbrella is only one line of YAML code to activate it.
for example to activate the UI editor for input booleans you just need to put input_boolean: in the configuration.yaml. that’s it.
the only exceptions to that (that I can think of) are automations, scripts and scenes. And those only require an !include statement so it’s still only one line of code.
the only time anything else is needed is if there are further configuration options required. But if that was the case then you would still need to add those config changes even if you already use default_config anyway.
I just go here to see what is currently included in default_config if something is mentioned in the release notes (or every few releases in case I miss something).
then I just copy the list into my configuration.yaml and either comment or un-comment an item based on if I want it or not.
It really literally only takes a few minutes every few months to keep it up to date manually. I’ve been doing it for years like this ever since default_config was released and as far as I know I haven’t missed out on anything.
And it’s not the end of the world if you forget to add something. HA won’t stop working if you don’t add the latest integration added to default_config.
If you seem to be missing an option then pop over to the link I posted and check to make sure your list of integrations matches the list there.
I’m not trying to take away from your request/concerns but only trying to hopefully keep things in perspective.
tom isn’t completely wrong when he says that manually maintaining default_config isn’t onerous.
But I also feel there should definitely be an easier way to opt out of integrations even if the user chooses to use default config.
but to be real you know that will never happen, right? Once a decision has been made by the HA devs there has only been once or twice in the history of HA that a reversal has happened. The only one I know of is the reversal of the deprecation of the Supervised install. and that was only because of the HUGE uproar that the announcement caused.
There is nowhere near the outrage required about this for them to even give a second thought about it.
I also agree that there should be a GUI for maintaining which integrations you want - instead of relying on default config.
Failing that, I think it would be useful to be able to specify within default config anything you want left out. That is, you can specify explicitly what you want or you can specify by exception what you don’t want.
Having said that, I think there are so many hurdles to jump to get Assist to work peoperly that it isn’t something that will be easily misused.
To stop Assist being used you could do Any or some of these things:
You can install GitHub - tronikos/default_config_disabler: Disables components from Home Assistant's default_config that allows you to exclude any integrations you don’t want to be part in the default_config. It’s easier than applying the patch in the post #23 every time Home Assistant updates. It’s also easier than omitting default_config: and having to manage the dependencies yourself.
That feature is absolutely necessary (especially for “assist”). I do not understand, why the developers are so opposed…
Hi @rosch100, I thank you for bringing this thread back to my attention, I’d quite forgotten it. It’s still marked Solved, but I think it deserves an ending, for anyone that finds it via search (it’s currently the 4th link if you google "How to disable Assist in Home Assistant).
I’ve considered many ways to address this, but I’ve come to the conclusion that the main conversation shouldn’t happen on this platform.
I have a deep love for the ESPHome community, who have had such a profound impact on our farm over the years of drought, and the farms of those I was able to help with what I learned via a post I made there some years ago, which continues to remain active: https://community.home-assistant.io/t/using-esphome-to-build-a-water-flow-rate-meter/
People often aren’t aware of how a trivial action like a thread reply can impact the lives of others, but I want you to know that there are people out here whose livelihoods were saved thanks to your kindness. And in recognition of that kindness, I’ll just explain the core issue, in a way that’s easy to understand, for any noob user who finds this thread via search.
It comes down to what users understand by the word “consent”, and how that differs from what the devs understand it to mean.
In my country, we have a huge problem with very young children being exposed to pornography via the chat apps on their devices. To address this, educators are explaining to children what “consent” means, as a moral tool that a child can use to know whether, for example, a picture of a naked classmate is a thing they should forward to others.
This is the video that is being used by educators to explain Consent to children as young as five. It would be helpful if you would watch it; it’s two minutes long, and extremely funny: https://www.youtube.com/watch?v=pZwvrxVavnQ
So, I’m now going to explain what the dev’s current position on user consent is, using the terminology in this video.
I invited you into my home because your tea was amazing. I said “Yes!” to the tea, and we had tea for years. I let you live in my home because of how good the tea was.
But then you added something to the tea that wasn’t nice. You didn’t ask if you could.
You liked the thing, but I didn’t.
I said, “Hey, please don’t do that. The tea was good before, but now you’ve changed it. Please stop making me drink the new tea.”
And you said, “Learn how to make me stop.”
See?
I’m now addressing the devs, @frenck & co.
You did a thing without asking, and when I asked you to stop, you didn’t. I wonder whose call that was?
There is a saying I believe deeply: Never ascribe to malice that which can be adequately explained by ignorance.
Perhaps you didn’t understand what you were doing, or how wrong your response was. That’s fair - I screw up all the time.
But you’re not ignorant anymore.
This thread is now a canary.