Keg Cop: Keg Monitoring and Control

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Lee, Thomas from SwissFlo was kind enough to swap out their regular JG fittings for the 8mm ones when I purchased their flowmeters. If you buy the SF800 flowmeters, just ask if they can swap the fittings out--he said the cost differential was negligible. Thomas was curious about this Keg cop project too so I sent him the Homebrewing DIY podcast link.
Yep, I've been talking to him for about two years now I guess. I'm surprised he didn't connect the dots.
 
Hi all, as I’m patiently waiting for my various pieces to come through customs and elsewhere, can anyone please upload some pics of their board builds? I’m a very visual learner and really need the help with what goes where exactly for soldering. Or is this fairly self explanatory once I get all the pieces in hand? Thanks in advance!
 
I looked back through and I can't seem to find my pics. I thought I saved them but ...

I'd be happy to take any pics you'd like to see. Assuming I don't need to pull any kegs out. :)
 
I looked back through and I can't seem to find my pics. I thought I saved them but ...

I'd be happy to take any pics you'd like to see. Assuming I don't need to pull any kegs out. :)
Thanks Lee! I’d love to see each of the boards if you can.
 
Or is this fairly self explanatory once I get all the pieces in hand? Thanks in advance!

I am a neophyte when it comes to soldering and I successfully built the project. As that adage goes, if I can do it, anyone can. I followed the written instructions in the docs. I only had a couple of questions that @LBussy answered very quickly.

This is the only shot I have during the build
PXL_20210713_135726669.jpg


All that's left to install are screw terminals and RJ-45 jacks. You will note the onboard DS18B20 top-left of the main board. There is also a 3-pin header just to the right of it where you can connect a wired sensor. Lee's advice to me was to clip the onboard sensor and use an external one as heat from the relays would affect readings from the onboard sensor - assuming you are going to use the enclosure as outlined in the documents and room temperature is an important metric you want to track.

Hope that helps.

Cheers!
 
Thanks for posting those! You saved me some time. :)

The RJ45 jacks fit in all the boxes on the board having 8-holes. Then there's a handful of three-wire terminals on the break-out boards.

There's really not a lot on these boards. I tried very hard to make it simple and approachable. For instance, there are five resistors for each of the one-wires. More than a couple of people have asked "why not use one-wire like it's supposed to be done and use one wire?!" Well, if you use BrewPi or any of the derivatives, one of the "fiddly" things is you need to determine which sensor is which. Well, let me ask you: Would you rather call a sensor "Tower," or "28EED5641A1602EC?"

The daisy-chain breakouts (the "T" shaped boards) are pretty simple. There are no electronic pieces on them, only connectors. Two RJ45 and a three-wire terminal to connect the flowmeter.

IMG_1783.jpg


You can see the yellow ethernet cable come in the bottom and out the top of #1. The out from there goes into the in on #2, and so on. The 3D printed covers just clip on the boards and show the direction of the daisy-chain wiring. If you put them on in the right orientation it matches the liquid flow, but nothing forces that.

Pay no attention to the fact that I REALLY need to defrost my kegerator :)

IMG_1784.jpg


Here's a working Keg Cop:
  1. Power (for the kegerator) in
  2. Power out (through the relay)
  3. Room temperature sensor
  4. Temperature sensor cable (goes to breakout board)
  5. Controller power (5V)
  6. Flowmeter cable
IMG_1785.jpg


This is the temp sensor breakout in the 3D printed box. If my kegerator didn't need to be defrosted so badly, you would see the four one-wire leads coming out the back.
 
I wish that my brother had used two filament colours when he printed my enclosures. I know you included that setup instruction in the package. Those look very cool, Lee.

Creality printers are coming down in pricing ... maybe I'll ask for one for Christmas ...🤔
 
I wish that my brother had used two filament colours when he printed my enclosures. I know you included that setup instruction in the package. Those look very cool, Lee.

Creality printers are coming down in pricing ... maybe I'll ask for one for Christmas ...🤔
Thanks for all pictures, very helpful, am I missing the link to the 3-D printer files?
 
My brother has one....it isn't very big at all. He built it from a kit about 8 years ago I think. He had no trouble printing these enclosures for me. I bought him a roll of PLA to compensate as, sadly, he doesn't like beer.

The main board enclosure is the largest at 90 x 127 x 32mm or 3.5 x 5 x 1.25 inches assembled. It's printed in two pieces. The temperature sensor enclosure is 57 x 45 x 32 and the flow meter is 38 x 51 x 19. I think that budget 3D printers can handle objects 220 x 220 x 250mm.

Cheers!

PXL_20211028_141433755.jpgPXL_20211028_141453385.jpg
 
I finally got the ESP32 from China. Put Keg Cop on it.
I know this not a very good test, other than connectivity - but when I ping the Keg Cop ESP32 and an ESP8266 I have on the network, I get very different ping times. Might there be something in the firmware that puts ICMP latency higher on the KegCop firmware? I've never used an ESP32 before.

