I’ve got a supported Wifi router (Apple Airport Express), and it’s within reasonable range to all of the thermostats in our house (no more than 20 foot from any thermostat). While it’s unfortunately overlapping with a similar band/frequency in our house, the router is dedicated to only the Thermostats right now (a unique SSID).

It doesn’t have any settings that seem necessary to change:

Any ideas?

Usage is simple as calling setAway or setHome on the nest instance after authentication and a successful status has been returned (see commented calls below).

[javascript]
if (username && password) {
username = trimQuotes(username);
password = trimQuotes(password);
nest.login(username, password, function (data) {
if (!data) {
console.log(‘Login failed.’);
process.exit(1);
return;
}
console.log(‘Logged in.’);
nest.fetchStatus(function (data) {
for (var deviceId in data.device) {
if (data.device.hasOwnProperty(deviceId)) {
var device = data.shared[deviceId];
console.log(util.format("%s [%s], Current temperature = %d F target=%d",
device.name, deviceId,
nest.ctof(device.current_temperature),
nest.ctof(device.target_temperature)));
}
}
subscribe();
//nest.setAway();
//nest.setHome();
});
});
}
[/javascript]

Moved the code for the Nest API to GitHub. While I did have a preference for Bitbucket (free private hosting!!!), I moved it anyway.

I also created an npm called the unofficial-nest-api.

Enjoy.

Click on the image to launch the demo.

Animating SVG in a modern browser (including IE9) is generally easy enough. This example was slightly more interesting in that I wanted the thicker line to rotate based on the center point of the image, rather than the location of the line itself.

Not what I wanted:

Desired rotation:

The white bar would rotate around the center point (marked by the red arrow above).

I’ve included all of the code at the bottom of the post. (There’s quite a lot of path information).

The JavaScript just used an interval to move the line around the point:

(function () {
    window.onload = loaded;
    function loaded() {
        var colorTemp = document.getElementById("color-temp");
        var reading = document.getElementById('current-reading');
        var currentAngle = 0;
        var fill;

        var direction = 1;
        setInterval(function () {
            currentAngle += direction;
            if (currentAngle >= 120 || currentAngle <= -120) {
                direction *= -1;
            } else if (currentAngle === 0) {
                fill = direction === 1 ? "#BE1E2D" : "#10A2DC";
                colorTemp.setAttribute("fill", fill);
            }
            // adjust the opacity
            colorTemp.setAttribute("opacity", Math.abs(currentAngle) / 120.0);

            reading.setAttribute("transform", "rotate(" + currentAngle + ")");

        }, 25);
    }
})();

The angle is fixed between 120 and –120 degrees. When the angle reaches zero, the fill color is toggled.

As the angle adjusts, the line is updated as well as the opacity of the fill.

The overall size of the SVG drawing is 600×600. Knowing that (and wanting the exact center), I translated a group to an offset of 300x, 300y containing the line:

<g id="temp-transform" transform="translate(300,300)">
        <line id="current-reading" fill="none" stroke="#FFFFFF"
              stroke-width="5" stroke-linecap="round"
              stroke-miterlimit="10" x1="0" y1="-180" x2="0" y2="-120"/>
</g>

This effectively made the rotation now work from the center, once the line coordinates were adjusted to reflect the new translation.

This works because the contents of the outer group caused the new starting point (origin) to be 300x, 300y rather than the default 0x, 0y. You can see the line is from y –120 to y –180. That’s because I wanted the line to start in the top middle (as the x is set to 0 for the line).

I used Adobe Illustrator CS 5.5 to create the SVG image. Illustrator typically does not always handle fonts well when exporting as SVG. The final text node was this:

<text transform="matrix(1 0 0 1 254.1387 83.3198)" fill="#D1D3D4" font-family="'Arial'"
      font-weight="bold" font-size="29.4616">thermo</text>

To make it work across browsers, I needed to modify the text node below slightly. Note the font name and missing bold attribute. It’s not a hard switch, but it’s annoying if you need to make changes to your SVG multiple times.

