Nest issues

Hi, I’ve just noticed that I am unable to send commands via the Nest plug-in successfully, and that the current temperature that’s being reported differs from the Nest-provided web and app interfaces. I don’t have access to my Vera logs from here at the moment, so I’m hoping another Nest plug-in user could check their own functionality and let me know if they see issues, and if so, if I could get Vera logs to help me diagnose it. I am out of position to do this diagnosis myself from here as I don’t have access to my Vera logs. (If there is a Vera Control Ltd support person who could help me with that, I would appreciate it, otherwise it will be difficult for me to make any plugin changes.)

watou

Same problem here and I haven’t been able to check the logs. Perhaps Nest changed their API?

Just checked, and the plugin is working properly for me. I tested 3 of my Nests, and I was able to view status and control them as expected.

Maybe Nest is having an isolated outage that is only affecting a fraction of their users??

Working fine for me also. Can see the current temp and set point, as well as adjust it (was watching the Nest as adjustments were made via SQRemote)

I’m glad it’s still working for some users. I decided to change my password to force a new login, and now it won’t connect again, and I still have no visibility to my own logs to see what’s happening. Either there is an isolated outage, an isolated difference in the web interface, my IP was blacklisted, or Nest has instituted an API threshold that I’ve exceeded. Perhaps there are other possibilities.

If anyone else sees problems with the Nest plugin and can share some (sanitized) logs that show the errors, please share.

Regards,
watou

Interesting thought about you potentially being blacklisted. That’s always an unfortunate possibility.

Hopefully this isn’t a sign of bad things to come. I will continue to periodically check Vera’s ability to control my Nests, and will post here if something changes.

Good luck figuring it out. Hope it’s something simple.

Looks like the plugin is working here as well. There is some chance the Nest is disconnected from wifi. Of all the possible causes, this is certainly the one I have encountered most.

Glad it’s working for you, but I’m doubtful that the issue relates to the thermostat connecting to the mothership (nest.com), since I can still see and interact with it fine from the native web interface. It seems to do with the connection between the plug-in to nest.com. I have no signs of connectivity issues at the location where the thermostat and Vera are.

Is there a way that users can make use of Vera’s Account → Tech Support → Remote Access connection to my unit, or is that strictly for Vera support people?

Yes, if you can view the device via nest.com, then there is no wifi issue.

I am fairly certain that the Remote Access function you describe is strictly for Vera’s own support personnel.

Thanks. I will ask Vera support to get me the logs, but it’s understandable if they won’t do that (privacy, outside of support functions). In the meantime I’ve had to set my user name and password blank in the main plugin device to keep the plugin from repeatedly failing to communicate. Hopefully the logs, if I can get them, will shed some light.

If you have a PC that you can Remote Desktop into at your home, you can access Vera’s web page from there…

Good luck. Hopefully this is something really simple to fix.

I’m showing this in my logs:

luup_log:31: Nest: error getting status from nest.com with HTTP code=closed, status=nil

I’m trying to grep around to find any other relevant lines. Anyone know what I should be looking for?

Thanks

Thanks, if you have continued access to your logs, could you press the Set button next to your user name or password in the main Nest device, and then report what unusual Nest-related log lines you can see for a few minutes thereafter? (Making sure to obscure any user names, passwords or other identifying information that might appear in your log).

Much appreciated.

Set my username and here is the output. FYI, my email has been obfuscated

08 03/14/14 13:34:01.130 JobHandler_LuaUPnP::HandleActionRequest device: 31 service: urn:watou-com:serviceId:Nest1 action: SetUsername
08 03/14/14 13:34:01.130 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:watou-com:serviceId:Nest1
06 03/14/14 13:34:01.132 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: username was: eric@e********.com now: eric@e*******.com #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1
06 03/14/14 13:34:01.132 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: transport_url was: now: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1
06 03/14/14 13:34:01.132 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: userid was: now: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1
06 03/14/14 13:34:01.133 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: access_token was: now: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1
06 03/14/14 13:34:01.133 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: status was: 0 now: 0 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1

Thanks, @egoh. That is normal so far, but some seconds or minutes later it ought to show attempts to login and retain the session information, and then attempt to get status. If you have further log lines, please let me know. Thanks for your help.

If I try to set the temp, this is the output. FYI, userid and tokens removed

06 03/14/14 13:39:35.989 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: transport_url was: now: https://transport03-rts01-iad01.transport.home.nest.com:443 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0
06 03/14/14 13:39:35.990 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: userid was: now: [REMOVED] #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0
06 03/14/14 13:39:35.990 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: access_token was: now: [REMOVED] #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0
06 03/14/14 13:39:35.991 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: status was: 0 now: 1 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0
01 03/14/14 13:39:36.103 luup_log:31: Nest: error getting status from nest.com with HTTP code=closed, status=nil
06 03/14/14 13:39:36.104 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: transport_url was: https://transport03-rts01-iad01.transport.home.nest.com:443 now: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0
06 03/14/14 13:39:36.104 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: userid was: [REMOVED] now: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0
06 03/14/14 13:39:36.105 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: access_token was: [REMOVED] now: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0
06 03/14/14 13:39:36.105 Device_Variable::m_szValue_set device: 31 service: urn:watou-com:serviceId:Nest1 variable: status was: 1 now: 0 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0

It’s interesting that, based on the transport URL nest.com returned, it appears that your and my Veras may be in the same geographical area, but that may be wrong or insignificant. While the login seems to be permitted, it falls apart at some point thereafter. I hope this is an operational issue, not an API change, but I would need more to go on. Thanks very much for your log information. If anything else appears that might be interesting, please pass it on.

Otherwise, blank out your user name or password in the main Nest device to keep the plugin from repeatedly trying and failing.

Regards,
watou

What was your polling frequency set to? Mine was 120 seconds. Any idea what Nest allows for their API?

My polling is set to the default 120 seconds. To my knowledge, there is no published answer to that question yet. I imagine/hope that the forthcoming official API will be explicit in how much API usage is permitted over time.

Taking a complete stab in the dark, I changed all of the uses of “sslv3” in the HTTPS calls to “tlsv1”, knowing that sslv3 is considered insecure nowadays. And so it seems to have worked.

@egoh, would you try the attached file? (going to Apps → Develop Apps → Luup files, check “Restart Luup and upload,” choose the attached I_Nest1.xml, and press GO)

If it works for you as well, I think it will be safe to update the plugin to 1.5 with this one change.

watou