KegWatch
My keg monitoring and beer analytics system!
One of the first things we purchased when we bought our first home was a kegerator (you know, the essentials). Aside from the near-year long journey it took to actually get it balanced and working properly, it’s been an absolute blast having it - especially for parties. Although, after hosting our first few events in the house I realized one downside with the kegerator…I never knew how much beer I had left.
Realistically, I could open the door up and pick the keg up to estimate how full it was but that just wasn’t a good enough answer. I thought it would be awesome to have something I could integrate into my Home Assistant dashboard so I started doing some research (hoping to avoid re-inventing the wheel). Surprisingly, there were very few options available geared toward home users vs commercial bars. The only slightly promising solution was a product that was sold as a smart keg scale but it had so many downsides like cost (had to buy one per keg and mine is a two tap kegerator) and size (too tall for my kegerator). I even explored a few commercial options that used flow rate sensors in the beer lines, but they got crazy expensive and were not as open for development. The logical next step was to just build my own!
Based on my research, there were two ways to go about tracking beer: weight or flow.
Weight
This should be the simplest solution! Get the weight of an empty keg and a full keg, take the difference, and estimate the amount of beer left. The following issues arose:
Drift: I looked into using load cells to build a scale, but the cells drift over time. I was fairly confident I could counteract this programmatically, but even if I could, space becomes a concern.
Space: I don’t have the vertical space in my kegerator to lift the kegs more than an inch or so. This means I would have to build an impossibly thin scale and deal with the challenges of swapping kegs in and out with reduced headroom.
Temperature: Adding a scale inside the refrigeration unit would require drilling a hole to run wires out the back or through the door. Not only does this look terrible, but it could also affect temperature control.
Flow
There are two ways to measure flow: the physical addition of flow rate sensors into the beer line or measuring the time the tap handle is open to estimate flow rate. The flow rate sensors present the following concerns:
Price: The most commonly used sensors (for this application) are food-grade and reliable but are quite expensive. I was aiming to keep the cost down overall.
Change: It took me a very long time to balance my draft system. I spent a year or so battling flat, foamy, and warm beer so the thought of making unnecessary changes to my beer lines freaked me out.
Temperature (Again): Adding components inside the refrigeration unit would require drilling a hole to run wires out the back or through the door. Not only does this look terrible, but it could also affect temperature control.
My Solution
Time. A draft setup is a closed system with fixed pressure applied constantly. As you pour beer it draws from the bottom of the keg and the head space in the keg is replaced with CO2. Assuming you have a well balanced configuration and a decent CO2 regulator, you should generally have a consistent pour rate from the time a keg is tapped to the minute it kicks.
Enter, KegWatch. As you can tell from above, my biggest concern with other keg monitoring products was adding electronics and components inside the kegerator. I wanted something simple and unobtrusive that wouldn’t interfere with the beer itself. I designed KegWatch as a self-contained box that sits on top of the beer tower and uses sensors and magnets to track the state of the tap handles. After an initial calibration it will (with a decent level of accuracy) track every beer that is poured!
Once I had the hardware and basic functionality working, it really snowballed into a massive project that included dashboards, beer tracking, beer statistics, and even user statistics.
How it works
Hardware
I started with reed switches inside the KegWatch box and magnets mounted on the back of the tap handles. It started out ok on bench tests, but was so unstable in reality. Frequently I would find that beer was “pouring” overnight because of some sort of interference with the reed sensor, or if the tap handle didn’t close just enough it would remain open (digitally).
I scrapped that and moved to hall sensors like the A3144. This was much more reliable because it was based on magnetic field detection over a physical/mechanical magnetic latch. As long as the magnet was in range it would trigger open/closed. I spent months using this method, and even had it reporting relatively accurately; for example at the end of a 660oz. keg the system was only off by 10oz.
The biggest problem I had with accuracy is the fact that these hall sensors just report open/close once a magnet is in or out of range. Turns out some people pour beer slower than others and that was really impacting my numbers. Friends would either not open the tap all the way, or pull it open too slow so the system would miss the first ounce (ish) of beer. That doesn’t sound like much, but if you pour 50 beers…it adds up.
My final solution, still using hall sensors, is to switch to a linear hall sensor. A linear hall sensor (e.g. SS49E) has an analog output that essentially represents the distance of a magnet (just in voltage). The closer a magnet is to the sensor, the higher the output will be. By using this type of sensor, I can actually measure how far away the tap handle is versus is it open/closed. This is still a work in progress, but, ideally it should allow me to better represent how much beer is being poured if I can account for things like the tap being fully open, partially open and producing more foam, etc.
Software
I love data, and I also love beer…so naturally after creating my KegWatch sensor it was time to get some sweet sweet data.
As it stands now, KegWatch is written in micropython (I know there are better options, but I know Python and this was the quickest path for prototyping). In the very beginning I was using Python on a Raspberry Pi and a MySQL Python module to communicate directly to a database (also hosted on the Pi), but I graduated a bit from that. I’ve moved over to embedded hardware (esp32) and micropython for the sensor code and built an API service that runs via Docker for database communication. I’m still using MySQL as the backend database, but again that’s just because of my existing comfort level and this is a personal project.
This system has turned into a full on keg management platform simply due to the fact that every time I wanted to visualize data I needed more information, so I would add it to the database. Everytime a new keg gets tapped, you add it to the system and provide information like the tap number, beer name, size, and ABV. A UUID is generated along with the current date/time and it is logged as a new keg. Everytime a beer is poured it’ll reference the keg ID and keep subtracting until it thinks the keg is kicked. Once the keg hits 0oz the system automatically kicks the keg, disables the tap, and adds the date/time.
To take it a step further, I thought it would be fun to track who was drinking beer. I’ve gone through a few iterations of this as well but it is all based around the same concept - using barcodes or QR codes and a scanner to tag beers to people. The KegWatch hardware uses a small QR code scanner and before someone pours a beer they either scan their cup or the QR code on a mobile site I built to tie the beer to them.
Using Grafana I can visualize all sorts of things like who drank the most, which beer gets consumed the quickest, and how much beer is actually left.
What’s next?
I have a lot of ideas for this project still and although I haven’t had a chance to work on it as much lately…I hope to keep adding things here and there, maybe even making it available for sale one day. As I work on it I will continue to provide updates on my blog, so be sure to follow!