This coffee maker was previously written up on Hackaday, but I thought I should move the project here, as it is ongoing and I have a few updates since this article ran.

It may not have been obvious from the article why I made the coffee maker wireless. The time savings of one minute was mentioned, and it might seem like a really minor benefit at best. (But at four cups of coffee per day, that is a full 24 hours per year - an entire day - of just waiting! A horrible waste.) That alone was reason enough, but the real reason was so that the coffee maker could integrate into my network and interact with other components.

Currently I have it so that a transceiver in my car will contact an RF network node on the network when it arrives. (Here's a picture removed from the car - this is actually another project; this unit will be getting a human interface and GPRS connectivity!)

Proximity turns the coffee maker on and starts the heat process. By the time I arrive at the coffee maker, it is ready. Other nodes on the network take statistics on my coffee usage and help to prevent me from getting over-caffeinated. That is almost as bad as under-caffeinated! There is a sweet spot for coding, and I’ve optimized for it.

Should I want a cup of coffee on an impromptu basis, I have a voice recognition module (R.Pi with mic and with HopeRF radio) that will allow me to trigger the coffee maker verbally. I used to do this with a rudimentary webpage control served by the R.Pi, but ultimately I felt that clicking to the webpage which I always kept up in a persistent browser was also wasting time - creating a tiny time tax that becomes significant with repetition. Further, I was only at that computer (with the page up) only about 75% of the time. And that statistic was dropping. That forced me to waste time navigating to the page at other computers. Now, that has been eliminated completely.

Another thing that happens is that the coffee cartridges are counted by a separate node. This allows me to know when to buy more. Before, I would not notice and then have to waste time with backup supply workflow - either going out and getting coffee from the outside, or using some ground coffee (if I had some) in the ground coffee adapter, which I would have to clean, etc. Or I would go without - but, being under-caffeinated is not optimal for code generation. I now can avoid this interruption via machine augmentation.

Because my coffee maker has a wireless interface, it was possible to add this automatic water filling pump.

It’s a separate machine entirely, but it can talk to the coffee maker and serve its needs so that I don’t have to. I am committed to the idea that machines should serve me, not force me to serve them.

I have wirelessly controllable AC power sockets in this same network. I could plug the coffee maker into one, and interrupt the power if I detect a condition like fire. I think that is a low risk so I don’t do that. I hope I didn’t just jinx it.

Small and simple interfaces can interact in complex ways to produce multiple outcomes. The coffee maker by itself is a simple hack, and stand-alone it might not make much sense. Another example is, I can query the system for the last time I had a cup of coffee, if I was curious about how I was feeling vs. how long it’s been. Since the metrics are all there, they are available. I don’t have to rely on my already over-burdened human memory. (I’m improving the part where the system distinguishes me from other people, with respect to the coffee usage, so the metrics are not just how many times the coffee maker was triggered, it’s how many times for a particular individual.)

I realize this may seem way overkill for coffee - maybe so. But this entire workflow is really just a test case for every workflow that involves material preparation, processing, and movement. The fact that it is coffee is just fun … and motivation. The exact same execution could apply to laundry, washing the dishes, any...