Move Google Assistant entity config out of customize

[balloob]

Description:

Google Assistant was using customize to store entity config. This is not allowed and is being addressed in this PR.

This PR moves the entity config to be defined as part of the config for either google_assistant or cloud.

CC @philk

Related issue (if applicable): #10732 (Alexa done in #11461)

Breaking Change
Google Assistant is no longer configured via customize but instead has its configuration under the google_assistant entry in your configuration.yaml. The attributes will no longer have to be prefixed with google_assistant_ either.

Old option	New option
google_assistant	expose
aliases	aliases
google_assistant_name	name
google_assistant_type	type

Before:

homeassistant:
  customize:
    switch.kitchen:
      google_assistant: false
      google_assistant_name: nice lights
      google_assistant_type: light
      aliases:
        - roof lights

google_assistant:

After:

google_assistant:
  entity_config:
    switch.kitchen:
      expose: false
      alias: roof lights
      name: nice lights
      type: light

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>

Example entry for configuration.yaml (if applicable):

Checklist:

• The code change is tested and works locally.

If the code does not interact with devices:

• Local tests with tox run successfully. Your PR cannot be merged unless tests pass
• Tests have been added to verify that the new code works.

[philk]

I slightly on the fence about the entity_config change but reading through that issue you all have put way more thought into it than I have so I'm fine with that. It's probably going to be somewhat painful though. Not the place for a feature request but I'd really like to be able to use the same filter across both Alexa and Assistant (without resorting to yaml tricks).

[philk]

I'd like to see it remain as "aliases" to make it clear it's an array. Also your doc example should be an array instead of a single value (not sure if that gets auto converted by something but the doc should at least show it can be an array)

[balloob]

Ok

[balloob]

(and yes, a single value will be converted to a list)

[balloob]

I went initially for CONF_ALIAS because it's an existing option. However, you're right that it is confusing that it is not plural.

[philk]

I noticed this over on the Alexa PR, the rename from Assistant to Actions. What's the motivation there? I ask because I'd originally written this as actions and went with assistant because it felt like that matches what end users will expect the component to be named (only devs see it as Actions on Google).

(Also if I wanted to nitpick I'd say all the assistant->actions renames should be in this PR)

[balloob]

That's only within the Cloud component. I did not want to change the component name. I called it that way because that seems to be the product name that Google gave their side.

[balloob]

The Cloud component will offer the same filters between both Alexa and Google. I didn't want to introduce a breaking config change to the google_assistant component.

[philk]

👍

[balloob]

Will work on an update to the docs today.

[ChristopherLMiller]

I'd like to know how this breaking change is better than it was with the customize method. ll of my packages contain one purpose which is usually just a single entity and anything that acts upon that object such as automations and naming. by changing this I can no longer have the google assistant name for an entity be changed right there but in another package where i define google_assistant. This means that now if i decide to name the light differently i have to go to one package to update the name of the object and all instance of it for within my HASS server which includes alexa through haaska to now having to hunt down another file JUST TO RENAME THE OBJECT for one service......

this makes no sense to me. The above AFTER code must be able to be in each package file or this is not a solution at all to an "issue"

EDIT: i've included an example of an entity from my config to show what i'm talking about.
https://github.com/moose51789/home-assistant-config/blob/master/packages/lights/modeling_desk.yaml

[MartinHjelmare]

Please don't use closed PRs for discussion. Use the forum or discord.

[rofrantz]

Without trying to be a smartass or trying to offend anyone:

1. Devs read pr's to see what will "hit" them; endusers use forums, after pr's are merged; @moose51789 is probably trying to trigger a warning before this hits us

2. I know that "a decision has already been taken" and all main devs praise the fact that it will be easier to reload ha without restart (i know this because i also watch & read pr, NOT forums) but think also at the price we pay for this and I think that moose51789 has a point here;

3. This is history repeating: the same (bad imho) thing happend also with zwave entity ids where we had 3-4 breaking changes and if i'm not mistaking there's now a 4th by the man itself (ballob). And again all those changes for easier custmization from ui config panel and harder and stupider automation configs for devs like the real case example that moose51789 gave

[arsaboo]

Just echoing what @MartinHjelmare said....let us not use closed PRs for discussion.

Devs have already indicated that packages will not be fully integrated (as it is difficult to reload them on runtime and the additional complexity they bring in). It is a small price to be paid for ease of long-term maintenance of the project. Lot of thought goes in before making such breaking changes, as it is bound to upset some users. But, please understand the devs situation, who are responsible for maintaining the long-term health of the project.

I, for one, like the fact that the entities can be customized where they are defined and we don't have to use customize to scatter our configs.

[ChristopherLMiller]

using the forum is a joke as they are down more than they are working, and i've yet to see a dev on discord to discuss with which is why i addressed it here.

If packages aren't to be supported then the ability to use them needs to be removed entirely from documentation and all as this just divides the community. Power users like packages, why break this? I will not ever use the editors as they have proven to be garbage thus far and i should be able to continue to define my configs as i have been not be forced to put something in one place because someone said this doesn't make sense when it makes perfect sense.

[balloob]

using the forum is a joke as they are down more than they are working

And how have you helped to fix that? Don't complain, help out.

I will not ever use the editors as they have proven to be garbage thus far

And how have you helped to fix that? Don't complain, help out.

i should be able to continue to define my configs as i have been

And how have you helped to fix that? Don't complain, help out.