Keg Cop ESP32:
Reply from 192.168.2.247: bytes=32 time=79ms TTL=255
Reply from 192.168.2.247: bytes=32 time=312ms TTL=255
Reply from 192.168.2.247: bytes=32 time=213ms TTL=255
Reply from 192.168.2.247: bytes=32 time=134ms TTL=255
Reply from 192.168.2.247: bytes=32 time=51ms TTL=255
Reply from 192.168.2.247: bytes=32 time=263ms TTL=255
Reply from 192.168.2.247: bytes=32 time=178ms TTL=255
Reply from 192.168.2.247: bytes=32 time=94ms TTL=255
Reply from 192.168.2.247: bytes=32 time=320ms TTL=255
Reply from 192.168.2.247: bytes=32 time=256ms TTL=255
Reply from 192.168.2.247: bytes=32 time=147ms TTL=255
Reply from 192.168.2.247: bytes=32 time=41ms TTL=255
Reply from 192.168.2.247: bytes=32 time=270ms TTL=255

Ping statistics for 192.168.2.247:
Packets: Sent = 830, Received = 829, Lost = 1 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 2276ms, Average = 172ms
Control-C
^C
C:\Users\Roger>^X


ESP8266 for Fermentrack:
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=7ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=4ms TTL=128
Reply from 192.168.2.249: bytes=32 time=5ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=3ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128
Reply from 192.168.2.249: bytes=32 time=1ms TTL=128

Ping statistics for 192.168.2.249:
Packets: Sent = 110, Received = 109, Lost = 1 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 81ms, Average = 11ms
Control-C
^C
C:\Users\Roger>

Or might this be an indication of some other problem? Or not a problem at all and I should just chill?
 
I'm gonna go with "They all do that".
Here are five of my esp32s running light camera duty and their response times look every bit as random as yours :)

Pinging espcam1 [192.168.1.201] with 32 bytes of data:
Reply from 192.168.1.201: bytes=32 time=61ms TTL=255
Reply from 192.168.1.201: bytes=32 time=278ms TTL=255
Reply from 192.168.1.201: bytes=32 time=182ms TTL=255
Reply from 192.168.1.201: bytes=32 time=90ms TTL=255

Pinging espcam2 [192.168.1.202] with 32 bytes of data:
Reply from 192.168.1.202: bytes=32 time=139ms TTL=255
Reply from 192.168.1.202: bytes=32 time=57ms TTL=255
Reply from 192.168.1.202: bytes=32 time=279ms TTL=255
Reply from 192.168.1.202: bytes=32 time=189ms TTL=255

Pinging espcam4 [192.168.1.204] with 32 bytes of data:
Reply from 192.168.1.204: bytes=32 time=139ms TTL=255
Reply from 192.168.1.204: bytes=32 time=34ms TTL=255
Reply from 192.168.1.204: bytes=32 time=248ms TTL=255
Reply from 192.168.1.204: bytes=32 time=164ms TTL=255

Pinging espcam7 [192.168.1.207] with 32 bytes of data:
Reply from 192.168.1.207: bytes=32 time=100ms TTL=255
Reply from 192.168.1.207: bytes=32 time=96ms TTL=255
Reply from 192.168.1.207: bytes=32 time=113ms TTL=255
Reply from 192.168.1.207: bytes=32 time=119ms TTL=255

Pinging espcam8 [192.168.1.208] with 32 bytes of data:
Reply from 192.168.1.208: bytes=32 time=180ms TTL=255
Reply from 192.168.1.208: bytes=32 time=198ms TTL=255
Reply from 192.168.1.208: bytes=32 time=217ms TTL=255
Reply from 192.168.1.208: bytes=32 time=17ms TTL=255

All of my 8266s are used for BT/Serial bridges, ain't gonna get no ping responses from them ever...

Cheers!
 
OK. I'll chalk my ESP8266s up as "Super-Controllers" since they respond usually at 1ms or so. Everything on the same WiFi network/SSID.
Ping time info is erased from my memory.
Now looking for a Swissflow meter.

I'm pumped up to get this project done.
 
The ESP8266 handles interrupts very differently, the scheduling is completely changed between the two. While those times sorts suck, it's not like you are going to depend on network performance for flowmeter performance. I would chuck it in the * it bucket and keep going :)
 
