We have moved at community.getvera.com

Author Topic: Nest: The Offical API Discussion  (Read 3849 times)

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Nest: The Offical API Discussion
« on: June 25, 2014, 03:29:19 pm »
As I'm sure most are aware, the Nest API has been released. We've been awaiting this 'official' release for quite some time and I'm sure we all have/had hopes for what it (either initially or eventually) would provide us in our automation ventures. This thread is more centered around discussing what can be achieved (outside of the current plug-in), creative ideas and obviously use cases.

With that said, I do want to thank Watou for all the development, personal time and troubleshooting spent with support of this great Plug-in. I look forward to seeing what lies ahead in future implementation.

https://developer.nest.com/documentation
openLuup, AltUI, Zway and HomeWave, enough said...

Offline watou

  • Moderator
  • Hero Member
  • *****
  • Posts: 889
  • Karma: +44/-12
Re: Nest: The Offical API Discussion
« Reply #1 on: June 25, 2014, 03:54:19 pm »
The official API does not appear to support features that are being used by the current plugin.  If my understanding of this is correct, then this means that a plugin based on the current official API will lose features.  I would be very happy if someone were to check my analysis.  Following is a re-post of my observations:

I'm just curious, what is missing that you'd like to see?

On my quick perusal of the new spec, the API does not include thermostat battery_level or current running equipment state (heater_state, ac_state or fan_state -- however is_using_emergency_heat seems to mean the current running state of emergency heat in heat pump systems).  It also rounds ambient and current setpoint temperatures to whole degrees (F) or half degrees (C), instead of exposing the full known precision.  There is no ability to turn the fan on and off, or to set the periodic fan interval (fan_timer_timeout is read-only and would not be how to set the interval anyway).  The structure element does not expose the full location details (street_address, location, postal_code -- if the user authorizes the plugin to know this information, it ought to be able to retrieve it). 

I may be reading the spec incorrectly or too hurriedly, and my list above may be incomplete as to things the plugin ought to be able to know and do.

watou

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: Nest: The Offical API Discussion
« Reply #2 on: June 25, 2014, 04:59:36 pm »
1. The API does not include thermostat battery_level.
Yes, only appears to apply to Protects; "ok" or "replace".

2. Current running equipment state
Yes, nothing that I see indicates we can identify the state (cooling/heating) of the thermostat.

3. Rounds ambient and current set point temperatures to whole degrees (F) or half degrees (C).
Yes, confirmed.

4. There is no ability to turn the fan on and off, or to set the periodic fan interval (fan_timer_timeout is read-only and would not be how to set the interval anyway).
https://developer.nest.com/documentation/permissions-reference

I think this is directly dependent upon the equipment. For instance the fan has to be independent of heating and cooling.
So it's read only if dependent and r/w if independent (controlled via G-wire on t-stat). This is indicated in the result of has_fan (a bool).
So assuming that's correct, fan_timer_timeout would be used to to set the amount of time for the fan to run (decrements to 0). Once the fan is engaged, the fan_timer_active is set to true.

5. The structure element does not expose the full location details.
I'm actually ok with this, I believe this may have been an issue of security/anonymity in the event the information/device is compromised (being Google intends on linking devices etc.)
« Last Edit: June 25, 2014, 05:12:37 pm by CudaNet »
openLuup, AltUI, Zway and HomeWave, enough said...

Offline watou

  • Moderator
  • Hero Member
  • *****
  • Posts: 889
  • Karma: +44/-12
Re: Nest: The Offical API Discussion
« Reply #3 on: June 25, 2014, 05:18:32 pm »
1. The API does not include thermostat battery_level.
Yes, currently only a string value of "ok" or "replace".
I believe this applies to the smoke/CO detector only, and that there is no battery information for the thermostat.

4. There is no ability to turn the fan on and off, or to set the periodic fan interval (fan_timer_timeout is read-only and would not be how to set the interval anyway).
https://developer.nest.com/documentation/permissions-reference

I think this is directly dependent upon the equipment. For instance the fan has to be independent of heating and cooling.
So it's read only if dependent and r/w if independent (controlled via G-wire on t-stat). This is indicated in the result of has_fan (a bool).
So assuming that's correct, fan_timer_timeout would be used to to set the amount of time for the fan to run (decrements to 0). Once the fan is engaged, the fan_timer_active is set to true.
I interpret the documentation differently, and I also did not find anything in the API to simply turn the fan on or off.  If you see specifically how to turn the fan on any off via the API, please let us know.

5. The structure element does not expose the full location details.
I'm actually ok with this, I believe this may have been an issue of security/anonymity in the event the information/device is compromised (being Google intends on linking devices etc.)
To me, the distinction from other information is arbitrary, and could be easily addressed with new permission sets.  Having precise location information could be useful for geocoding and weather purposes, but I agree it may not be a critical function for most users.  However, like the other information I mentioned, it does represent a loss of information and function vs. the current plugin.  I've also just now noticed an absence of relative humidity level and the potential to control humidity setpoints.

Also note that any automation triggered off battery level, current running equipment state, humidity level, etc., would also no longer be possible.

watou

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: Nest: The Offical API Discussion
« Reply #4 on: June 25, 2014, 05:31:41 pm »
You're correct, I was looking at the wrong device (Protect) ... I corrected my initial response.

