[Version 2 Release] RaspberryPints - Digital Taplist Solution

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.
Well ... I replaced all connections between the probe and the RPi and now have the probe directly connected to the RPi GPIO header (I had some terminal strips for the transition from inside the keezer to outside the keezer, I have eliminated them) ... and now I am getting good, regular temp readings. The only remaining issue is that the temp reading is not displaying in the upper right corner like it should, even though "Show Avg Temperature on home screen" is set to "on".
For anyone else who is experiencing this problem (as I was on each of 2 installs: One on a Model B rev 2 with 32 gb running buster and the second on Pi 4 2 gb with 64gb same OS) using the RandR+ branch of the command line (curl -L https://raw.githubusercontent.com/rtlindne/RaspberryPints/master/util/installRaspberryPints | sudo bash) the problem does not seem to be overheating, corrupted databases, lack of hard wiring the probe, insufficiently powered Pi, etc (at least in my case) but rather that the Pi and/or the software is loosing track of where the temperature probe is and therefore defaults out to the minimum reading of 32 F in the setup of raspberry pints minimum and maximum or just freezes on the last good measurement, time and date. (I determined this by watching the folder containing the probe data dissapear at some point under /sys/bus/w1/devices, or if it was there, returning the correct temperature as described below, but raspberry pints did not show that data.)

To fix this I followed instructions in this article (Using DS18B20 Digital Temperature Sensors with the Raspberry Pi - Raspberry Pi Spy ) by implementing the following commands:
sudo nano /boot/config.txt
at the bottom of the file you will see the following if you have gone through sudo raspi-config and enabled the one-wire interface

dtoverlay=w1-gpio

below that I added the specific gpiopin number that the data wire from the probe was connected to on the Pi through the 4.7K resistor. It looks like this in my config.txt:

#added this to see if I could get the probe to stabilize gpiopin=4

I then did a
sudo reboot
logged back in, went to

cd /sys/bus/w1/devices

did a ls

selected the number of my probe and went into that directory:

cd 28-0206917714fc

and then ran

cat w1_slave

to get the reading:

b6 01 55 05 7f 7e 81 66 ad : crc=ad YES
b6 01 55 05 7f 7e 81 66 ad t=27375

t=27375 tells the software that the temperature is 27.375 C

I've run this for most of a day and it keeps on updating everything correctly on the landing page upper right-hand corner.

Hopefully, this will help someone experiencing this problem, as it took me quite some time to find this fix.
 
I'm a bit surprised you could access the probes at all without enabling the interface.
Never tried that myself. Haven't needed to declare the pin, either, but maybe this is all a Buster thing...

Cheers!
 
I'm a bit surprised you could access the probes at all without enabling the interface.
Never tried that myself. Haven't needed to declare the pin, either, but maybe this is all a Buster thing...

Cheers!
Just to be clear, I did enable the one-wire probe through the interface provided by the sudo raspi-config command. I think that is how the line "dtoverlay=w1-gpio" gets inserted into the config.txt file. My only addition was the "gpiopin=4" which I believe is pin 7 on my Pi(s).

I'm a bit surprised as well that this is required, but my Raspberry Pints is still chugging along with the most recent temp and time flawlessly.

If I remember correctly from all the threads I looked through to figure this out, you are not running the RandR+ branch. This might also contribute to how the temp data is being called or somehow forgotten and might explain why you didn't need to add this step. Curious to know if there is a correspondence between flavor of this software and this problem. From my experience, it certainly is consistent across models of Pi running the same OS.

In any case, the install script provided a great way to get rpints running. Many thanks to everyone who contributed to it.
 
I have found that every time the "Unable to update Chromium" message box appears, the temperature updating stops until I clear the message box and reboot.
 
Hi again. Want to add a temperature probe to my setup with flowmeters. What probe do you recommend and how should it be connected? Would i need to reinstall raspberry pints for it to work? Thanks :)
 
If you're using the RandR+ branch you want ds18b20 probes hooked up to the RPi host.
Make sure you do not get probes wired for parasitic mode or you're gonna have a bad time :)
After installing the probes and rebooting I suspect you can just enable temperature reading via the RandR+ branch's web gui and have them work, but note a few posts back there might be a bit of twiddling needed on the RPi if you're not getting stable (or any) readings...