<text transform="matrix(1 0 0 1 254.1387 83.3198)" fill="#D1D3D4" 
font-family="'Arial-BoldMT'" font-size="29.4616">thermo</text>

If you have any questions, please leave a comment!

<!DOCTYPE HTML>
<html>
<head>
    <title>Svg Spinner Demo</title>
    <style>
        #demo1 svg {
            width: 300px;
            height: 300px;
        }

    </style>
</head>
<body>

<div id="demo1">
<svg version="1.0" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     width="600px" height="600px" viewBox="0 0 600 600" enable-background="new 0 0 600 600" xml:space="preserve">
<g>
    <radialGradient id="SVGID_1_" cx="298.9106" cy="196.146" r="399.267" gradientUnits="userSpaceOnUse">
        <stop  offset="0" style="stop-color:#D9D9D9"/>
        <stop  offset="1" style="stop-color:#C2C2C2"/>
    </radialGradient>
    <path fill="url(#SVGID_1_)" d="M300.646,595.41c-78.957,0-153.188-30.747-209.02-86.579C35.795,453,5.048,378.77,5.048,299.812
        c0-78.957,30.748-153.188,86.579-209.02S221.689,4.214,300.646,4.214c78.958,0,153.188,30.748,209.019,86.579
        c55.832,55.831,86.579,130.063,86.579,209.02c0,78.958-30.747,153.188-86.579,209.019
        C453.834,564.663,379.604,595.41,300.646,595.41z"/>
    <path fill="#808285" d="M300.646,6.214c39.637,0,78.086,7.762,114.281,23.071c34.961,14.787,66.359,35.957,93.324,62.922
        s48.135,58.364,62.923,93.325c15.309,36.193,23.07,74.643,23.07,114.28s-7.762,78.086-23.07,114.281
        c-14.788,34.961-35.958,66.359-62.923,93.324s-58.363,48.135-93.324,62.923c-36.194,15.309-74.644,23.07-114.281,23.07
        s-78.087-7.762-114.28-23.07c-34.961-14.788-66.36-35.958-93.325-62.923s-48.135-58.363-62.922-93.324
        C14.81,377.898,7.048,339.449,7.048,299.812s7.762-78.087,23.071-114.28c14.787-34.961,35.957-66.36,62.922-93.325
        s58.364-48.135,93.325-62.922C222.559,13.976,261.009,6.214,300.646,6.214 M300.646,2.214
        C136.287,2.214,3.048,135.453,3.048,299.812S136.287,597.41,300.646,597.41s297.598-133.239,297.598-297.598
        S465.005,2.214,300.646,2.214L300.646,2.214z"/>
</g>
<g>
    <radialGradient id="SVGID_2_" cx="299.0464" cy="204.2632" r="368.0053" gradientUnits="userSpaceOnUse">
        <stop  offset="0" style="stop-color:#141414"/>
        <stop  offset="1" style="stop-color:#080808"/>
    </radialGradient>
    <path fill="url(#SVGID_2_)" d="M300.646,572.266c-72.775,0-141.194-28.34-192.654-79.8c-51.459-51.46-79.8-119.879-79.8-192.654
        s28.34-141.194,79.8-192.654s119.879-79.8,192.654-79.8s141.194,28.34,192.654,79.8c51.46,51.46,79.8,119.879,79.8,192.654
        s-28.34,141.194-79.8,192.654S373.421,572.266,300.646,572.266z"/>
    <path d="M300.646,29.358c36.512,0,71.931,7.15,105.271,21.252c32.205,13.622,61.129,33.123,85.968,57.962
        c24.84,24.839,44.341,53.763,57.963,85.968c14.102,33.34,21.252,68.759,21.252,105.271c0,36.512-7.15,71.931-21.252,105.271
        c-13.622,32.205-33.123,61.129-57.963,85.968c-24.839,24.84-53.763,44.341-85.968,57.963
        c-33.34,14.102-68.759,21.252-105.271,21.252c-36.513,0-71.931-7.15-105.271-21.252c-32.205-13.622-61.129-33.123-85.968-57.963
        c-24.839-24.839-44.34-53.763-57.962-85.968c-14.102-33.34-21.252-68.759-21.252-105.271c0-36.513,7.15-71.931,21.252-105.271
        c13.622-32.205,33.123-61.129,57.962-85.968s53.763-44.34,85.968-57.962C228.715,36.509,264.133,29.358,300.646,29.358
         M300.646,25.358c-151.577,0-274.454,122.877-274.454,274.454c0,151.576,122.877,274.454,274.454,274.454
        c151.576,0,274.454-122.878,274.454-274.454C575.1,148.235,452.222,25.358,300.646,25.358L300.646,25.358z"/>
