Nest Thermostat OOBE

I have a Nest thermostat. Actually, I have two. They’re both the second generation model, and I’ve had them about a month. During that time the weather has been clement, so they haven’t had to do much, but I’ve played with them enough to form a decent first impression; a real review will have to wait until winter.

The packaging shows obvious Apple influence. The cardboard is way heavier than it has to be, and everything nestles in beautiful molded-cardboard cradles. My first installation was for a forced-air gas furnace. Common wiring was available. It went very smoothly, and took only about five minutes. The wire connections are made with push-thru connector like you find on cheap speakers. I would much prefer some nice screw connectors. Each push-thru connector is apparently equipped with a switch, because the thermostat can tell what wires are installed. It would be possible to duplicate this feature with screw-down connections, but it would probably cost more.

The system fired right up and appeared to be working, but when I went to the Nest web site to register the thermostat, all I say was a big question mark. I went to the thermostat itself, and walked through the settings screens. It had correctly registered with the DHCP server (Wi-Fi only; Ethernet would be nice, especially with PoE to power the thermostat in no-common installations (see below), but I guess it would only make sense in new construction), I found a screen that did repeated pings to something on the Internet, and it indicated 100% success, but with latency that seemed too high. That pretty much ruled out basic networking problems. A search of Nest’s support materials yielded nothing.

I took stock. This had all the indications of being firewall-related. I surmised that the Nest thermostat used some non-standard TCP or UDP ports, and the thermostat’s feeble cries for connection to the Nest mothership were being cruelly denied by the Sonicwall meanie. A quick web search got me what I needed. I opened up TCP port 9543, and the thermostat and the Nest servers rushed into each other’s arms.

Score Nest down a bit for the non-standard port. Score them down a lot for not mentioning that prominently in their installation instructions.

I was able to see and set the thermostat via the web, and, after a few days, monitor the amount of time that it was calling for heat. The analysis tools are meager: no graphs, no calculations of energy used or fuel costs incurred. Nest ought to take a lesson from Sunpower on how to do reporting right.

Still, I was sufficiently impressed that I bought another thermostat, and connected it up, this time to a zone in a radiant-heating system. Installation was a bit more troublesome, since the wires were 18-gauge solid core, and didn’t want to go in to the push-in connectors on the thermostat. I dug around the Nest web site, and finally found the specs for the connectors; they should work with my wire. I filed off the corners on the copper left by the diagonal cutters and was able to fit the wires into the connectors, albeit with some difficulty. The place with I was putting the thermostat had no common connection. The Nest compatibility check list said this was no problem, but I was suspicious. How was the thermostat going to power itself? Steal 24 volt ac from the line, but not enough that the furnace will think it’s calling for heat? Turns out that’s the reverse of what it does. It steals power when calling for heat (or cold). I wouldn’t have designed it that way, since in temperate climes, there are months on end where no heat is needed. What the thermostat apparently does during those times is call for heat when it’s not necessary just so that it can charge its batteries. This uncivil behavior could easily eat up all the energy savings the device may provide during the winter. If I’d been designing the device, I’d have had it test to find out how much current it could draw without tripping the relay that tells the furnace that the ‘stat is calling for heat, and then make sure it takes less than that to charge the battery during times when its not calling for heat.

It must try to minimize the amount of power it draws by shutting down what it considers to be nonessential functions, because the zoomy feature that makes the thermostat’s display turn on when you approach it is missing in action in the no-common installation. That aside, the installation worked for me, but I’d be careful if you don’t have a common, especially considering all the complaints floating around the ‘net from unhappy customers.

It didn’t take long for me to discover that both thermostats thought the room was hotter than it really was. I wondered if the calibration of the temperature sensor was off, or if the too-high reading were due to self-heating – there’s a lot more processing going on in this thermostat than your average dumb one, and that processing has to need power.

I took a floor-standing fan, placed it below one of the thermostats, aimed it upwards so that it blew air parallel to the wall, turned it on, and monitored the temperature. After fifteen minutes, it had come down five degrees. I checked the temperature with an expensive photo processing thermometer. It was now right. I turned off the fan, and, over the next half hour, the temperature as reported by the thermostat rose back to where it started. I performed this test several times over several days, and saw drops of between three and seven degrees. Apparently, the thermostat uses more or less power depending on what it’s doing.

My conclusion is that the temperature sensor in the thermostat is accurate, but that self-heating is throwing the readings off. This doesn’t seem like the right way to design a thermostat. I can understand not being able to insulate the sensor from the heating of the thermostat, but I can’t understand why the thermostat’s software doesn’t calibrate out the error. The thermostat knows the humidity; there’s a sensor built in. The thermostat should be able to know how much power it’s been drawing well enough to build a model for the heat that it’s putting into the sensor, use the humidity number to calculate the unwanted rise in reading, and subtract that amount from what the sensor says.

This solution probably wouldn’t be perfect, since the airflow in the location of the thermostat is unknown, but it would be a whole lot better than the present situation. It would not increase manufacturing cost by one cent, and it should be pretty easy to develop. I can’t understand why anyone would design a product with a built-in error-generating mechanism which has an easy solution and not take advantage of that solution.

It wouldn’t be so bad if the error were constant, but having it change all the time makes it a real problem.

Until this is fixed, I would not recommend the Nest thermostat for use with radiant heating, which doesn’t take kindly to having the temperature of the thermostat changed arbitrarily.