Hi,
my environment is quite complex:
Synology NAS with hass 0.104.0 running in docker container, host network, port 8123 ipv4
Synology Reverse Proxy, dns name ha.hauptsache.myds.me, port 443, using let's encrypt cert
Internet access via cable DSLite, ipv6 only incoming :-(
This means if you try to reach the dns name via ipv4 it won't work. only ipv6
Anyway, so far the reverse proxy works fine and I can access my hass installation via the android companion app remotely (via cell network, German Vodafone) and locally via WiFi.
The problem is the google assistant integration. I read the documentation and setup the whole environment to connect to ha.hauptsache.myds.me.
This works:
In Google Home app I click on the "+" to add new devices and I select my test app.
The home assistant webpage appears.
I enter my credentials and the app shows a popup which tells me in German "sie werden angemeldet" (translated: logging in).
This doesn't work:
After a few seconds the popup disappears and I'm back in the "Konten verwalten" (manage accounts) screen. my test app is still not listed under the assigned services section.
Now I wonder, what am I missing? How can I debug this? Things I found in the logfile:
2020-01-17 15:11:28 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/google_assistant/report_state.py", line 45, in async_entity_state_listener
if entity_data == old_entity.query_serialize():
File "/usr/src/homeassistant/homeassistant/components/google_assistant/helpers.py", line 442, in query_serialize
deep_update(attrs, trt.query_attributes())
File "/usr/src/homeassistant/homeassistant/components/google_assistant/trait.py", line 1288, in query_attributes
ERR_NOT_SUPPORTED, "Querying state is not supported"
homeassistant.components.google_assistant.error.SmartHomeError: Querying state is not supported
2020-01-17 17:35:10 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/google_assistant/report_state.py", line 45, in async_entity_state_listener
if entity_data == old_entity.query_serialize():
File "/usr/src/homeassistant/homeassistant/components/google_assistant/helpers.py", line 442, in query_serialize
deep_update(attrs, trt.query_attributes())
File "/usr/src/homeassistant/homeassistant/components/google_assistant/trait.py", line 1288, in query_attributes
ERR_NOT_SUPPORTED, "Querying state is not supported"
homeassistant.components.google_assistant.error.SmartHomeError: Querying state is not supported
md5-a59db7106a7258ab9058d74dd487c19f
2020-01-21 13:19:20 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/google_assistant/report_state.py", line 45, in async_entity_state_listener
if entity_data == old_entity.query_serialize():
File "/usr/src/homeassistant/homeassistant/components/google_assistant/helpers.py", line 442, in query_serialize
deep_update(attrs, trt.query_attributes())
File "/usr/src/homeassistant/homeassistant/components/google_assistant/trait.py", line 1288, in query_attributes
ERR_NOT_SUPPORTED, "Querying state is not supported"
homeassistant.components.google_assistant.error.SmartHomeError: Querying state is not supported



Hey there @home-assistant/cloud, mind taking a look at this issue as its been labeled with a integration (google_assistant) you are listed as a codeowner for? Thanks!
Check all the steps again and ensure that your proxy is properly routing all the api's for google assistant. There are a few URLs you will want to make sure are routed correctly. Also ensure you have removed the app shortcut that gets created from Chrome when you add to homescreen. There is a note about that in the docs as well.
Start with less entities exposed. You are exposing som entity with unknown state.
@dshokouhi thanks for trying to help, but I'm not sure how to respond. I tried to follow the documentation but unfortunately it's outdated. If you walk through it step by step you'll find out some things have changed. Nevertheless I think I have done it correctly.
Not sure about the homescreen shortcut. I didn't have one.
The URLs might in deed be the problem. To be correct: my reverse proxy. For home assistant to be accessible via reverse proxy I needed to set some special http header configuration. Not sure if the same is needed on top for for google assistant integration.
@elupus
can you be more specific? Maybe google integration doesn't work if one of the entities is in unknown state? I say this because I faced the exact same issue with openHAB in the past, but it was fixed somehow. I don't know the reason. Can you point me to the problematic entity? I'm not even sure my configuration is correct.
This is my config:
google_assistant:
project_id: home-assistant-project-265414
service_account: !include home-assistant-project-265414-b665ef99bd7e.json
report_state: true
exposed_domains:
- switch
- light
- cover
entity_config:
switch.shelly_shsw_1_24d457:
name: Deckenlicht_HomeOffice
aliases:
- BRIGHT_LIGHTS
- ENTRY_LIGHTS
You are exposing all switches all covers and all lights. Please reduce your exposed entities to a minimum to start with. I suspect it's covers that is causing problem.
I reduced the config to (see below) and restarted the server. The behavior is still the same, google home app returns to the list of service providers and has not added my test app:
google_assistant:
project_id: home-assistant-project-265414
service_account: !include home-assistant-project-265414-b665ef99bd7e.json
report_state: true
The log says:
2020-01-22 20:29:19 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/google_assistant/report_state.py", line 45, in async_entity_state_listener
if entity_data == old_entity.query_serialize():
File "/usr/src/homeassistant/homeassistant/components/google_assistant/helpers.py", line 442, in query_serialize
deep_update(attrs, trt.query_attributes())
File "/usr/src/homeassistant/homeassistant/components/google_assistant/trait.py", line 1288, in query_attributes
ERR_NOT_SUPPORTED, "Querying state is not supported"
homeassistant.components.google_assistant.error.SmartHomeError: Querying state is not supported
@Stefan300381 by default all entities are included based on your configuration. Try to include just 1 entity and see if it works.
Set this false https://www.home-assistant.io/integrations/google_assistant/#expose_by_default
Then expose only 1 device
@dshokouhi my config below (without any entity), same behavior. After login I'm back in the accounts screen of google home app.
Any chance I can manually test/verify the URLs I have setup in the google actions console?
https://ha.hauptsache.myds.me/api/google_assistant
https://ha.hauptsache.myds.me/auth/authorize
https://ha.hauptsache.myds.me/auth/token
google_assistant:
project_id: home-assistant-project-265414
service_account: !include home-assistant-project-265414-b665ef99bd7e.json
expose_by_default: false
report_state: true
I just performed the whole setup myself and I used the same config @Stefan300381 ended up with in his last comment. (Unintentionally, I only now found this issue). I am currently facing the exact same problem.
I don't know a lot about OAuth but as far as I know, the service must provide a redirect-url after a succesful login. Could it be that the redirect URL that homeassistant provides is wrong?
Any errors in log when no entities are setup? @Stefan300381 also are you behind som reverse proxy?
Network wise, I'm using a DynDNS with an additional CNAME record on top of it plus port-forwarding, so technically the most straight-forward configuration.
There are no errors in the log. I have a few test entities set up (TV + Hue) but set expose_by_default to false in the config. Should I delete them all for further testing?
For additional information:
So, I'm pretty much out of ideas for the moment. I wish Google Home itself would provide some more meaningful errors other than just "it did not work" :roll_eyes:
My main question remains, what can I do to test the setup components (like authorization URL). Something is clearly not working, but what?
If you haven't, turning on debug logging might help. Also, the test app is enable I'm action console right? It turns off after some time.
@elupus
debug didn't reveal anything more. about testing: to be honest I'm not 100% sure. I thought if testing isn't enabled then the test app wouldn't show up in the google home app, right? in the google actions console it says on the top right: testing on device: enabled
@cybrox, did you make any progress?
@Stefan300381 Sadly not. I tried the HomeAssistant cloud free trial period just to see if my setup somehow messes that connection up as well (I know it's different endpoints but I'm running out of ideas) but that works fine.
My next guess would be to see if there's any way to have Home Assistant log every single HTTP request and its OAuth flow. From how I understand the OAuth workflow, the error happens after successful authorization of the Google App Client, which leads me to believe that either the redirect URL used in the guide is wrong (outdated) or Home Assistant gets a request that errors right after completing the OAuth flow and the Google Home app aborts.
I'll report if I figure something out. Will look at it in the next few days again.
@cybrox
The strange thing is, that I experienced exactly the same situation with openHAB in the past. But the problem solved itself after a day or two. And with openHAB I was NOT using my own local instance, but the official cloud service. This is so frustrating, as I would really love to move from openHAB to HA ;-)
I'm having the exact same issue. Except there are no errors at all in the logs. Checked debug level as well, nothing..
@codecvlt How are you running HomeAssistant? It seems @Stefan300381 and I are both running it in a docker container. Are you using docker as well?
I'm considering trying out the actual hass.io image for the Raspberry Pi and see if there's any difference. - I know there really should not be but I'm absolutely out of ideas and I don't think this issue will get much actual attention, since the GA integration is one of Nabu Casa's selling points.
I'm running it in docker yes. Took this route cuz I also run pihole on the same pi and that has its own image. Let me know if you have any luck with the hassio image.
cc @codecvlt @Stefan300381 I tried using the actual hass.io image on the raspberry pi, complete with plugin registry and re-setup let's-encrypt via plugin. Re-published the test application aaand.... the exact same error...
The only idea I have left would be to re-setup the docker setup and use tcpdump to capture traffic on lo and see if there's any clue in there, as to why it is not working. To be honest, I'm kind of running out of motivation, though.
Thanks for testing. Do you have an ipv4 internet account? I run unity media which is ipv6 only (idp ipv4 natted). For now I will just stay with Openhab where they provide the cloud service for free. A pity as I love HA
Per default, my provider sets up a dual-stack setup, but I had them change it to just IPv4 because of some legacy devices. I think if network connectivity was the issue, Google Assistant would not be able to even start the OAuth flow and show the HomeAssistant login screen.
Interestingly, I actually forgot to add my GCP credentials yesterday, and the error was the exact same. Added them today, went through the whole app setup process again, still no luck. Commented them out, same error.
This leads me to assume that the issue is with the GCP access configuration.
Maybe they just updated the expected configuration format, the documentation is oudated and our provided settings are never even loaded / have no impact at all...
If gcp you mean the service account, then that is not needed to complete the linking.
What is the service account used for then? Just so that HA can push new devices to google without performing the authentication flow again?
Regarding my previous answer, the config seems to be loaded correctly. I can comment out keys and it will complain about them missing, so that's working, even though it might not have any impact on the error.
For the sake of completion for the maintainers, I ran the whole flow again with debug logging enabled for all components.
Sometimes, there would be a 404 returned by the following endpoint so I removed all integrations and tried again.
2020-02-27 10:04:57 DEBUG (MainThread) [homeassistant.components.google_assistant.http] Response on https://homegraph.googleapis.com/v1/devices:reportStateAndNotification
This is the debug log during the OAuth flow. Looks to me like the flow completes successfully and there is no additional activity logged afterwards. (Set the default log level to debug, so all components should log).
2020-02-27 09:56:27 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/providers to 172.30.33.2 (auth: False)
2020-02-27 09:56:27 DEBUG (MainThread) [homeassistant.components.http.view] Serving /manifest.json to 172.30.33.2 (auth: False)
2020-02-27 09:56:27 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow to 172.30.33.2 (auth: False)
2020-02-27 09:56:36 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow/8cb89d631d0c442a8573b73a441afb90 to 172.30.33.2 (auth: False)
2020-02-27 09:56:38 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow to 172.30.33.2 (auth: False)
2020-02-27 09:56:38 DEBUG (MainThread) [homeassistant.components.http.view] Serving /manifest.json to 172.30.33.2 (auth: False)
2020-02-27 09:56:39 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/token to 172.30.33.2 (auth: False)
2020-02-27 09:56:41 DEBUG (SyncWorker_17) [homeassistant.helpers.storage] Writing data for auth
2020-02-27 09:56:41 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.33.2 for / using bearer token
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/app/entrypoint.js to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/app/chunk.b2dce600432c76a53d8c.js to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/app/chunk.e46c606dd9100816af4e.js to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/app/chunk.0b82745c7bdffe5c1404.js to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/app/chunk.d4931d72592ad48ba2be.js to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/app/chunk.4d45ee0a3d852768f97e.js to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/token to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/token to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.33.2 for /api/hassio/ingress/session using bearer token
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/ingress/session to 172.30.33.2 (auth: True)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.33.2 for /api/hassio/addons/core_configurator/info using bearer token
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio/addons/core_configurator/info to 172.30.33.2 (auth: True)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hassio_ingress/TE80BnOLBnZSSRBfolvAybyOuB9mVUhw7T5bP31F3NE/ to 172.30.33.2 (auth: False)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.32.2 for /api/services using bearer token
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/services to 172.30.32.2 (auth: True)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.32.2 for /api/events using bearer token
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/events to 172.30.32.2 (auth: True)
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.32.2 for /api/states using bearer token
2020-02-27 09:56:49 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/states to 172.30.32.2 (auth: True)
These look to me like google actually got a correct bearer token and is using it to do.. _something_(?)
2020-02-27 10:13:50 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/services to 172.30.32.2 (auth: True)
2020-02-27 10:13:50 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.32.2 for /api/events using bearer token
2020-02-27 10:13:50 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/events to 172.30.32.2 (auth: True)
2020-02-27 10:13:50 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated 172.30.32.2 for /api/states using bearer token
Yet, the Google Assistant app still just flashes the _Couldn't update settings, check your connection_ banner after _Logging in..._ and _Linking to [test] HomeAssistant_
Service account is for syncing new or changed devices on request from hass. You can do this from GA instead by asking it to "Sync my devices". It is also used if you turn on report state feature to proactively report state to GA
Sorry didn't mean to close. Missed button on mobile.
I suggest you disable state reports and remove service account untill you get it linked. Reduces potential issues.
Think you could temporarily port forward instead of using your reverse proxy? So we can exclude it as a problem.
Ah, gotcha, thanks for clarifying what it actually does.
I suggest you disable state reports and remove service account untill you get it linked. Reduces potential issues.
Disabled it and commented out the service_account portion of the config. HA does not complain but the log output remains the same.
Think you could temporarily port forward instead of using your reverse proxy? So we can exclude it as a problem.
I think @Stefan300381 was using a reverse proxy in his original issue report. I've always used port-forwarding. Forwarding 80, 443 and 8123 to the Pi at the moment. Accessing it from the outside via the HA app for example works and the certificate is valid. So I'm pretty sure that part of the set-up should be alright.
Never forward anything but 443 with certs in place. Just as a ps.
I'm pretty sure port 80 is needed when using http as acme-challenge for certificate renewal?
I agree that forwarding 8123 makes no sense anymore, once https is set up properly.
Edit: Plus since browsers still default to HTTP, I like having an HTTPS redirect in place for convenience.
I have the exact same problem. Anyone with a possible solution?
I have the same issue. Really hoping to get my HA to interact with GA
Any errors in your logs @faizalgazali and @Dirckvdb
Any errors in your logs @faizalgazali and @Dirckvdb
@elupus no, unfortunately I seen nothing in the logs
After login page it is linking

