Building an Open Source Nest 195
An anonymous reader writes "Google's recent acquisition of Nest, the maker of smart thermostats and smoke detectors, has sparked concerns of future plans for the devices, and how Google's omnipresent thirst for information will affect them. Thus, a team of engineers at Spark sat down and roughed out a prototype for an open source version of Nest. It looks surprisingly good for such a short development cycle, and they've posted their code on Github. The article has a number of short videos illustrating the technology they used, and how they used it. Quoting: 'All in, we spent about $70 on components to put this together (including $39 for the Spark Core); the wood and acrylic were free. We started working at 10am and finished at 3am, with 3.5 engineers involved (one went to bed early), and the only work we did in advance was order the electronic components. We're not saying that you can build a $3.2 billion company in a day. But we are saying that you can build a $3.2 billion company, and it's easier now than it's ever been before.'"
Re:The hard part (Score:5, Interesting)
The hard part isn't building a smart thermostat.
Meh. The hard part is realizing that you should NOT be trying to build a thermostat, period. Static temperature is relatively useless for comfort, which is why people end up moving the thing up and down all the time.
Our bodies don't sense temperature directly. They sense heat transfer, which involves evaporation rate of perspiration in addition to convection. This is the basis of "wind chill" (increased convection increases heat loss) and "heat index" (humidity reduces evaporation).
If there were actually a smart tech company out there designing such a thing, it would do something like keep a relatively constant dew point in the summer. The temperature is irrelevant. It can be 82 degrees and perfectly comfortable in my house, but on other days it can be 70 and unbearably stuffy. Cooling the house on hot non-humid days is stupid; having to adjust the thermostat down on cooler humid days just adds cost. (This is relevant in the winter as well. When it's really dry in the house, you often need a different temperature to maintain comfort than when humidity is at normal levels.)
It would be much more efficient to just stop the whole "thermostat" idea altogether... if we're really after "comfort" with least energy expenditure, why not program our houses to respond to what actually makes us comfortable (which is a more complicated formula taking humidity and temperature into account), rather than a scientific abstraction like temperature that has little human relevance?
Re:The hard part (Score:5, Interesting)
1000x this. HVAC controls should be about comfort, not temperature.
I'd also love to see a "thermostat" with a "dehumidify" button: run for the next 15 minutes no matter what the temperature is. That'll fix both cool/damp and warm/muggy. And also feel great when I come in after the yardwork drenched in sweat and want to stand in front of the register with cool air coming from it.
Re:the A/C companies are stagnant (Score:5, Interesting)
I built an Arduino-based datalogger for my 5-zone heating system for exactly this purpose. It senses the states of the 24VAC and 120VAC relays and converts them into timestamped logical On and Off. The output is a CSV files on an SD card. I didn't go the extra step of putting it on the network, although that'd be pretty easy. The tricky part is the visualization of the data: I spent almost as many hours developing scripts to (offline) post-process and display the data as I did laying out the custom shield and writing the firmware. It'd be swell if I could accomplish that on a Raspberry Pi, serving up a furnace dashboard and interactive history. But, really, I'm not interested enough to go that extra step, nor do I have the time.
So, yes, it would be neat if this functionality were already built into the HVAC equipment, but such a tiny minority of customers would be interested in it that no manufacturer would add the cost of it.