• Please visit and share your knowledge at our sister communities:
  • If you have not, please join our official Homebrewing Facebook Group!

    Homebrewing Facebook Group

[Version 2 Release] RaspberryPints - Digital Taplist Solution

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I may need a self deprecating, you can do this Garz Button....kinda like the Easy Button, but Easier.

Not to ignore you @sigel619, but no, that's not normal behavior. /var/log/apache2/error.log ....the man that can help has arrived!
Ha! Thanks. I do not feel ignored. However, I think I fixed it myself. Lots of Google searches made me try switching the HDMI cable out and it hasn't crashed since. So it leads me to believe it was something with the cable.
 
Once the tap isn't assigned a beer, I go ahead a clean...then have to go into the DB and delete those pours....maybe this is a feature request? A way to clean lines where the recorded pulses aren't included in the pour history, beer statistics, tap statistics, etc. (or maybe a flowmon stop to clean lines button, and a flowmon start in the GUI?)
I found if you go to the taps table and delete the old tap row that is no longer active it'll cascade and remove all the entries in the pours table. You obviously lose all the history of your taps and pours except those that are active but to me it just makes it easier to look at the pours table in case something goes awry.
 
I found if you go to the taps table and delete the old tap row that is no longer active it'll cascade and remove all the entries in the pours table. You obviously lose all the history of your taps and pours except those that are active but to me it just makes it easier to look at the pours table in case something goes awry.

So, the logic is querying the database and taking first to last. Removing a row, say row 3, bumps up the remaining rows.

In my experience, it's always best, and most perferred, to resolve an issue/error, instead of kludging things.
 
Just a gentle reminder for all you users - RUN A BACKUP of your card occasionally. A few weeks ago I was having issue with one of my taps not registering and after some debugging thought I had it figured out, soldered the connections and retested and it failed again. Frustrated I rolled up the line and put it in the keezer to avoid blowing a fuse. However in doing that I must have crossed something and smelled something - I touched the Pi and my memory card was HOT to the touch. Sure enough I somehow fried it. Luckily I had a backup from about year ago - reloaded a new card, put it in, crossed my fingers and everything came back up. I was cringing at the thought of redoing the install on my 3-4 year old setup with new OS, software, hardware etc - luckily I avoided all of that with a backup. BACKUP BACKUP BACKUP
 
Just a gentle reminder for all you users - RUN A BACKUP of your card occasionally. A few weeks ago I was having issue with one of my taps not registering and after some debugging thought I had it figured out, soldered the connections and retested and it failed again. Frustrated I rolled up the line and put it in the keezer to avoid blowing a fuse. However in doing that I must have crossed something and smelled something - I touched the Pi and my memory card was HOT to the touch. Sure enough I somehow fried it. Luckily I had a backup from about year ago - reloaded a new card, put it in, crossed my fingers and everything came back up. I was cringing at the thought of redoing the install on my 3-4 year old setup with new OS, software, hardware etc - luckily I avoided all of that with a backup. BACKUP BACKUP BACKUP

Absolutely! I detail the steps, in pain staking detail (reads worse than it actually takes to do), here (see the Clone microSD card.txt)

http://github.com/Tobor-8thMan/RaspberryPints
 
So, the logic is querying the database and taking first to last. Removing a row, say row 3, bumps up the remaining rows.

In my experience, it's always best, and most perferred, to resolve an issue/error, instead of kludging things.
The logic is querying the taps table by ACTIVE taps and ordering by tapNumber. Removing a row does absolutely nothing to the what is returned since its a non ACTIVE tap.

There is an ACTIVE column and a unique tap ID (not tapNumber) on the table. Once you kick the keg the ACTIVE flag is turned off and the data is never queried again. I would have just deleted the row when the keg is kicked which would have cascaded the delete to the pours table but to each their own. There is nothing Kludgy about this. With proper unique id management they've avoided any issues with removing a row in this table and its good DB design. I personally don't see the need to keep 1000s of records of pours from beers I had on tap 6 years ago - that's just DB bloat and makes queries run slower. Nothing wrong with keeping them there but you'll never see those records again.

If someone wants to clean up the pours table I was just offering a potentially faster (and maybe safer) option than accidently removing rows from active taps in the pours table and messing up the amount poured for active kegs.
 
I personally don't see the need to keep 1000s of records of pours from beers I had on tap 6 years ago - that's just DB bloat and makes queries run slower. Nothing wrong with keeping them there but you'll never see those records again.

If someone wants to clean up the pours table I was just offering a potentially faster (and maybe safer) option than accidently removing rows from active taps in the pours table and messing up the amount poured for active kegs.

Thanks for looking out for me @jbinbama. You’re right. The fear of removing wanted rows from the DB is real. (I Make sure to mess with the DB when I’m not drinking)

Me? I’m a data junky. I am not capable of purposefully deleting data....even if it’s six year old data (except my cleaner/starsan/rinse water pours, that’s just noise)
 
[shrug] I'm still running my original database since the first flow-meter-enabled installation on Memorial Day weekend 2014.
It's now 18MB with 12230 pours registered. Roughly 5.5 pours per day. So, pretty spot on :D
Pour updates still happen in a blink on an RPi2B.