And after that

In HA new token created represents a login session. And no logs.
I get the follow error after the login page.
The error translates: Something went wrong, please try again.

Exactly same issue here. No useful logs.
@CodeInDreams @faizalgazali are you guys also running home assistant in Docker in combination with Nginx?
@CodeInDreams @faizalgazali are you guys also running home assistant in Docker in combination with Nginx?
I'm running Home Assistant 0.106.6 on HassOS 3.12. Using nginx on hass.io official repository.
Here is the config:
domain: #mydomain.com
certfile: fullchain.pem
keyfile: privkey.pem
hsts: max-age=31536000; includeSubDomains
cloudflare: false
customize:
active: false
default: nginx_proxy_default.conf
servers: nginx_proxy/.conf
@CodeInDreams I am using HassOS 3.12 on raspberry pie with Nginx
Just full clean installed 0.107.7 on another ubuntu server (18.04). Same issue.
2020-04-08 01:59:27 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/providers to 172.30.33.3 (auth: False)
2020-04-08 01:59:28 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow to 172.30.33.3 (auth: False)
2020-04-08 01:59:37 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow/b1e0fbb9b381479c8523496458ab0fd1 to 172.30.33.3 (auth: False)
2020-04-08 01:59:45 DEBUG (MainThread) [homeassistant.components.http.view] Serving /auth/login_flow to 172.30.33.3 (auth: False)
My time zone is UTC+8 Asia/Shanghai. The date in log is 1 hour later than real time.
Same problem :(
Could not update settings, please check your connection.

Decided to start this Google Assistant integration endeavor two days ago. Was basically stuck at the same connection issue when trying to link in the Google Home app. I was able to finally link it though, but I don't know if this was due to maybe a time thing or a small change I did. The change itself was setting the role of the service account you created (and have set under service_account in configuration.yaml) to Owner within the IAM page in GCP (mine was set to Editor initially)
Hopefully this provides some insight into this issue
Odd. That role doesn't even exist for me. I have mine set to "Service Account Token Creator"
I think mine was "Service Account Token Creator" as well, since that's what the HomeAssistant documentation recommends. I did not find any way to check or even modify this. But I did delete and re-create the service role and I can select "Project" > "Owner" in the progress.
Unfortunately, I tore down my whole test setup (Running via NabuCasa at the moment, because I just didn't have time to deal with this), so I can't really test if it makes a difference :(
Decided to start this Google Assistant integration endeavor two days ago. Was basically stuck at the same connection issue when trying to link in the Google Home app. I was able to finally link it though, but I don't know if this was due to maybe a time thing or a small change I did. The change itself was setting the role of the service account you created (and have set under service_account in configuration.yaml) to Owner within the IAM page in GCP (mine was set to Editor initially)
Hopefully this provides some insight into this issue
A slight clarification. The change to owner was made to the default service account, not to the one you would create with the JSON key:

Essentially, the one with [Your_Project_ID]@appspot.gserviceaccount.com
I changed it by clicking on the Pencil edit under Inheritance, then changing the Role to Project -> Owner

^ This totally fixed it for me. Thanks for the tip!
Changing the App Engine Service Account permissions to Owner unfortunately did not work for me.
I'm having the same issue as well; running Home Assistant Core in a Docker with nginx+letsencrypt reverse proxying (also in a Docker). I also see no helpful log entries.
I've had Google Assistant integration running in the past, but after I unlinked it a couple weeks ago, I've been unable to link it back since even after deleting and re-creating a fresh Google Cloud project.
Same for me (using it in Docker on Synology with the Synology RP), tried all described solutions...
I also tried te solution mentioned above. Unfortunately without success.
On 8 Jun 2020, at 14:59, AdrinkBeer notifications@github.com wrote:
Same for me (using it in Docker on Synology with the Synology RP), tried all described solutions...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/31054#issuecomment-640587276, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEE4G4NIGDY3H6ALPW2R6DDRVTOEHANCNFSM4KJU3RQA.
I stuck on this for months. Still have no idea what's wrong.
I have tried serveral os like Ubuntu server 16/18/20.04 (core/supervisor), HassOS (stable/test), also tried with hass version 0.106~0.110. Nothing happend.
I can make sure ssl, nginx and test app things is working fine. Maybe IP banned by google assistant??
Tried to do it with DuckDNS/Let's Encrypt (and port forwarding) instead of the Synology RP with my domain, the behavior is a bit different :
with the Syno RP, when I click on my test app, it loads ("Connecting...") then goes back to the list.
with the DuckDNS solution, it also loads but then displays another popup ("Linking test app...") and then goes back to the previous screen (where I clicked on "Works with Google") but still no entities are available. In my config, only one entity is exposed.
I tested with the cloud NabuCasa solution and it works..
Similiar problem here.
I am using HA 0.113.2 on a Raspberry Pi with the NGINX Proxy Manager (port forwarding from 443 to duckdns:8123).
I successfully created the Test App for the second time.
Trying to add it to Google Home, I was asked to enter my credentials in Google Home for connecting.
After the screen showed "you are being logged in..." I was moved back to the Google Home services list with the test app still unconnected.
My guess is that is has something to do with the proxy manager.
Do you have any suggestions what I could else try to get it working?
Thank you guys!
It finally worked for me!
Some key things...
a) When you get to the google home app part, if you get to choose your test app, log in to HA ok, then says "signing in..", but then it just drops you back to the list of apps, then the problem is probably that google can't contact your server from outside (my issue was port blocking from my ISP, other possibilities are your firewall setup, or your dns entry is new and needs a few minutes/hours/a day to propogate).
b) If when doing the above, it drops you back to the "set up" page with "New devices" and "Works with Google", then I think you have an issue with the configuration in HA - perhaps the project name is wrong (it should be "adjectivenoun-number" if using the default, or "name-number" if you customised it), or maybe you're exposing too many services or something that's freaking google out. Maybe pare it back to just "switches" or something.
It's helpful to look at the logs for your proxy container when diagnosing this. If you run docker ps, and find the name for your proxy container, then run docker logs -f containername (in my case, containername is 'public_proxy_1' because I use docker-compose to run it). This will show you the log file, and keep waiting for new entries to show up (press Ctl-C to break out of it). Leave this running while you attempt the linking process, and compare it to my results below...
Here's what my successful addition looked like from the logs (Italics are my comments, bold is my emphasis, corrupted are my tokens, hostnames, etc):
172.27.0.1 - - [02/Aug/2020:21:12:45 +0000] "GET /auth/authorize?redirect_uri=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2Fpensive-beaver-555555&client_id=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2Fpensive-beaver-555555&response_type=code&state=ArEallyLongStringOfCharsForState&scope=email%20profile&user_locale=en-GB HTTP/1.1" 200 2355 "-" "Mozilla/5.0 (Linux; Android 5.0; SM-N9005) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.111 Mobile Safari/537.36" "-" ^ this is you loading the HA sign-in page, so it probably came from inside your network rather than via the internet. Note that I set scopes to "email" and "profile", since "name" doesn't seem to be a current scope, I don't know if that's important. 172.27.0.1 - - [02/Aug/2020:21:12:45 +0000] "POST /auth/login_flow HTTP/1.1" 200 263 "https://home.example.com/auth/authorize?redirect_uri=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2Fpensive-beaver-555555&client_id=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2Fpensive-beaver-555555&response_type=code&state=ArEallyLongStringOfCharsForState&scope=email%20profile&user_locale=en-GB" "Mozilla/5.0 (Linux; Android 5.0; SM-N9005) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.111 Mobile Safari/537.36" "-" ^ This is your phone again, loading the content "inside" the HA login page. 172.27.0.1 - - [02/Aug/2020:21:13:02 +0000] "POST /auth/login_flow/488e39853a37bb883 HTTP/1.1" 200 255 "https://home.example.com/auth/authorize?redirect_uri=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2Fpensive-beaver-555555&client_id=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2Fpensive-beaver-555555&response_type=code&state=ArEallyLongStringOfCharsForState&scope=email%20profile&user_locale=en-GB" "Mozilla/5.0 (Linux; Android 5.0; SM-N9005) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.111 Mobile Safari/537.36" "-"' ^ This is you successfully logging in to HA. Note the "200" response which means login was successful. A 400 or 403 or something here indicates you got your login details wrong :-) Also note the project name "pensivebeaver-555555", you should see exactly this project name in the url when setting up your project in the google actions console thingie. 172.27.0.1 - - [02/Aug/2020:21:13:05 +0000] "POST /auth/token HTTP/1.1" 200 396 "-" "OpenAuth" "-" ^ Hurrah! This means google's server is contacting your server, and the 200 says that they're getting along well. This is the key line, really. If you don't see this (access to /auth/token) then it means google's servers are not reaching you - which might be because of your dns, your firewall, or the paths you put into the OAuth2 settings in google action console. Entries like the below are the general "google talking to HA stuff" that will happen as statuses are updated, lights are switched etc. 172.27.0.1 - - [02/Aug/2020:21:13:09 +0000] "POST /api/google_assistant HTTP/1.1" 200 5785 "-" "Mozilla/5.0 (compatible; Google-Cloud-Functions/2.1; +http://www.google.com/bot.html)" "-" 172.27.0.1 - - [02/Aug/2020:21:13:12 +0000] "POST /api/google_assistant HTTP/1.1" 200 5785 "-" "Mozilla/5.0 (compatible; Google-Cloud-Functions/2.1; +http://www.google.com/bot.html)" "-"
Hopefully that will give you what a good session looks like, compare it with your own, and help you work out where things are going awry.
How can I trace those connections on a standard hassio installation on a Raspberry Pi 4?
Finally got it work! I stuck for several months! I tried everything I saw until I realized that "I can login" NOT means google can.
Even I opened the login page and "logged in", google wasn't.
Yea that's the problem. I believe many people ignored it.
Note that I have public IP and properly deployed https website but still has this issue. Some ISP like China blocks Google's traffic.
I solved this by forwarding 8123 to another server using Frp.
I also just starting running into this issue. I tried to relink my home assistant account and got a message saying Google Home "Couldn't update the setting. Check your connection.". This is after I logged in and was forwarded back to my google home from homeassistant.
I tried setting the service account as project owner. I tried disconnecting phone from wifi. I tried changing my project linking. I tried different setups but none of them worked.
One thing I noted was that this occurred around the same time as I relinked my samsung smartthings connection to google. I also updated to 0.114.3 around that time and even added another google device to my setup as well. I am not sure if any of that is related or not.
I am also getting this error in my homeassistant which I never got before
https://homegraph.googleapis.com/v1/devices:reportStateAndNotification failed: 404
404 on report means a device is reported that wasn't synced
same issue here - trying to add [test] my test app.
I see app linked successfully but i'm dumped back on the Google Home App home screen. Going back to the list of apps an I see `[test] my test app' is in fact not linked.
I'm using Docker and synology Reverse Proxy - no issues with external connectivity (Alexa has no issues) and i'm using a SSL wild card certificate.
Try changing expose_by_default: false to true That's the only way I was actually able to get the integration to work
Here is my config:
google_assistant:
project_id: hass-assistant-f1209
service_account: !include assistant_service_account.json
secure_devices_pin: '0000'
report_state: true
expose_by_default: true
exposed_domains:
- light
- camera
- cover
- switch
entity_config:
light.downstairs_lights:
name: Downstairs Lights
room: Downstairs
light.upstairs_lights:
name: Upstairs Lights
room: Upstairs
light.dining_lights:
name: Dining Lights
room: Dining
light.downstairs_bath:
name: Downstairs Bath
light.porch:
name: Porch
light.back_porch:
name: Back Porch
light.kitchen_lights:
name: Kitchen
room: Kitchen
light.hallway_lights:
name: Hallway
room: Hallway
light.master_closet_2:
name: Master Closet
light.master_lights:
name: Master Lights
room: Master
light.dining_1:
expose: false
light.dining_2:
expose: false
light.dining_3:
expose: false
light.mommy_s_light:
expose: false
light.daddy_s_light:
expose: false
light.kitchen_1:
expose: false
light.kitchen_2:
expose: false
light.laundry_light:
expose: false
light.kids_room_light:
expose: false
light.master_bath_1:
expose: false
light.master_bath_2:
expose: false
light.living_room:
expose: false
light.bar_light:
expose: false
light.kids_bath_1:
expose: false
light.kids_bath_2:
expose: false
light.entry_light_1:
expose: false
light.entry_light_2:
expose: false
light.entry_lights:
expose: false
light.bar:
expose: false
light.all_lights:
expose: false
light.entry:
expose: false
light.kids_bathroom_lights:
expose: false
light.kids_room:
expose: false
light.laundry_room:
expose: false
light.hallway_1:
expose: false
light.hallway_2:
expose: false
light.master_bath_lights:
expose: false
light.master_bedroom:
expose: false
light.master_zone:
expose: false
light.wled:
expose: false
light.hyperion:
expose: false
This was the only way I could get the test app to actually add and get my entities to show up, if I left exposed by default to false I would get the loop back when trying to add my test app
That seemed to do it, thanks.
Appreciate the help.
However this is not how it 'should' work - so wonder if the code owner will take a look?
If the entities are set to expose:true by default, it seems superfluous to set expose_by_default: true as well.
Anything listed in the entity_config should be exposed.
Anyway, thanks for the tip 😀
I think what you ran into was solved recently actually. You probably had assumed state entities , that failed on sync.
I tried to update my config a week ago by removing the true statement and when I went to re-link the app it still failed so I'm not sure which version it's fixed in but it still doesn't seem to work
Well the fix mentioned was not released yet :)
ah, any idea when the fix will be released? - browser_mod as an example adds a new light for the device you are viewing your lovelace dashboard on - so expose_by_default: true will just flood my GA devices list with random devices I dont need/want.
@jaburges if you look at my config You noticed I listed entities with the attribute expose: false which will remove that entity from Google That's why my config is so long I'm pretty sure it will be released in 0.115 which I think the beta is coming on Monday
yeah, but i dont know what the name of the new lights that browser_mod will create it uses a browser deviceID.
So if another light is added that i dont implicitly know (or declare as expose: false) and then reboot HA each time (ball ache) - i'll end up with the random lights I dont need in GA.
That said, great timing the fix is just around the corner - good bit of luck i guess :)
Yes that is what I meant. If you have issues pairing with expose all. The likely cause is that we failed to generate data for some entity. Previous the whole sync would then fail.
ahhh - interesting. Ok. before i try the fix i'll see what device is causing all the fuss
Yeah I don't understand what device could be giving bad data because the devices I was trying to get into Google work just fine I've been exposing all filtering out the ones I don't want.
also - hold on. Maybe i'm missing something.
if i set expose_by_default: false
and I add 2 lights and nothing more
GA linking FAILS
if i set expose_by_default: true
it automatically adds ALL lights
GA linking succeeds
It cant just be bad data, as exposing all devices in that domain would make the problem worse (or the same) not better?
Okey that make no sense 🤣
i know right - so weird.
I'm only exposing a single domain right now. Lets see what the fix brings
Right now my exclusion list is crazy long lol
_I have a solution! For DS-lite_ , be sure to leave the ipv4 field empty in duckdns! Otherwise the GA will not work !!!