Support commands and broadcast to Google Assistant

[tronikos]

Proposed change

Allow sending commands and broadcast messages to Google Assistant.

• Sending commands is useful to control devices supported by Google Assistant but not Home Assistant.
• Broadcasting messages is useful to not interrupt music playback. Broadcast service is setup as a notify service to be able to use it in alerts etc. It optionally supports targets (Google Assistant currently seems to only support rooms as targets).

Requirements for this to work:

• Enable Google Assistant API for your project similar to how Enable Device Sync enables HomeGraph API.
• Have service_account in the config. Not needed if Enable Device Sync section from the documentation has already been done.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hi tronikos

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[home-assistant]

Hey there @home-assistant/cloud, mind taking a look at this pull request as it has been labeled with an integration (google_assistant) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of google_assistant can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Change the title of the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign google_assistant Removes the current integration label and assignees on the issue, add the integration domain after the command.

[elupus]

I looked at the lib, and given that it is very small and we generally have all google requests directly in home assistant i think we should do that here too. I will check internally.

[elupus]

Also. I think this is part of Conversational Actions which google is removing in 2023?
https://developers.google.com/assistant/sdk

[tronikos]

Sure let me know if I should move the code from the library here. I did it in a separate library per the requirement in the docs. What's the advantage of having it here? No this doesn't use conversational actions. https://developers.google.com/assistant/ca-sunset#how_do_i_know_if_my_action_is_a_conversational_action

[balloob]

Feels like this should a new integration. It’s not dealing with the smart home messages but with a different api. Yes, the smart home integration shouldn’t have been called Google Assistant maybe, but that doesn’t mean we should put it all in one integration now

[tronikos]

I actually started coding this as a new integration but I realized it would cause a lot of user confusion named similar to the existing one and having the same logo/icon. If everyone agrees this should be a new integration, any name suggestions?

[elupus]

It seem to be based on the google assistsnt sdk, so maybe just that?

[tronikos]

There is already Home Assistant Add-on: Google Assistant SDK so I worry about user confusion. I can start with that name and discuss it in the separate pull request I'll prepare.

[elupus]

Ps. Keep your lib for now if we move this to a new integration.

[dshokouhi]

Personally speaking to any user Google Assistant will always be Google Assistant to them. They won't really care about Smart Home API or broadcasting because to them they all interface to Google Assistant, one may ask it to do something like turn on a light and another may want it to alert someone. To a user they still use the same command "Hey google turn on the light" "hey google broadcast to living room home I am coming home". So from an end user perspective it makes total sense to keep them as the same integration just a new feature.

I understand the need to separate it code wise as it does use a different API but at some point we should take a step back and look at the bigger picture from an end to end perspective. Does Google separate these features from their end user and keep it as 2 different products? Maybe internally but definitely not to the user who just sees the product as a whole, Google Assistant.

[tronikos]

Well said. Who makes the final call here? In the meantime I'm working on the alternative approach, creating a google_assistant_sdk integration, so you can chose the best option among the two.

[balloob]

It should be a new integration. Frontend concerns don't drive backend architecture. We have brands to group integrations.

[tronikos]

#82328 adds the new integration. Feel free to close this.