The Kegerator Project 2.0

By Lindsay Farlow | Oct 28, 2015

After a busy and fun-filled summer, we are sad to say that the original kegerator prototype has passed on. The kegerator was a source of much happiness and laughter around the office, and touched the hearts (and livers?) of all who drank from the tap. But, alas, it was a prototype made from an old fridge, and its time had come.



But, dry your eyes! This just means it’s time for Kegerator 2.0. Senior Design Engineer Ken Wells reports on what we learned, and what we’re doing better for the next design.

It has been almost a year since we first began the kegerator project. My personal goal was to learn software design and be able to put my skills towards building the software controller for the kegerator. The plan was pretty successful; I now know how to develop python software in a Linux environment, setup and organize SQL databases using MySQL, and dynamically update webpages using WebSockets, and we all drank some great beer.


But one night, when the kegerator was being appreciated heavily during a party with DiscoFish, the Raspberry Pi that was the main processor running the access control code popped, demonstrating a previously unknown pyrotechnic feature. It was probably due to ESD, beer spillage, overdriving an IO pin, or some combination of all three.

It would be simple enough to just replace the board, but by then the project had piqued the interest of several engineers and especially our marketing department (*cough*Lindsay*cough*), and we decided to pick the project back up with gusto. My colleagues were already foaming over with ideas (har har), and so we took the first steps of documenting what we learned from the prototype build, and how to move forward.

What We Learned from Kegerator 1.0

The Pi. The proto build ran on a Raspberry Pi that featured a Broadcom ARM-based processor.  We want Kegerator 2.0 to be able to read our security badges and our phones’ NFC signals. My research has shown that our HID brand cards require an HID brand card reader, such as the Omnikey 5321, which has proprietary drivers that are only compiled for x86 processors.

For this reason, we plan to switch to an x86 system in the next build.  Challenges will include finding an x86 board that has GPIO capability and can handle the ~1kHz pulse trains from our SF800 flow meters.


Web Interface. In an effort to keep costs low for the proto kegerator the Raspberry Pi was used for both displaying the web interface and running the controlling software.  In this capacity it was underpowered and it would take a long time to display the webpage when refreshed.  Solutions to this problem are using a more powerful processor, or just using a separate computer to display the web interface.  There has been some talk of using a touch screen tablet for this, as they are cheap, full featured computers with the touch input capability.

Foaming. Having never built a computerized kegerator before, I didn’t know the best approach for plumbing valves and a flow meter in with the beer lines to minimize foaming. I learned that the solenoid shutoff valve should be very close to the faucet.  I’m sure there are some underlying fluid dynamics there, but I’ll leave it as an exercise to the reader to figure all that out. In any event, shutoff valve closer to faucet = less foam.

Paying for beer. We haven’t implemented a payment system yet, but requiring user authentication could be beneficial.  We often invite friends to our building to participate in after hours projects like DiscoFish and Combat Robot builds. Some of them aren’t 21.  Some of them decimated our keg of Anchor Steam. Being able to limit who can pour which beer would allow us to buy some really special kegs, where quantity is low and cost is high.

Logging In. The idea of using our work badges to login to the beer system, which would allow data logging, has made a few people uneasy.  We will have to be careful and completely open about how we collect data and what data we collect.  Maybe everything will be anonymous, with electronic balances stored with an obfuscated user ID number instead of a person’s name.  We’ll have to figure something out.

Mobility. Our current kegerator is big, heavy, and difficult to move around.  The next iteration will be mobile so that it can be stowed away (should the need arise), or moved into more prominent locations for parties and events.

That’s a pretty big list to consider, and we feel that decisions for this type of project are best made over a cold pint of good beer.  Look for our next kegerator blog post coming soon to find out what ideas we’ve come up with for version 2.0.