API auto-away state deprecation

release-notes

#1

I read in the What’s New? release notes article titled ‘New things for fall - October 2016’, that there is a change to the API structure, the away states will now be either “home” or “away”, adding “(‘auto-away’ is deprecated)”. It’s November 14th, and I’m still seeing the ‘auto-away’ state being used. Two questions:

  1. Is ‘auto-away’ state for the ‘away’ field under ‘structure’ really being deprecated? If so, when?

  2. If it does go away, the ‘away’ state will mean two things – away and auto-away. How can an App know if the Away state means that a user manually set the state overriding the Home/Away Assist processing or the state was set by Home/Away Assist processing and will automatically be set to ‘home’ when appropriate?


#2

Auto-away will still be seen in the API if the thermostat itself still supports it. Thermostat versions below 5.6 will still have it, while everything above will have ECO.

You’re right that without auto-away a developer wouldn’t know if the transition happened manually or automatically.


#3

Thanks urman for the response.

I’m only concerned with integration using the API, not what any of the devices display. The API documentation appears to be updated to correspond with the recent release notes.

Since the Oct '16 release notes article explicitly states ‘auto-away’ state will be deprecated in the structure, I’m concerned why I’m still seeing ‘auto-away’ as a state, and will it still be going away soon? More importantly, my original question, how will an app know if Assist will set the state back to ‘home’ appropriately. Am I missing something, or is Nest removing visibility to this?

BTW, I noticed another change in devices regarding this issue, too. Previously, there needed to be thermostat present to manage the home/away state, but with the change to Home/Away Assist, it appears this is now managed without a required thermostat. For example, a home with just protect devices (no thermostat), the home/away state is updated. I tested this and found it was accurate, but the ‘auto-away’ state is still being used.


#4

The API matches the device. If a thermostat still has a firmware version that uses auto-away then you will still see auto-away in the API. If the device was upgraded with ECO then it will no longer report auto-away. You will only see the auto-away state in thermostats that haven’t been updated.

Going forward auto-away is deprecated and you’ll only see it on devices that haven’t been updated yet.

BTW, I noticed another change in devices regarding this issue, too. Previously, there needed to be thermostat present to manage the home/away state

Previously Home/Away functionality worked with the thermostat and the nest cam. I believe it still works with only a nest protect, but I don’t think any functionality is tied to it.


#5

You’ve lost me – I think because you’re mixing what a user sees on a device (thermostat in your example) and what is received programmatically using Firebase or REST. I am specifically addressing the latter and not concerned with what one can see on a device.

You stated, “Going forward auto-away is deprecated and you’ll only see it on devices that haven’t been updated yet”. Again, I’m not looking at any device. I’m looking at what is being returned from the API server. The ‘auto-away’ that is deprecated is a state value for the ‘away’ field in the returned data that is associated with the entire structure i.e., home location, used in the API and not associated with a specific device, as you’re referencing.

To be overly clear, let’s forget about a thermostat. Let’s say I only have multiple Protect devices. There is no ECO on these device. So, when you say, “If the device was upgraded with ECO then it will no longer report auto-away”. Yet, ‘auto-away’ is being reported via Firebase in this situation.

My question is not being addressed – when the deprecated ‘auto-away’ value is deleted, how can an App determine the difference between a user setting the state to ‘away’ or Home/Away Assist determining no one is home?

I called Nest’s technical support today and opened a case. I spoke to two representatives that unfortunately were not API developers. The second representative provided me a URL to submit my technical question. The problem description was constrained to 255 characters on the web page, making it difficult. The submission confirmation that I received afterwards stated, “If you have a technical question, please go to Stack Overflow and search or post with the tag “nest-api”. Nest engineers are continuously responding to posts, and they’ll get back to you shortly.” It isn’t reassuring to read that AFTER I was told to submit my question at their location. I guess I’ll wait to see what response I get back.

Thanks


#6

Ok let me try again :slight_smile:

Auto-Away was a thermostat feature. Other devices in the home would help Auto-Away but it required a thermostat to do.

