The Process

Background - The Problem

A couple of years out of college I lived in a house in D.C. with a perfect space for a bar. Naturally, I immediately bought a nice bar-top followed by a two-tap kegerator. For the uninitiated, a kegerator is basically a mini-fridge with beer taps on top that run liquid tubing down to one or more kegs inside the fridge, which are also connected by air line to a carbon dioxide tank. Mine could fit one “regular” (half barrel) keg or two “slim” (sixth barrel) kegs.

It was a fun thing to have in my early-to-mid twenties. I’m pretty sure the first keg was a half barrel of Bud Light. Two years later, I moved into a one bedroom apartment, sold the bar-top, and shoved the empty kegerator in a corner for a couple years. Having a kegerator in a three-person house signals you like to entertain, having an active kegerator in a one-bedroom apartment by yourself may signal you have a problem.

When we moved to the west coast a couple of years later, I was somewhat surprised when my then-girlfriend-now-wife, Briana, insisted that we resurrect the kegerator. Since then, we’ve had 2 beers on tap at our place at all times. It’s a fun alternative to cans or bottles, especially when hosting people, and we enjoy continuously having craft beers on tap as well as collecting the corresponding tap handles.

But there’s one important problem with the kegerator: you never really know when you are about to run out.

The sixth barrel kegs we usually get contain about 55 12oz beers. Usually they last between one and three months depending on consumption patterns--a pretty big range. You may recall the typical college keg measurement technique of lifting it up to feel how heavy it is, but this doesn’t really work when they are packed tightly inside a mini-fridge. It seemed that without fail, our kegs would always suddenly run out in the middle of a party or gathering. We decided this was a problem that demanded our immediate attention.

Our First Attempt

Two software product managers with technical backgrounds, we set to work on a solution. Taking a page from the “pick it up” methodology, we came up with a plan: we’d put weight sensors under each of the kegs. Measuring the decreasing weight would tell us how much beer was left and give us an indication of when they were about to go empty. Being an electrical engineer by education, I started on the hardware side of things armed with a Raspberry Pi. Briana started work on the software side. We outlined the functions of each and specced out the interface between them—our version of a modern romance.

Things seemed promising at first. With the basic circuitry connected and a debug program written, we started doing some calibration. We put an empty keg shell on top of the weight sensor, topped it with an empty bucket, and then started to pour measured amounts of water into the bucket to see if the sensor would correctly pick up the change. It worked directionally, but the accuracy wasn’t great. We figured this was because we just had the sensor as a single point slipped under the keg. So we made a scale platform of sorts by putting the sensor between two round metal plates.

After some promising additional calibration runs, we installed everything in the kegerator. Unfortunately, we quickly hit a major problem. It turns out 55 beers wrapped in an aluminum keg shell weigh quite a lot. The pressure sensors we tried to use couldn’t handle the continuous heavy load and their readouts degraded faster than we could consume the beer. We thought there was probably a way to make it work with better and/or more sensors, but never really felt confident in the stability of a weight-based solution. We got distracted with other things. Two years went by.

A Fresh Look

After another housing move, it was time to solve this problem for good. With renewed energy, we came up with another plan: we’d use flow sensors spliced into the beer lines. This was something we considered before but had two concerns with. First, it involved cutting the beer lines, which seemed like an invasive and irreversible process if something went wrong. Second, we weren’t exactly sure what beer would do to a liquid flow sensor, or vice versa. But after finding some flow sensors that were deemed “food-grade,” we decided to give it a shot.

The quick-connect aspect of the flow meters we got actually made installation pretty easy. You shove the connectors into the sensor, shove the barbed end into the spliced beer line, and add some plastic clamps. We figured worst-case, this wouldn’t work either and we’d just have beer flowing through two useless sensors until we replaced the beer lines.

Each flow sensor has three leads coming out of it: power, ground, and signal. The way they work is basically to send out a pulse on the signal line every time a mechanical wheel inside the flow meter makes a revolution. Then you can count the number of pulses and convert the number of revolutions into the amount of liquid that has flowed through. We attached each of these to a GPIO pin on a Raspberry Pi, and wrote some Python code with basic logic to measure each “pour” of beer through a flow sensor.

The way the code works is that it counts the number of pulses from each flow sensor since it was last reset. If it senses a pulse, it adds to the counter. If the number of total pulses is above some threshold (corresponding to about an ounce of beer—this was mostly to make sure it wasn’t picking up random fluctuations), it’s determined that this series of pulses now counts as a real “pour.” Once this threshold is past, the program checks to see when five seconds have passed since the last pulse. When this happens, it’s determined that the pour has been completed, and information about the pour is both stored in a local database on the Pi and sent via HTTP POST to our web app. The counter is then reset to be ready for the next pour.

While we could have decided to have the whole thing self-contained on the Raspberry Pi, we also wanted to play around with React and Node.js, so we decided to build the front-end as a separate web app.

The app has a simple database which contains a history of kegs, pours, and the status of the active kegs. It’s updated and accessed via a basic REST API built with Node.js and Express. As described above, every time a new pour completes, the Raspberry Pi POSTs to this API with the pour information, which is then stored in the DB and used to update the status of the active kegs.

The front-end we built with React and has a couple of key views. The primary one shows the current status of our two kegs with dynamic keg images as status bars. Another shows the time and amount of each individual pour. This has the unfortunate side effect of allowing Briana to keep tabs on any drinking I might be doing during the week. Our version of a “burndown” chart shows the drinking velocity. A history view shows all of the kegs we’ve had through the kegerator, and an admin page lets us specify that new kegs have been installed.

With each individual component working, the last step was to put it all together and add some final flourishes. We bought a 10-inch touchscreen which we mounted to the wall over the kegerator and connected to the Raspberry Pi, which displays our web app. Since the screen goes to sleep every 5 minutes, we also updated the Pi’s code to wake up the display whenever a new pour is sensed to be started. We hid the Raspberry Pi in an old moscow mule box that sat on top of the kegerator.

As a bonus, we also used websockets to fire off real-time pour data from the Pi to the web app, so that the screen can show the amount being poured as it’s happening, counting up as you pour.

Finally, we created an Amazon Alexa skill so that we can ask Alexa “how much beer is left in the kegerator” and get an up-to-date answer. Currently in “beta,” this skill is of course only available in our household.

We loved working on this project together and are pretty excited how it turned out.

We still pick it back up every now and then to make improvements, upgrades or fixes. Once we had a bunch of pour data in our database, we added an “analytics” view to summarize some of the drinking trends (no judgment on our consumption habits, please). When we upgraded our bar setup in our new place, we added a bigger, higher quality screen which led us to then develop the “dashboard” view in the app that shows all the key components at once. We talked about adding a camera with facial recognition so that each pour can be attributed to a unique “drinker” in the data, but somewhere along the line I decided that may not work out great for me.