</g>
<g>
    <radialGradient id="SVGID_3_" cx="299.5176" cy="232.4409" r="259.4771" gradientUnits="userSpaceOnUse">
        <stop  offset="0" style="stop-color:#212121"/>
        <stop  offset="1" style="stop-color:#0D0D0D"/>
    </radialGradient>
    <path fill="url(#SVGID_3_)" d="M300.646,491.916c-105.927,0-192.104-86.178-192.104-192.104
        c0-105.927,86.178-192.104,192.104-192.104c105.926,0,192.104,86.178,192.104,192.104
        C492.75,405.738,406.572,491.916,300.646,491.916z"/>
    <path d="M300.646,109.708c25.666,0,50.561,5.026,73.996,14.938c22.638,9.575,42.968,23.283,60.429,40.743
        c17.46,17.46,31.167,37.791,40.742,60.428c9.912,23.435,14.938,48.331,14.938,73.996s-5.025,50.561-14.938,73.996
        c-9.575,22.638-23.282,42.968-40.742,60.429c-17.461,17.46-37.791,31.167-60.429,40.742c-23.435,9.912-48.33,14.938-73.996,14.938
        s-50.562-5.025-73.996-14.938c-22.637-9.575-42.968-23.282-60.428-40.742c-17.46-17.461-31.168-37.791-40.743-60.429
        c-9.912-23.435-14.938-48.33-14.938-73.996s5.026-50.562,14.938-73.996c9.575-22.637,23.283-42.968,40.743-60.428
        s37.791-31.168,60.428-40.743C250.084,114.733,274.98,109.708,300.646,109.708 M300.646,105.708
        c-107.201,0-194.104,86.903-194.104,194.104c0,107.201,86.903,194.104,194.104,194.104c107.201,0,194.104-86.903,194.104-194.104
        C494.75,192.611,407.847,105.708,300.646,105.708L300.646,105.708z"/>
</g>
<g opacity="0.8">
    <path id="color-temp" fill="#BE1E2D" opacity="0" d="M300.646,489.309c-104.489,0-189.497-85.008-189.497-189.497c0-104.489,85.008-189.497,189.497-189.497
        c104.489,0,189.497,85.008,189.497,189.497C490.143,404.301,405.135,489.309,300.646,489.309z"/>
    <path d="M300.646,110.815c25.515,0,50.266,4.997,73.566,14.852c22.505,9.519,42.718,23.146,60.075,40.504
        s30.984,37.57,40.504,60.075c9.854,23.3,14.852,48.051,14.852,73.566s-4.997,50.266-14.852,73.566
        c-9.52,22.505-23.146,42.718-40.504,60.075s-37.57,30.984-60.075,40.504c-23.3,9.854-48.051,14.852-73.566,14.852
        s-50.266-4.997-73.566-14.852c-22.505-9.52-42.718-23.146-60.075-40.504s-30.985-37.57-40.504-60.075
        c-9.855-23.3-14.852-48.051-14.852-73.566s4.997-50.266,14.852-73.566c9.519-22.505,23.146-42.718,40.504-60.075
        s37.57-30.985,60.075-40.504C250.38,115.812,275.131,110.815,300.646,110.815 M300.646,109.815
        c-104.933,0-189.997,85.064-189.997,189.997c0,104.932,85.064,189.997,189.997,189.997c104.932,0,189.997-85.064,189.997-189.997
        C490.643,194.879,405.578,109.815,300.646,109.815L300.646,109.815z"/>