There was no difference in what the states were called on the device and in the API. You see the same state names as the user. So if you have a thermostat that still supports Auto-Away you will still see auto-away in the API.

When thermostats are upgraded they no longer have a concept of what Auto-Away is, which means it will never pass that value to the API.

To answer your question directly, you will not know if the structure entered Away manually or automatically.


#7

And I will try again… :wink:

Auto-Away was a thermostat feature. Other devices in the home would help Auto-Away
but it required a thermostat to do.

Correct. Key word is ‘was’.

There was no difference in what the states were called on the device
and in the API. You see the same state names as the user. So if you have
a thermostat that still supports Auto-Away you will still see auto-away in the API.

When thermostats are upgraded they no longer have a concept of what
Auto-Away is, which means it will never pass that value to the API.

Maybe true, but irrelevant to my question.

To answer your question directly, you will not know if the structure entered
Away manually or automatically.

That’s what I suspected, and I was looking for official confirmation.
The system must still be keeping this information somewhere because it still “knows” when it should return the state to “home” or not. By removing the ‘auto-away’ state, it is removing the visibility of this. Why is this necessary?

So, the Nest API is being upgraded, and removing functionality. Not exactly a good kind of upgrade.


#8

I will side with Wes4Nest, auto-away is still alive, my Nest’s firmware version is 5.6-7 and the structure goes into auto-away state, I wish it went into away instead so all the broken Works with Nest integrations like Wemo and IFTTT would work as expected.

By the way, @Wes4Nest: why would you need to know if your structure is in auto-away state vs away?


#9

As I’m sure you know, before ‘auto-away’ was deprecated, ‘auto-away’ meant that the state would automatically return to ‘home’ when the systems sensed someone was … well, home. And ‘away’ meant it would not return to ‘home’. It would stay in the ‘away’ state until the value is manually set to ‘home’ before the automatic handling resumes.

I have a need to know if the automatic processing is in effect or not. If both states are now handled using a single ‘away’ value. I cannot tell the difference programmatically. I contend that there must be another setting somewhere (a semaphore) indicating if/when the automatic ‘home’ processing is in effect or not. Deprecating the ‘auto-away’ value simply means Nest stopped exposing the difference of the two situations.

Sounds like we are in opposition to each other. You want a single value, ‘away’, to indicate when either the system was manually placed in the ‘away’ state or if the system automatically placed itself in the ‘away’ state. I want to know if the system is in a situation where it will automatically be set to ‘home’ when someone returns home.


#10

Would it make sense to you if the system was still set to away when you were home?

I think you would like to know if Eco was set manually or automatically and that I understand, because if it is set automatically then it can end automatically too.

Home/Away should be just an indicator of whether someone is home or not, that is why they removed home/away switch from the thermostat and it makes sense to me.

Nevertheless until they fix it you should be fine :wink: you can use auto-away.

A perfect fix would be to remove auto-away from away status and move it to a substatus field of eco with manual/auto values ( eco/auto-eco ). Also eco should be an on/off switch and not one of hvac modes.

Auto-away in current form is of no use for either of us.


#11

It’s not a matter of whether it makes sense to me – it’s the way it is. And I’m trying to work within the framework as setup and documented.

Your suggestion agrees with what I’ve already said. When ‘auto-away’ was deprecated as a value, it should have been exposed “somewhere”, but ‘eco’ is not a good choice. The home/away state has a data relationship with the home (in Nest terms ‘structure’). ‘eco’ is associated only with a thermostat, and it uses the home/away state as a data point for its processing. What if a home only has Protect devices? There is no ‘eco’ data to reference for the home/away state because there is no thermostat.


#12

I have to completely disagree with you. Can you provide a reference for your claims? My structure still uses auto-away, I wish it did not. Is it a bug ?


#13

Please look at my first post for this issue. It shows that ‘auto-away’ is documented as deprecated, but it is still being used.

A Nest developer responded to my StackOverflow post, stating, “If you are still seeing auto-away, this is bug and should not be happening.”.


#14