If I can't pick up a Swissflow meter from someone in the US and save on shipping, would this flow meter be acceptable? I only thought it might work better because the flow is rated for 1L/min and if it's running at closer to the max capacity I thought it might be more accurate. It says .1-1.2L/min (with "1% repeat Error Drinking") - whatever that is. Unless 1L/min is too low (which I'm now thinking it might be).

I see many people are using the Swissflow meters. Has anyone had success choosing something less costly?
 
Last edited:
If I can't pick up a Swissflow meter from someone in the US and save on shipping, would this flow meter be acceptable?
I don't know of anyone in the US selling them new. It will work, and Keg Cop will allow you to calibrate to the proper pulse rate.

I only thought it might work better because the flow is rated for 1L/min and if it's running at closer to the max capacity I thought it might be more accurate.
Not better, definitely not more accurate.

Unless 1L/min is too low (which I'm now thinking it might be).
Well, do you want to stand there taking 30 seconds to pour a beer? Generally, 10 seconds for a point is a good pour rate. There is a class that does 0.5l - 6.0l that seems reasonable.

The whole point was to support nearly any flowmeter using 5v excitation and a pulse signal. There are more than a few people using lesser-priced flowmeters and they generally like them okay. I don't know of anyone who has SwissFlow That wants to change.
 
Firstly, many thanks to @LBussy for sharing this really cool project (pun intended!)
Are wondering if there is any chance of load cell integration into keg cop,possibly using HX711 amplifier,instead of flow meters ?
Also,what are your thoughts regarding using load cells for keg monitoring ?
People complain of drift over time,could this be due to some load cells having an aluminium frame which could be distorting over time ?
Cheers
 
Yes but no. :)

The firmware is getting pretty cramped, especially when I have to build in debug mode. I have poked around at load cells and I think I can re-use a bunch of the code, but adding it as a configuration item may be a step too far. I have some of it done, but my free time has been sucked up here lately.

WRT drift - yes, I've got some plans for that.
 
@DaveS and @LBussy -
I use Home Assistant to control a lot of stuff at my house - IoT types of things. I use load cells on my bed to detect when my wife or I are in bed to turn off lights and turn the alarm on when we're both in bed after a certain time at night. It uses that weight info to turn off the alarm off and turn on my office light when I get out of bed in the morning.

The guy who wrote the code for that included an "auto-tare" function to compensate for drift. There's an automation in Home Assistant to do this every day when we're not in bed. I don't know how it works (or if it really works).
The project for this is located HERE and HERE if you want to check it out.

I was thinking about integrating weight sensor data from my kegs in the Kegerator into my Home Assistant dashboard to determine when I was low on beer. Then I found Keg Cop and thought that actually measuring the volume of beer coming out the tap would be much more accurate to determine when it's near time to swap kegs.
 
@rkhanso ,thanks for the links,will check them out.
I use openhab to automate things around my house and monitor my keezer and brewpiless using MQTT.
I had the same idea of using loadcells and an LCD to show bargraphs of how much beer is remaining and MQTT this info to openhab,then found kegcop and this is much better than my limited coding skills would ever accomplish.
There are some wiring tricks I have found to work to reduce drift over time on the HX711 amplifier boards,there are some floating grounds on the green boards that cause erratic readings.
Not sure how an auto tare function could work in his application as the keg weight obviously changes with every pour.
My idea was to reset the bargraph to full when hooking up a keg and when that weight dropped by close to19 kg show it is empty,this way any 19 litre keg can be used, my kegs have different empty weight.
I will watch with interest what Mr Bussy comes up with.
Cheers
 
The guy who wrote the code for that included an "auto-tare" function to compensate for drift.
Auto-tare won't work in this application.
What most do is include a reference cell...
Well, yes and no.

First of all, we must accept the following:
  1. A (good quality) flowmeter will be more accurate than a load cell measuring a keg getting banged around in a moist climate surrounded by other kegs and lines
  2. All load cells drift
  3. We pour beer in increments generally greater than a couple of ounces
  4. Keg Cop and RPints before it discard "small pours" that can happen due to bubbles (generally micro-ounces)
  5. Anything less than a couple of ounces (probably by an order of magnitude) is probably drift
If we can accept all that, then scale drift is not an issue. What will still be an issue is someone bumping into your kegerator and shifting things. I can't help that.
 
Would anyone presently using flow meters comment on foaming and the cleaning procedure required.
I assumed flow meters would be a pita to clean and don't want foaming issues,that is why was looking at a load cell option.
Perhaps they are not too bad after all.
Cheers
 
Assuming I understand the question: If you keep the lines horizontal or slightly downward-sloping through the flowmeters, you do not get "interference" from bubbles. If you mean causing foaming, no, not with the SwissFlow anyway. There are some which use a turbine sort of setup which may not be as gentle but I do not have extended experience with the cheaper ones.

As far as cleaning goes, I just do like normal, BLC and/or Saniclean (I stopped using Star-San but that works too.)
 
I've been running six sf800s since 2014 with literally zero dispensing issues over that time. For cleaning I rinse the lines from QDs through faucets, then recirculate warm-ish BLC or LLC, whichever I have on hand, through all six lines in parallel for 20 minutes, then do a long non-circulating rinse, then blow out the lines and hook them all back up. No biggie...

Cheers!
 
Just ordered all the parts for this; thanks for making the Mouser links to the projects...saved a ton of time. Looking forward to getting this going. I'd been using the flowmeters connected directly to Raspberry Pints, but this seems like a more elegant solution long term.
 
I'd been using the flowmeters connected directly to Raspberry Pints, but this seems like a more elegant solution long term.
Certainly allowing people to integrate this into RPints was a goal so I'd be interested to hear how it works out for you. I would not be surprised if some tweaks are warranted.
 
Certainly allowing people to integrate this into RPints was a goal so I'd be interested to hear how it works out for you. I would not be surprised if some tweaks are warranted.
I may also be your huckleberry. Just ordered all the parts from China a couple days ago.
 
Back
Top