@jebro thank you!
That’s what I was searching for.
Maybe im bad luck or maybe this isn’t for me. I was able to get to the part where i have to paste that CURL thing on terminal, so far I am getting curl: (3) URL using bad/illegal format or missing URL or a Error 400 bad request return .
bad/illegal using the code provided by google and 400 bad request when i remove the lines and leave the url into one single line. does anybody else had this problem?
I also managed to figure out the google part, everything went done by the book
Now, getting back to the binding, I have tried all the ways as described in the above posts by using the binding directly from Paper UI and adding the values for project, client, secret, auth code. I tried all combinations popssible for auth code but each time im saving the binding i get a 500 error , tried the .cfg file as well but still no success. if someone made this work, can you please share how did you made it work? it was via Paper UI or? thanks a lot.
Things that slowed me down getting this to work:
- authorizationToken is really access_token
- Setting up params with paperUI does not work. You need to create nestdeviceaccess.cfg and update props here.
- nestdeviceaccess.cfg also needs the following values else you get a NPE on startup: serviceAccountPath, subscriptionId, pubsubProjectId
- serviceAccountPath is the path to an oauth credentials file that you must download from google api console
- subscriptionId, pubsubProjectId values are created when you create Pub/Sub topic in google device access console
The authorizationToken is not an access_token. It is the initial authorization token provided and is a one time usage. The access token is an hourly expiration token that is provided by the initial refresh token and access token request. The refresh token is what is used there after to refresh the access token hourly.
The reason it is easy to get the two confused, is that the authorization token is never used again after it’s initial usage.
The nestdeviceaccess.cfg needs the properties for serviceAccountPath, subscriptionId, pubsubProjectId defined but they can be empty if you don’t want to use the pubsub functionality. If you want to utilize the pubsub function, you will need to setup pubsub capabilities on your project and assingn a service account to view the subscriptionId messages.
I strongly recommend the pubsub functionality because it is required for camera functions and is faster than polling via the API. Also, there is a SDM API limitation imposed by Google for non-commercial projects where the Pubsub doesn’t have that requirement… i.e. Tune down the asynchronous poll and leverage the pubsub functionality…
I’ve been away on some personal business but will start to help as I can with the questions being posed.
I’m sorry that there was some figuring out on some things to get this working… I may create a new project and follow the documentation to ensure it is clear… Then I can update to help folks set this up from scratch… That may help here…
Hello there… PaperUI should only be used once nestdeviceacccess.cfg is setup with at least a valid projectId, clientId, clientSecret and refreshToken. Once you verify via openhab-cli console -> config:list “(service.pid=org.openhab.nestdeviceaccess)”
Then you go to inbox->±>nestdeviceaccess and the discovery service will discover devices from Google via the SDM API.
If you are trying to setup nestdeviceaccess via PaperUI manually, this means that the nestdeviceaccess.cfg was not setup properly and the discovery service failed… This may be something that I need to change to avoid the confusion here because the manual method is not supported in the binding.
Just to confirm, you have not gotten an initial authorizationToken? If that is the case, this could be a setup issue with your Google project configuration and not much an issue with the binding… Google’s directions on how to set this up are pretty good…
If you did get the authorizationToken already via the above procedure and retrieved your refreshToken and initial accessToken. Then you can configure the binding at this point via nestdeviceaccess.cfg. I can look at your debug logs and see if I can help with the configuration.
-Brian
The json response from google has the fields access_token and refresh_token. I didn’t see anything called authorizationToken.
They can be empty, but if props don’t exist you get a NullPointerException due to toString call.
I hope you didn’t think I was complaining. I was just trying to share some of the things I had to work through. I’m happy to have something to control my thermostats again. Everything seems to be working now.
Hello Brian
1st of all: Thank you for your work.
I wanted to start from scratch just to make sure I will provide all the information needed in order to help you troubleshoot the issue.
The problem was from my end, as I got messed up with the auth tokens and after reading your reply to James about the authorization token , I updated the values in nestdeviceaccess.cfg and somehow the thermostats showed in my inbox.
In my nestdeviceaccess cfg file i have the following:
project id
client id
client secret
authorization token
refresh token
I also tried sending a command from Control page in Paper UI to change the target temperature and so far it updates the value, nest app also show the updated value which means i am going somewhere
Now, a dumb question, will i need to manually update the refresh token each hour in the nestdeviceaccess cfg file or this will work as it is? i saw in this topic some posts that had rules with some curl commands. If i have to do so, what would be the best automation way for this?
I also seen that you strongly recommended to use the pub/sub functionality, will this be needed in my case where i only have to set target temperature and mode for my thermostats?
Thank you very much!
No issues at all… Yes, when you authorize your devices to the Google project at this step:
https://nestservices.google.com/partnerconnections/project-id/auth?
redirect_uri=https://www.google.com&
access_type=offline&
prompt=consent&
client_id=oauth2-client-id&
response_type=code&
scope=https://www.googleapis.com/auth/sdm.service
It returns back an “Authorization Code”, I called it an authorizationToken (Code would be more accurate…)
You then take that “Authorization Code” and retrieve your first accessToken and refreshToken.
I hope that helps explain.
Yes, the pubsubProjectId can be empty if you don’t need pubsub functionality but it must be present as you identified with the NullPointerException… I’ll see if I can fix that…
I’m actually REALLY glad you are helping contribute for others… Keep doing that… 
Thank you for all the help… I just wanted to explain the authorizationToken/Code piece to clear things up… Thanks again
1 Like
Awesome that it is working… Yes, the authorizationToken/Code will get folks tripped up… I’m glad you got this working… Next challenge for you is to setup the pubsub
My preference is to use pubsub because it updates the thermostat status faster and uses less SDM API calls…
No, there is no need to update the nestdeviceaccess.cfg further unless you want to set the pubsub configurations up… The refreshToken is used in the binding and will update your accessToken hourly or when it detects it is expired.
I hope that helps… BTW, no question is dumb and I’m really glad this is working for you…
-Brian
Thank you very much Sir! I really appreciate it.
So far I can see binding and things are still working , when i change target temperature it sends the command instantly and everything seems to work perfectly. so far I have not encountered any issue. hopefully i’ll be lucky enough to configure a Nest lock the same way.
After 3 days of trying i am really happy that it finally works and my log is error free lol
I just installed and finished testing the binding with Pubsub and all seems to be working fine. I have two thermostats. I also have four cameras of varying generations drop and nest cams. These were discovered but show up as nest doorbells. Happy to test the camera feature once its added to the binding. Thanks for all the hard work and hints on how to get this working… @wborn and @BHigg!!
Great to hear… BTW, the class that I used generically was called NestDoorbell. I later found out that the only difference between Doorbells and Cameras was the chime 
My original idea was to have individual classes for Doorbell and Cameras. Therefore, I reused the Doorbell class handler vs coding separate classes. This is why Cameras show up as a Doorbell ;(
I’m going to refactor the binding to rename to a generic camera class but this may require rediscovery of devices as a result… I know, cosmetic but I’m OCD a bit…
I’ll report back when that is done…
I noticed there was very little difference between the doorbell and camera structures and being equally OCD, thanks in advance for updating the binding - it may just reduce one more thing folks try to resolve when troubleshooting problems. No issues with rediscovering devices, that’s the easy part… Being fairly new to using APi’s and Google’s systems I plan to document the steps I went through to get this up and going - while the Google instructions are good, they do assume your a developer and are familiar with the terminology.
1 Like
I have an old developer account and until recently was able to manage my devices, but I upgraded openhab and my token seemed to expire.
I am unable to get to the old webportal to create a new one. Does anyone know how to do this - or failing that, would you say this binding is stable enough to manage thermostats (all I care about right now) and is there a simple guide for getting this going?
From the readme, it looks like you are simply saying duplicate the .cfg file into your file structure, then drop the jar file and do the rest in PaperUI - unless you want to create your own project from scratch? I am not quite clear on what actually needs editing in the Google Web portal to get this going?
Thanks for any help…
@bulletprooffool I was in a similar situation like you, except I didn’t had a old web portal from nest. so here’s what i did to make this work:
- go to Google cloud console, create a new project, name it how you want.
- after creating the project, go to api and search for google sdm and enable it
- Create credentials for Oauth by configuring the consent screen and etc, please note: developer email and support email needs some email addresses, also redirect url should be https://www.google.com/ , there’s no need to fill in other domains or policy pages
- go to google device access portal and register for a subscription, it will charge you 5 usd
- create your project, copy your auth client id from the project you created in cloud console
and follow these steps: https://developers.google.com/nest/device-access/authorize
Please note: the authorization token is represented as access token in cfg file as @BHigg explained in above reply
Also, on Oh part, please make sure you don’t configure nothing via paper ui
all you need to do is to put the .cfg file in the proper path, fill in the fields and it should work. at least that’s how i made it work after at least 6 attempts.
Let us know if these worked for you
1 Like
Hello @BHigg , have you ever took in consideration to implement the Nest Yale locks into this binding? so far it works like a charm for the thermostats, it would be very nice addition to include these locks as well. please let me know what is your thought on this one and thanks for all your help and contribution brought here
Wonderful - thanks - will do this and hopefully get some testing going. Appreciate the help.
Not 100% sure on this but if you currently have a legacy Nest account, you will need to migrate to a Google account. This is the only way your devices will be given authorized access to the API. Migrating your Nest Account to a Google Account. I had to take this step before the binding would see my thermostats and cameras. Hope this helps…
Thanks Dave - I figured that would be the case, but held off in hope of getting the old binding going.
Seems enough people have this working, so I’ll have a crack at it.
Thanks for the help