Cheers!
 
I successfully installed RasperryPints from the RandR+ fork and it's working well, thanks @LBussy and @day_trippr. I noticed one minor bug when uploading beers via XML (that you wouldn't notice unless you were running tail -F on the apache error log...). I submitted a patch at

https://github.com/rtlindne/RaspberryPints/pull/2
I'm now waiting for my flow meters to arrive...
 
I have a question for anyone that is familiar with BSPP pipe threads. I have flowmeters which have 3/8" male BSPP threads, and I have hose barbs that have 3/8" female BSPP threads. There is no shoulder on the flowmeters, so the seal needs to be made internally (between the end of the male flowmeter and the inner end of the female hose barb). Do I use copper crush washers inside the hose barbs? Do I use o-rings inside the hose barbs? And if so, any idea what size they would be?
 
I have a question for anyone that is familiar with BSPP pipe threads. I have flowmeters which have 3/8" male BSPP threads, and I have hose barbs that have 3/8" female BSPP threads. There is no shoulder on the flowmeters, so the seal needs to be made internally (between the end of the male flowmeter and the inner end of the female hose barb). Do I use copper crush washers inside the hose barbs? Do I use o-rings inside the hose barbs? And if so, any idea what size they would be?
I quite literally just did a as I would for any water connection in my house and used teflon tape on the threads. No problems or leaks that I’ve seen yet
 
I quite literally just did a as I would for any water connection in my house and used teflon tape on the threads. No problems or leaks that I’ve seen yet
That was my first try ... 6 to 8 wraps of teflon tape on each connection and tightened them up. Woke up to a gallon of beer on the floor of my keezer.
 
Wow this is ace.
Been looking at Raspberrypints for a while but was dreading a load of work trying to get the old code running. I didn't realise this community had been keeping it alive (and evolving it). Massive thanks to those that made this so easy to install, setup and use.

All installed, beer xmls imported from Brewfather, tweaked my layout to be how I want and I have keg volumes working from my Plaato Kegs. (not bad for an afternoons work)

