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.
Last week I had a post make it to the Hacker News front page, and my site immediately went down. After fighting with it for a while, I was able to get it limping along well enough to last the day, and since then I’ve made several simple changes that serve as a much more robust solution. I imagine there are a ton of self-hosters out there with similar setups as I had, so hopefully the details of my comeuppance will help others preventatively.
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.
I finished my first significant electronics project in a while: Power Hungry. The idea is that I use sensors to monitor the actual voltage & amperage usage of various devices in my apartment, and I wirelessly transmit that to a base station, which calculates various statistics. The results are then beamed to my linode server, where I have some graphs of the data. The ultimate goal is to use this data to reduce my overall energy usage, but for now I’m just working on establishing a baseline, so I can best judge the effectiveness of whatever changes I make. The results so far, though, are fairly interesting.
I recently picked up a graphic LCD display and a clear touchscreen panel for a project I’m starting. They’re a lot of fun (and pretty cheap), but there are a lot of wires needed to get it hooked up, which means it’s somewhat fragile to move around.
If (like me) you like to move around when you code (couch/coffeeshop/bed/etc), then you’ll want to build a breakout board for your setup.
For Inspectinator (a sinatra microapp), I needed a database-less authentication solution that was as lightweight as possible, but with a reasonable amount of security and maintainability. I came up with something that suits this purpose well, and I’m sharing it in case anyone is looking for something similar. I call it EasyAuth.
I’ve been wanting to experiment with sinatra for a while, so I popped something off my things-to-do-someday list and put together Inspectinator. It’s aim is pretty straight-forward: parse standard ruby #inspect strings into a more palatable form. It parses a string into a system of nested objects, and displays it as a tree. Some simple jQuery let’s you drill down to the level of detail you want.