A while back I built my own thermostat using an Arduino, nodejs, and Google Calendar. It worked really well, but when I moved to a new apartment last year I couldn’t use it (because I now have window units instead of centralized heating/AC). I finally got around to putting it back together this weekend, but I had to rip out the (now unused) thermostat code. What was a Google-Calendar-controlled thermostat is now just a thermometer. Not nearly as cool, but I’m at least glad to have the portion that makes sense back up. You can see it here.
I’ve completed the first pass of what seems to be a popular electronics self-education project: a home thermostat. I’ve already written about some of the software, and now I’d like to share some of the hardware details.
For Hot or Not, I wanted to leverage as much existing code (open-source libraries) as possible, so I could focus on the more interesting application logic. I found a library to work with the database (RRD), but there were a few things about it that didn’t fit my needs, so I ended up releasing a new library. What follows are the reasons I decided to build my own solution, and the downsides to that course of action.
Recently, I’ve worked on two projects (Power Hungry, Hot or Not) which (among other things) collect write-once data over time, and graph the results. The projects collect very different data, but this task was painful enough in postgres that I ended up switching to a temporal database for the second go, and it made the data collection & querying much easier. What follows is a brief discussion of the problems I faced with postgres, and how moving to RRD solved them.