1. The API does not include thermostat battery_level.
Yes, currently only a string value of "ok" or "replace".
I believe this applies to the smoke/CO detector only, and that there is no battery information for the thermostat.

4. There is no ability to turn the fan on and off, or to set the periodic fan interval (fan_timer_timeout is read-only and would not be how to set the interval anyway).
https://developer.nest.com/documentation/permissions-reference

I think this is directly dependent upon the equipment. For instance the fan has to be independent of heating and cooling.
So it's read only if dependent and r/w if independent (controlled via G-wire on t-stat). This is indicated in the result of has_fan (a bool).
So assuming that's correct, fan_timer_timeout would be used to to set the amount of time for the fan to run (decrements to 0). Once the fan is engaged, the fan_timer_active is set to true.
I interpret the documentation differently, and I also did not find anything in the API to simply turn the fan on or off.  If you see specifically how to turn the fan on any off via the API, please let us know.

5. The structure element does not expose the full location details.
I'm actually ok with this, I believe this may have been an issue of security/anonymity in the event the information/device is compromised (being Google intends on linking devices etc.)
To me, the distinction from other information is arbitrary, and could be easily addressed with new permission sets.  Having precise location information could be useful for geocoding and weather purposes, but I agree it may not be a critical function for most users.  However, like the other information I mentioned, it does represent a loss of information and function vs. the current plugin.  I've also just now noticed an absence of relative humidity level and the potential to control humidity setpoints.

Also note that any automation triggered off battery level, current running equipment state, humidity level, etc., would also no longer be possible.

watou
openLuup, AltUI, Zway and HomeWave, enough said...

Offline CudaNet

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1401
  • Karma: +42/-11
  • Chimichanga !
Re: Nest: The Offical API Discussion
« Reply #5 on: June 25, 2014, 06:25:09 pm »
Perhaps we expected more from the API since we tend to want more control over our products than the 'average' user. The premise appears to have been for them to provide a simple solution to common tasks (temp up, temp down, I'm coming home, I'm leaving etc.). Keeping it simple just makes it easier for integration by other products, after all why would IFTT or Mercedes care about the battery/humidity level or if the house is currently cooling/heating.  As long as it's cooling/heating as you're approaching the house that seems to be sufficient from their point of view.

I think of it like this, if all the Nest GUI's were kept as simple as the API from the beginning, would we expect more. Watou reversed engineered the product so well that the official API appears deficient in their delivery. Again, it's intent appears far different from the GUI experience.

I jumped over to IFTTT and logged in to see what Nest was offering in ways of control (trigger/actions). Sure enough, fan control does appear to be an action. In fact I had to wonder why someone created a recipe that IF smoke was detected in the house, THEN turn the fan on. Hmm, perhaps I'm missing something there...

Anyways, I have hopes that the plug-in will co-exist happily and uninterrupted as it truly has more to offer than the API.

The official API does not appear to support features that are being used by the current plugin.  If my understanding of this is correct, then this means that a plugin based on the current official API will lose features.  I would be very happy if someone were to check my analysis.  Following is a re-post of my observations:

I'm just curious, what is missing that you'd like to see?

On my quick perusal of the new spec, the API does not include thermostat battery_level or current running equipment state (heater_state, ac_state or fan_state -- however is_using_emergency_heat seems to mean the current running state of emergency heat in heat pump systems).  It also rounds ambient and current setpoint temperatures to whole degrees (F) or half degrees (C), instead of exposing the full known precision.  There is no ability to turn the fan on and off, or to set the periodic fan interval (fan_timer_timeout is read-only and would not be how to set the interval anyway).  The structure element does not expose the full location details (street_address, location, postal_code -- if the user authorizes the plugin to know this information, it ought to be able to retrieve it). 

I may be reading the spec incorrectly or too hurriedly, and my list above may be incomplete as to things the plugin ought to be able to know and do.

watou
openLuup, AltUI, Zway and HomeWave, enough said...

Offline SM2k

  • Full Member
  • ***
  • Posts: 179
  • Karma: +4/-0
Re: Nest: The Offical API Discussion
« Reply #6 on: June 26, 2014, 11:14:10 am »
http://hackaday.com/2014/06/24/rooting-the-nest-thermostat/

It appears you can make the nest do anything you want if you're willing to mod the firmware--It's an embedded Linux device.

Not that I would advocate messing around with a device designed to save your life, but I would expect the nest protect is similar under the hood. Wifi enabled motion detector anybody?

Offline hadiesper

  • Beta Testers
  • Full Member
  • *****
  • Posts: 116
  • Karma: +1/-14
Re: Nest: The Offical API Discussion
« Reply #7 on: June 29, 2014, 07:11:52 pm »
Is there any current effort to develop an official nest api plugin on Vera?
I plan to do it on control cube, but it is going to take me pretty long to read through all the documentation, id rather wait till someone posts some sample xcode or lua
HadiEsper
http://www.shifrasmarthomes.com - 20 Fibaro Dimmers, 3 Thermostats, 1 Energy Meter, 2 Motion Sensors, 1 Temp/Hum Sensor, 2 VERAs, 5 Sonos Play:3 Zones, 2 TVs on GC iTach IR Control, 1 Apple TV on GC iTach, 2 Satellite Receivers on GC iTach, 1 XMBC MediaCenter, 10TB Synology