Networking the Coffee Maker
My own take on one of the most common maker/hardware hacker projects: connecting the office coffee pot to the internet.
The first question was how I could detect when the machine was brewing. I don’t want to open the machine: there’s high current and water in there, so I’m going to stay out. My first idea was to try to measure current draw or the flowrate in its water line. Unfortunately it maintains a hot water tank even when not brewing, and has a hot water dispenser used frequently for making tea, so these seemed prone to false positives, not to mention are generally more difficult to measure or require more expensive sensors. Much easier seemed to be montioring the little red light that is lit when it is brewing. Completely external and independent of the machine’s operation, and without mucking with high current or water, it seemed like it should be easy enough to sense the light’s output with a cheap and simple photoresistor.
I’ve used a variety of Arduino and similar microcontrollers, but one of my new favorites is the ElectricImp: These things can run for a month or more on a couple AA batteries if you’re careful, they are tiny, they have analog inputs and they have built-in WiFi, all of which make them ideal for these kinds of projects.
The Imp and batteries fit nicely in a tiny Sparkfun box (fantastic quick/cheap project enclosures). I was able to ditch the mini-breadboard by slipping the ends of the 4.7K Ω bias resistor in with the headers on the leads running to the photo-resistor.
One of the great things about the Imp is that, unlike most Arduinos or other hobby controllers, it is programmed over the air. I could go ahead and physically install it in the kitchen to get some real sample numbers from the sensor, even though the code it would eventually run wasn’t ready yet — I can keep iterating on the code and updating it, all from the comfort of my desk (or anywhere else), without having to physically access the device to test every iteration.
The ElectricImp also divides your program into code actually executed on the device and code executed on their servers, allowing you to minimize the actual work done on the more power-constrained micro controller. The initial device code was 8 lines: wake the device up once every 10 seconds to send a reading to the server (or “agent” in Imp terminology):
On the server, these levels are checked against a constant (determined via observation) to determine if the light on, updating the stored brewing state. Whenever the state changes indicating brewing has started or stopped, the server calls a Slack webhook to post a message to our #coffee chat room.
And the result:
A few days running this initial proof-of-concept indicated it worked as expected, but it rapidly exhusted its batteries. A quick change to move the comparison of the light level from the server to the controller allowed keeping the Wifi radio off for longer periods of time, only connecting to Wifi when the brewing state has changed. This seems to be good enough so far, though I also added a Slack message if the supply voltage starts to drop, so I should get a chance to replace the batteries before it goes offline next time.
If end up wanting to cut power usage even further in the future, storing the last reading in nonvolatile storage would allow the device to power almost completely down between readings. I could use the time-of-day to put the device into deep-sleep overnight, when brews are very unlikely.
Charts and Graphs
The final touch was to send brewing events to a data-collector. I didn’t feel like setting up or maintaining graphite or some datastore just for this (and our Wifi subnet obviously has no access to our existing production services), so I decided to just POST to a Google Spreadsheets Form, which automatically creates a row in spreadsheet with the submission time-stamp.
Applying a few WEEKDAY, HOUR and COUNTIF calls bucket up brews by day-of-week or hour-of-day and yields some quick bar charts.
The finished code is a little longer than the first draft, but essentially the same in concept. I’d previously used an Imp to monitor and control fermentation temperatures for my home-brewing , and it made both these hacks much simpler than an Arduino or Raspberry Pi would have, thanks to having both integrated networking and analog inputs.
Running on batteries did mean spending a little more time on the code to minimize power usage, but it avoided running more cords though our office kitchen and I like the comfort of knowing there is no possible way anything more than a 5V can be on any of these wires.
Next hack: monitoring and remotely requesting the elevators.
Send me comments or suggestions on twitter: @davidtaylor.