I've occasionally charted the pour history on a batch through Excel to see how fast is was consumed. More curiosity than anything else, but occasionally it has affected my planning...

Cheers!
 
Last edited:
[shrug] I'm still running my original database since the first flow-meter-enabled installation on Memorial Day weekend 2014.
It's now 18MB with 12230 pours registered. Roughly 5.5 pours per day. So, pretty spot on :D
Pour updates still happen in a blink on an RPi2B.

That’s what I’m talking about!

I’m only 11,900 pours behind you!
 
Drink faster :D
I did have help - my boys love my beer - but as one of the first adopters I suspect pretty near everyone is somewhere behind me...

Cheers!
 
Was actually a bit surprised by the number of entries. To be honest I do often drink half pint pours and have had some foaming issues(forced carb/natural carb that gone bad) which may require a top off or two.
 
I periodically comb the database and remove any ghost pours. They happen every so often - usually on my higher-pressure CO2 line where I've been keeping various wheat beers over the years. Over a month I might find a handful of phony pours across all six taps, most often on my higher-carbed wheat beer line.

It's easy enough to scan the database by date and tickle the amountPoured threshold to see if any small pours happened. I just checked all pours for August so far and they're all legit...

Cheers!
 
In the beginning I monitored for phantom pours but did not see any so I have not looked in a while. Probably would not hurt to take a look once in a while.

I am using inexpensive flow meters and thinking maybe they are not sensitive enough or the courser filtering may let the bubbles slide. Foamy pours do mess up the accuracy, those kegs kick before getting to zero.
 
You really only see the end state of the pour. My SF800s average 5800 pulses per liter. At my serving pressure a liter pours in about 20 seconds, so during a pour they are running at 290 flashes per second, which is way to fast to see. Still, I find it useful to have an analog indicator that things are working.

One other thing I added was a set up DIP switches that can turn the SF800 pulse pin connection to the Arduino on and off. These allow me to disconnect the SF800 at the start of a keg when I'm flushing StarSan out of the line. The obvious alternative is just to wait until the beer is coming out of the tap before actually putting it on tap in RPints. I just had the DIP switches lying around.
I wondered about the DIP switches. I figured they allowed you to turn the SF800 on and off per se, but not why. Using it for flushing makes total sense! I appreciate your picture BTW, mine will look very similar I am thinking! I will post a pic when I am done.
 
Almost finished with my build.
From left to right ->
  • Arduino Mega 2560 (RPints)
  • Pi3 (RPints)
  • Pi Zero (TiltPi and Fermentrak)
  • Wemos D1 Mini (Not yet populated, running ESPHome for Kegerator monitoring and interior light, tied into HomeAssistant)
  • Wemos D1 Mini (Fermentrak Controller)
All that's left is adding the ESPHome Wemos into the box, terminating a bunch of cables, and clean up the wire runs. One of the 1/8" panel jacks is busted so I also have re-route that if I want all 4 flow meters.
20200815_222409.jpg

There's also a 2-port USB outlet on the right to charge my phone and thermo-pen.
 
Has anyone actually run any of the current RaspberryPints branches sketch on a Mega?
It may well work, but I cannot recall anyone actually trying it...

Cheers!
 
Has anyone actually run any of the current RaspberryPints branches sketch on a Mega?
It may well work, but I cannot recall anyone actually trying it...

Cheers!
I have R+R's running flawlessly thanks to this thread. Pin mappings are a bit off but it works! Running on pins 11, 12, 51 & 53
 

Attachments

  • 20200816_003300.jpg
    20200816_003300.jpg
    1.8 MB
Last edited:
Thanks for that. Yeah, having done some development work using both Unos and Megas in parallel I'd expect a few pin changes would be required.
But it's good to know it'll work :)

Cheers!
 
The sketch uses PCINT calls, so long as you call the PCINT pin by number it works. Mega I believe gives you more options than the Uno. I had the Mega lying around so I tried it and got it to work after digging into the sketch and R+R's help.
Link to post
 
Last edited:
Way more options - and waaay more code store :)
I did a project that eventually evolved beyond an Uno's capability but was right in the Mega's wheel house...

Cheers!
 
HA! I have no experience with the Arduino Uno, and frankly it seems very limited by spec. If we can get the RPints sketch running on an ESP32 than that would be awesome! Seems like that little board is way more powerful than an Ardunio, has multiple interrupts, and GPIOs, plus bluetooth. I'm all for the ESP01 & 8266s for home automation stuff, but just toying with these ESP32s in situations where I've run out of pins!
 
Noob here....I've got Raspberrypints installed up and running but for some reason I have vertical fields. How do I move them to horizontal? I've figured out how to change font, color and size but can't figure out how to rotate the brew lists. Any help would be great thanks in advance. I'm using R+.
 

Attachments

  • 15976297202872019298469912774065.jpg
    15976297202872019298469912774065.jpg
    2.4 MB
Is the raspberrypints the best place to get started for a new set-up? I am in the process of building out my kegerator and wanted to take advantage of Rpints.

If not, can someone point me to the most up to date post #?

Thanks!
 
Back
Top