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.

Reactron water 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 number of household workflows - or industrial ones.

One of the drawbacks of the coffee maker is that it was designed solely for human interaction. It wants a human to load the cartridges and a mug, fill the water, and press the buttons, and remove the mug. I do some of these things now (load cartridges, place and remove mug), others I have managed to make the machines do (trigger buttons, fill water).

I don’t mind that it is designed for humans, since sometimes I operate it entirely manually, and if I have a guest user they aren’t wastefully serialized by an unfamiliar, machine-optimized interface. But not having a machine-optimized interface means I have to make machines that use the human interface, which is often not an optimal task. “Pressing” SPST momentary buttons via a parallel relay is one thing, doing the complex mechanical task of loading in a coffee cartridge is quite another. I have been working on the coffee loading 

OWI-535 Robot arm

and mug placing. I do have the ability to detect when a cup of coffee has been filled

Reactron Kitchen scale

or if an empty mug is present (the latter prevents automatic actuation resulting in spillage). I’ve also been working on the coffee delivery system.


These are totally stand-alone nodes on the network, but if I can get them all working in harmony, I will have a do-whatever-you-want system, one that can be programmed to anticipate needs according to preferences and conditions, and augment my life’s workflow. I actually oppose general-purpose machines, what I mean here is an amalgamation of so many singular purposes that the permutations seem general-purpose. That’s the idea, anyway.

I've been in the process of converting just about every electronic device I own, to have a machine-optimized interface. If we are going to allow machines to integrate better into a world where humans live, we will need to make it easier for them to do so if we can. But not at the expense of normal human experience. As much as the home may become a mini-factory (turning prepared raw materials into final products like ready-to-consume coffee, clean dishes, 3D printed objects, etc.) there is no need for a home to be factory-like, just as we don’t build factories that are optimized primarily for human comfort (safety, perhaps; comfort, no).

More to come.