</g>
<g id="temperature-markings">
        <line fill="none" stroke="#C7C8CA" stroke-width="5" stroke-miterlimit="10"
              x1="300.646" y1="123.751" x2="300.646" y2="161.603"/>
        <line fill="none" stroke="#C7C8CA" stroke-width="5" stroke-miterlimit="10"
              x1="422.102" y1="371.971" x2="454.881" y2="390.896"/>
        <line fill="none" stroke="#C7C8CA" stroke-width="5" stroke-miterlimit="10"
              x1="146.41" y1="390.896" x2="179.191" y2="371.97"/>
</g>
<g id="temp-transform" transform="translate(300,300)">
        <line id="current-reading" fill="none" stroke="#FFFFFF"
              stroke-width="5" stroke-linecap="round"
              stroke-miterlimit="10" x1="0" y1="-180" x2="0" y2="-120"/>
</g>
    <text transform="matrix(1 0 0 1 254.1387 83.3198)" fill="#D1D3D4" font-family="'Arial'"
          font-weight="bold" font-size="29.4616">thermo</text>
</svg>


</div>


<script type="text/javascript">

    (function () {

        window.onload = loaded;

        function loaded() {
            var colorTemp = document.getElementById("color-temp");
            var reading = document.getElementById('current-reading');
            var currentAngle = 0;
            var fill;

            var direction = 1;
            setInterval(function () {
                currentAngle += direction;
                if (currentAngle >= 120 || currentAngle <= -120) {
                    direction *= -1;
                } else if (currentAngle === 0) {
                    fill = direction === 1 ? "#BE1E2D" : "#10A2DC";
                    colorTemp.setAttribute("fill", fill);
                }
                // adjust the opacity
                colorTemp.setAttribute("opacity", Math.abs(currentAngle) / 120.0);

                reading.setAttribute("transform", "rotate(" + currentAngle + ")");

            }, 25);
        }
    })();


</script>
</body>
</html>

Some of the details may be found on their blog.

A few of the new features include an historical view of the heating/cooling usage:

On Friday, April 6th for example, you can see when the heat turned on and what the set points were for the day for my First Floor thermostat. The data isn’t as interesting during our Midwest Spring as the furnace doesn’t run nearly as much.

Here’s from another day:

I doubt I’ll use this feature much. It only has 10 days of information available apparently right now, so I just can’t see this being very useful. I’m skeptical that this will affect my choices as it comes to how we use our HVAC system. I could see potentially how aggregate data of many users (in a similar geographical area) could become more compelling and potentially a source of data that Nest might be able to sell.

The settings for a thermostat have been tweaked visually. The same basic data is available as before:

The learning tab has been cleaned up as well:

For some reason, our thermostat that we’ve had for four months is apparently still in training (Time to Temp). That seems like an issue that maybe I’ll look into. Although I don’t really care much about the “time to temp” feature normally as I don’t manually adjust the affected thermostat much.

The “Away” tab changed:

Not a big improvement for usability. Probably more touch friendly (and it’s logically correct as it heats when less than 58 degrees for example), but it feels wrong. Thermostats aren’t normally left to right oriented (temp goes up and down), so this breaks a typical UX model.

On the Equipment tab, they’ve tweaked the UI as well:

I clicked on the Safety Temp word (? it’s not a button, nor a link, so I don’t know what to call it) and the above UI displayed. The same temperature range UX is displayed, but here I like it even less. I suppose we don’t have a maximum temperature in the house during cooling season, but this is clunky. (And given that it’s safety related, I wish it were more clear). I can hear some of you say, “but it’s clear to me.” I do understand it, but I’m confident there is a better way of displaying and adjusting these temperatures that would be more obvious.

(And Nest Labs, go ahead and spell out “TEMP” please? Thanks!)

The technical info tab is the same basically.

There’s now a lock feature (which I have no need for, and am not going to experiment with right now):

