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
1 Like
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.
3 Likes
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! 
Will take a look at it later today. Out for fishing now 
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?
Thanks in advance!
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 used the one described in the README ismarslomic / google-assistant-oauth
1 Like
Sure, I also used the same command as you described in the README.
docker run --rm \
-p 3005:3005 \
-v /opt/google-assistant-broadcast/config:/usr/src/config \
ismarslomic/google-assistant-oauth:latest
With /opt/google-assistant-broadcast/config being the path where the client_secret.json is located. Below an image of the executed commands:
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:
Thanks for helping me 
!
Hmm, not sure what the issue is. Can you try mounting an folder within users home path?
You could also try replacing image tag latest with 1.0.0
I tried changing the tag to 1.0.0, which didn’t help.
I don’t understand what you mean, isn’t the /usr/src/config/ folder of the container already mapped to the hosts system with the -v (volumes) tag?
Also tried to put the command in a docker-compose which didn’t help. I wanted to check inside the container but when it finished it automatically exits. So I cant go inside the container or copy files if it should have created one.
And is the way I created my client secret alright? Or maybe I made a mistake there? This is the structure I have:
Your client_secret.json content looks correct!
What I meant is that you should try mounting another folder (from your host) that is owned by the user you are logged in with in your OS, /opt is owned by the root user. I suspect we are dealing with write/permission issues from docker container to the host folder /opt/google-assistant-broadcast/config.
Here is a example for default user (ubuntu) in Ubuntu OS, Also, I´m here demonstrating how to start the docker container in interactive mode so the container does not quit after tokens.json is generated. This can help you check if the tokens.json gets created in the folder /usr/src/config inside the container, when the authentication flow ends.
- Start container in interactive mode and mount a folder which user
ubuntuowns
docker run --rm -it \
-p 3005:3005 \
-v /home/ubuntu/google-assistant-oauth/config:/usr/src/config \
ismarslomic/google-assistant-oauth:latest \
/bin/ash
- Execute this command when you are inside the container
node index.js
-
Do the authentication flow
-
When the authentication flow is done, verify that
tokens.jsonis created in container:
ls -al /usr/src/config
- Exit container by typing exit
exit
- Verify that the
tokens.jsonexists at host
ls -al /home/ubuntu/google-assistant-oauth/config
1 Like
Yes apparently it were some weird permission issues.
Which is very weird because initially I executed everything with the root user which should have all the permission.
But when I executed it with the pi user (one of my users) it worked after is put sudo before each command. Thanks for your help, much appreciated!
After I got the tokens.json I was able to spin up the broadcast container. Now I have the same problem as @joolui, I always get an empty response back and no sound comes out my Nest speakers.
But this may be a problem with the new google account I created for this use case. It has all the rights like my main google account but it doesnt work yet. I’ll give it some time and otherwise I’ll try it with my main account. But thanks for all the troubleshooting!
- Is it normal that those tokens expire after 1h of creation?
Glad you fixed the issue with tokens.json file. I will update the README file to get attention for new users on this topic.
Since I’m not able to reproduce the error you and @joolui is facing, I don’t know how to help. But please let me know if you find out, so I can either make a bugfix or update docs.
I have used the same token for several weeks, without needing to recreate it.
I’ll keep you posted if I find out why it doesn’t broadcast the messages.
What I do find very strange if I look in the Google Console Platform I see there are a few Google Assistant API request, so they go through the API but it doesn’t get played:
(This is with my main google account, so the owner of my Google Home)
In your setup did you have to do specific settings to tell which speakers it could broadcast to?
(I have Google Nest speakers which I can broadcast to with Google Assistant via my phone/car)
Last question, in your OAuth consent screen did you publish the APP? I did not and have it set tot external user type with myself (main google account email address) as a test user).
Can you please register new issue in Github repo, regarding questions in last post? I can provide some input on what you could try to fix the problem.
Hey @ismarslomic. Thanks for getting this back up and running. I’m struggling with getting the tokens. My HASS is hosted in a docker container on a headless server. I don’t have a GUI, let alone a web browser, to paste the link into for the oauth credentials. When I try to use a different system with a gui (on the same network) it obviously borks at the “localhost:3005” portion of the callback. I also tried changing “localhost” to the server’s IP, but that also didn’t work.
Any idea how else i can get the token?
To obtain the access token you can start the google-assistant-oauth container on whatever machine you have access to (server, PC, Mac, etc.). This is a one time job you do to obtain the tokens file, which you need in the google-assistant-broadcast container.
If you start the google-assistant-oauth container on your headless server, copy the url to your web browser (you must be on the same network or use VPN), you can replace the localhost with the IP address of your headless server when the OAuth flow is finished and your browser is redirected.
Hope this helps!