I looked at a few of the options and for one reason or another, I decided that I didn’t want to use the plug-ins/extensions and came up with a simple solution using a bit of naming trickery. I use this technique for SnugUp.

Here’s what I did in Lightroom version 3.

1. I selected the photos I wanted to export.  (I generally use the Quick Collection Feature)
2. File > Export (CTRL + SHIFT + E)
3. Adjust the Export To option to point to a specific folder of your choosing (in the example below, I set the folder as E:\PhotosBackupJPG
   
4. You may optionally put them in a subfolder of your choice (I did not)
5. Next click the Rename To option and select "Edit…”
   
6. Clear any value that may already be in the text box below the Example (just highlight the text and press delete).
   
7. Then, edit the template to be Folder Name and then Original filename. Select those by using the Image Name grouping. Click the Insert button after each.
   
8. Then, I added some text that I knew would be unique to be used as a separator (=-= equals minus equals). To add the text, just click with your mouse  between the two values you just inserted. I know that none of the file names in my library have this exact combination of characters in them. It’s important later. You can confirm this by using the search feature in Lightroom if you’re not sure.
   
9. Click on the Preset (yours may say something else) and then click “Save Current Settings as New Preset”
   
10. Give it a name that you’ll remember (I called mine Folder-Filename) and hit Create.
    
11. Adjust the remaining settings per your export needs and begin the process by clicking the Export button.
12. Wait patiently. Then go do something else as you realize it’s going to take a lot longer than you had expected/wanted.
13. Now, the next step is the simple trickery. What we’ve done is named all of the files so that they include the folder name as well. So, using a Powershell 2.0 script (Powershell is available for all modern versions of Windows as part of a package download here). So, download it now if you don’t already have it. (You can check for it by looking for Powershell ISE as described in the next step if you’re not sure. You probably have it if you’re using Windows 7).
14. Start Windows Powershell ISE (in Vista and Windows 7, just type “power” into the Start menu search):
    The reason I suggest the ISE (integrated scripting environment) is that it’s easy to just get stuff running without a lot of hassle.
15. The ISE will start:
    
16. I performed the move/rename in two steps so I could verify things between each step. If you’re familiar with Powershell, feel free to combine them into one step. It’s simple enough. First grab the entire script below and paste it into the top pane (under the tab labeled Untitled1.ps1):
    

    $root = #"E:\PhotosBackupJPG"
    $items = Get-ChildItem $root
    foreach($item in $items) {
        $path = [regex]::split($item.Name, "(=-=)")
        if ($path.length -eq 3) {
            $destPath = $root + "\" + $path[0]
            if (!(Test-Path -path $destPath))
            {
                New-Item $destPath -type directory
                "New folder: " + $destPath
            }
            Move-Item $item.FullName $destPath
        }
    }
    

    I’ve intentionally left an error in the file so that you’re forced to make the change. Unless you have an “E” drive and the path, “PhotosBackupJPG”, the script needs a tiny modification to make it work.

17. The first line of the script, $root = #”E:\PhotosBackupJPG” needs to be changed to match with the export location you selected earlier AND also the “#” needs to be removed (it’s a comment character in Powershell script). So, if you exported your photos to C:\Users\Steve\ExportedPhotos, remove the “#” and remove the text inside of the quotes on the first line and replace it with your photo location.
18. After confirming the location points to where you exported your photos (and videos), hit the Run button (the green arrow in the screen shot below). Or hit the F5 key on your keyboard.

    

19. The output (or any errors if you made a typo) appears in the light blue box in the center and when it’s complete, the word “Completed” appears in the status bar at the bottom of the application. It may take a few minutes to complete. I’d suggest looking at your export directory using Windows explorer to confirm everything looks fine before continuing. At this point, you should have some subfolders and all of the files should have been moved into the proper subfolder. Next, renaming.
20. Click the “New” icon (first icon on left shown above) to create a new Powershell script file (or just replace the existing one, you won’t need it again for this process). In the new file, copy this Powershell script and paste it:
    

    $root = #"E:\PhotosBackupJPG"
    $items = Get-ChildItem $root -recurse
    foreach($item in $items) {
        $path = [regex]::split($item.Name, "(=-=)")
        if ($path.length -eq 3) {
            # $destPath = $root + "\" + $path[0]
            Rename-Item $item.FullName $path[2]
        }
    }
    

21. Again, fix the $root to match with the export folder you created.
22. Confirm it, and hit the Run button.
23. All of your photos (and videos) will be renamed to only the original file name. The extra folder name and =-= are removed.
24. Bask in the glory of Powershell and your file wizardy. No plug-ins necessary.

If you’d like to use something other than =-= as the delimiter between the folder and file names, you’ll need to fix the Powershell scripts. The delimiter is on the line:

$path = [regex]::split($item.Name, "(=-=)")

But, unless you understand how Regular Expressions in Powershell work, you may want to avoid this change … it’s not necessarily as simple as just replacing the text.

The scripts above do these things with each file:

1. Check to see if it has the right pattern
2. If so, grab the folder name and check to see if the folder exists.
3. If it does not, create it.
4. Move the file to the new folder.
5. Rename the file name, removing the folder and delimiter

If you have questions, please leave a comment.

While this shouldn’t cause any harm, (especially if you just point it at a folder of exported photos and videos, which worse case you just re-export), you use technique and code this at your own risk. I can say I successfully used the script on over 30,000 exported photos without a single problem.

To fix, remove all of the alpha channel images from the ICO file and recompile.

You’re probably familiar with this UI in Visual Studio. It hasn’t changed much since it was first created:

A list of properties, data type, scope and a default value. Admittedly, it makes things simple. However, with my WPF .NET application that I created a few years ago (SnugUp), I’ve always been troubled by the magic of the settings. It was too easy to get in a situation where a user would loose their settings doing uninstalls, reinstalls, upgrades.

While I’m sure it’s possible to make the built in settings classes to work, it wasn’t worth the effort for me to understand them and learn what the nuances of where they’re placed, how to do a decent upgrade, how not to loose them, etc.

In the SnugUp WPF UI, the code uses a two-way bindings to directly edit the settings of the application (like: "{Binding AppSettings.DebugMode}"). It was simple, and all I needed. It’s handy that ApplicationSettingsBase implements the INotifyPropertyChanged interface which WPF needs for simple two-way data bindings.

My solution, which I admit is heavier than the original as it requires a large additional assembly is to use JSON.NET as the serializer/deserializer for a new settings class I created.

So, the basic pattern:

   1: public class ApplicationSettings : INotifyPropertyChanged

   2: {

   3:     public event PropertyChangedEventHandler PropertyChanged;

   4:  

   5:     private bool _debugMode;

   6:     private string _albumNameFormat;

   7:     private string _extraFileExtensions;

   8:     private bool _automaticRun;

   9:     private string _galleryCreationSubCategory;

  10:     private bool _filenameOnlyCheck;

Properties created the standard way for INotifyPropertyChaged:

   1: private DateTime _nextUpdateCheck;

   2: public DateTime NextUpdateCheck

   3: {

   4:     get { return _nextUpdateCheck; }

   5:     set

   6:     {

   7:         if (_nextUpdateCheck != value)

   8:         {

   9:             _nextUpdateCheck = value;

  10:             RaisePropertyChanged("NextUpdateCheck");

  11:         }

  12:     }

  13: }

I wanted a predictable path for storing settings (so it would be easy to document and backup for users). I used the AssemblyCompany attribute and the AssemblyProduct attribute as the folder names:

   1: internal static string GetSettingsDirectory()

   2: {

   3:     string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

   4:     var attrs = Assembly.GetEntryAssembly().GetCustomAttributes(typeof(AssemblyCompanyAttribute), false);

   5:     if (attrs.Length == 1)

   6:     {

   7:         path = Path.Combine(path, ((AssemblyCompanyAttribute)attrs[0]).Company);

   8:  

   9:     }

  10:     attrs = Assembly.GetEntryAssembly().GetCustomAttributes(typeof(AssemblyProductAttribute), false);

  11:     if (attrs.Length == 1)

  12:     {

  13:         path = Path.Combine(path, ((AssemblyProductAttribute)attrs[0]).Product);

  14:     }

  15:     return path;              

  16: }

In this WPF application, in the AssemblyInfo.cs file, the attributes are set as follows:

   1: [assembly: AssemblyCompany("WiredPrairie.us")]

   2: [assembly: AssemblyProduct("SnugUp")]

On my machine, that maps to this path:

d:\Users\Aaron\AppData\Roaming\WiredPrairie.us\SnugUp\

Loading settings then is straightforward using JSON.NET:

   1: public static ApplicationSettings Load(string filename)

   2: {

   3:     ApplicationSettings settings = null;

   4:     var directory = GetSettingsDirectory();

   5:     var path = Path.Combine(directory, filename);

   6:  

   7:     if (File.Exists(path))

   8:     {

   9:         string fileData = File.ReadAllText(path);

  10:         try

  11:         {

  12:             settings = JsonConvert.DeserializeObject<ApplicationSettings>(fileData, new JsonSerializerSettings { });

  13:         }

  14:         catch { }

  15:     }

  16:     if (settings == null)

  17:     {

  18:         settings = new ApplicationSettings();

  19:         SetDefaults(settings);

  20:         // initialize settings once

  21:         Save(settings, filename);

  22:     }

  23:     return settings;

  24: }

In my code, if the settings file didn’t exist or fails to serialize into something meaningful, a new settings file is created with a few defaults. (I haven’t decided what to do when there’s an exception when reading the file, hence the empty catch).

Saving the settings is just as easy:

   1: public static void Save(ApplicationSettings settings, string filename)

   2: {

   3:     Debug.Assert(settings != null);

   4:     var directory = GetSettingsDirectory();

   5:     var path = Path.Combine(directory, filename);

   6:  

   7:     JsonConvert.SerializeObject(settings);

   8:  

   9:     if (!Directory.Exists(directory))

  10:     {

  11:         Directory.CreateDirectory(directory);

  12:     }

  13:  

  14:     var fileData = JsonConvert.SerializeObject(settings, Formatting.Indented, new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore, DefaultValueHandling = DefaultValueHandling.IgnoreAndPopulate });

  15:     try

  16:     {

  17:         using (StreamWriter writer = File.CreateText(path))

  18:         {

  19:             writer.Write(fileData);

  20:             writer.Close();

  21:         }

  22:     }

  23:     catch { }

  24: }

The SerializeObject method returns a string which is then written to a file using a StreamWriter.

I added a Save method to the instance of the ApplicationSettings:

   1: public void Save()

   2: {

   3:     ApplicationSettings.Save(this);

   4: }

This preserved the functionality that exists in the built in Settings support in .NET (which was being used in my application).

By keeping all of the property names the same and making a few tweaks to the types of some fields in my application, I had swapped out the entire “settings” infrastructure in about 45 minutes.

I’m planning some other JSON activities within my application, so the overhead of using JSON.NET is acceptable.

The best part of this alternative is that there isn’t any magic. It’s all easy to manage. Further, I can easily modify my installer to properly handle/update, etc., the settings file with just a few clicks.

I’m not going back to the built-in .NET settings support again. I’ve learned my lesson. 

What have you done for “user” settings?

New features:

• (Changed to version 2)
• Completely revamped look and feel (which did remove a few ‘flashy’ features)
• Uses Click once for application updating (which should make it easier to push updates and bug fixes out to users)
• Added settings for automatic upload (when application starts)
• Added setting for Subcategory selection (only selection, no creation of subcategories through SnugUp)
• Added setting for custom gallery naming
• Completely changed settings user interface to more logically group and explain settings
• Fixed a number of bugs (that shouldn’t have appeared to user anyway!)
• Added support for new file extensions (to upload videos in particular)

It does require .NET 4.0 Framework Client profile (which likely you’ve already got on your machine, but if you don’t the installer SHOULD make it easy to download).

Go here (http://www.wiredprairie.us/SnugUp) for more information and to download. I’d recommend uninstalling the old version first.

When I woke up this morning, I decided that I’d use the remote features of my Nest Thermostat to increase the temperature of the first floor as the normal schedule hadn’t started yet.

Here’s what I saw on my iPad:

Basement: ?

First Floor: ?

When I tapped the Basement image, this alert was displayed:

“Thermostat Disconnected: The thermostat Basement last connected to nest.com more than 7 hours ago.”

What?

I next checked the First Floor. Thankfully, it said that it had only been 17 minutes since it last connected. I’ve seen that issue before and it usually resolves. But, I’ve never seen one go more than about 50 53 minutes without reporting in.

The fact that I was using the iPad and the Nest application meant that WiFi Internet was available in our house.

I went to the Basement thermostat and noticed this glaring issue after clicking through to settings:

What?  Seriously?

As I wasn’t sure what the best option was at 6:45AM for support, I decided to re-add the thermostat to our account. The thermostat had no trouble accessing the Nest cloud and obtaining one of the one time connection keys. (So, I maintain, it’s not general Internet connectivity issues).

After deleting and adding it back, the web site still reported it as MIA. So, I tried a reset:

After resetting, and waiting several minutes after it had completely restarted, it appeared again on the Nest web site.

However, 3 hours later:

It’s again, gone missing.

So, I called support this fine Sunday morning and talked to one of the same support engineers I’ve spoken with in the past (“DK”). I explained the general problem (and emphasized that my biggest concern was that it had lost my account information), my “solution”, and said that it was again not reporting in. In a typical (somewhat ironic) support fashion, as I was explaining the issue and walking to the basement, the thermostat reported in successfully to the Nest cloud.

He had me drop the account, add it to my account, and restart it again. He said that resolves the problem in about 70% of the cases. In the other 30%, he mentioned that they often manually update the firmware and that will help. [ugh]

I’m going to keep an eye on it and will add more details as needed/available.

If you want to talk and discuss more about digital thermostats with others, I’d suggest here: digtstat.com (it’s a web site I created to help provide a better place to have discussions about the Nest thermostat).

When I went to use it this morning, I plugged it in, and then turned it on. After a few minutes of use, the battery status still showed as “not charging.”

The light on the mag-safe connection was green, as if the battery was completely charged.

When I depressed the battery indicator button on the side of the MacBook Pro, the response was 5 quick green flashes on the first LED. According to Apple support, that indicates the battery hasn’t been charged to what’s required for a single indicator light yet. However, while my MacBook Pro had discharged like this before, it would normally start charging right away.

So, apparently, before taking it in for a repair (which is what a lot of people in forums were recommending), you might try resetting the System Management Controller. One of the issues that a reset could fix is that the battery does not appear to be charging properly.

To reset the controller, perform these steps (as documented on the Apple Support web site):

1. Shut down your laptop completely.
2. Plug in the MagSafe power adapter to a power source, connecting it to the MacBook if its not already connected.
3. On the built-in keyboard, press the (left side) Shift-Control-Option keys and the power button at the same time.  [Wow, it’s awkward to do that! I pressed the S-C-O keys first and then the power button and it worked]
4. Release all the keys and the power button at the same time.
5. Press the power button to turn on the computer. 
   Note: The LED on the MagSafe power adapter may change states or temporarily turn off when you reset the SMC.

A few moments after I performed the steps above, the mag safe LED light switched to an orange color (charging) and the battery indicator no longer blinked 5 times quickly.

Problem resolved, and much simpler than taking it to a local Apple “Genius” bar.

As this wasn’t an obvious fix, I’ve decided to put this on my blog in the hope that someone else might find it useful, and so when I have this happen again, I don’t need to go hunting for the solution!

I have done just that this afternoon.

It’s brand new, and hasn’t had the tires kicked much yet (just the absolute basics), but I thought I’d put something out there as the comments and discussion have outgrown my installation of WordPress (and it’s ability to nicely manage a discussion effectively about multiple topics). I really enjoy the conversation and thought it might be best provided in a different forum (pun intended).

It’s here: digtstat.com. (It’s short for Digital Thermostat)

If there’s enough traffic to warrant it, I’ll definitely promote some others as moderators, as it will be kept a civil location for discussions about digital thermostats.

Enjoy.

A few new things have occurred since I last posted.

January 11, 2012: Nest Labs updated the firmware of the thermostat to version 1.0.6. There isn’t any publically available information about what was updated however other than “bug fixes.” Thanks to GregN for pointing it out. Here’s a link to their current software releases and updates for anyone interested:

http://support.nest.com/customer/portal/articles/246009-nest-learning-thermostat-nest-mobile-software-updates

This week, one of my thermostats in “learning” mode wiped out some of the set points I had specifically added for the weekend (this has happened before). I have no rational explanation for why it would do this as our weekend schedule on the floor where it happened is routine enough that it shouldn’t have made that choice. Nest Labs support suggests turning off “learning” mode when this has occurred to see if it’s related to learning mode. They apparently don’t have a way to track the causes or triggers unfortunately (a debug log would come in very handy now). I turned it off for the time being and have added the deleted set points to see if the problem occurs again.

UPDATE: 1/25/2012:  One of our thermostats that still has “learning” turned off decided that our morning set points for our first floor weren’t important and deleted them. Apparently, we didn’t want the house to start warming before we got out of bed.

I found an interesting issue with the Away Temperature settings that you’ll want to watch out for until they fix it (as it could affect triggers for “auto away”).

Essentially, there are values that when you put them into the away temperature field, they won’t “stick.” You won’t necessarily notice this right away unless you click around:

In the video (GIF) above, you’ll see how the “58” won’t stay 58F. It switches to 57 (it happens with 60F as well). I’ve sent a support request to Nest about the issue (they responded the following day and said they’d look into it). Since their web API deals with Celsius, I speculate it could be a rounding issue in their JavaScript code.

Update: 1/24/2012 The bug appears appears to have been corrected in the few places I happened to check earlier today (as I’m not their QA team, I didn’t check around much ).

Randal pointed out that there was someone who’d done some analysis of the temperature readings of a working Nest thermostat (compared to another thermostat). I’d concur that the readings do seem to be far more consistently accurate on the Nest thermostat on average and that our house is more comfortable. However, I’m certainly aware that this comfort will come at a cost. The house is more consistently warmer (now in the heating season). So, depending on your old thermostats and how you handled the temperature in the house, you may find your heating costs rise a bit. Simple way to compensate: you may be able to turn down the thermostat a few degrees! The temperature may read lower, but the actual temperature may be closer to what you had grown accustomed to. We may do that.

I’m still trying to understand why “Auto Away” is sometimes triggered when I wouldn’t expect it. I believe that once it was because the “away” temperatures were one degree LESS than the typical set point. So, the house would not “see us” around, and compared the day time (at work for example) set point (60F) to the “away” temperature (59F) and activate the “away” mode. I found the issue with the away temperature above when I was trying to make everything match one evening this week.  The problem with Auto-away activating is that your scheduled set points won’t be used until it is overridden via the remote interface or locally.

Update: 1/25/2012: Apparently, auto-away unfortunately can trigger even when the temperature settings match exactly. (Even when there’s nothing to do). I don’t understand what it’s “auto-awaying” from.

Here’s a few relevant tweets from @Nest:

Although I admit to not understanding the topmost tweet. My tweet had been:

I honestly didn’t feel like trying to clarify again in 140 characters.

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.

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:

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 “