Brewin' a Solution to Coffee Keg Levels

LPLers love to solve problems. As Ryan (our CEO) would say, the harder the problem – the better. Problems give us the chance to think outside the box and apply innovative approaches and technologies in the solution.

So when a seemingly simple problem arose in our office, we were more than ready to roll up our sleeves and find a solution.

Runnin’ out of Java

Our team is fueled by iced coffee. We could hardly keep enough of it around in our office, so we decided to upgrade and get a two tap coffee kegerator to quench our thirst. The result was blissfully smooth and flavorful bean water that became the watering hole of our office, and a slight addiction for some.

It seemed like no matter how much iced coffee we had on tap, it was always met with a seemingly unquenchable thirst for more. When one of us would go to the tap, we were frequently met with the dreaded sound of fizz and no coffee. Worst of all? The lead time on getting a replacement keg was usually a minimum of 2-3 business days for the delivery service we used. Running out of java is not ideal for thirsty folks!

Brewin’ a Solution

To keep the team happy, we had to strategize to come up with a solution – which isn’t as easy to do without our caffeine supply. We didn’t have room for extra kegs as a backup, so we needed to know when the kegs were about to be empty. We knew that we wouldn’t be consistent enough to check the coffee level each day, and the kegs were opaque, making it difficult to see the level of liquid regardless.

This seemed like a perfect opportunity to align our interests: literally rolling up our sleeves to solve a problem and leverage hardware and software in an IoT (internet of things) system to solve our problem.

As two of the main consumers of coffee in our office, Dave Corwin and myself went about trying to solve this problem. We postulated a couple initial solutions but quickly dismissed some as not viable or pragmatic:

Weigh the kegs: If we could track the starting weight of a keg and could know the “empty” weight, we could anticipate when the keg was about to be empty. This raised a couple key questions:
- How do we take sample weights automatically?
- How do we calibrate the scale to know when a keg is close to empty as coffee kegs are different in terms of dry weight?

This option was appealing but ultimately we felt it had too many manual and repetitive steps to work in the real world.

Visual inspection of condensation line: If we could visually see the condensation line, we could know the coffee level inside the keg.

This option was too inconsistent in terms of contrast in the condensation line to be a reliable indication of keg internal volume remaining.

Track how much fluid is removed: If we know the standard starting volume (5 gallons), then if we track each time coffee is removed, we could calculate the current volume. This also had the added benefit of being able to track our team consumption by time of day. To accomplish this, we’d need a simple device called a flow meter that can measure the volume of liquid passing through it.

This was our winning solution!

Next we had to move from the whiteboard solution stage to bringing our solution to life. This required a handful of subsystems working in concert to produce a visualization of the keg volume remaining. We’d need a little bit of all the wares:

Hardware
- Flow meter: to be installed inside the kegerator and spliced into the feed lines between the tap and keg
- IoT breadboard: mounted on the outside of the kegerator, this would receive the signal from the flow meter and broadcast those readings from our kegerator to our cloud infrastructure
Firmware
- Connected device: developed the rudimentary software running on the circuit board to calibrate the flow meter readings to volume measurements to be broadcast as events to our cloud functions that would permanently persist the readings
Software
- Dashboard: developed a simple visualization to show the volume remaining in each keg leveraging some of our go-to web technologies: React, Firebase DB (Real-time), Surge (static hosting)

After a number of runs to the hardware store to pick up supplies and tools for installing our flow meter, we debuted our solution at our Demo Day in July 2016. Much to our surprise, the system worked! We performed a live demo of us filling a pint glass with cold brew coffee and saw our dashboard live update.

A Whole Latte Effort on Coffee

While we saw early success, ultimately our lack of mechanical engineering skills proved to be our downfall. After running well for a few months, our team noticed their coffee was not as fully nitrogenated as they’d like. The quick solution was to turn up the pressure in the lines which our hastily installed flow meters were not rated to handle. Upon arriving into the office one sleepy Friday morning, we stumbled upon a large puddle of coffee on the floor as the feed line had popped off from the keg. We begrudgingly put an “Out of Order” sign on our keg.

While not a production level solution, we had proven the technology and the solution by building a rudimentary IoT system. Each subsystem had to perform a single responsibility to feed data and information to the next subsystem to power our visualization.

The restless masses were too thirsty to not have a working keg system so we opted to swap in the normal keg feed lines and decommission our system affectionately named “Flo-rida”.

Fast forward a couple of years, and our experience working in IoT architectures has been deployed on a few projects. Our mix of multidisciplinary engineering, determination to find a solution, and ability to leverage custom software has prepared us to create solutions within an IoT architecture. Our work on this mission during SPACE proved to be beneficial in our other hack projects as well as client projects involving these types of distributed systems.