[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.
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!
 
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...
 
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

Kegberry and kegbot has been out for a while. Kegberry is kegbot for the rpi.
 
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.:mug:
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!
 
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!

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.
 
Excellent data!

I will get to this over the weekend, and try it out on my test system (which has an HDMI monitor).

I've played with tvservice in the past but while I was able to get the display to shut down, waking it back up left it in weird states (either geometry was wrong or the color space was AFU). Looking at your wake-up command I'm pretty sure I wasn't passing that many parameters, so that may be the key...

Cheers!
 
Excellent data!

I will get to this over the weekend, and try it out on my test system (which has an HDMI monitor).

I've played with tvservice in the past but while I was able to get the display to shut down, waking it back up left it in weird states (either geometry was wrong or the color space was AFU). Looking at your wake-up command I'm pretty sure I wasn't passing that many parameters, so that may be the key...

Cheers!

Yeah I played around with different combos of the wakeup command and if I omitted either the fbset or the xrefresh I got the weird geometry and other issues you are describing. After several tries the command I posted above seems to reliably wake it up each time with correct geometry.

Thanks much for providing the pir script in the first place.
 
Thanks day_trippr for the offer and thanks crane for providing the data. Those are the exact commands I had found reported to do the trick. I was going to test them before posting and then my &*#^*&$(*)@#&()@ SD card died and I have to set everything up again.
Please let me know if I can provide any additional info or help with testing.
I really appreciate it. :mug:

Chris
 
Well I have hit another snag. I have to be missing something simple but can't locate it.
First
When I hit this step: $ sudo cp flowmon /etc/init.d
the /var/www/python folder does not contain a file(or folder) called flowmon.
There is 1 file called flow_monitor.py. So I copy flow_monitor.py to /etc/init.d.
Maybe I have already gone wrong here?

Then
In the next 2 steps I substitute flow_monitor.py for flowmon
sudo chmod a+x /etc/init.d/flow_monitor.py
$ sudo /etc/init.d/flow_monitor.py start $ ps aux | grep flow_monitor.py

This seems to launch but never returns anything and does not return me to a prompt.

Thanks to a dead SD card this is the 2nd time in a row I got this far in the install and hit this same issue.

Any suggestions would be greatly appreciated.
 
I think I just found a way to fix this. I looked at the 2.01 hotfix and I see the flowmon file in the /python folder. It appears that the flowmon file is not in the 2.0 release. I am sure it was there when I did my first install before my SD card failure. Has it been removed for some reason?
Anyway, I am heading out for breakfast and will try this when I get back.
 
Tried searching to no avail, so I'll ask it here:

I'm planning to build a RaspberryPints tap list, at first without flow meters, then (hopefully) adding them on at a later date. Should I configure my initial system for flow meters, or reconfigure when I decide to add them on? Also, should I install the AlaMode board now or when I add the meters? If reconfiguring later, will I lose my previous data in the process?

Thanks!
 
I think I just found a way to fix this. I looked at the 2.01 hotfix and I see the flowmon file in the /python folder. It appears that the flowmon file is not in the 2.0 release. I am sure it was there when I did my first install before my SD card failure. Has it been removed for some reason?
Anyway, I am heading out for breakfast and will try this when I get back.

There's more in 2.0.1 than just the service file addition...

Cheers!
 
Tried searching to no avail, so I'll ask it here:

I'm planning to build a RaspberryPints tap list, at first without flow meters, then (hopefully) adding them on at a later date. Should I configure my initial system for flow meters, or reconfigure when I decide to add them on? Also, should I install the AlaMode board now or when I add the meters? If reconfiguring later, will I lose my previous data in the process?

Thanks!

You can do the full metered install without actual meters.
If I had all the other bits that's what I'd do...

Cheers!
 
I am assuming that if I just blow into the flow meter that should be sufficient to test it until I have the correct connections. Can anyone confirm that?

I have everything wired up but cannot get a "pour" to register by blowing into the meter.

I have confirmed:
1. The sketch has been updated using pin 7.
2. ps aux | grep flow_monitor.py confirms the script is running
3. Wires from adafruit flow meter (red 5V, black ground, yellow I/O) go to the correct pins on the Rpi 2 B. (Red to pin2, black to pin 6 and yellow to pin7)
4. In my taps list I have the pin # set to 7.

So either I have messed something up or simply blowing in the meter is not sufficient? I do hear something inside spinning when I blow into it so I would think this should work?

Any suggestions/pointers on where to look next?
BTW, I am running hotfix 2.01.

Also, I tried both Pin7 and the one that maps to GPIO7 which is 26 but neither worked :confused:

Thanks,

Chris
 
I deleted all files and unzipped 2.0.1 update and I do have Chromium open when testing.
 
Ok, if you've installed the full 2.0.1 kit, one way to debug the meters is to:

- Stop the Flowmon service:
Code:
$ sudo /etc/init.d/flowmon stop

Run the flow_monitor script in a terminal:

Code:
$ sudo python /var/www/python/flow_monitor.py

Leave that running while you blow through your meter(s).
It should display a terse (3 short lines iirc) pour packet in response to meter rotation. Get that to work first.

Once you're getting pour messages you will need to alter a constant in pours.php to account for the non-Swissflow SF800 meter...

Cheers!
 
Thanks alot for your time in helping me triage this. I am still not having any luck even just using the debug method you suggested. Could you please clarify if I program for pin 7 is that the 7th pin on the board or whatever pin maps to GPIO7?:confused::confused::confused:
 
Yes, "Pin 7" = Digital IO 7
ArduinoUno_R3_Front.jpg

My keezer uses IO 2 and 5 through 9, so I know for sure that pin works...

Cheers! (yes, that's an Uno, but same difference)
 
I don't always see anything from flow_monitor.py unless there is an issue or I didn't have chromium running. When chromium is running I get nothing from the script in terminal. But the browser comes forward in the screen and it refreshes showing me that a pour has happened.
 
Thanks all for your help. Luckily I pointed a friend to this thread who is also doing this setup and I think the uno picture tipped him off. I was using GPIO7 on the header instead of Digital I/O 7. I know have pours registering when I blow into the meter. Once I get my connectors I will be able to try some actual pours and adjust the pulse constant in the pours.php.

day_trippr, I will look forward to your motion sensor modifications to use tvservice -o / -p :rockin:
 
Good to see you're making progress.

As for the tvservice thing: I still have a problem returning to the on state; the color is definitely altered from the normal/default such that everything looks slightly neon or "electric". There must be some parameter that's not right for my recent vintage HDMI monitor.

Anyway, that aside, I was hoping to have xscreensaver run the command to shut off the display and have my pir_run turn it back on, but xscreensaver doesn't have the ability to run a program.

So I don't have a way to turn off the screen yet, but I'm thinking I need to figure out how to use the xscreensaver "watch" function with Python...

Cheers!
 
Good to see you're making progress.

As for the tvservice thing: I still have a problem returning to the on state; the color is definitely altered from the normal/default such that everything looks slightly neon or "electric". There must be some parameter that's not right for my recent vintage HDMI monitor.

Anyway, that aside, I was hoping to have xscreensaver run the command to shut off the display and have my pir_run turn it back on, but xscreensaver doesn't have the ability to run a program.

So I don't have a way to turn off the screen yet, but I'm thinking I need to figure out how to use the xscreensaver "watch" function with Python...

Cheers!
Thanks, it has been a bit of a slow battle but it is getting there. I am excited to get this thing up and running. Too bad it could be 3-4 weeks before my barbed connectors arrive :(
For the tvservice could you just say if nothing detected from the PIR for X minutes and then shut off. Then any detection from the PIR then back on, with another X minute delay? Seems to simple, I must be overlooking something:confused:
Now that I have my SD card backed up (after the last &#(&(&@# failure that caused me to start over) I will hunt around, I know I have seen a few different commands used to turn the display back on. I will see if I can find one that returns a normal screen. From what I have seen a simple tvservice call is not sufficient.
Cheers!
 
I'm using flow meters that are very similar to the Adafruit meters.

I've changed the following line in /includes/pours.php

$amount = $PULSE_COUNT / 21120;

to

$amount = $PULSE_COUNT / 1500;

and it gives me pretty accurate pours.

HOWEVER, pours under 8 or 9 oz don't register. Is there some kind of threshold somewhere that can be tweaked?
 
I haven't used the 1/2" flowmeters for rpints yet but that pulse count looks extremely low.
 
To answer my own question:

I edited the Arduino sketch (raspberrypints.ino), line 68:

if ( pulseCount > 100 ) {
//filter out any tiny bursts

to
if ( pulseCount > 30 ) {
//filter out any tiny bursts

I guess for my meter, it outputs way fewer bursts than the Swiss Flow Meter. This works for me, YMMV, but this is the variable to tweak if smaller pours aren't showing up for you. In flow_monitor.py, I uncommented some print statements to let me know what values were being sent by the sketch, which allowed me to tweak the values to get the appropriate numbers.
 
I'm having trouble adding on flow sensors to my build. I can't seem to upload the arduino sketch to the alamode board. The only thing I can really think of is that I have a raspberry pi 2 model B v1.1 and it has a 40 GPIO pin header and the alamode has 26 pin header meant for the original raspberry pi model b which has 26 pins as well. Would this cause issues with my raspberry pi being able to successfully communicate with the alamode? The exact error I get when I try to upload my sketch is "avrdude: stk500_recv() programmer is not responding". Thanks so much for your help in advance.
 

Latest posts

Back
Top