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… 
Just for people who also land here on google, what you have to do if you follow through with disabling the default_config:
default_config:#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.
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.