@urman, can you confirm that it is a bug and it is being worked on? Seems like a pretty obvious flaw given how verbose the press releases were about removing auto-away when eco was introduced. I think that Nest developers would have caught it a long time ago.


#15

I can confirm that this is a bug and is currently being discussed on a quick remedy. You’re correct that this was introduced when eco was announced. In the mean-time you should map auto-away to away.

Hopefully I’ll have more info soon.


#16

Sure I can, but this bug makes Nest a lame home automation hub in the mean-time.
A decent work around would be for Nest to update IFTTT away trigger to include auto-away.


#17

Auto-away has been deprecated and doesn’t exist for any device. A bug in the API back end has it showing up in the API only occasionally through streaming connections. We should be able to fix that in our next sprint.

Nest has no way to update a Works with Nest developers integration. Only IFTTT can make changes to their integration.


#18

Apologies if this is a little off topic, but if auto-away is deprecated why is it still putting my thermostat (with 5.6-7 software) into auto-away mode even though I’m still at home, and I’ve disabled sensors in Home/Away assist and it’s not using my phone location?

I really don’t want the Nest thermostat to go into auto-away mode - I want to manually trigger home or away using the Nest API (or the thermostat itself). However the thermostat continues to automatically go into auto-away mode (eco temperature) even when I’m home, which is leaving the house cold.

What follows is a sampling every 60 seconds of various parameters using the Nest API:

Tue 31 Jan 09:19:01 GMT 2017: Away [home], Mode [heat], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:20:02 GMT 2017: Away [home], Mode [heat], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:21:02 GMT 2017: Away [home], Mode [heat], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:22:01 GMT 2017: Away [home], Mode [heat], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:23:02 GMT 2017: Away [home], Mode [heat], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:24:02 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:25:01 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:26:02 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [23.0C], Target [22.5C]
Tue 31 Jan 09:27:02 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [22.5C], Target [22.5C]
Tue 31 Jan 09:28:02 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [22.5C], Target [22.5C]
Tue 31 Jan 09:29:02 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [22.5C], Target [22.5C]
Tue 31 Jan 09:30:02 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [22.5C], Target [22.5C]
Tue 31 Jan 09:31:02 GMT 2017: Away [auto-away], Mode [eco], State [off], Temp [22.5C], Target [22.5C]

You can see the thermostat transitions automatically into “auto-away” at 9:24 even though I’m still at home.

Is it possible to completely disable automatic auto-away without disabling Eco mode (which I want to be used but only when I set it manually to “away”), or the auto-schedule? How is the thermostat detecting I’m “away” when it has no sensors to do this? Frustrating!

Many thanks…


#19

Just disable 'Automatically use Eco temperature when no one's home' option and use Eco like you used to use Home/Away. I hope it works like that.


#20

Unfortunately not.

I’ve got a case open with Nest, they called me this morning. First line support took me through the Thermostat and App settings, they couldn’t see anything wrong - all home/away assist options are disabled, there is no phone location or activity sensors enabled, Eco is off. Everything that could possibly be used to determine home/away status is disabled.

Since everything is disabled that could be disabled he passed me to second line support and we went through the same setting checks, only to come to the same conclusion - everything related to home/away assist is disabled that could be disabled (even though I don’t want everything disabled - it’s meant to be a “smart” thermostat after all!) yet the Thermostat continues to automatically go into “auto-away” mode at 9am every morning turning off my heat when I’m still at home.

The conclusion from first and second line support is that the system is “misbehaving” so now my case has been passed to third line support which may take another 24 hours or so.

For now, I’m polling the status of the Thermostat every 60 seconds with a script (it uses python-nest) and logging the Home/Away status as above. When the script sees the Thermostat go from “home” to “auto-away” it resets the the away-mode back to “home” (and logs that it had to make this correction). Without this hack, the Nest would be in the trash. With it, I’m happy to work with Nest to identify this problem.

Note that I only added the polling script AFTER realising that the Thermostat was automatically switching to “auto-away” mode (I’ve only had the thermostat 2 weeks) so the script is not causing the issue.