I've also just checked my security /floodlight camera. The Motion option was enabled already (with the notifications option disabled) so I am assuming this is why this camera has worked more reliably than the doorbell.
Thanks
Steve
The original API implementation from Google (and still the case for legacy Nest devices before the Google acquisition/assimilation) only provided one event, essentially a STARTED event - the timeout was part of my development to handle this as a "sensor" in Hubitat. When Google released their own hardware under the Nest name, they added the different event types, so the code no longer uses that timeout for such devices - under the assumption that we would always get an ENDED event, too. The goal was to be more accurate, e.g. if the actual motion period was shorter/longer. Only if the event does not specify, does the App assume a legacy device and apply this timeout, under the current code.
1 Like
Sorry for missing that one, and thanks for filing the issue and for creating/maintaining this integration!
I searched in the thread a few times and didn’t see an answer to this question, hoping someone has done this before.
I may upgrade from my Gen2 to Gen3 Nest, do I have to totally redo this entire process or does it only require minor changes?
Any insight is appreciated!
All that should be required is that once the device is installed and added to your Nest/Google account, go to the App, click the Auth Link to validate/enable permissions for the new device, then click the Discover button to generate the associated Device in Hubitat.
Hi @dkilgore90
I just got my hub a day ago and this is a very stupid question I got step 14 and now I can't find SDM Api App location so I can create the new app. Can you point me to the right direction
Thanks for confirming! I didn’t want to touch anything and mess up the integration. It worked just as you stated. Thanks again!
I have a similar issue as KYBourbonGuy but the re-Auth and Discover doesn't work. My problem started after I had a several hour internet outage and when it was restored 1 of my 3 thermostats didn't come back completely, it was connected to WiFi but not to the Nest app, It was still controllable through ActionTiles via Hubitat. The only way I could get it back on the Nest app was to reset it and re-add it to the account, that was successful but after that I could no longer control it using ActionTiles and Hubitat. I initially tried deleting the device from Hubitat and using the Discover button to bring it back with no luck, so I tried the re-Auth and Discover process, that still didn't work but it did grab another thermostat that I have at another location using the same Nest account so I know the process was basically sound. I'm running out of ideas, any suggestions would be greatly appreciated.
I am using the Nest thermostat (Gen 2) in conjunction with the Hubitat Thermostat controller. All has worked well from last winter until a few days ago.
Now when the thermostat controller sends an update to the Nest, I get:
executeCommand sdm.devices.commands.ThermostatTemperatureSetpoint.SetCool response code: 400, body: { "error": { "code": 400, "message": "sdm.devices.commands.ThermostatTemperatureSetpoint.SetCool command not allowed in current thermostat mode.", "status": "FAILED_PRECONDITION" }}
In the google SDM API logs.
However: I can control the Nest thermostat through the device itself.
The only other thing that I am seeing in the logs is:
com.hubitat.app.exception.LimitExceededException: App 1249 generates excessive hub load on line 476 (method handleDeviceGet)
Note: app 1249 is the Google SDM API application
What and how did I break this? Any ideas?? Thanks!
Hmm, seems like HE is out of sync with the current thermostatMode of your actual device, which causes it to send the wrong command, instead of mapping correctly, e.g. setCool if in cool mode, setRange if in auto/HEATCOOL mode.
Likely this out of sync state is related to the severe load you mentioned... Is this being logged frequently? Or just once? Do you have debug logs enabled? The surrounding log entries from the App would help, to provide more context of what sequence is running when this occurs.
I have a similar issue as KYBourbonGuy but the re-Auth and Discover doesn't work. My problem started after I had a several hour internet outage and when it was restored 1 of my 3 thermostats didn't come back completely, it was connected to WiFi but not to the Nest app, It was still controllable through ActionTiles via Hubitat. The only way I could get it back on the Nest app was to reset it and re-add it to the account, that was successful but after that I could no longer control it using ActionTiles and Hubitat. I initially tried deleting the device from Hubitat and using the Discover button to bring it back with no luck, so I tried the re-Auth and Discover process, that still didn't work but it did grab another thermostat that I have at another location using the same Nest account so I know the process was basically sound. I'm running out of ideas, any suggestions would be greatly appreciated.
Ah, sorry. Saw your post before but forgot to respond. It's possible that the thermostat has been placed under a different "Home" in Google, but within the same account.
After clicking the Auth Link, the resulting Google steps may have a drop-down at the top to select a home.
Yup, that was it. Thank you so much, it was driving me crazy(er) 
The log for LimitExceededException ... was occurring every 5 minutes or so. I can only go back so far in the logs (that I know of?) and I can't get anything before this a.m. on the past logs. BUT, after I read your post last night, I was wondering if a power outage we had the day before this started happening contributed to the out of sync issues. We were out for about 11 hours. Everything came back up so I didn't think about it, but if. the sync issue maybe the Nest thermostat didn't reconnect at the same time--its kinda slow to rejoin the wifi when it loses power.
This may be a coincidence. But I rebooted the hub and everything is working fine so far.
For those who were having trouble with setpoints while in auto/HEATCOOL mode, it seems like this issue has disappeared, or at least improved - several comments on the ticket that it is working, and I've verified my 3rd gen thermostat is working as expected again now via this integration.
1 Like
It was acting up a week ago, and it seemed to be related to me setting a setpoint in HE that had no decimal places. In HE, if I went to my thermostat, setHeatingSetpoint=25 then it seemed to pass through nothing for heat (null), so it defaulted to cool, and tossed an error with the call since it was expecting two temps. If I entered 25.0, then it was fine.
Might have been just a red herring, and they fixed the backend while I was playing with it, no clue, but it seemed to toggle between work/not work with the above. Looking at the code, makes no sense why that would matter though, unless Google was having an issue of no decimal places on their side.
I apologize for the question as I'm sure it was answered somewhere in the last 1097 posts, but I couldn't find it by searching or within the last chunk of posts.
With Google retiring the Works w/Nest program and servers at the end of the month, I'm wondering if this SDM integration will work in October and beyond. I've been running the MyNext Manager for a couple of years now, but that was built on the WWN servers and is ending soon.
2 Likes
Yes, this post from Google mentions that Device Access (which includes the SDM api) is the new/ongoing interface for integrating with Google Nest devices. So this integration will remain functional when WWN is retired.
The one unfortunate point is that Nest Protect (smoke/CO detectors) was never included in the new API provided by Google, even though it was exposed by WWN
2 Likes
I noticed that and as I was setting up a secondary integration for my family cabin, they (Google) even showed a picture of a Protect on the Create a Project page.
