I can also be a tester with the Nest IQ Outdoor camera and Nest Doorbell. Thank-you!
I was able to get the token and renew it. How do I use it now to get i.e. temperature from a thermostat?
Do I need to manually create a thing for the thermostate?
Hi,
to retrieve data youāve to call a GET in a rule like below:
val string NestCommand = "C:/Curl/curl.exe -s -X GET \"https://smartdevicemanagement.googleapis.com/v1/enterprises/RESERVED INFO/devices\" -H \"Content-Type: application/json\" -H \"Authorization: Bearer "+NestToken.state+"\""
logInfo("Nest", "Nest Command {}", NestCommand)
val String NestStatus = executeCommandLine(NestCommand, 120*1000)
logInfo("Nest", "Nest status {}", NestStatus)
Youāll see the response in openhab log
Itās a primitive way to do but itās working, remember Iām not a programmer 
It would very appreciated if you time to work on a binding, as you see Iām just testing the new Google approach but my programming skills are limited so any help from a software guy is welcome
I have a couple of nest protects and can help with testing for those devices.
Interested to work on the binding, Iām getting my Nest thermostat next week, and looking to hook it up with openHAB. If thereās a Slack channel set up or something, let me know, otherwise Iāll start working on one next week 
2 Likes
Iāve started working on a basic Java Wrapper for the google nest here: https://github.com/Lovett1991/Google-Nest-Java-API/tree/init/src/main/java/com/alexlovett/nestapi, was going to finish some models first and then work on either a PR, or possibly a new Binding as to leave the old nest one alone (I donāt know what the preference of the community is).
Iāve managed to hit the api, although getting the oauth token was a bit of bother. Example response below:
{
"devices": [
{
"name": "enterprises/50c23437-496d-4346-8ab5-025ad314f588/devices/AVPHwEugs3UXY24WnpmWAHPGCxWvWibmfuIsGkNtqwtNxfgukru42yGkOqE7mvPM7pJPzrNPprSX3QNt2RtVMWscbxmIJg",
"type": "sdm.devices.types.THERMOSTAT",
"assignee": "enterprises/50c23437-496d-4346-8ab5-025ad314f588/structures/AVPHwEtcHnbHeXrGt5OzvtHSB4UfL6Nc0f1ZW4jx7l3LIIyoL3ZgzXlsMt29dgX-tRV905UBtZ7bGTPRspMp9-s44U27AQ/rooms/AVPHwEtRuiPChXZytLkGbuZ84PN1ehtCpjMRMMUguULj6dmlkmG44N_sF6hWYeu2aM2_WoAC6V7OQyjHEOgZnhIPIxWBR11flQihzgOWiFm6NaZaaqDnpYjctLcWu7tssom6WrN-wsKmayI",
"traits": {
"sdm.devices.traits.Info": {
"customName": ""
},
"sdm.devices.traits.Humidity": {
"ambientHumidityPercent": 70
},
"sdm.devices.traits.Connectivity": {
"status": "ONLINE"
},
"sdm.devices.traits.Fan": {},
"sdm.devices.traits.ThermostatMode": {
"mode": "HEAT",
"availableModes": [
"HEAT",
"OFF"
]
},
"sdm.devices.traits.ThermostatEco": {
"availableModes": [
"OFF",
"MANUAL_ECO"
],
"mode": "OFF",
"heatCelsius": 10,
"coolCelsius": 24.44443
},
"sdm.devices.traits.ThermostatHvac": {
"status": "OFF"
},
"sdm.devices.traits.Settings": {
"temperatureScale": "CELSIUS"
},
"sdm.devices.traits.ThermostatTemperatureSetpoint": {
"heatCelsius": 15.36406
},
"sdm.devices.traits.Temperature": {
"ambientTemperatureCelsius": 20.73999
}
},
"parentRelations": [
{
"parent": "enterprises/50c23437-496d-4346-8ab5-025ad314f588/structures/AVPHwEtcHnbHeXrGt5OzvtHSB4UfL6Nc0f1ZW4jx7l3LIIyoL3ZgzXlsMt29dgX-tRV905UBtZ7bGTPRspMp9-s44U27AQ/rooms/AVPHwEtRuiPChXZytLkGbuZ84PN1ehtCpjMRMMUguULj6dmlkmG44N_sF6hWYeu2aM2_WoAC6V7OQyjHEOgZnhIPIxWBR11flQihzgOWiFm6NaZaaqDnpYjctLcWu7tssom6WrN-wsKmayI",
"displayName": "Living room"
}
]
}
]
}From what I read, you shouldnāt need to do this. The refresh token is valid indefinitely. We can just keep polling the api until we receive a 401, and then grab a new token on that event. OkHttp has functionality to do this for us.
@McFly I have to reply here Iām afraid, the comment limit is 3 for new usersā¦
Yup, there are 2 tokens, one is for accessing the data which expires after an hour (as you stated), the other is the refresh token (as youāve stated), when I looked it up, it seems that the refresh token doesnāt expire, but it can obviously be revoked by the user.
For what I understood we have 2 tokens
One to be renewd every hour. This should be the one used for normal poll.
The second is for requests the renewal of the first one. I donāt know if and when this expires.
Iāll probably add it to the existing binding and then remove the old implementation when the API is dropped so users can migrate whenever they want.
Itās also a lot easier to implement everything in the existing binding using libraries that are already part of the openHAB target platform, instead of implementing it in a third party library with non standard or incompatible openHAB dependencies. That reduces overhead and makes it easier to fix bugs or add new features in the binding.
6 Likes
Iāve created an issue for this
Does migrating your old Nest Account to a Google Account break a current setup? I do only have a lot Nest Protect but I want to try Googleās own Home & Away Routines.
I canāt answer your question, but I also only have a Nest Protect and I noticed that itās not included in the Device Access Console. I canāt think of any reason other than ābecause Googleā.
1 Like
Because google acquires the separate devices and tech from different companies and builds a product family. It takes a while to re-engineer the back ends of these devices to all talk on the same API. The process has to be done carefully as to not break what is already working. Some devices are so radically different they will never be fully added, new version will be manufactured and they have to end of life others. Itās a slow process.
I took on the dubious task of learning the SDM API and using device access along with binding development (Especially after my Nest integrations broke when I migrated way from āWorks with Nestā )
Here is what I got thus far:
setup non-commerical GCP project for SDM API - check
setup pub/sub in the project - check
authorized my Google/Nest account with GCP project -check
coded an Openhab binding that works with thermostat base functions (getDevices, getStructures, etcā¦) - check
coded an Openhab discovery service that enrolls things from the project device listing -check
Iām now going through adding handlerCommand actions for the thermostat channels (I donāt have cameras or other devices to test.) Since I have most data from the Devices listing, the informational items like ambient temperature, current modes and settings will be very easy to add. Then Iāll move on to changes like setpoint updates in temperature setting, mode changes etcā¦ Lastly, finishing with a pub/sub topic integration to feed events into the handler.
I went down this route because:
1 - Learning Google oAuth and SDM programming is fun and wanted to do my first project with it
2 - I migrated away from āWorks with Nestā and found that I havenāt had nest integration with my thermostats until this binding development
Iāll probably complete this binding for my need since there isnāt an āofficialā binding out there that I can use.
I suppose my question is whether there is an āofficialā binding in the works or if what Iām working on sums up to more than a pet project? Iām happy to share code or the binding if there is an interest. If there is an official binding in the works, then this was a great experience either way 
3 Likes
That would make sense if the Protect wasnāt already part of the same family as the other Nest products, and if it hadnāt taken them well over a year to go from shuttering Works with Nest to releasing the Device Access Console. However, as far as Iām aware (and please correct me if Iām wrong), the Nest thermostats, cameras, and Protects were designed by the same people from the start. This isnāt like TP-Link buying the Tapo IP and running it alongsideābut separately fromātheir existing Kasa devices.
Donāt get me wrongāIām generally cool with Google and have defended the company a fair amount in this forum, but itās impossible to ignore their practice of abandoning products by quietly dropping support in the hope that no one will notice. Thereās a decent chance that the Nest Protect will suddenly appear in the DAC one day, but itās also entirely possible that Google is no longer interested in supporting smoke/CO detectors or putting more development time into the ones theyāve sold.
Personally, Iāll be fine with the Nest Protect so long as the app continues to work. Integration aside, itās a great smoke/CO detector. Itās just disappointing that it hasnāt met its potential.
Yes Iām working on getting the new SDM API supported in the official binding while keeping the WWN API support also working (see also #8664). The new SDM API doesnāt support all features that WWN does, so for instance users with Nest Protects would lose their complete Nest integration.
Please do because I hate reinventing wheels! 
Perhaps you can push it to a GitHub branch so I can have a look at it?
Now that we have a pretty stable OH 3.0.0.M1 (which was my main priority) I will shift my priorities to getting the Nest SDM integration added to 3.0.0. It wouldnāt make much sense to use the updated Nest Binding when OH3 itself is unstable. 
5 Likes
You might be right. Iām irritated now because I canāt use my google suite account wit their new API, and app. And now my nest products are Dead until I create a NEW gmail account that is not gsuite. Which irritates me. I PAY extra for a google account I canāt use with GOOGLEās product.
Sorry for the delayed response. I took sometime to refactor the binding to allow for individual device classes (i.e. Thermostat, doorbell and camera.) The Thermostat class if pretty much fully functional with Nest Thermostats SDM APIs. Also, since there is a way to set Eco it could replace the AWAY function in that you set an away switch and it triggers ECO mode. There are definitely some items missing from the WWN implementation and integrations with other products that is a bummer. For folks like me that migrated and canāt go back to WWN, the binding does the trick.
Iām going to do some testing tomorrow/this weekend and then I can post the code for folks to review. Iām sure there are items/fixes to make that others will see
Also, right now Iām operating off a non-commercial project with the SDM APIs enabled. Is someone going to create a commercial project?
The way the binding is written is you update the projectId, clientId, clientSecret, initial authorizationToken and it will go get the refreshToken. From there it performs a discovery against devices that you authorized on the project and are accessible by your accessToken. Then you can begin working in OH with the things.
Theoretically you can fill those fields out and tie the binding to any SDM enabled project. Iām just using a sandbox for now to get the binding up/tested
To do:
Get pub/sub up and running (Leveraging refreshScheduler at 30s intervals for now.)
Get camera class written
get doorbell class written.
Congrats on the OH 3.0.0.M1 stabilityā¦
3 Likes
Great to read that!!!
Waiting for your news
When youāre ready Iām here for testing
Thanks for your time