Nest binding updates

Nest Labs is rolling out firmware updates for thermostats to version 5.6, and have updated the Nest API to expose new information and function made possible with this firmware update. I’ve submitted a pull request and provided a test JAR for you to test.

Once you have the new firmware rolled out to your thermostat(s), upgraded your product definition at developer.nest.com to include the v6 permissions, and re-authorized your account with a new PIN and added the PIN to your .cfg file, you should be able to access the following new fields of thermostat devices:

  • eco_temperature_high_f (replaces “away” temperatures with more generic purpose, away_* deprecated)
  • eco_temperature_high_c
  • eco_temperature_low_f
  • eco_temperature_low_c
  • sunlight_correction_enabled (whether you have enabled sunlight correction)
  • sunlight_correction_active (is the sun shining directly on your thermostat?)
  • where_name (simpler way to access where in the house your thermostat is)
  • fan_timer_duration (set the number of minutes to run the fan)
  • time_to_target (minutes until the structure will reach target temperature)
  • time_to_target_training (whether still in training or ready)
  • previous_hvac_mode (the last-selected hvac_mode)

You will also now be able to set hvac_mode to “eco”.

Please report successes/failures here when all of the above test conditions are in place, and thank you!

4 Likes

You are faster with updating the binding than Nest is with updating my Thermostat! :wink: Is your thermostat already updated?

Will the old binding still continue to function properly after firmware update? I think it should if their API versioning properly works.

1 Like

No; my thermostats are still at v5.5. The old binding should continue to work after the firmware update, but lack the new fields. Nest gets into greater detail about the transition to v5.6 firmware here:

https://developers.nest.com/documentation/cloud/eco-transition-guide

OK thats good news! Also that there is actually some new functionality in the update. To me their consumer communications looked like they had spent months in meetings to rename Auto-away to Eco. :smile:

1 Like

Well the “Away” setpoints should have always been called “Eco” setpoints, and the restrictions on controlling the thermostat when in “Away” mode should never have been there, so these are good improvements! But yes, I shudder at the thought of sitting in endless meetings talking about what to call things. :smile:

Any reason this wouldn’t be able to parse the 5.5.1-6 TStat JSON?

I’ve reconfigured to add the requested v6 Nest perms, PIN etc, along with the new Binding code (using a 1.8.3 openHAB), and it’s having issues parsing the JSON response:

11:50:57.398 WARN  o.o.b.n.internal.NestBinding[:173]- Exception reading from Nest: Could not parse JSON from URL 'https://developer-api.nest.com/?auth=

It provides the response JSON, which parses correctly in JSON Lint, but the new binding code appears to have some sort of issue with it.

I’ll PM you a private copy of the JSON in case there’s something else amiss.

Thanks for testing, @guessed, and sorry about the bug. I misread the docs on the type of time_to_target. I’ve updated the PR and test JAR linked there, if you don’t mind giving it another try.

Thanks for the quick fix, all working again now :smile:

1 Like

My thermostat got updated a few hours ago so I’m now also running the updated binding. So far so good and everything is working well so far :+1: @watou. As a basic test I added eco low/high temperatures :seedling: and also see these in Basic UI.

I did go through updating the permissions but not the pin-process. I logged into my nest.com account and saw the message “A client has been updated” and approved it. That seemed to be enough in my case to let it start using its new permissions.

1 Like

Interesting…Nest must have simplified this from the previous requirement to create a new PIN when permissions are changed. Thanks very much for testing the changes (and also to @guessed, who had to try three times before the code was right :slight_smile: ).

1 Like

The values for all new properties seem to work for me (including writing/reading eco in hvac_mode). The only value I didn’t test test is fan_timer_duration because I don’t use cooling. You didn’t list the new label property in your opening post/PR but you do support it.

It is also worth mentioning that you already updated the Nest Wiki (that does list label). The updated Wiki is also useful for determining the correct item types (Number/Switch etc). I first thought the sunlight items weren’t working due to using the wrong type. Its easy to start using the wrong item types when mass testing with copy/paste values! :wink:

1 Like

@watou,
For diagnostics, have you considered Logging the “error” response field, from the HTTP-400 responses?

I had a permissions misconfig, and enabled trace to see:

13:59:55.776 WARN  o.o.b.n.i.m.AbstractRequest[:153]- Method failed: HTTP/1.1 400 Bad Request
13:59:55.777 TRACE o.o.b.n.i.m.AbstractRequest[:172]- {"error":"No write permission(s) for field(s): away","type":"https://developer.nest.com/documentation/cloud/error-messages#no-write-permission","message":"No write permission(s) for field(s): away","instance":"...","details":{"fields":"away"}}
13:59:55.778 ERROR o.o.b.n.internal.NestBinding[:388]- Error updating data model: DataModelResponse[devices=<null>,structures=<null>]

