SHvanBommel
Well-Known Member
- Joined
- Nov 5, 2007
- Messages
- 548
- Reaction score
- 57
this is rad. so you can either use the seed studio or adafruit sensors?
[Version 2 Release] RaspberryPints - Digital Taplist Solution
- Thread starter skemp45
- Start date
Help Support Homebrew Talk:
Well update on my foaming problem, I seemed to have forgotten that moving kegs around can cause foaming. After just letting the kegs sit for a day after moving them for the sensor install fixed the problem. My foaming problem went away. Flow sensors are working very well and seem to be very accurate.
Excellent!
And thanks for the follow-up, good to know the "solution" was time
Cheers!
And thanks for the follow-up, good to know the "solution" was time
Cheers!
wbarber69
Well-Known Member
- Joined
- Oct 13, 2013
- Messages
- 2,191
- Reaction score
- 263
I went with the seeedstudio ones because they were white plastic over black. Like it really matters. And the fact that they were 1/4". But be warned, they are 1/4" bsp. It took over 12 wraps of Teflon to get any fitting I could find to make up with it.
SHvanBommel
Well-Known Member
- Joined
- Nov 5, 2007
- Messages
- 548
- Reaction score
- 57
How much modification needs to be done to the original raspints SW in order to get them to work properly?
Basically, you change one constant in a php file...
Cheers!
Cheers!
![Craft A Brew - Safale BE-256 Yeast - Fermentis - Belgian Ale Dry Yeast - For Belgian & Strong Ales - Ingredients for Home Brewing - Beer Making Supplies - [3 Pack]](https://m.media-amazon.com/images/I/51bcKEwQmWL._SL500_.jpg)
wbarber69
Well-Known Member
- Joined
- Oct 13, 2013
- Messages
- 2,191
- Reaction score
- 263
If you're using the alamode then 1 line in pours.php. If you're using an arduino it's slightly more work. The 1/4" seedstudio ones (they are all the same manufacturer: SeA) needed to be drilled out for better flow. I've got a 1/2" one on its way from China now for another project. I can test it out once it arrives and see if the pulse count ends up being different. I'm using a pulse count of 3500 for the modified 1/4" meters. And I'm hitting 16oz on a full pint glass every time.
SHvanBommel
Well-Known Member
- Joined
- Nov 5, 2007
- Messages
- 548
- Reaction score
- 57
that's seriously impressive. what did you drill out to on the 1/4" one? Also, i'm assuming in the pours.php is where you change the number to 3500. amiright? also, big cheers to all of you guys for this. looking forward to making this happen. would probably go with an alamode board re: ease of use/integration.
wbarber69
Well-Known Member
- Joined
- Oct 13, 2013
- Messages
- 2,191
- Reaction score
- 263
I don't remember what bit I used exactly. It was already in the drill and fit into the inside of the larger output hole on the meter. I drilled straight through from the smaller inlet side to the outlet side and then came back with some 300 grit sandpaper rolled up and cleaned up the hole all the way through. I think the original finder of these meters earlier on in this thread was using a much higher pulse count. And I attribute that to the tiny inlet hole pressurizing the water coming in. It took quite a while to realize I needed to go that low in the pulse count to get accurate results.
SHvanBommel
Well-Known Member
- Joined
- Nov 5, 2007
- Messages
- 548
- Reaction score
- 57
well i appreciate it and will start a thread using the alamode and these guys.
andrewmalizia
Well-Known Member
FYI... I havent read the thread in a while, so this may have been mentioned, but the Alamodes are on sale at Makershed right now for $25
One weakness in the RaspberryPi platform is the sdcard storage scheme. It's not what I would consider robust. I had a card totally die last December, and today the sdcard in my "production" system that runs my tap list, ferm fridge, carb fridge and keezer gagged up a bad block that panicked the kernel on reboot. It needed a fresh format and a re-imaging.
As all four of my RPi systems are now sharing a single sdcard image it only takes the time to write a card again, say 15 minutes, plus a few minutes changing the system name and IP address, to get the system back on the air. But what inevitably gets lost is the current RaspberryPints tap list data, and all of the BrewPi logs and scripts and my temperature logger data.
Out of all that, the one I actually care about is the tap list data. It's a pita to try to re-create the database state to a "best guess" of what and how much is on tap. So at the least, I need a way to copy the running database to a safe location.
On my RPi systems, MySQL databases are stored in /var/lib/mysql.
In that folder there is a raspberrypints folder, which contains all of the forms for the RaspberryPints database.
But the data file is /var/lib/mysql/ibdata1
And as my experiments have shown, it can be cloned, copied, backed-up, restored...whatever. Having a copy of that data file somewhere handy is A Good Thing, and obviously, the more current the better.
While I could fire up WinSCP and pull a copy to my workstation when I remember to do it, instead I will be getting grive running, to automate the back-up of my 'Pints data file, temperature logger and BrewPi data...
Cheers!
As all four of my RPi systems are now sharing a single sdcard image it only takes the time to write a card again, say 15 minutes, plus a few minutes changing the system name and IP address, to get the system back on the air. But what inevitably gets lost is the current RaspberryPints tap list data, and all of the BrewPi logs and scripts and my temperature logger data.
Out of all that, the one I actually care about is the tap list data. It's a pita to try to re-create the database state to a "best guess" of what and how much is on tap. So at the least, I need a way to copy the running database to a safe location.
On my RPi systems, MySQL databases are stored in /var/lib/mysql.
In that folder there is a raspberrypints folder, which contains all of the forms for the RaspberryPints database.
But the data file is /var/lib/mysql/ibdata1
And as my experiments have shown, it can be cloned, copied, backed-up, restored...whatever. Having a copy of that data file somewhere handy is A Good Thing, and obviously, the more current the better.
While I could fire up WinSCP and pull a copy to my workstation when I remember to do it, instead I will be getting grive running, to automate the back-up of my 'Pints data file, temperature logger and BrewPi data...
Cheers!
I've changed to running a Ubuntu Linux VM on my server and have all the SQL data stored there. If you have a Linux NAS or other device, you could move your data there as well. My RaspberryPi that runs my beer board is now just the Chromium browser installed and showing the web page from my VM. It runs faster without all the overhead and I'm sure it likely won't kill the SD card now that MySQL is no longer running on the Pi.
I honestly don't see any reason to be using MySQL for this app. There's no reason the data can't easily be stored in some JSON or XML files.
No doubt there are other ways RaspberryPints could have been implemented, but I'm fine with the way the team went because the result is actually fairly elegant, the gui can be customized without heroics, and phpMyAdmin lets you tweak the database when necessary.
In any case, I don't think it matters what method is/was used wrt sdcard volatility, a write is a write.
In any case, I don't attribute the card failures with the R'Pints application, or frankly any user-level code.
I don't keep any of our peecees running 24/7 these days as they're so quick to wake up from S3.
But I suppose I could mirror critical files on one of the RPi systems that do run 24/7.
And in the short term, that may prove to be the most viable solution, as it turns out a change to a critical Google Drive API back in April rendered Grive non-functional and the author has been MIA.
In the subsequent half-hour of looking around I've found various, non-elegant alternatives. More research is needed.
As for the speed thing, you'd be amazed how nicely R'Pints runs on an RPi2. Screen updates are done in a blink where the Model B and B+ might take a couple/few seconds. And you get the real-time tap list update instead of waiting for a refresh timer to expire...
Cheers!
In any case, I don't think it matters what method is/was used wrt sdcard volatility, a write is a write.
In any case, I don't attribute the card failures with the R'Pints application, or frankly any user-level code.
I don't keep any of our peecees running 24/7 these days as they're so quick to wake up from S3.
But I suppose I could mirror critical files on one of the RPi systems that do run 24/7.
And in the short term, that may prove to be the most viable solution, as it turns out a change to a critical Google Drive API back in April rendered Grive non-functional and the author has been MIA.
In the subsequent half-hour of looking around I've found various, non-elegant alternatives. More research is needed.
As for the speed thing, you'd be amazed how nicely R'Pints runs on an RPi2. Screen updates are done in a blink where the Model B and B+ might take a couple/few seconds. And you get the real-time tap list update instead of waiting for a refresh timer to expire...
Cheers!
rabeb25
HE of who can not be spoken of.
I bought a Pi2 for this but then noticed the header was different for the alamode, what did you do to get it to work?
thanks!
rabeb25
HE of who can not be spoken of.
I know somewhere in the thread was a post or 2 about pins that were verified working, anyone have that? I just had to re-install due to a sd card failure, and am getting weird pours on 2 of the 5 taps. I had to unplug the flows on the alamode side, to get at the SD card and just plugged then into 7-11( and updated the pints file accordingly). IIRC I didnt have them like that before, when I wasn't seeing the issues..
Thanks!
Thanks!
Nothing other than positioning the AlaMode so it picks up the RPi2 IO header with both starting at the pins 1 & 2 end (the end opposite from the USB & NIC receptacles). There will be "unconnected" RPi2 pins but the AlaMode header shroud will fit in the gap between pins 25/26 and 27/28 without issue...
Cheers!
[edit] As for the "known good" pins for meters, they are 2, and 5-11.
IO12 may work but I've never used it, it's shared with the MISO SPI function.
And IO13 should work if it isn't committed to driving the "Blink LED" on the AlaMode to confirm a pour was detected (I have that feature in my AlaMode sketch).
So after perusing the demise of Grive and the various flaky alternative methods of accessing Google Drive from an RPi, it occurred to me that I had the makings of a more optimal solution right in front of me.
The Netgear gigabit router I use for our private subnet has the ability to host a USB storage device using SMB protocol, something I imagine most routers are capable of doing these days. I've never had a compelling need to use it, but this is the perfect application for it.
I had a 4GB USB2 key that has been idle for months, so I plugged that into the router and within seconds it was available on the network. I left it totally wide open as there's no reason to protect it with user credentials.
Then from my W7U system I created a folder on the drive for each of my RPi systems using their system names (rpints, bpints, raspi1 and raspi2).
Next, on each RPi I created a local folder under the existing /media root to associate the mount point for the SMB drive.
For example, on system rpints:
Next, on each RPi I added an entry to /etc/fstab
Note that you must have a trailing CR/NL in the fstab file; it'll bitch about it if there isn't a blank line at the end of the file.
The IP address is the LAN address for the router (aka the "gateway" IP address) and the rest of that first path drills down to the target folder on the SMB drive. That will obviously vary - for example Netgear uses "\\readyshare\USB_Storage" as the drive root where I'm sure Cisco does something different. The second path is the corresponding local mount point.
cifs is the file access method; the user, domain name and (null) password paramters seem to be required even if the SMB drive requires no privileges; and sec is the security mode parameter, set to ntlm.
With the fstab file changes the SMB drive will automatically mount on boot, but the drive can be mounted manually at this point:
If the mount didn't fail the drive should be available via the mount point defined in the fstab file.
And you can list the contents of the SMB folder:
Those are copies of my R'Pints and temperature logger data files sitting in the SMB drive folder.
So with that all set up, an automated backup process for select files can be constructed.
In this example, I'll save a copy of the R'Pints data file and the temperature logger data file from system rpints to its folder on the SMB drive.
I created a bash script at /home/pi/backup.sh
This script stops MySQL, copies the R'Pints data file and my logger data file to the SMB drive folder, then starts MySQL again and exits.
After writing out the script, be sure to set it to executable for owner and group.
Finally, I added a command to root's crontab to run the script every night at 12:05 AM:
Et voila! Automated critical file backups!
Cheers!
[edit] This requires cifs-utils which I believe is part of the standard Debian distributions these days, but it's easy to check to see if it's already installed:
If it hasn't been installed, do this:
The Netgear gigabit router I use for our private subnet has the ability to host a USB storage device using SMB protocol, something I imagine most routers are capable of doing these days. I've never had a compelling need to use it, but this is the perfect application for it.
I had a 4GB USB2 key that has been idle for months, so I plugged that into the router and within seconds it was available on the network. I left it totally wide open as there's no reason to protect it with user credentials.
Then from my W7U system I created a folder on the drive for each of my RPi systems using their system names (rpints, bpints, raspi1 and raspi2).
Next, on each RPi I created a local folder under the existing /media root to associate the mount point for the SMB drive.
For example, on system rpints:
Code:
$ sudo mkdir -p /media/readyshare/rpintsNext, on each RPi I added an entry to /etc/fstab
Code:
//192.168.1.251/USB_Storage/rpints /media/readyshare/rpints cifs user=guest,domain=CORP,password=,sec=ntlmNote that you must have a trailing CR/NL in the fstab file; it'll bitch about it if there isn't a blank line at the end of the file.
The IP address is the LAN address for the router (aka the "gateway" IP address) and the rest of that first path drills down to the target folder on the SMB drive. That will obviously vary - for example Netgear uses "\\readyshare\USB_Storage" as the drive root where I'm sure Cisco does something different. The second path is the corresponding local mount point.
cifs is the file access method; the user, domain name and (null) password paramters seem to be required even if the SMB drive requires no privileges; and sec is the security mode parameter, set to ntlm.
With the fstab file changes the SMB drive will automatically mount on boot, but the drive can be mounted manually at this point:
Code:
$ sudo mount -aIf the mount didn't fail the drive should be available via the mount point defined in the fstab file.
And you can list the contents of the SMB folder:
Code:
pi@rpints ~ $ ls -l /media/readyshare/rpints/
total 20208
-rwxr----- 1 root root 18874368 Jun 19 21:34 ibdata1
-rwxr--r-- 1 root root 1812480 Jun 19 21:34 tempdata.db
pi@rpints ~ $Those are copies of my R'Pints and temperature logger data files sitting in the SMB drive folder.
So with that all set up, an automated backup process for select files can be constructed.
In this example, I'll save a copy of the R'Pints data file and the temperature logger data file from system rpints to its folder on the SMB drive.
I created a bash script at /home/pi/backup.sh
Code:
sudo service mysql stop
cp /var/lib/mysql/ibdata1 /media/readyshare/rpints
cp /var/www/tempdata.db /media/readyshare/rpints
sudo service mysql startThis script stops MySQL, copies the R'Pints data file and my logger data file to the SMB drive folder, then starts MySQL again and exits.
After writing out the script, be sure to set it to executable for owner and group.
Finally, I added a command to root's crontab to run the script every night at 12:05 AM:
Code:
$ sudo crontab -e -u root
Code:
5 0 * * * /home/pi/backup.sh > /dev/null 2>&1Et voila! Automated critical file backups!
Cheers!
[edit] This requires cifs-utils which I believe is part of the standard Debian distributions these days, but it's easy to check to see if it's already installed:
Code:
$ dpkg -s cifs-utils
Package: cifs-utils
Status: install ok installedIf it hasn't been installed, do this:
Code:
$ sudo apt-get update
$ sudo apt-get install cifs-utilswbarber69
Well-Known Member
- Joined
- Oct 13, 2013
- Messages
- 2,191
- Reaction score
- 263
I was scouring the web today looking for example flow meter code for another project and I noticed one project that seems to be quite marketable. Then I started looking at the features and screenshots they have posted and I noticed a bit of similarity with rpints. Actually I'm pretty sure these guys just changed some cosmetic stuff and basically took rpints and ran with it.
Http://kegberry.kegbot.org
Http://kegberry.kegbot.org
rabeb25
HE of who can not be spoken of.
Was the phantom pours ever figured out? Suddenly today I have 4 out of 5 sensors doing it, all of which had not done it....ever( been up for a year or so). The only change in the entire arrangement was new rpints on a new sd card.
Don't worry about it. The folks behind Kegberry appear to be the same folks that brought Kegbot into the world - which was years before RaspberryPints was even an idea. And if they lifted anything from our 'Pints friends I guarantee they'd put that right out there.
Frankly, the 'Pints gui kicks the Kegberry gui to the virtual curb, but I'm a total homer
Cheers!
Frankly, the 'Pints gui kicks the Kegberry gui to the virtual curb, but I'm a total homer
Cheers!
I have not had a phantom/ghost pour in just over a year now...
Cheers!
[edit] I see it's been rather warm for Minnesota recently.
How well are you managing your kegerator/keezer interior temperature?
CO2 breakout can play havoc with flow meters...
Cheers!
[edit] I see it's been rather warm for Minnesota recently.
How well are you managing your kegerator/keezer interior temperature?
CO2 breakout can play havoc with flow meters...
mcangeli
Well-Known Member
- Joined
- Dec 26, 2012
- Messages
- 371
- Reaction score
- 59
Kegberry and kegbot has been out for a while. Kegberry is kegbot for the rpi.
wbarber69
Well-Known Member
- Joined
- Oct 13, 2013
- Messages
- 2,191
- Reaction score
- 263
Yeah I just noticed the interface is basically the exact same layout and feature set. It just looks like they changed the layout and images ever so slightly so it doesn't look exactly the same. Even the admin panel is spot on.
First off, a big thanks to all who have contributed to this great project.
I have set up my PIR and it wakes up the screen saver but I am trying to get my monitor in and out of power saving mode.
According to this link DPMS will not put the monitor into power saving mode.
https://github.com/raspberrypi/linux/issues/487
So I have found that I can I can turn the monitor off with /opt/vc/bin/tvservice -o and back on with /opt/vc/bin/tvservice -p. (which also needs fbset -depth 8; fbset -depth 16; xrefresh)
So my question is has anyone written a PIR script using the above commands, or got their monitor in and out off power saving mode (with the PIR) using any other method? Basically forget the screen saver and use a script to enter power saving mode and then only wake up with the PIR is triggered.
If not, it may be time for me to learn python
I have set up my PIR and it wakes up the screen saver but I am trying to get my monitor in and out of power saving mode.
According to this link DPMS will not put the monitor into power saving mode.
https://github.com/raspberrypi/linux/issues/487
So I have found that I can I can turn the monitor off with /opt/vc/bin/tvservice -o and back on with /opt/vc/bin/tvservice -p. (which also needs fbset -depth 8; fbset -depth 16; xrefresh)
So my question is has anyone written a PIR script using the above commands, or got their monitor in and out off power saving mode (with the PIR) using any other method? Basically forget the screen saver and use a script to enter power saving mode and then only wake up with the PIR is triggered.
If not, it may be time for me to learn python
LOL! You have no idea how many paths I've followed looking for the Holy Grail that is a low power display state.
The original R'Pints thread is laced with the long sordid history.
What type of display are you using - HDMI or DVI?
And are you executing the tvservice commands from a remote terminal?
If you can provide the literal commands you're using I think I can cobble up a pir_run script to use them.
Don't leave anything out wrt parameters, etc...
Cheers!
The original R'Pints thread is laced with the long sordid history.
What type of display are you using - HDMI or DVI?
And are you executing the tvservice commands from a remote terminal?
If you can provide the literal commands you're using I think I can cobble up a pir_run script to use them.
Don't leave anything out wrt parameters, etc...
Cheers!
Just played around with this for a bit and found that the following commands work to 1 - turn off the display, and 2 - turn it back on.
tvservice -o
tvservice -p && fbset -depth 8 && fbset -depth 16 && xrefresh -d :0
On my pi tvservice does not live in /opt/vc/bin/tvservice as others have found. It lives in /usr/bin/tvservice. I am running these on a remote SSH connection. My monitor is DVI. If you can cobble up a pir_run script that uses these that would be awesome. My python skills are pretty bad.
Similar threads