One of the big new TM’ed features is called Airwave. Apparently, when it’s hot and the humidity is low (not typical for Wisconsin, as our summers are usually hot and humid), the thermostat apparently will try to do more cooling by turning off the air conditioning system early and using the fan more. (I always thought our air conditioner already did that as the compressor turns off before the fans). If it helps lower our electricity bill, awesome. I’ll report back if I can tell that it is working and helping (without historical data though, it will be difficult for us, especially as we added solar panels to our house last fall).

The scheduling tab looks basically unchanged. The support tab has more content, so you don’t have to go to their web site to read the information. That’s a nice improvement.

OK, this was very strange. As I was writing this post (and in the middle of using the application), I saw the following:

Now, the thermostats are all disconnected in some odd way:

A few minutes later, things improved (but not perfect):

Twenty minutes later, the BASEMENT thermostat is still disconnected. I reset the thermostat and it’s back now.

I grabbed the iPad and used the Nest app. The thermostat that I had set AWAY to was reporting the same error that I’d seen back in January: the giant question mark. Tapping the image resulted in the message:

Thermostat Disconnected – The thermostat First Floor last connected to the nest.com more than 3 days ago.

Three days?

So, I went to the thermostat and checked it’s settings. Great, no wifi and no account information. It had apparently forgotten it’s wifi connection information completely and also my account information.

Seriously, I’d want to fire myself if I wrote code that was this bad. Why would it EVER dump that information? It’s literally its key to being a smart thermostat.

Thankfully, as we still have 2 other thermostats in the house, it was simple to add the account back to the thermostat after entering the wifi password again, as the thermostat recognized that there were other Nests nearby.

Without the wifi connection, you still have a thermostat (thankfully!). However, you loose all remote scheduling capabilities via their web site or apps.

I still can’t recommend these thermostats. While the “BETA” label has been finally removed from their remote access web application, the device itself still has numerous unresolved issues.

The project is hosted on GitHub. It uses JSON.NET for parsing the return values from the Nest servers.

There are three projects, with the lib containing the assembly that is used by the two test applications. One is a console app and the other a simple WPF application:

(My thermostats are named Zero, One, and Two).

If there’s interest, I plan on adding some methods to the library which allow modification of data (such as the current temperature), and ideally, support for live updates from the devices if I can make sense of the data that is returned.

FYI: I’ve now written a Node version of the API, detailed here.

A few things are going on, the majority as you’d probably expect.

The web interface is using a long polling technique apparently to watch for updates to the schedule, temperature, etc.

I haven’t determined what the frequency is though, or the wait time. It’s very inconsistent, even when I wouldn’t expect much new “live” data to be available on the network, it frequently updates and polls again.

There are a few constants set in the HOME page script:

C.ABSENT_USER_THRESHOLD     = +('300') || 0;  // seconds
C.DEAD_DEVICE_THRESHOLD     = +('300') || 0;  // seconds
C.pollingInterval           = +('2500') || 0;       // ms
C.WEATHER_POLLING_INTERVAL  = +('120000') || 0; // ms

If the C.pollingInterval value were for the subscribe endpoint mentioned above, I’d see a LOT more calls than I do – so I’m still not clear how the polling interval is decided.

The API calls, for the most part are using JSONP syntax over an HTTPS connection.

The most frequent request is to “subscribe.” It sends as part of the GET request a large block of encoded JSON (using encodeURIComponent and then JSON.stringify).

I’m not familiar with the key/value system that they’re using (it may just be something they’ve constructed in-house – although given the number of open source JavaScript libraries they’re using, I thought someone might recognize it):

“key”, “{actualkey}.{value}”

I don’t understand why they’ve redundantly specified “key” in a list of keys when it’s evident that the actual key is contained within the value as a delimited string. It’s more data to send and more data to parse this way. So, again, maybe it’s based on some DB or model system I’m not familiar with. (Anyone recognize it?)

I’ve substituted the actual values (as they are serial numbers of my devices) with text representations of what the value represented below:

