Thanks for the advice @dschoepel. Like @gribnut, I too am not using pub/sub, though - are you using it @dsmuttley? I tried to set it up, but hit a roadblock and haven’t dedicated more time to figuring it out since my initial attempt.
Anyway it does seem like the problem is originating from Google given their documentation and Rick’s observation that the openhab service/partner setup is removed automatically from partner connections after 7 days. Frustrating. If this keeps up I may just delete everything from google and start from scratch with Dave’s step by step tutorial. Either that or try to get pub/sub working, I guess.
@Marcusfacius, @gribnut, @dsmuttley, @dschoepel: I am using pub/sub (at least I think I am…I followed the instructions and it seemed to work, but I don’t know how I would check that), and I did follow the step-by-step tutorial, and I think I am still experiencing the 7-day problem you all are.
I originally thought my disconnect was happening because of the internet outage problem that is mentioned elsewhere in this post (I happened to notice the disconnect both times it happened to me right around the time of an outage), but I cannot get my system to find my devices after the disconnect unless I issue myself a new token (<-- probably not the right word). And it definitely did not last more than a week, so I’m fairly confident it’s the 7-day issue.
I’ll poke around my account(s) to see if there is some setting I chose wrong or can at least change, but I do hope someone finds a solution to the 7-day disconnect. I can’t be getting a new token every week. I was thinking about writing a python script that automates grabbing the token, but I suspect that isn’t going to work because I think there are authorization buttons you have to click. Sigh.
Did a little digging and found a couple things that may be related but can’t say for sure. One sure thing, way too many steps by Google to get this stuff working - they are missing out on an opportunity to gain more customers even if it cuts into their closed ecosystem.
All calls to the SDM API to manage authorized structures and devices must use the unique access token granted to the developer by the user during authorization. Access tokens are short-lived and must be refreshed regularly to ensure continued access.
If a user later revokes developer access to a structure or a device, the access token immediately expires and cannot be refreshed, and the developer will no longer be able to call the SDM API on behalf of that user.
I do have a service account set up for my pub/sub - perhaps that is what is preventing it from being expired after 7 days, but I can’t seem to find any Google documentation to support that idea. And I just realized that I did not include that bit in the documentation I created. The service account info ends up being included in the JSON file that is downloaded from the credential manager, which is then used by the binding…
Service accounts are recommended for managing SDM API subscriptions and event messages. A service account is used by an application or virtual machine, not a person, and has its own unique account key.
Service account authorization for the Google Cloud Pub/Sub API uses Two-legged OAuth (2LO).
In the 2LO authorization flow:
The developer requests an access token using a service key.
The developer uses the access token with calls to the API.
Create a service account and service account key as described in Creating a service account. We recommend giving it only the Pub/Sub Subscriber role. Make sure to download the service account key to the machine that will be using the Pub/Sub API.
Provide your authentication credentials (service account key) to your application code by following the instructions at the page in the previous step, or get an access token manually using oauth2l, if you want to quickly test API access.
Figured it out. You need to set set the status of your app from testing to production.
Reauthentication required often : If you are frequently getting logged out, this means your authentication token was revoked by Google. The most likely reason is the OAuth Consent Screen is set to Testing by default which expires the token after 7 days.
I have highlighted the items you need to make sure are set correctly in the attached image. Be sure your publishing status is set to In production and User type is set to External. This should fix your problem with 7 day expirations…
Thanks! I changed the setting and got myself a new refresh token. That made the devices reappear in PaperUI. I’ll let you know if it’s still working after a week.
Awesome, thank you Dave! I saw that option earlier, hitting the button labeled “Publish App” is what brought up the window listing all the absurd requirements to move from “Testing” to “In Production” in my screenshot from a few days ago…
Based on your advice I went ahead and clicked on “Confirm” despite the list of requirements, and it appears to have successfully changed the publishing status to “In production” despite me not having satisfied those requirements, but now under “Verification Status” there is a message stating “Needs verification” where yours says “Verification not required”, and there is a “Prepare for verification” button and a list of requirements similar to what I had posted previously which is strange. Apparently this is because I’m using “one or more sensitive scopes” but I am not sure what that means exactly…
Is this what your “OAuth consent screen” page looks like now @dathbe? Also curious to hear what this page looks like for @gribnut & @dsmuttley after you guys attempt to make this change as well. I guess its possible this may still fix my 7 day refresh token interval problem despite the “needs verification” and “prepare for verification” messages… who can say. As you said Dave this is all so convoluted and confusing on Google’s end.
Marcus, looking at the verification FAQ, doesn’t seem like you need to go through that as your app would be considered an exception. Somehow you may have checked a box that sent you down that path… Cant say for sure where though. Maybe going through the edit bit for the consent screen, looks like there are a few steps (workflow) to go through - you may hit a setting that you agree to the exception. I am avoiding it cause all is working for me now - would not want to jinx my config
I also saw the <100 user exception, but I could not find a place to convey to Google that this is intended for personal use. Maybe they will realize that is the case whenever my app is reviewed, now that I have moved it to production and in so doing requested a review. One would think they could automatically see how many users I have associated with the app (two, myself and my wife) and automatically exclude me from these options/messages regarding requirements for verification, but what are you gonna do. I am sure you are right that I ended up here because I checked a box I shouldn’t have or some such. I suppose we will see what happens when google reviews my project.
For what its worth that channel is empty in the OH2.5 version of the binding as well; so my guess is that it is working as currently designed and needs to be coded to update the channel with the name.
Verification Status
Verification not required
Your consent screen is being shown, but your app has not been reviewed so your users may not see all of your information, and you will not be able to request certain OAuth scopes. Learn more
I understand. Problem is that this is the only channel what is visible for that thing. All other channels are not existing. Or at least it is not avaiable for me.
Hi - I’ve been trying to get this configured and functioning in openhab using @wborn version for 3.0. (I am running version 3.1 of openhab). I have successfully setup things with Google and have successfully authorized the device and made a device call using the curl command from the google instructions.
Unfortunately, when I create a “Nest Device Access” thing and fill in the items (I’ve tried both through the UI and using a nestdeviceaccess.cfg file, this stays as UNITIALIZED with status HANDLER_REGISTERING_ERROR. In looking at the logs, I see the following - which I presume is the problem. Any suggestions?
Exception occurred while calling thing handler factory ‘org.openhab.binding.nestdeviceaccess.internal.nestdeviceaccessHandlerFactory@6db46’: null
java.lang.NullPointerException: null
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:878) ~[?:?]
at com.google.api.client.util.Preconditions.checkNotNull(Preconditions.java:125) ~[?:?]
at com.google.api.client.auth.oauth2.RefreshTokenRequest.setRefreshToken(RefreshTokenRequest.java:142) ~[?:?]
at com.google.api.client.googleapis.auth.oauth2.GoogleRefreshTokenRequest.setRefreshToken(GoogleRefreshTokenRequest.java:119) ~[?:?]
at com.google.api.client.googleapis.auth.oauth2.GoogleRefreshTokenRequest.setRefreshToken(GoogleRefreshTokenRequest.java:74) ~[?:?]
at com.google.api.client.auth.oauth2.RefreshTokenRequest.(RefreshTokenRequest.java:95) ~[?:?]
at com.google.api.client.googleapis.auth.oauth2.GoogleRefreshTokenRequest.(GoogleRefreshTokenRequest.java:85) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.nesthelper.NestUtility.refreshAccessToken(NestUtility.java:198) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.nesthelper.NestUtility.(NestUtility.java:67) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.nestdeviceaccessHandler.(nestdeviceaccessHandler.java:36) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.nestdeviceaccessHandlerFactory.createHandler(nestdeviceaccessHandlerFactory.java:74) ~[?:?]
at org.openhab.core.thing.binding.BaseThingHandlerFactory.registerHandler(BaseThingHandlerFactory.java:129) ~[bundleFile:?]
at org.openhab.core.thing.internal.ThingManagerImpl.doRegisterHandler(ThingManagerImpl.java:664) [bundleFile:?]
at org.openhab.core.thing.internal.ThingManagerImpl.registerHandler(ThingManagerImpl.java:641) [bundleFile:?]
at org.openhab.core.thing.internal.ThingManagerImpl.registerAndInitializeHandler(ThingManagerImpl.java:1110) [bundleFile:?]
at org.openhab.core.thing.internal.ThingManagerImpl.thingAdded(ThingManagerImpl.java:515) [bundleFile:?]
at org.openhab.core.thing.internal.ThingRegistryImpl.notifyTrackers(ThingRegistryImpl.java:212) [bundleFile:?]
at org.openhab.core.thing.internal.ThingRegistryImpl.notifyListenersAboutAddedElement(ThingRegistryImpl.java:132) [bundleFile:?]
at org.openhab.core.thing.internal.ThingRegistryImpl.notifyListenersAboutAddedElement(ThingRegistryImpl.java:1) [bundleFile:?]
at org.openhab.core.common.registry.AbstractRegistry.added(AbstractRegistry.java:175) [bundleFile:?]
at org.openhab.core.common.registry.AbstractRegistry.added(AbstractRegistry.java:1) [bundleFile:?]
at org.openhab.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:60) [bundleFile:?]
…
Try to regenerate access token and replace with the new one. Then go to Inbox choos the binding run scan and add it again. It should wokr I think. access token is valid for an hour and if you do not start within this timeframe you get handler error. Plus set up the Refresh interval field to some seconds.
Normally it does not need. There is a certain time, if you check the specification of the API what is the expiration time if the keys. If you exceed it with idle time of your Openhab instance then you need new authorization code.
If you are using wborn’s development jar file for v3.0 openhab, there is a known issue where some data/tokens are not maintained persistently between restarts. Your stack trace differs slightly from what has occurred in 3.0 so not sure if slightly different problem or due to your running openhab 3.1. (see issue 8664).
If same problem as case of NullPointerException for 3.0 listed in issue 8664, you just need to delete and re-add the Nest Thermostat thing to resolve. I’ve not had to resort to generating new auth/refresh token (but I’ve also not gone extended period between restart and re-adding thing).
java.lang.NullPointerException: null
at org.openhab.binding.nestdeviceaccess.internal.nesthelper.NestUtility.isAccessTokenExpired(NestUtility.java:128) ~[?:?]
at org.openhab.binding.nestdeviceaccess.internal.nesthelper.NestUtility.getAccessToken(NestUtility.java:108) ~[?:?]
Ditto. Been over a week and my partner connection was not removed by Google after setting after setting status to “In production”. I had overlooked that option in past. Google’s verbiage is horrible in prompt making one think you had to verify app prior to setting to production. And I was unable to find any mention that Testing status would result in 7 day limit. Thanks for the tip @dschoepel !
