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?
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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:
- Unexpose all your entities from Assist so that Assist has nothing to work with
- Not have HTTPS access enabled in HA prevents the use of microphones via web browsers
- Not have any connected hardware with microphones or speakers
- Not have a wake word - oh, I forgot, we don’t yet
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.
3 Likes
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.
1 Like
Incidentally, this thread is now the second result if you Google “How to disable Assist in Home Assistant”.
@tom_l, please could you PM me the contact details of someone who’s authorised to speak to media on behalf of Nabu Casa? It makes it easier on the fact checking team if they can go direct.
Hey guys,
I am fairly new to HomeAssistant, and so far I had a great journey.
I must say, that I also actively dislike not having a way to disable the assistant/referalls to the assistant in the gui. I understand, that some money has to be made through home assistant, and HA is absolutely harmless in stuff it tries to make you do, but the whole Assistant thing leaves a sour taste in my mouth, similarly to the first setting category being “Home assistant cloud”.
I respect the fact that you can disable the assistant by changing the yaml, but as previously stated by @DeeBeeKay, it certainly felt nonconsensual, trying to force me to subscribe to a cloud service/make it an auto-opt-in feature.
I also agree, as the previous posters, that I don’t see it being likely to be reverted to an “opt-in”-feature, but I still think it is important to voice my impression. I even took my time to register specifically for that purpose.
I’m sorry, but that is not correct. You don’t automatically opt-in. And neither are you in any way required to be a subscriber.
Honestly, I can’t see where the fuzz is coming from. It is simple, and practically copy&paste, if you don’t want Assist included in your default configuration. The majority of users wants it that way, that’s why it is handled this way.
For the very few, that don’t want it, they can delete that part of the configuration with a piece of code that is inserted in less than one minute.
And let’s not forget, using and enabling Assist does not require any outside subscription, opt-in or whatsoever. With the default config, your Assist is locally enabled. Nothing else. It’s not like you would give your soul out in the open, it’s still only a local assistant, with no costs.
I really can’t see, where anything with this is automatic opt-in. If you want more functionality, you can opt-in, but you don’t have to to use Assist.
Sorry, to say, but that sour taste doesn’t come from HA, that’s for sure. It might have to do something with not enough informed… 
1 Like
Just for people who also land here on google, what you have to do if you follow through with disabling the default_config:
- You need to access the config yamls. You can do that via SSH or via AddOns like the VSCode addon.
- You are interested in the configuration.yaml file.
- You need to comment out/delete the line with
default_config: - You need to go to Default Config - Home Assistant, manually open every link, and see how the integrations have to be loaded. Currently, as of 12.05.2024, I have the following list:
#assist_pipeline:
backup:
bluetooth:
config:
#conversation:
dhcp:
energy:
history:
homeassistant_alerts:
#cloud:
image_upload:
logbook:
media_source:
mobile_app:
my:
ssdp:
stream:
sun:
usb:
webhook:
zeroconf:
I have commented out the assist, conversation and cloud entries, which should in my opinion be opt-in additions. I rebooted the system, and everything works as expected. I will have to watch out for new default changes in the future, I guess.
2 Likes
So you’re asking that the developers create an opt-in to ENABLE those features, instead of the much easier to implement opt-in to use them. I can understand that, I suppose, but where do they draw the line once they start? Should they make them all opt-in?
Landed here after I installed 2024.10.1 update and the log insisted on Detected blocking call to open with args and Detected blocking call to read_text with args on the same file inside the event loop by integration 'conversation'.
I was first looking into “Integrations” in HA UI, but there was no conversation. So I looked into my configuration.yaml if it was not added by some “automation” (as I was pretty sure I never wrote that into the yaml myself), but it was not.
This way I learned about default_config, which is BTW nowhere mentioned in my configuration.yaml either and I am pretty sure it did not exist 7 years ago, when I wrote that file myself.
I have read the whole thread hoping to find a trivial answer to the OP’s question and instead read a bunch of excuses trying to marginalize the topic.
It is important. I want to know which integrations are devs considering “default” (yet not mandatory per the previous definiton) and add them to my config, because I might consider them not “default”.
If I could find the list of those integrations in the GUI and I saw conversation there, I would just disable it (to solve the error I am facing) and move on. And disable all other integrations I never wanted and never asked for.
Is the rule “never add anything to the users configurations for which they did not ask” or “if you do, make it opt-in” difficult to grasp?
And to avoid a misinterpretation, I am not saying “do not add new features”, nor “do not add them to the default config”. But this is an entirely different “default config”. This is a default config created at the time of the installation or the first configuration. Not something silently created and pushed on everybody and used as an excuse to push more dependencies or unwanted features.
if you type “default” into the HA docs website integrations page you get a link to the following:
I am not sure, if you were replying to my post, so just for the record, meanwhile I verified that I am not using default_config (in my configuration.yaml or anywhere else) and made a separate post about the topic here.
yes, I was referring to this statement:
you wouldn’t have a “default_config” entry in your configuration.yaml since you were a user before “default_config” had started being used. It wouldn’t have been added automatically so you would have had to add it manually after that point.
1 Like