Just wanted to share that I have made a solution for broadcasting message to Google Assistant enabled speakers (tested with Sonos One speakers) from HA (tested with version 2022.4.3).
You basically run embedded Google Assistant in Docker container ismarslomic/google-assistant-broadcast, which exposes REST Api that HA triggers through the RESTful Notification integration.
No interruption of music
No mic or speaker required to run the Docker containers
This looks fantastic!! Is there a way to target specific speakers in the house? ie. I do not want broadcasts going to my office while I am working as I will likely be on the phone. Or, only send a notification to the kitchen speaker.
Good question. Broadcasting is per definition, as I understand, message to all speakers. But like I documented in README.md, Google Assistant documentation says you can target specific devices with text/voice as well.
I’ll get this installed and play with it to see if I can target a speaker or display. Thank you! Also, any plans to make an add-on for this? Would be nice to just run it on my HA Blue instead of my media or game server.
I have none experience with building HA Addons, but I can take a look at it. I have mainly used the core HA integrations and couple of HACS components because of stability, upgrades and maintenance. Im also running HA in docker, so Addons are not available for me, and testing will be little bit harder.
To be honest I think tts integration in HA should support this. Will work more on this solution after easter holidays.
@ismarslomic I could use your solution for a couple of weeks but I’ve got an authentication required error. I regenerated the oauth tokens, so the error disappeared but my assistant stayed silent.
The “Hello world” sample curl gives this response:
curl -X POST http://localhost:8085/broadcast -d '{"message":"Hello world!!"}' -H "Content-Type: application/json"
Can you make sure to pull the latest version of Docker image ismarslomic/google-assistant-broadcast and ismarslomic/google-assistant-oauth and retry all the steps? You could also try to generate new OAuth 2.0 Client ID in Google Cloud Platform console.
I know enough to be dangerous - that I would need to modify the dockerfiles and build my own containers to work on arm/v7, but I’ve never done that before. My experience is limited to writing compose files and pulling other peoples images. Would this be simple to do, or have I got a small hill of learning to climb first?
Its hard for me to tell. But basically you need to make sure you have installed Docker on Raspberry Pi, create an file named docker-compose.yml (you can see an example in the README file) and run docker-compose up -d. The nice thing with Docker is that if you do something wrong it is isolated to the Docker container and does not impact your host (Raspberry Pi).
Ah, no, that bit I’ve done. I already have docker installed, and am running a bunch of other containers on there (mosquitto, zigbee2mqtt, zwavejs2mqtt, tasmoadmin etc). The issue is that your images are built for a different architecture: linux/amd64. Docker throws a warning about this, but then tries to run the container anyway, which fails with an “exec format error”.
I guess its time to learn how to build my own container images!
Aha, I misunderstood your question then. I can make sure that the pipeline builds and releases docker image for arm/v7 architecture as well. Please create an issue on the Github repo and we can take it from there.
I have added support for the linux/arm/v7 and linux/arm64 architectures in the Docker build step of the build pipeline. Would be nice if you could give it a try and verify that you can run the Docker Image on rpi
Awesome, thanks! I’ve been busy the last few days but just had a bash. the Oauth container works, and I managed to get the required oauth token. However, the Assistant Brodcast container exits with a permission error. I’ve opened an issue on GitHub with a little more detail.
Just to clarify: Google supports two kinds of messages. Broadcast, which in nature is to all speakers and does not interrupt a music stream, and Text to speech, which is basically casting an audio stream. The last one stops playback of other streams ad does not resume them. The solution above adds broadcast support to Home Assistant, which without this solution only supports text to speech.
For those who want to target specific speakers there is another solution on the forum. It does not require docker but uses scripts.The benefit is a) resume playback after text to speech on a specific speaker and b) the possibility to know which unit received a speech command so you can direct an answer right back (in combination with other scripts). That solution looks rather complex with scripting though. So both solutions have their merits.
Thanks for the input! I did try that script, but it didnt work on my HA installation (on Nuc using Docker container). By all means, whatever works for you guys use it!
Hello, I have a small question regarding the oauth container.
I ran it multiple times it always gives me a code and says it has saved the tokens to /usr/src/config/tokens.json, which is volume mapped through the path I gave it (where the client_secret.json is as well).
Code is */********************************************-*********-*******-********
Tokens acquired.
Tokens saved to /usr/src/config/tokens.json.
But when I look at the mapped path no tokens.json file was created. Any ideas why/how this is possible?
I didnt manage to reproduce the issue you are describing with the ismarslomic / google-assistant-oauth repo. I run it on Nuc and RPI4 and I could find the tokens.json file.
Can you share the Docker Command you used to run the container?
I did go to the provided URL, and logged in and did the whole “validation”-thing. After that I got redirected to a localhost URL (which can be seen in de client_secret.json as well & in the URL the container spits out). Where I changed the localhost part with the IP-address of my Pi. Then the docker container says it was successful but I cannot find the token file.
Could it be that I did something wrong in my client_secret.json request? It is a desktop type OAuth 2.0 Client ID:
!