{"keys":
    [{"key":"user.#USERID#",
        "version":209478897,"timestamp":1324159145000},
    {"key":"user_alert_dialog.#USERID#",
        "version":-1320296685,"timestamp":1325967612000},
    {"key":"structure.#STRUCTURE-GUID#",
        "version":656192675,"timestamp":1325967612000},
    {"key":"device.#DEVICE 1 SERIAL NUMBER#",
        "version":1485027516,"timestamp":1326034984000},
    {"key":"shared.#DEVICE 1 SERIAL NUMBER#",
        "version":588844038,"timestamp":1326034818000},
    {"key":"schedule.#DEVICE 1 SERIAL NUMBER#",
        "version":1187107985,"timestamp":1326005677000},
    {"key":"track.#DEVICE 1 SERIAL NUMBER#",
        "timestamp":1326035650601,"version":1041047847},
    {"key":"device.#DEVICE 2 SERIAL NUMBER#",
        "version":149169270,"timestamp":1326034820000},
    {"key":"shared.#DEVICE 2 SERIAL NUMBER#",
        "version":659841570,"timestamp":1326034820000},
    {"key":"schedule.#DEVICE 2 SERIAL NUMBER#",
        "version":-2016290692,"timestamp":1326005625000},
    {"key":"track.#DEVICE 2 SERIAL NUMBER#",
        "timestamp":1326035650862,"version":528978433},
    {"key":"device.#DEVICE 3 SERIAL NUMBER#",
        "version":1637112547,"timestamp":1326035399000},
    {"key":"shared.#DEVICE 3 SERIAL NUMBER#",
        "version":760504326,"timestamp":1326035397000},
    {"key":"schedule.#DEVICE 3 SERIAL NUMBER#",
        "version":-314552357,"timestamp":1326003402000},
    {"key":"track.#DEVICE 3 SERIAL NUMBER#",
        "version":-645931164,"timestamp":1326035531802}]}"

We’ve got three thermostats, so there are always three sets of subscription requests for each call to subscribe.

