Open HeedfulCrayon opened 3 years ago
I just got exactly the same issue. its been working for about a week. I had to create another user using the same OAuth client ID. why is that?
Also seeing this issue
Same issue, and also solved by creating a new user using the same credentials.
Creating a new user only fixes it temporarily. After a few days it will go back to doing the same thing
Yep that’s what I ran into
On Dec 29, 2020, at 08:10, HeedfulCrayon notifications@github.com wrote:
Creating a new user only fixes it temporarily. After a few days it will go back to doing the same thing
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Also getting this, going to try running a command to ask the time every six hours to see if that stops any timeout.
Happening to me again, 7 days after. Who is causing this to expire? GAR or Google?
Same for me. @matt---4 Any luck with your testing to repeat a command every X hours?
So far the issue hasn't happened since I started asking the time every six hours. I'll post back on here in a week or so with another update or if the issue happens again.
@matt---4 ok good to know! I'll be testing this myself as well.
I'm having the same issue and have automations which run daily at minimum firing commands. All working fine until 4 days ago with nothing having changed but now with the invalid_grant error. Same happens if I fire from sandbox mode.
EDIT - FYI I also added a new user using the same auth creds and it works again with this new user. I will monitor to whether this user gets impacted over time
me 3
I'm a bit concerned the dev doesn't seem to react on this issue... Is there anyone still maintaining this code ?
I'm a bit concerned the dev doesn't seem to react on this issue... Is there anyone still maintaining this code ?
Calm down, last commit was 14 days ago. Just set up an automation to run every 6 hours like stated above and you won't lose auth. Mines been working fine for over a week
Not sure the regular automation trick works. I set up a new user to prevent the problem on the current user, set up an automation to run every 5 hours. It was fine for the first day and now is failing with the invalid_grant error again
My raspberry pi crashed and I got invalid grant when it started up again. So I don't know how long the automation thing would have worked for.
Both my users lost the grant at the same time, one was used much more frequently than the other so I doubt it is interaction dependent. It was also 7 days after I set the system up.
Is there maybe something with the testing function that are used for the grants?
Just saying, mine is still going just fine
@HeedfulCrayon that's good. What environment are you using this in? For me I am using the Home Assistant add-on and triggering automations through node-red. Curiously at the moment I get the error only in node-red, but can still successfully use the sandbox mode to trigger directly on the latest user account. My original user account fails in both Node-red and sandbox.
I might try installing a separate instance on a VM and see how that goes.
@Snacker001 I am using it in the Home Assistant add-on and I am using the native yaml automations:
id: 'google_assistant_relay_heartbeat'
alias: Google Assistant Relay Heartbeat
description: 'Keeps the token for Google Assistant Relay Alive'
trigger:
platform: time
at:
- "09:30:00"
- "12:00:00"
- "18:00:00"
- "00:00:00"
- "06:00:00"
action:
- service: rest_command.assistant_relay
data:
command: What time is it?
Don't think this is a GAR problem. I am not seeing any problem running in Docker on Ubuntu. It can be days between broadcasts and I'm not having any problems.
I see the same behavior
I'm having the same issue. Have not been tracking but would guess I loose grant after about 4 days. Will set up automation to track this more closely.
Mine finally died. Looks like running an automation periodically doesn't seem to fix the issue
I ran into the same problem twice now, it does not appear to be related to lack of activity. I'm posting in case my experiences help narrow down the problem.
The first failure, my Pi lost power hard and didn't boot back up properly. After solving the boot problem, I still received the invalid_grant errors. I didn't do any other testing, I reloaded the OS on the Pi and started over.
The second time, last night, I was actively sending commands when the credentials began failing. I sent 475 commands in 1 day successfully and began receiving the invalid_grant error on the 476th command.
The Google Assistant API reported "1 of 1 quota is reaching limit", the quota is 500 requests per day so I was near it.
I confirmed Google reported the Assistant API quota reset overnight, but I was still getting the same invalid_grant response this morning. I created a new Assistant-Relay user with no other issues to temporarily mitigate the problem.
What environment are you running GAR in? I am running in a plain Linux Alpine based Docker container and I am not having this problem. I would look more at what your OS might be contributing to this. If it was a GAR problem, we would all be seeing it.
I've been having the same issues. I thought it was occurring every 7 days for me (Sunday to Sunday) but I lost it again today after really 2 day, after I had also set up another webCoRE piston to ping every 5 hours. I'm on a Ubuntu vm on vmware running on a Windows 10 host. And I don't think I would have hit the 500 requests per day limit. This is getting really annoying.
Has this problem a few times when deploying AR via the Hassio add-on. Since moving it to run on a VM running ubuntu18.04 it has not reoccurred.
For what it's worth I have a benign automation running every 5 hours, but I am not sure that really helps - it certainly didn't when running the hassio add-on. I am also nowhere near the 500 per day request rate.
I do not think the problem is only caused by exceeding the quota.
Just speculation, but it seems once the invalid_grant error appear for whatever different reason it does not recover until a new user is created. Even if the root cause of the invalid_grant error gets solved (i.e. timeout no longer occurs, quota has expired, etc) that user won't stop reporting a failure. Problems like timeouts or disconnects that occur for reasons completely unrelated to GAR, and would normally be solved by sending another request, ultimately stop the service until manual intervention.
If that's the case, I agree a more powerful server would have less of a chance of initial failure avoiding this issue altogether.
I too am encountering this issue. GAR v3.2.0 running on Win10.
Solved for me when using an automation to ask the time (no broadcast) every 6 hours, using Hass.io. At least it's been running for more than a week as such.
Solved for me when using an automation to ask the time (no broadcast) every 6 hours, using Hass.io. At least it's been running for more than a week as such.
This is exactly what I did, but it still ended up failing after a while
Well... Seems I spoke too fast... It finally broke today. Last execution was at 12h00, then at 6pm got the invalid grand issue again. I think I'm going to back using the Google Assistant Webserver add-on on hass.io...
@littlbee hope GAW works for you, it was because that seemed to stop working for me that I migrated to GAR! Since I moved from the add-on to running directly on ubuntu (VM) a week ago I've had no more problems with GAR, fingers crossed ....
Now I had to reenable my accounts again to be able to use Relay. The permission disappears from the Google account but the same secrets can be used to reenable the service so the OAuth is still vaild.
I still think this has to do with the testing function that is used and limited that are placed upon this environment.
When I create a credential according to the guide, this message appear:
I am not sure what "Sensitive scope login" means but maybe it is a new login for every time HA is restarted (I use the Add-on) which can explain why the Add-on is experiencing this issue more frequently than the stand-alone version that is probably not restarted that often. Also explains why both my accounts fail at the same time even though they are used very differently.
All you have to do is set up the user consent screen. There is nothing special needed to do that. Just click on the hamburger menu on the upper left corner of the Google Developers console then click APIs and Services then Oauth Consent Screen.
The only thing you should have to fill in is the App name and the support email at the top. Nothing else should need to be filled in.
I have set up a consent screen, I think this is required to get GAR to work, but the consent screen is not verified by Google and it will never be because it is not a "real" project.
Don't you get the same notice when you create a new OAuth client?
So I spoke too soon, it has just failed again for me. Fixed by deleting the user and then adding a new one, same name, same client_secret file then all back up and working again. I guess until fixed I will be doing this weekly
Verification isn't required. Only that it is set up.
My consent screen is set up but not verified and thus I get the 100 sensitive scope logins restriction. Do you also get that message when creating a new OAuth client?
My consent screen is set up but not verified and thus I get the 100 sensitive scope logins restriction. Do you also get that message when creating a new OAuth client?
I get the same message.
Fyi yesterday after I published the app (so its status became In Production) in the developer console, I also got the new verification status which is Verification Not Required. After that when I added a new user, I no longer got the Unverified App warning. Will update here in a week where the invalid_grant error returns.
I had to redo my grants again even with Verification not required status. But I still get the same information when I create a new OAuth client that it is 100 sensetive logins because the consent is not verified...
Update. Still working for me after 8+ days. It always expired in 7 days or sooner before. What I did was I published the app in the developer console (status showing In Production). Verification status is Verification Not Required. I didn't get the Unverified App warning after this, when I added a new user. Notice this: if your users are seeing the "unverified app" screen , it is because your OAuth request includes additional scopes that haven't been approved.
Update. So it's been 15+ days for me and still works (no invalid_grant error). Anybody else successful in reproducing what I did?
I’m trying, but only two days in. Will post if I’m still good after a week.
On Feb 6, 2021, at 14:24, jayhohoho2019 notifications@github.com wrote:
Update. So it's been 15+ days for me and still works (no invalid_grant error). Anybody else successful in reproducing what I did?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Update. So it's been 15+ days for me and still works (no invalid_grant error). Anybody else successful in reproducing what I did?
I "published" 4 days ago and fine so far. Mine typically failed after a week, so still unproven for me but fingers crossed!
So by way of update, a week on and having published on the developer console it has fallen over again. A quick remove and re-add user with the same client_secret and back up.
Interestingly, I also have a similar issue with Nest, again on almost a weekly basis it fails and needs re-authenticating via the integrations pain. Looking into that it seems there are issues where google invalidates the tokens:
https://github.com/home-assistant/core/issues/44584
https://developers.google.com/identity/protocols/oauth2#expiration
How many users do you have set up for the project? I only have one and I have never had this problem. I just use the same Oauth client everywhere (since they are all me).
Only 1 user for me too and GAR probably only triggers commands around 10 times a day, so should be nowhere near quotas
Describe the bug Assistan relay seems to lose auth after a while. Whenever testing anything in sandbox I get this error: Getting metadata from plugin failed with error: invalid_grant
To Reproduce Steps to reproduce the behavior: Try any command in sandbox
Expected behavior Command or broadcast to occur without issue.
Desktop (please complete the following information):