However is there any way to get it to auto refresh? If I pour the display stays the same (direct off the pi and accessed via the Pi's IP). It displays the new values once refreshed but can't imagine this is normal?
I assume it's because I'm usuing the Plaato kegs and not the more usual flow sensors so it's not getting a push alert to refresh, any way round this (user level = utter novice BTW!)
 

Attachments

  • IMG_20200622_222317.jpg
    IMG_20200622_222317.jpg
    2.5 MB · Views: 42
The original R'Pints auto-updates the local console, but any web-connected displays need a local refresh.
I would expect RandR+'s branch to work the same way - at least using meters. No idea how Plaato data is integrated...

Cheers!
 
However is there any way to get it to auto refresh? If I pour the display stays the same (direct off the pi and accessed via the Pi's IP). It displays the new values once refreshed but can't imagine this is normal?

I've been hitting the same issue with my install and here's what I found. There's no JavaScript or HTML in the main index.php page to trigger a periodic refresh, so any updates you make (adding a new tap, changing a keg, etc.) need a manual refresh on the browser that's displaying the R'Pints home page.

As @day_trippr said, if you're using the flowmon daemon, this opens a multicast socket that listens for connection a connection from browsers (The links below are to my fork of the RandR+ version):

https://github.com/duncan-brown/RaspberryPints/blob/master/python/ws/rpupdate_wsh.py#L36

Then there is JavaScript run by the R'Pints index.php onload() to open a web socket connection to this server:

https://github.com/duncan-brown/RaspberryPints/blob/master/admin/scripts/ws.js#L45

If an update message gets sent from the server flowmon to the browser via the web socket, it triggers a reload of the web page:

https://github.com/duncan-brown/RaspberryPints/blob/master/admin/scripts/ws.js#L58

This will update the whole page.

However, it looks like information from Plaato is just pulled like a static database query by apache when you load index.php:

https://github.com/duncan-brown/RaspberryPints/blob/master/index.php#L75

After that, there's no communication to tell your browser to refresh the page and it stays static unless you do a manual reload.

Fixes to R'Pints would be:
  1. Add some code to index.php to get it to do a refresh every e.g. 300 seconds so at least you're no more than 5 mins out of date. I might put in a patch to do this, if the attempt to open a web socket fails because the user isn't running flowmon.
  2. Fix the web socket code to update when things other than flowmon change, but since Plaato data is pulled from the remote Plaato server, that would need a daemon on the R'Pints server to interrogate it for changes, which is more complexity and CPU load than option 1, so probably not worth the effort.
If you want a workaround without hacking R'Pints, you could use the following trick on the machine that is running chromium in kiosk mode to display the beers. First, install a couple of extra tools with:

Bash:
sudo apt-get install xdotool x11-xserver-utils

The create a script called refresh.sh in /home/pi that contains

Bash:
#!/bin/sh

/bin/sleep 6
/usr/bin/lxterminal --command watch -n 90 xdotool key ctrl+F5 &

Make this script executable by running the command chmod 755 /home/pi/refresh.sh

Then start this script when you start the browser by running the command /home/pi/refresh.sh. You can also add it to /etc/xdg/lxsession/LXDE-pi/autostart if you want it started automatically.

The script will send CTRL+F5 to the window that has the focus every 90 seconds (set by -n 90. You can tweak this as you want. Since the window with the focus should always be chromium, if it's in kiosk mode, this will trigger a reload of the page.
 
Last edited:
I've been hitting the same issue with my install and here's what I found. There's no JavaScript or HTML in the main index.php page to trigger a periodic refresh, so any updates you make (adding a new tap, changing a keg, etc.) need a manual refresh on the browser that's displaying the R'Pints home page.

As @day_trippr said, if you're using the flowmon daemon, this opens a multicast socket that listens for connection a connection from browsers (The links below are to my fork of the RandR+ version):

https://github.com/duncan-brown/RaspberryPints/blob/master/python/ws/rpupdate_wsh.py#L36

Then there is JavaScript run by the R'Pints index.php onload() to open a web socket connection to this server:

https://github.com/duncan-brown/RaspberryPints/blob/master/admin/scripts/ws.js#L45

If an update message gets sent from the server flowmon to the browser via the web socket, it triggers a reload of the web page:

https://github.com/duncan-brown/RaspberryPints/blob/master/admin/scripts/ws.js#L58

This will update the whole page.

However, it looks like information from Plaato is just pulled like a static database query by apache when you load index.php:

https://github.com/duncan-brown/RaspberryPints/blob/master/index.php#L75

After that, there's no communication to tell your browser to refresh the page and it stays static unless you do a manual reload.

Fixes to R'Pints would be:
  1. Add some code to index.php to get it to do a refresh every e.g. 300 seconds so at least you're no more than 5 mins out of date. I might put in a patch to do this, if the attempt to open a web socket fails because the user isn't running flowmon.
  2. Fix the web socket code to update when things other than flowmon change, but since Plaato data is pulled from the remote Plaato server, that would need a daemon on the R'Pints server to interrogate it for changes, which is more complexity and CPU load than option 1, so probably not worth the effort.
If you want a workaround without hacking R'Pints, you could use the following trick on the machine that is running chromium in kiosk mode to display the beers. First, install a couple of extra tools with:

Bash:
sudo apt-get install xdotool x11-xserver-utils

The create a script called refresh.sh in /home/pi that contains

Bash:
#!/bin/sh

/bin/sleep 6
/usr/bin/lxterminal --command watch -n 90 xdotool key ctrl+F5 &

Make this script executable by running the command chmod 755 /home/pi/refresh.sh

Then start this script when you start the browser by running the command /home/pi/refresh.sh. You can also add it to /etc/xdg/lxsession/LXDE-pi/autostart if you want it started automatically.

The script will send CTRL+F5 to the window that has the focus every 90 seconds (set by -n 90. You can tweak this as you want. Since the window with the focus should always be chromium, if it's in kiosk mode, this will trigger a reload of the page.

Awesome, have it refreshing every 90s which 'works' real time would have been nice but in reality this is fine.
Many thanks.


As a completely unrelated item, I saw an image (somewhere in this monster thread when trying to search for answers to my refresh issue) an image of someone's setup where the grain and hops are shown. This info is available on my setup as I've imported the beers as. xml files but I can't see an option to make it visible? What am I missing?
 
Last edited:
That was my first try ... 6 to 8 wraps of teflon tape on each connection and tightened them up. Woke up to a gallon of beer on the floor of my keezer.

Ouch. You definitely need a washer with BSPP. The last P stands for parallel so the threads don't have the tapering of NPT (the usual North American thread) or BSPT. Just wrapping with teflon tape is a gamble. What type of flow meters do you have? I have some SF800s on the way from the Netherlands, so if you have those I can measure the washer size before I install them.
 
Ouch. You definitely need a washer with BSPP. The last P stands for parallel so the threads don't have the tapering of NPT (the usual North American thread) or BSPT. Just wrapping with teflon tape is a gamble. What type of flow meters do you have? I have some SF800s on the way from the Netherlands, so if you have those I can measure the washer size before I install them.
I purchased some iSentrol stainless steel flowmeters from AliExpress, they're 1/4" BSPP. I have some 6MM ID X 9MM OD and 6 MM ID x 10MM OD copper crush washers on the way from eBay, hopefully one of those sizes will fit. If not, I'll try some o-rings.

https://www.aliexpress.com/item/33005811144.html?spm=a2g0s.9042311.0.0.62434c4d25U2Yb
 
If bound and determined to use a female BSPP barbed fitting with an SF800 I think you'd be best taking it to a hardware store and finding a nice thick flat Buna-N gasket that will stuff into the threaded end of the fitting. I would be leery of using an actual metal crush water with plastic fittings as it's easy enough to blow the back out of these things through over-torque - and that's with rubber gaskets.

fwiw, both models of John Guest fittings I have used with my SF800 meter fleet have captive integrated gaskets. While the latest/current version I'm usingi is 8mm OD by 3/8 BSPP to accommodate the EVAbarrier tubing I converted to, I used 3/8 OD by 3/8 BSPP with a stemmed 3/8 OD to 3/16" barb insert to work with the Bevlex 200 3/16" ID line I used to run. That would be a reliable solution here.

I greatly prefer the full PTC system with the EVAbarrier vs barbs 'n' clamps 'n' stuff.

Cheers!
 
Last edited:
If found and determined to use a female BSPP barbed fitting with an SF800 I think you'd be best taking it to a hardware store and finding a nice thick flat Buna-N gasket that will stuff into the threaded end of the fitting. I would be leery of using an actual metal crush water with plastic fittings as it's easy enough to blow the back out of these things through over-torque - and that's with rubber gaskets.

fwiw, both models of John Guest fittings I have used with my SF800 meter fleet have captive integrated gaskets. While the latest/current version I'm usingi is 8mm OD by 3/8 BSPP to accommodate the EVAbarrier tubing I converted to, I used 3/8 OD by 3/8 BSPP with a stemmed 3/8 OD to 3/16" barb insert to work with the Bevlex 200 3/16" ID line I used to run. That would be a reliable solution here.

I greatly prefer the full PTC system with the EVAbarrier vs barbs 'n' clamps 'n' stuff.

Cheers!
I have stainless flowmeters (male) with stainless barbs (female), both threaded in 1/4" BSPP. I'm just not used to BSPP fittings, everything I've used in the past was NPT and teflon tape is all you need.
 
I have stainless flowmeters (male) with stainless barbs (female), both threaded in 1/4" BSPP. I'm just not used to BSPP fittings, everything I've used in the past was NPT and teflon tape is all you need.

If it's metal to metal, then you should be good with the copper crush washer. I'm a John Guest shop like @day_trippr so my plan is to use the BSPP to 3/8" OD fittings Swissflow includes to go directly to my BevSeal Ultra.

Here's a page with some nice images explaining why you need the washer:

https://www.ralstoninst.com/news/story/the-difference-between-npt-bspp-and-bspt-seals
 
If it's metal to metal, then you should be good with the copper crush washer. I'm a John Guest shop like @day_trippr so my plan is to use the BSPP to 3/8" OD fittings Swissflow includes to go directly to my BevSeal Ultra.

Here's a page with some nice images explaining why you need the washer:

https://www.ralstoninst.com/news/story/the-difference-between-npt-bspp-and-bspt-seals
Yes, I've seen that page, but thanks! My situation is slightly different than the BSPP example on that sheet, the male end of my fitting has no shoulder, so an external crush washer will not work, the seal needs to be made at the very end of the male fitting where it bottoms out into the female fitting. Hopefully the crush washers I have coming will fit inside the female fitting yet will be large enough to seal against the male end.
 
the male end of my fitting has no shoulder

Ah, I see from the image of the sensor. Looks like you are making a HIAB (flat-face) BSPP fitting:

https://www.hoseandfittings.com/int-thread-id/#hiab
Normally that uses a rubber o-ring to make the seal, but I'd give the copper crush washer a go (with a drip tray under the sensor) and see what happens. You could do a test where you just pressurize it with 25 psi of CO2, then squirt the connections with star san, and watch for bubbles (if you don't want to risk an initial test with beer).
 
Ah, I see from the image of the sensor. Looks like you are making a HIAB (flat-face) BSPP fitting:

https://www.hoseandfittings.com/int-thread-id/#hiab
Normally that uses a rubber o-ring to make the seal, but I'd give the copper crush washer a go (with a drip tray under the sensor) and see what happens. You could do a test where you just pressurize it with 25 psi of CO2, then squirt the connections with star san, and watch for bubbles (if you don't want to risk an initial test with beer).
Exactly! Unfortunately, the face of the male fitting is not machined to fit an o-ring, it is just a flat mating surface. Hopefully the internal crush washers will seal the joints, if not then I'll try to find some flat rubber or nylon washers or something. Good idea with the CO2 test, I have an empty keg I can connect and pressurize to test each of the connections for leaks before connecting my full kegs to them.
 
Just to be clear, I did enable the one-wire probe through the interface provided by the sudo raspi-config command. I think that is how the line "dtoverlay=w1-gpio" gets inserted into the config.txt file. My only addition was the "gpiopin=4" which I believe is pin 7 on my Pi(s).

I'm a bit surprised as well that this is required, but my Raspberry Pints is still chugging along with the most recent temp and time flawlessly.

If I remember correctly from all the threads I looked through to figure this out, you are not running the RandR+ branch. This might also contribute to how the temp data is being called or somehow forgotten and might explain why you didn't need to add this step. Curious to know if there is a correspondence between flavor of this software and this problem. From my experience, it certainly is consistent across models of Pi running the same OS.

In any case, the install script provided a great way to get rpints running. Many thanks to everyone who contributed to it.
More
For anyone else who is experiencing this problem (as I was on each of 2 installs: One on a Model B rev 2 with 32 gb running buster and the second on Pi 4 2 gb with 64gb same OS) using the RandR+ branch of the command line (curl -L https://raw.githubusercontent.com/rtlindne/RaspberryPints/master/util/installRaspberryPints | sudo bash) the problem does not seem to be overheating, corrupted databases, lack of hard wiring the probe, insufficiently powered Pi, etc (at least in my case) but rather that the Pi and/or the software is loosing track of where the temperature probe is and therefore defaults out to the minimum reading of 32 F in the setup of raspberry pints minimum and maximum or just freezes on the last good measurement, time and date. (I determined this by watching the folder containing the probe data dissapear at some point under /sys/bus/w1/devices, or if it was there, returning the correct temperature as described below, but raspberry pints did not show that data.)

To fix this I followed instructions in this article (Using DS18B20 Digital Temperature Sensors with the Raspberry Pi - Raspberry Pi Spy ) by implementing the following commands:
sudo nano /boot/config.txt
at the bottom of the file you will see the following if you have gone through sudo raspi-config and enabled the one-wire interface

dtoverlay=w1-gpio

below that I added the specific gpiopin number that the data wire from the probe was connected to on the Pi through the 4.7K resistor. It looks like this in my config.txt:

#added this to see if I could get the probe to stabilize gpiopin=4

I then did a
sudo reboot
logged back in, went to

cd /sys/bus/w1/devices

did a ls

selected the number of my probe and went into that directory:

cd 28-0206917714fc

and then ran

cat w1_slave

to get the reading:

b6 01 55 05 7f 7e 81 66 ad : crc=ad YES
b6 01 55 05 7f 7e 81 66 ad t=27375

t=27375 tells the software that the temperature is 27.375 C

I've run this for most of a day and it keeps on updating everything correctly on the landing page upper right-hand corner.

Hopefully, this will help someone experiencing this problem, as it took me quite some time to find this fix.
More fun with the role of the /boot/config.txt file was had when I attempted to run my Pi 4 2 gb with rpints installed from a 16 gb SSD drive instead of the SD card.

Having recently upgraded to a Pi 4, I was disappointed to find that the software developers had neglected to enable 'boot from usb' as a feature as they had apparently done in the Pi 3 B+. The problems with using a SD card as a storage device had made me abandon early versions of RPI because they were slow and notoriously unreliable for a long-term storage solution--something they were never designed to do. After getting rpints to work, I didn't want to wake up to missing data.
I stumbled on this web site which gave a strategy about how to get the SSD drive to work in combination with the SD card:

https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/
Having an old 16 gb M.2 drive from a chromebook lying around, I decided to give it a try. Unfortunately, although I had 'approved' hardware from the list, I could never get this to work. However, I was able to benchmark the speed of my SD card from the command line by using the command:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

and comparing my results with others in the database:

https://storage.jamesachambers.com/
My microcenter 64 gb SD came in with a score of 1365

Reading a comments on this article, I found an alternative that worked here:

https://www.tomshardware.com/how-to/boot-raspberry-pi-4-usb
Even better, once the Pi is set up, you no longer need the SD card and you can install Raspbian to the SSD using the Raspberry Pi Imager or whatever your preferred method is. The only requirement is that in the SSD boot directory you must replace the *.elf and *.dat files from a download of a zip file you can find here.

https://github.com/raspberrypi/firmware/tree/a6c9b6b48ce86ef2527586a50760d52f1b33f642
Of course, you should also add an empty "ssh" file to the boot so that you can use that service to log in remotely. One interesting glitch I found on a 1 Terabyte drive I formatted this way was that apparently the fdisk the Pi does on initial boot got "stuck": removing the usb cable and replugging it back in while the pi was still in the initial boot fixed this problem and the Pi booted normally. However, I did not experience this with the 16 gb M.2 drive. For comparison to the SD card, my score with this Kingston drive was 4278--a little over 3 x as fast as the SD card with improved data stability.

https://storage.jamesachambers.com/benchmark/28021
Purchasing faster drives can push this number up into the 10,000 score range or about 7.5 times as fast--you can peruse the database to see what the best bang for the buck might be.

So the interesting point of all this was not only improvement in speed and reliability but how the UNO I am monitoring pours with interfaces with the Pi.

Once again, I used:

curl -L https://raw.githubusercontent.com/rtlindne/RaspberryPints/master/util/installRaspberryPints | sudo bash

to install rpints and used the RandR+ branch

My UNO clone required that I use:

sudo nano /var/www/html/python/Config.py

and add or replace '/dev/ttyACM0' with '/dev/ttyUSB0'. I also set pin 7 for beer number one for my digiten flow meter.

Despite the fact that my hardware had not changed, everything worked except the flow meter. What was frustrating was that I could use the SD card and all was fine, but when I used the SSD--no pours.

Finally, I went back to my instructions above and changed the

dtoverlay=w1-gpio
to
dtoverlay=w1-gpio,gpiopin=4
in
sudo nano /boot/config.txt
and rebooted.
Instant success! Apparently the Pi is confused about which input to use for 1-wire until it is specifically defined. (This may also explain why the 1-wire would suddenly go missing in my setup)
Now, everything is working at 3 x the speed and with more stability.
Hope this helps someone who either wants to run rpints on a SSD drive or is having problems getting their flow sensors to work on a UNO clone.
 
I'm using the latest Raspberry Pi on a RPi3 with rpints. Will an older SSD drive have sufficient IO? I don't have flow meters yet but that is in the future! Brand new Raspberry Pi install and brand new rpints (RandR+) install. It worked the first time.
 
Considering the USB ports on the RPi3 and below share a fairly low bandwidth path to the SOC I'm sure even the oldest SSD you can find won't be challenged for throughput...

Cheers!
 
An SSD is supported by the Pi, but you are not going to set any speed records. Seems to me you may actually be borrowing trouble. Is there some reason you;re headed that direction?
 
Yeah mate. You can choose the RANDR+ version or the TOBOR version i think its called. I chose RANDR+.

Is this for real? haha! I literally just spent a couple hours getting this up and running on Jessie on PHP5... Going to go this route and try it out. Now to find out the difference between TOBOR and RANDR+
 
The Tobor_8thman branch is essentially the original RaspberryPints 2.0.1 with heavy code changes, mostly for compatibility with the currently available database manager. Behaviorally it should appear the same as the classic version.

The RandR+ branch adds greatly increased user control over the gui, more rational keg management, and incorporates some of the add-ons I came up with over the years (motion sensor screen wake-up, temperature monitoring, etc).

Cheers!
 
My SF800 flow meters arrived today, so I can now get these hooked up. Can anyone who has used these confirm that the pitch on the three-pin female connectors is 2mm? It looks slightly smaller than 2.54 mm breadboard connectors. I'll pick up some 3pin 2mm connectors from Amazon so I can hook them up to the breadboard that's going to have the 2200 ohm load resistors on it.
 
Yes, that sounds correct, hard metric 2mm pitch. I cut them all off and used TinyXLRs...

After 15 mins of playing with unsatisfactory connections with the 2mm connectors, I chopped them off, stripped the wires, and screwed them into screw-terminal block. I used a piece of 16x16 plastic peg board I had lying around as the base so it sits nicely in the bottom of my keezer.

To give me some additional visual monitoring, I hooked up the base of a 2N2222 transistor via a 4k7 ohm resistor 22k ohm resistor to the pulse pin of each flow meter. I connected a 120 ohm resistor and 2V/20mA LED in series between the 5V supply from the Alamode and the transistor’s collector. The emitter is connected to the Alamode’s ground.

Edit: I swapped the 4k7 resistor on the base to a 22k ohm resistor which is enough to saturate the transistor and drive the LED, but doesn't pull down the voltage on the digital pin as much. With 4k7, I was pulling the voltage down close to the high/low transition threshold which was giving me spurious pulses and triggering a keg kick.
 

Attachments

  • AE6B74C0-EB17-4406-AF47-0BBCB8E9AD6D.jpeg
    AE6B74C0-EB17-4406-AF47-0BBCB8E9AD6D.jpeg
    786.3 KB · Views: 41
  • 3070A129-4DC0-43C3-AB01-A4265FF29FE4.jpeg
    3070A129-4DC0-43C3-AB01-A4265FF29FE4.jpeg
    1.4 MB · Views: 40
Last edited:
In case it's useful to others, I hacked together a secondary page that just displays the beer name and a large keg icon. This works well to display the keg status on a 3.5" LCD display that's hooked up to the Pi in the brewery, with the main page displayed on a TV in the bar. The files for the keg page are
Drop these files into /var/www/html and /var/www/html/includes and go to http://rpints/keg.php to view them.

IMG_6229.jpeg IMG_6230.jpeg IMG_6231.jpeg

As you can see, I am running dangerously low on beer, so it's time to stop messing with equipment and start brewing!
 
I am currently in the process of building a keezer and I am planning on setting up raspberry pints on it. I have absolutely no experience with this sort of thing but am currently at the stage of just sourcing all the bits I need. I am based in the UK and the Swiss flow meters are not really a thing over here as far as I can tell. I was hoping someone could point me in the direction of an alternative. (There are some cheap ones on eBay but I don’t know if they are suitable?) Any advice much appreciated!
 
Back
Top