Using my iPad, I adjusted the set point for our second story (#DEVICE 2#) down one degree Fahrenheit (to 67°).

Within approximately a second, the most recent pending subscribe request returned with a far more interesting payload:

jQuery17108417355176061392_1326035646750(
    { "status": 200,
        "headers": {
            "X-nl-skv-key": "shared.#DEVICE 2 SERIAL NUMBER#",
            "X-nl-skv-version": 869022424,
            "X-nl-skv-timestamp": 1326038279000,
            "X-nl-service-timestamp": 1326038279825
        },
        "payload": {
            "current_temperature": 19.98,
            "hvac_fan_state": false,
            "name": "TWO", "hvac_heat_x2_state": false,
            "hvac_ac_state": false,
            "can_cool": true,
            "auto_away": 0,
            "compressor_lockout_enabled": false,
            "target_temperature_low": 16.66667,
            "target_temperature_high": 26.66667,
            "compressor_lockout_timeout": 0,
            "hvac_heater_state": false,
            "hvac_aux_heater_state": false,
            "target_temperature": 19.44444,
            "can_heat": true,
            "target_temperature_type": "heat",
            "target_change_pending": true
        }
    });

Everything above is needed to update the current state of the UI. As you can see, the current temperature (returned as Celsius apparently) is 19.98 (67.964°F). The current temperature as displayed on the thermostat and the web UI was 68.

Seeing these return values makes me think that they may be using Ruby and Rails (as the naming convention tends to follow Rails naming using underscores between words). I know for example, I wouldn’t name variables/columns that way when building a C#/JavaScript MVC project.

Rather than just a delta payload of what’s changed, they’ve currently opted for a full update of all information related to the thermostat state.

Several seconds later, a much larger payload was returned to a subscribe request:

"status": 200,
"headers": {
    "X-nl-skv-key": "device.#DEVICE 2 SERIAL NUMBER#",
    "X-nl-skv-version": -2086438581,
    "X-nl-skv-timestamp": 1326038378000,
    "X-nl-service-timestamp": 1326038379023
},
"payload": {
    "ob_orientation": "O",
    "upper_safety_temp": 1000.0,
    "forced_air": true,
    "creation_time": 1324142042019,
    "switch_preconditioning_control": false,
    "click_sound": "on",
    "leaf": false, "user_brightness": "auto",
    "learning_state": "steady",
    "heat_pump_comp_threshold": -1000.0,
    "local_ip": "10.0.0.205",
    "backplate_serial_number": "#SHOULD BE DEVICE 2 SERIAL NUMBER, BUT ISN'T?#",
    "capability_level": 1.03,
    "postal_code": "#POSTALCODE#",
    "upper_safety_temp_enabled": false,
    "heat_pump_aux_threshold": 10.0,
    "lower_safety_temp_enabled": true,
    "serial_number": "#DEVICE 2 SERIAL NUMBER#",
    "temperature_lock": false,
    "learning_time": 1002,
    "current_version": "1.0.4",
    "model_version": "Diamond-1.10",
    "backplate_bsl_info": "BSL",
    "auto_away_enable": true,
    "heat_pump_comp_threshold_enabled": false,
    "fan_mode": "auto",
    "range_enable": false,
    "temperature_scale": "F",
    "backplate_mono_info": "TFE (BP_DVT) 3.5.2 (ehs@ubuntu) 2011-11-05 12:00:00",
    "backplate_bsl_version": "1.1",
    "equipment_type": "gas",
    "range_mode": false,
    "lower_safety_temp": 7.0,
    "has_fan": true,
    "hvac_wires": "Heat,Cool,Fan,Common Wire,Rc",
    "learning_mode": true,
    "away_temperature_high": 32.0,
    "switch_system_off": false,
    "time_to_target": 1326039444,
    "away_temperature_low": 14.444444444444445,
    "current_humidity": 45,
    "mac_address": "#MACADDR#",
    "backplate_mono_version": "3.5.2",
    "has_aux_heat": false,
    "type": "TBD",
    "hvac_pins": "W1,Y1,C,Rc,G",
    "has_heat_pump": false,
    "heat_pump_aux_threshold_enabled": true,
    "battery_level": 3.945,
    "target_time_confidence": 1.0
}

A few things to note:

• Upper_safety_temperature is just a bit beyond my comfort zone at 1832°F. I don’t know why it’s sending a value like that to the client, and why it’s stupidly high.
• The backplate serial number doesn’t match with the thermostat according to the payload response. I don’t know why this might be as I confirmed that the numbers matched through visual inspection of the device just now.
• The majority of these details are exposed in one way or another in the details area of the web UI.
• Time to target (payload.time_to_target) is unusual in that it’s a JavaScript Date value, divided by 1000. So, in the example above, the time to target is: new Date(1326039444 * 1000).toString() = >”Sun Jan 08 2012 10:17:24 GMT-0600 (Central Standard Time)”Next, a payload is returned with the new status:

  "status": 200,
  "headers": {
      "X-nl-skv-key": "shared.#DEVICE 2 SERIAL NUMBER#",
      "X-nl-skv-version": 1689916148,
      "X-nl-skv-timestamp": 1326038378000,
      "X-nl-service-timestamp": 1326038379151
  },
  "payload": {
      "hvac_fan_state": false,
      "name": "TWO",
      "hvac_heat_x2_state": false,
      "hvac_ac_state": false,
      "can_cool": true,
      "auto_away": 0,
      "compressor_lockout_enabled": false,
      "target_temperature_low": 16.66667,
      "current_temperature": 19.53,
      "target_temperature_high": 26.66667,
      "compressor_lockout_timeout": 0,
      "target_change_pending": false,
      "hvac_aux_heater_state": false,
      "target_temperature": 20.55556,
      "can_heat": true,
      "target_temperature_type": "heat",
      "hvac_heater_state": true
  }

   

  Here, the hvac_heater_state is set to true. The furnace is on.

  A little while later, that value is set to false.

  Occasionally, the payload includes the complete schedule for the thermostat. I’m not going to reproduce the entire payload here as it’s too large, and quite boring. Here’s a snippet of what it returns:

  "schedule": {
      "#DEVICE 2 SERIAL NUMBER#": {
          "$version": 1187107985,
          "$timestamp": 1326005677000,
          "name": "One Current Schedule",
          "days": {
              "0": {
                  "0": {
                      "type": "HEAT",
                      "temp": 14.445,
                      "time": 0,
                      "entry_type": "continuation"
                  },
                  "1": {
                      "type": "HEAT",
                      "temp": 14.445,
                      "time": 27900,
                      "entry_type": "setpoint"
                  },
                  "2": {
                      "type": "HEAT",
                      "temp": 20.556,
                      "time": 63000,
                      "entry_type": "setpoint"
                  },
                  "3": {
                      "type": "HEAT",
                      "temp": 14.445,
                      "time": 70200,
                      "entry_type": "setpoint"
                  }
              },
              "1": {
                  "0": {
                      "type": "HEAT",
                      "temp": 14.445,
                      "time": 0,
                      "entry_type": "continuation"
                  },
                  "1": {
                      "type": "HEAT",
                      "temp": 18.889,
                      "time": 20700,
                      "entry_type": "setpoint"
                  },

   

  It’s a basic table structure. The first set point of the day is at 0, and is a “continuation.” These don’t show up in the UI.

  Here’s what the day 1 looks like on the Nest thermostat UI:

  

  When changing a temperature setpoint, I’m a bit disappointed to see that the entire schedule is sent with every request apparently. I just wouldn’t have expected that given that the more setpoints that there are, the bigger the payload must be. The UI is often sluggish when rapidly making adjustments in the schedule, and this could be one of the factors.

  In the example below (which I’ve snipped most of the payload sent again as a JSONP request), I’ve set the first set point to 57F.

      "payload": {
          "days": {
              "0": {
                  "0": {
                      "type": "HEAT",
                      "temp": 14.685,
                      "time": 0,
                      "entry_type": "continuation"
                  },
                  "1": {
                      "type": "HEAT",
                      "temp": 15.000444444444444,
                      "time": 24300,
                      "entry_type": "setpoint"
                  },

  For the JSONP requests sent as “MAKE CHANGE” (easily could have been PUT), they each contained the following attributes as shown below. All JSONP requests are apparently routed on the web server using “headers” rather than a RESTful URL based system:

      },
      "headers": {
          "X-nl-client-timestamp": 1326041210566,
          "X-nl-session-id": "#SESSION ID#",
          "X-nl-protocol-version": 1,
          "Authorization": "Basic #BASIC AUTH#"
      },
      "path": "/v1/put/schedule.#DEVICE 2 SERIAL NUMBER#",
      "redir": "https://home.nest.com/post_jsonp",
      "jsonp": "4_"
  }

  It’s RESTful in spirit as there is a route (“path”), but it’s managed by some internal routing engine. (Now, I think that they’re not using Ruby and Rails).

  For something simple, like changing the current temperature of a thermostat, the request is thankfully simple:

  {
      "payload": {
          "shared": {
              "#DEVICE 2 SERIAL NUMBER#": {
                  "target_temperature": 18.333333333333336
              }
          }
      },
      "headers": {
          "X-nl-client-timestamp": 1326041744556,
          "X-nl-session-id": "#SESSION ID#",
          "X-nl-protocol-version": 1,
          "Authorization": "Basic #BASIC AUTH#"
      },
      "path": "/v1/put",
      "redir": "https://home.nest.com/post_jsonp",
      "jsonp": "14_"
  }

  While, I haven’t taken the time to try to write a custom UI for this undocumented API yet, it looks like it should be relatively easy to do, especially as it relates to the schedule and current temperature settings. I know there’s been some Siri proxy stuff that’s been written – but I don’t have any interest in trying to get that to work.

  As with most APIs like this, the trick is often getting authorization correct. For Nest, it appears that making a POST request to https://home.nest.com/accounts/login/ with username and password as form data, that the server responds with 2 cookies:

  1. sessionid == used in X-nl-session-id in headers
  2. cztoken == used as the Authorization in headers (prepended with the text “Basic “

  FYI: I also have a Node version of the API that is more up to date than this.