Wait, what just happened? was it a FR and I missed it or did it get changed? 
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.
I moved it.
2 Likes
Hi @tom_l, thanks for your feedback. You are correct, for a computer literate person that is not a completely impossible task, especially if it were possible to copy and paste them.
However, that is not as user-friendly a solution as a checkbox, nor as respectful of choice as a plugin. Much of the work around Home Assistant in the last year has been in making it easier to use for people who aren’t computer literate. Requiring an under-the-hood edit for something that is currently optional speaks to intent.
This issue, for me, speaks both to the technology that is in Assist, and the kind of decision making that leads it not to be optional. While it requires manual configuration to remove it, it cannot be described with honesty as “optional.”
1 Like
@DeeBeeKay I agree with you completely. Having this on by default goes completely against what I understand to be the fundamental goal of Home Assistant to be ‘local first and by default’.
@tom_l I respectfully disagree with your statement.
I’m going leave this open but is essentially a duplicate of this:
Current official position on the matter: https://github.com/home-assistant/core/pull/62139#issuecomment-1030845314
1 Like
Hi @tom_l, thank you for leaving this open. I can certainly see why the two are connected: the issue you linked would provide an easier - though still not convenient - way for a user to disable Assist, and would certainly satisfy my personal anxiety around this.
But here is why I still don’t feel like that’s a good solution from a philosophical standpoint.
If HA cannot run without Assist enabled, then Assist is core functionality. If it can, then Assist is not core.
I would like to hear the case for why Assist is core. If it is not core, then it’s adoption should not be mandatory, but should preferably be as easy a choice to make as choosing not to install a plugin.
I regret that this is a principle issue for me.
If it truly is trivial to disable Assist without being saddled with manual admin for the foreseeable future, I would appreciate a page in the documentation with example code for how to do it.
Thank you for continuing the conversation.
EDIT: from reading the thread you linked to, editing default config will not currently be allowed
That is sidestepping the issue. This is not about how to ‘take control’ of the default_config (although I too disagree that this ‘really isn’t that hard’. It is hard. The issue is about whether the Assist feature should be in the default_config in the first place, which I emphatically agree with OP that it should not. The Assist feature should be an explicitly optional feature preferably not even installed by default, let alone enabled by default.
2 Likes
No, that’s not how it works. Most of integrations in default config Home Assistant can run quite happily without.
Hi @tom_l, I understand you to be saying that Assist is not core functionality, which is a relief to me. Thank you for clarifying that.
It is a core integration but Home Assistant can run fine without it, just like most of the other integrations in default_config. For example I don’t have counters installed or enabled because I don’t use them. Yet counters are a core integration.
Core: released/updated along with monthly Home Assistant updates. Maintained by the Nabu Casa development team and volunteers.
Third Party: released/updated at any time. Maintained by anyone.
1 Like
@tom_l Thank you for clarifying, it’s a linguistic issue around our understandings of the word “core”.
I mean it in the sense of, fundamental to operation, but you’ve explained that Home Assistant uses it differently.
What word would do you feel would describe a component that is optional - one without which the system’s operation would not be affected? If we agree to use “optional”, then the opposite would be “mandatory”.
So a rephrasing of my question would be, I would like to hear the case for why Assist is not optional.
I understand you to be saying it is currently as turn-offable as any section of the config, and I will look into that. But for the time being I will hold back on updating in the hopes that Assist becomes optional to a layman.
I could see it being one of the questions you’re asking during initial setup: would you like to use Assist to control your Home Assistant installation? Because @frenck is right about one thing: it will be a significant game changer.
To make it opt in it would be as easy for the devs to just remove it from default_config.
then the user could add it or not as they see fit.
3 Likes
I’m not sure what everybody is worried about.
HA doesn’t have any ears jet, so even if the feature is activated it doesn’t do much in relation to privacy.
And unless you actively add some it won’t grow ears either.
1 Like
It’s a new feature and the creator wants their average user base to enjoy it. I think that’s perfectly reasonable and no need for a deep explanation. The developers already offer a way for advanced users like yourself to disable features. The default config feature is designed for average users to enjoy new features without changing anything. If you don’t fit into that category you should then take control of your configuration.
2 Likes
You’re missing the main point which is whether it should be disabled by default. My vote is for disabled.
I am a long time HA user and to be honest I didn’t even know the default config existed until they added the energy feature and I wondered why I couldn’t see it! My point is that having the required keys in your configuration.yaml isn’t that onerous and indeed allows you to unload any of the integrations you don’t actually use. You can keep an eye on what is included (beside watching the release notes) by visiting this page Default Config - Home Assistant
Hello, I’m sorry it’s taken me so long to respond, I’m in a country that is having significant problems with its power grid.
On review, framing this issue in terms of the benefits and risks of language recognition technology is the wrong way to approach this; as far as that goes, I think it’s sufficient to acknowledge that the tech is cool, but that privacy issues do exist.
A simplified form of the issue is, if saying no requires giving up the functional benefits of automatic configuration, then it’s not a choice. This should not be on by default, any more than any “user choice” feature should be.
The following statement is true, and should also make it clear how unnecessary this thread is.
`“Assist is an optional, non-critical feature that make Home Assistant even easier to use. You can choose not to use it, but in that case you must be computer literate and willing to perform manual edits every time a new version breaks something.”
Is it necessary to argue further? I hope it’s not, because this is an issue that doesn’t need to exist.
Anyone claiming that manual config is easy has not been using Home Assistant long enough to remember what it was like when the default config didn’t exist. The YouTube channels of people like The Hookup, Dr ZZz, and Bruh exist because while using a text editor is easy, editing YAML isn’t.
Home Assistant is only accessible to people that aren’t computer literate because default config now exists. Requiring end users to become computer literate in response to an arbitrary decision to enable a thing, isn’t a good choice, and doesn’t respect how far the platform has come.
I admire @frenck a great deal, and would value a statement from him on this issue. I would also like to reiterate that this isn’t about the value of Assist, or, I’d prefer it not to be. It’s about turning on features by default without making it possible to disable them easily in the Settings menu.
If it isn’t easy for end users to turn it off, you haven’t given them a choice at all.
2 Likes
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.
6 Likes