Having the error component from the TRACE would save a diagnostics step.

I think this will work, but I haven’t created a test scenario that would create the additional logged data.

EDIT: I have just updated to the new binding, and it reads fine! So please ignore my post below, which I’ve left for the sake of completeness!

I’m using the original 1.8.3 Nest binding still. Everything is working okay except when it’s set to Eco mode.

My Nest is brand new, and I’m still learning how it learns… I have the iphone app which is supposed to sense my location, but when I’m away, it doesn’t seem to set the Nest to away.

In fact when I am away, and I manually set the Nest app to away, it switches itself back to home. So my heating is always on…

Then I noticed that when I set it to away, my OpenHAB bus shows:

2016-12-03 13:36:48.935 [WARN ] [.o.b.nest.internal.NestBinding] - Exception reading from Nest: Could not parse JSON from URL 'https://developer-api.nest.com/?auth=c.i4kEblDzuwY

[loads more json]

I think what is happening is this: when I set Nest app to away (or the iphone location sets the app to away), the OpenHAB binding is failing to read the settings because of the error above, but it IS updating the “Away” setting which is currently set to Home in OpenHAB. Therefore OpenHAB is writing “Home” to Nest, instead of reading “Away” from Nest…

Is that the cause? Should I therefore update the binding?

Sorry if this is obvious!

All versions of the Nest binding prior to the recent update for October 2016 API changes should be updated to that version, because earlier versions cannot understand the new hvac_mode called “eco”. So the older binding won’t update any other items while the thermostat is in “eco” mode, and you will see those errors in your logs. The API also deprecated the “away” target temperatures, in favor of the new “eco” target temperatures.

You can remove the binding JAR from your addons folder, and put this one in its place, and openHAB 1.8 runtime should just carry on from there.

Got it, thanks @watou.

Different question: is there a way to make the target temp show what it actually is, when in Eco? In my case, when I’m away the target temp should show 8*C.

Or should I set up an item for eco_temperature_low_c and use a rule to use that number when Away is set?

Also I’m a bit confused, what’s the difference between target_temperature, target_temperature_high, target_temperature_low?

Also the difference between eco_temperature_xxx and away_temperature_xxx? (I note the Nest API documentation still has both of those - is the away version just for Nests that haven’t had the firmware update yet?)

The Nest Examples wiki page is now slightly stale, but it shows a way to use the visibility attribute depending on the state of other items. I would be happy if you or someone updated the Nest Examples page to correctly consider the new eco mode and setpoints, and stopped demonstrating how to use the now deprecated “away” setpoints.

If your hvac_mode is heat or cool, then the single setpoint target_temperature_[fc] is used. If the hvac_mode is heat-cool, then you have to specify a range with the high and low setpoints.

If your hvac_mode is eco, then the eco_temperature* setpoints are used. the away_temperature* setpoints are deprecated with the new 5.6 firmware and October 2016 API update. Please see the API Release Notes for more info.

I also now see that Nest updated the API in November as well. I will have to do a new pull request to address those changes…

Wanted to add a note here for all who are getting these updates:

I wasn’t aware of this change, however I began to notice that my thermostat wasn’t going to “away” temperature settings despite showing away. I found this thread while searching on this topic. I updated my openhab installation and now have the functionality of being able to set eco temps separately from the Home/Away status of my Nest.

After this update, I was thinking that I was going to have to change my openhab rules to not just change my Nest from Home to Away when I left, but also set the eco temps. I got confused when I read over the guide on eco transition: https://developers.nest.com/documentation/cloud/eco-transition-guide. In that guide it says that when the Nest goes to Away, it is supposed to automatically change to eco temps. My Nest wasn’t.

Turns out this happened because I had, in the past, turned off the “Auto Away” feature on my Nest. I found that due to the location where my Nest was installed, it would incorrectly think that I was away and turn off the heat/AC. That option has changed now to “Home/Away Assist”->“When you are Away”->“Automatically use Eco temps when no one’s home?”. I changed the to Yes and now this feature works as advertised. There is also a new (I believe) option under “Home/Away Assist”->“What decides if you are home”. I turn off the Thermostat sensors option and I still won’t run into the “false away” issue I had in the past.

Thanks to @watou for all of his hard work on this binding!

2 Likes