Is there a way to verify the meters are working before plumbing them in. I have everything installed according to the tutorial but have yet to plumb the lines in my keezer. I got no errors while installing but once the meters are mounted i have to move the setup to my garage where its much less convenient to work on.
[Version 2 Release] RaspberryPints - Digital Taplist Solution
- Thread starter skemp45
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
Is that a code concern? For that matter, are there any known code issues with any of the AVR digital IO pins (aside from 0 & 1)?
I've spend inordinate amounts of time perusing the RPi, AlaMode and Uno schematics over the last many months for various reasons, and there are some potential conflicts with the AlaMode digital IO, beyond the obvious 0 & 1 being the hardware serial link to the RPi.
For instance, IO 3 is connected to the DS3231 RTC chip INTn/SQW pin - an output that can be configured in one of three mode: a square wave of settable frequency, an interrupt when the time matches an event register, or it can be set to do nothing. Two of those settings would conflict with using that pin for pretty much anything. I'd have to dig into the RTC support for the RPi to see if it enables the RTC to do anything with its output.
Then there are the SPI pins: SCK, MOSI and MISO, on digital IO pins 10, 11 and 12, that connect to the RPi SPI pins through a level shifter on the AlaMode (to get from the AVR 5V domain to the RPi 3.3V domain). If the RPi SPI is enabled I'm pretty sure those pins wouldn't be usable for meters.
So the pins that should be reliably available - from a hardware perspective - are 2 and 4 through 10 (8 total). The SPI pins are probably ok unless someone wants to use the RPi SPI for something. IO 3 might be ok - I should park a scope on it for awhile and see if it ever wiggles.
Anyway...None of this - or the choice of IO in my case - have anything to do with the problem I had, or the problem I have. I used the above "safe" subset of pins in a few combinations, but it wasn't until I changed how the database related to the AlaMode did I get signs of life. And the current problem is in the database as well.
I'm betting a start-from-scratch database will fix me right up, but with all the pour tests this afternoon and evening I'm going to put that off to tomorrow
Cheers!
"Got 'scope?"
With the pick-a-nick tap I was seeing an average of ~194 hz @ roughly 50% duty cycle across all seven meters. That's a bit too fast to blink an LED, so I'm not sure what one could do sans a 'scope, short of writing a python script to count pulses on a digital input (warning: if you try that, make sure your pull-up goes to the RPi 3.3V rail and not 5V!)
Cheers!
Sure, the meters can share power and ground. I chose to leave the long cables and 3 pin connectors on my meters intact and build a small board for the interface that plugs directly into the alamode. There's a pic I posted a few pages back.
Edit:
Post #126.
so, its a no-go for me as well. double checked hardware (all good), verified correct pins selected in aruino sketch (all good), got no errors while installing (did a clean install), everything seems ok, but its not registering pours on any tap. even tried taking it down to one tap, redid arduino sketch tried again, and no joy.....
not even sure where to start troubleshooting. any advice?
not even sure where to start troubleshooting. any advice?
In a terminal window, check to see if /var/www/python/flow_moniitor.py is running.
Eg:
$ ps aux | grep flow
If it isn't, get it running in the terminal:
$ python /var/www/python/flow_monitor.py
and leave it running while you launch Chromium to your localhost page.
Pour a few ounces and if the page doesn't refresh within a second of stopping the pour, check the terminal to see if the meter data was posted or not.
If you don't see anything, the AlaMode isn't talking to the RPi.
If you see data, it's likely followed by an error status.
[edit]
And, as I mentioned earlier, if you do find the flow_monitor script is running (because it's started with the desktop environment) it's best to stop it so you can run it manually and be able to see what can be incredibly helpful that you won't see if it's running in a background process.
In the above, if you see it running, located its four digit Process ID <pid>, then
$ sudo kill <pid>
to terminate it kindly.
Then you can run flow_monitor manually as described above.
And you can quit that gracefully with Ctrl-C.
Cheers!
Eg:
$ ps aux | grep flow
If it isn't, get it running in the terminal:
$ python /var/www/python/flow_monitor.py
and leave it running while you launch Chromium to your localhost page.
Pour a few ounces and if the page doesn't refresh within a second of stopping the pour, check the terminal to see if the meter data was posted or not.
If you don't see anything, the AlaMode isn't talking to the RPi.
If you see data, it's likely followed by an error status.
[edit]
And, as I mentioned earlier, if you do find the flow_monitor script is running (because it's started with the desktop environment) it's best to stop it so you can run it manually and be able to see what can be incredibly helpful that you won't see if it's running in a background process.
In the above, if you see it running, located its four digit Process ID <pid>, then
$ sudo kill <pid>
to terminate it kindly.
Then you can run flow_monitor manually as described above.
And you can quit that gracefully with Ctrl-C.
Cheers!
Please forgive me as i am a linux noob.
after entering the command "ps aux | grep flow"
it returns "pi 3179 0.0 0.1 3548 808 pts/0 S+ 00:15 0:00 grep --color=au to pour"
im assuming this means the script is running correct?
after entering the command "ps aux | grep flow"
it returns "pi 3179 0.0 0.1 3548 808 pts/0 S+ 00:15 0:00 grep --color=au to pour"
im assuming this means the script is running correct?
If that's the only line with "pour" in it, then no, the script is not running.
That's actually part of your ps command...
Cheers!
[edit]
What you'd see if flow_monitor.py is running:
pi@rpints ~ $ ps aux | grep flow
pi 4244 1.2 1.0 13484 4840 pts/1 S+ 00:39 0:00 python flow_monitor.py
pi 4256 0.0 0.1 4032 808 pts/0 S+ 00:39 0:00 grep --color=auto flow
The pid for the script is 4244
if i try and run the script by " $ python /var/www/python/flow_monitor.py"
the cursor hangs for quite awhile then i get the error
"there are no window in the stack
invalid window '%1'
usage:windowactivate [options] [window%1]
..sync /only exit once the window is active (is visible + active)
if no window is given, %1 si used. see window stack in xdotool(1)
^[[15;5~
A couple of issues/implementation questions:
Random things:
Any thoughts on allowing users to add ABV, instead of needing to know OG/FG (ie for non homebrewed beer etc). I added "_Non-beer: Soda" manually to the DB, maybe add this to the standard code?
Thank you again for all your hard work on this, it's much appreciated. Can you add a 'Buy us a Beer' link on your website?
- Flow meter pin: needs to be set every time you tap a keg. Should be set to the tap permanently.
- When tapping a new keg and you enter a Starting Value < Keg Size, it shows the keg as full (ie. starting value is 2.5 gal, in a 5 gal corny keg it should show 50% full).
Random things:
Any thoughts on allowing users to add ABV, instead of needing to know OG/FG (ie for non homebrewed beer etc). I added "_Non-beer: Soda" manually to the DB, maybe add this to the standard code?
Thank you again for all your hard work on this, it's much appreciated. Can you add a 'Buy us a Beer' link on your website?
Sometimes the beer gods smile on you... Sort of.
I worked for 2 days trying to get my system to recognize pours. I got nowhere. All taps (6) showing no pours.
This morning I walk out and power up the pi and it shows that all of the kegs have had pours. And a lot of pours. It looks like the database was registering all the pours but not displaying the screen results. I was using a pump and using water/line cleaning solution and the tap I used the most shows nearly 5 gallons poured.
Not only that but now when I make a pour, the display updates about 30 seconds later now.
If your pours are not being recognized then you should check the database to see if they are registering there. Maybe this info will give the guys who devoted so much time developing this some help in resolving the problem.
I don't have a clue what happened but I think I'm happy.
Sent from my iPad using Home Brew
I worked for 2 days trying to get my system to recognize pours. I got nowhere. All taps (6) showing no pours.
This morning I walk out and power up the pi and it shows that all of the kegs have had pours. And a lot of pours. It looks like the database was registering all the pours but not displaying the screen results. I was using a pump and using water/line cleaning solution and the tap I used the most shows nearly 5 gallons poured.
Not only that but now when I make a pour, the display updates about 30 seconds later now.
If your pours are not being recognized then you should check the database to see if they are registering there. Maybe this info will give the guys who devoted so much time developing this some help in resolving the problem.
I don't have a clue what happened but I think I'm happy.
Sent from my iPad using Home Brew
mcangeli
Well-Known Member
- Joined
- Dec 26, 2012
- Messages
- 371
- Reaction score
- 58
You're getting this error message because you DO NOT HAVE a Chromium window opened on a monitor directly connected to the rpi.
IF this is the case and YOU DO NOT HAVE A MONITOR HOOKED DIRECTLY TO THE rPi, then you need to edit the includes/pours.php file and comment out the line that reads:
Code:
// REFRESHES CHROMIUM BROWSER ON LOCAL HOST ONLY
// COMMENT OUT TO DISABLE
exec(__DIR__."/refresh.sh");You ONLY need to comment out the exec(__DIR line (its line 60).
mcangeli
Well-Known Member
- Joined
- Dec 26, 2012
- Messages
- 371
- Reaction score
- 58
A couple of issues/implementation questions:
- Flow meter pin: needs to be set every time you tap a keg. Should be set to the tap permanently.
- When tapping a new keg and you enter a Starting Value < Keg Size, it shows the keg as full (ie. starting value is 2.5 gal, in a 5 gal corny keg it should show 50% full).
Random things:
Any thoughts on allowing users to add ABV, instead of needing to know OG/FG (ie for non homebrewed beer etc). I added "_Non-beer: Soda" manually to the DB, maybe add this to the standard code?
Thank you again for all your hard work on this, it's much appreciated. Can you add a 'Buy us a Beer' link on your website?
The flow meter to tap is not currently set permanently for several reasons. The biggest being that the pin number could change at any given time for any number of reasons. Maybe there's something on tap you do not want to track pours on (if you have a keg of cleaning solution you want to run thru the tap, then add it to the tap, set the pin to zero and go for it) or if you need to move pins (it happens). We Are working on adding a couple of other configuration options for the setting of pins that should make it a little easier. However these won't be released any time in the next two weeks...
I'll take a look at the issue of the non-full keg value and showing as full when taping a keg (I hadn't played around with that yet, but you're right, if you enter 2.5gal in a 5gal keg, it should show as 1/2 full and not full to begin with. I imagine this is an easy fix).
The next full version may have the stuff needed to make it easier to add store bought beer as well as some other goodies in it.
Unfortunately, no, we cannot add a buy a beer button if we want to maintain our *amateur* status here and not become a vendor.... instead, sit back, enjoy a brew and have fun!
mcangeli
Well-Known Member
- Joined
- Dec 26, 2012
- Messages
- 371
- Reaction score
- 58
Yea, I (and some others) have experienced that issue before as well. I think it has to do with the serial queue not being cleared when pours start coming in after uploading the sketch but I cannot be certain.
A good way to test for pours is to open the serial monitor in Arduino (its under tools) after you upload the sketch to the board. You can see what the arduino is passing along via the serial port with out it passing anything to the python/database
Also, for those like Day_trippr I will be working on adding in the centipede code needed in order to have more than a few taps (it looks like anything over about 8 taps will NEED the centipede board for additional pins).
mcangeli
Well-Known Member
- Joined
- Dec 26, 2012
- Messages
- 371
- Reaction score
- 58
Is that a code concern? For that matter, are there any known code issues with any of the AVR digital IO pins (aside from 0 & 1)?
I've spend inordinate amounts of time perusing the RPi, AlaMode and Uno schematics over the last many months for various reasons, and there are some potential conflicts with the AlaMode digital IO, beyond the obvious 0 & 1 being the hardware serial link to the RPi.
For instance, IO 3 is connected to the DS3231 RTC chip INTn/SQW pin - an output that can be configured in one of three mode: a square wave of settable frequency, an interrupt when the time matches an event register, or it can be set to do nothing. Two of those settings would conflict with using that pin for pretty much anything. I'd have to dig into the RTC support for the RPi to see if it enables the RTC to do anything with its output.
Then there are the SPI pins: SCK, MOSI and MISO, on digital IO pins 10, 11 and 12, that connect to the RPi SPI pins through a level shifter on the AlaMode (to get from the AVR 5V domain to the RPi 3.3V domain). If the RPi SPI is enabled I'm pretty sure those pins wouldn't be usable for meters.
So the pins that should be reliably available - from a hardware perspective - are 2 and 4 through 10 (8 total). The SPI pins are probably ok unless someone wants to use the RPi SPI for something. IO 3 might be ok - I should park a scope on it for awhile and see if it ever wiggles.
Anyway...None of this - or the choice of IO in my case - have anything to do with the problem I had, or the problem I have. I used the above "safe" subset of pins in a few combinations, but it wasn't until I changed how the database related to the AlaMode did I get signs of life. And the current problem is in the database as well.
I'm betting a start-from-scratch database will fix me right up, but with all the pour tests this afternoon and evening I'm going to put that off to tomorrow
Cheers!
We're not using SPI (in the base code) so it *shouldn't* be a problem, but you know as well as I do that sometime logic flies out the window...
I moved mine to pins 4 - 7 and haven't had an issue so far, but then I only have 4 meters and an RFID reader hooked up.
My plan is to begin looking at the centipede code needed to add the centipede board (as was the original plan) which should give somewhere around 64 input pins if done correctly and be a little more stable (as I believe it breaks out all of the other pins).
It would only be needed if you were using more than 6 meters or devices connected to the alamode.
To be clear, any conflicts on pin use would be due to how the user sets
up the RPi side, not what you have done on the AVR side. Eg: if someone wants to hook up something to the RPi SPI, he cannot use those same pins for meters.
That's not a problem of 'Pints making, that's a user issue...
Cheers÷
up the RPi side, not what you have done on the AVR side. Eg: if someone wants to hook up something to the RPi SPI, he cannot use those same pins for meters.
That's not a problem of 'Pints making, that's a user issue...
Cheers÷
Success!! (on kitchen table anyway). As it turns out my problem was as simple as a typo when i typed in the path to autostart the flow script. You guys rock!
If only there was some way i could make a donation to the project....
If only there was some way i could make a donation to the project....
mcangeli
Well-Known Member
- Joined
- Dec 26, 2012
- Messages
- 371
- Reaction score
- 58
The best way is to not remove the Raspberry Pints logo if you edit the index page at all.
I have read this from the beginning, and all of the other thread. It's just so much info to remember! lol
On the alamode site, there is some info as well that helped me close a couple gaps.
Thanks for all the hard work on v2!
If you're not selling it or forcing people to pay, I can't see why donations can't be accepted (it's not RasPints, it HBT forum rules). Besides the considerable time, I imagine there have been some costs associated with the project around development hardware and such.
Regardless thank you again for the time, energy, and beer that have gone into making this project fantastic.
Cheers! 
JaimeTheLimey
Well-Known Member
Hey guys, doing a fresh install to v2 and keep getting this error message when runing apt-get upgrade:
"(gtk-update-icon-cache:9208): GdkPixbuf-WARNING**: Cannot open pixbuf loader module file '/usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/2.10.0/loaders.cache':
No such file or directory"
Can anyone tell me what this means in layman's terms? Thanks.
"(gtk-update-icon-cache:9208): GdkPixbuf-WARNING**: Cannot open pixbuf loader module file '/usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/2.10.0/loaders.cache':
No such file or directory"
Can anyone tell me what this means in layman's terms? Thanks.
Try doing an apt-get update before apt-get upgrade. Always a good practice anyway...
Cheers!
Cheers!
billybryson54
Well-Known Member
I just completed mine about 30 minutes ago. All 4 meters on my setup are successfully logging pours. The only thing I really did was did a brand new fresh install straight to V2. My meters are being ran on pins 8,9,10, and 11. Followed all the instructions exactly and it wouldn't log at first. What eventually made it log for me was changing the pin number on the keg in 'Pints itself, right above where it asks for "Starting volume". In other words, when I tap a new keg in my first tap, set its PIN number to "8" Tap two gets set to "9" and so forth. As soon as I did that, everything ran perfectly. Hopefully this can help someone out...
billybryson54
Well-Known Member
Looks like I spoke too soon. After a reboot, none are logging anymore. I didn't change a thing either *Sigh* back to the drawing board...
This works for me.
Kill chromium by using alt+F4
Open lxde terminal and type
Cd /var/www/python
Python flow_monitor.py
Leave the terminal open and open chromium
Enter the IP address of you RPI followed by /index.php. So for me it's 192.168.1.88/index.php. Chromium will not be in the kiosk mode but the pours register on my system this way.
I don't know why this works. I am a raspberry pi novice.
Sent from my iPad using Home Brew
This works for me.
Kill chromium by using alt+F4
Open lxde terminal and typeNo
Cd /var/www/python
Python flow_monitor.py
Leave the Sam adams. Put bottles in a tub with water and some soap. 24 hours later the labels are all off. Some floating on top, others at the bottom of the tub. No muss, no fuss. open and open chromium
Enter the IP address of you RPI followed by /index.php. So for me it's 192.168.1.88/index.php. Chromium will not be in the kiosk mode but the pours register on my system this way.
I don't know why this works. I am a raspberry pi novice.
Sent from my iPad using Home Brew
I have found that this works for me.
Close chromium using alt+F4
Open lxde and enter the following 2 lines
Cd /var/www/python
python flow_monitor.py
Leave the terminal open and open chromium
Enter your RPI IP address followed by /index.php (for my system this is 192.168.1.88/index.php)
Chromium will not be in the kiosk mode but my pours register this way. After a pour I can see the activity go to maximum on the bottom right of the screen and a few seconds later my volumes update.
Hope this works for you too.
Sent from my iPad using Home Brew
Have a question about screen rez for you linux gurus out there. I have a 1600x1200 display that i'm using horizontally with 5 taps. Before i upgraded to 2.0 it used up the entire screen perfectly, now i have about 2 taps worth of dead space at the bottom. What did i miss during my install here?
I have both hdmi lines in boot/config.txt #'d out, and the overscan options dont seem to make a difference. If i change the hdmi lines to active and make them
group=1
mode=2
my display becomes so zoomed in that it wont even display one tap without severely damaging it.
any suggestions on settings i can use to take advantage of my full display, without deadspace like it was?
On another note, i transferred my setup to the keezer and was about to be super bummed when it didnt act like it wanted to register pours, i had the pin set incorrectly on the pints page so i changed the pin # and still no love.
i decided to try a reboot, and then all was good and registering like it should.
Is this a known thing? if i change pins on the pints admin page do i need to reboot before it will take effect?
I have both hdmi lines in boot/config.txt #'d out, and the overscan options dont seem to make a difference. If i change the hdmi lines to active and make them
group=1
mode=2
my display becomes so zoomed in that it wont even display one tap without severely damaging it.
any suggestions on settings i can use to take advantage of my full display, without deadspace like it was?
On another note, i transferred my setup to the keezer and was about to be super bummed when it didnt act like it wanted to register pours, i had the pin set incorrectly on the pints page so i changed the pin # and still no love.
i decided to try a reboot, and then all was good and registering like it should.
Is this a known thing? if i change pins on the pints admin page do i need to reboot before it will take effect?
Try going through the procedure here. Disable the autostart of monitor_flow.py (if you stuck a startup in your LXDE autostart, remove it or comment it out). Then either reboot, or find any running instances of monitor_flow.py and kill them. Either way, make sure it isn't running.
Then run it in a terminal window, then launch the 'Pints page and pull a few ounces. Assuming the gui doesn't update, check the terminal for status.
If you see tap data pushed by the AlaMode but there's a message to the effect "cannot open pours.php", you're exactly where I am right now...
Cheers!
So...after a long day of stripping Chinook cones I settled down to get this *&#%@%! thing running. I used phpMyadmin to blow away my existing database, blew away everything to do with RaspberryPints, then installed the kit anew. Populated the beers and kegs (takes for-fricking-ever with a dozen recipes and 14 kegs), set the AVR up for 6 taps on pins 4-9 (matching the settings in 'Pints), ran monitor_flow.py in a terminal as 'pi', launched the 'Pints page in Chromium, then pulled a few ounces.
Aaaaand the gui didn't update, and the terminal showed monitor_flow.py could not open pours.php. Tried it again but running monitor_flow.py as root, no difference.
So after all that I'm right back where I was when I tried doing the upgrade from 1.0.3. And I think we're going to need some help from the dev team on this bug...
Cheers!
Aaaaand the gui didn't update, and the terminal showed monitor_flow.py could not open pours.php. Tried it again but running monitor_flow.py as root, no difference.
So after all that I'm right back where I was when I tried doing the upgrade from 1.0.3. And I think we're going to need some help from the dev team on this bug...
Cheers!
Ok, so it looks like my latest (final?) problem may have been all about "ownership".
I won't know until I sober up enough to reboot the 'Pi and pour more beer, but after I changed the ownership of every file and folder in the 'Pints tree to my default user ('pi', of course) all six of my taps are now registering pours.
Because I have a lot more going on in /var/www than just 'Pints I may have had some files owned by www-data and the rest owned by pi, and I'm guessing that the python script had a different owner than the database files. Which could 'splain why the script couldn't open the database.
Given others' experience I guess I won't know for sure until I reboot and pour another beer, but right now I'm semi-baked. I have two glasses of who-knows-what in front of me and I'll be damned if I pitch them, so until I knock these down the ultimate test case is on hold.
Honest to gawd, debugging this thing is wreaking havoc on my beer stocks and my liver! I'm a few pours away from kicking a keg, but in the meantime all 14 of them have beer in them so I can't do this *$&^#%@! testing with a keg filled with water...
Cheers!
[edit] Killed those two pints...hanging on for dear life...rebooted the 'Pi...poured a few more ounces of my double RIS...'Pints still works!
I'm totally toasted...G'Nite!
I won't know until I sober up enough to reboot the 'Pi and pour more beer, but after I changed the ownership of every file and folder in the 'Pints tree to my default user ('pi', of course) all six of my taps are now registering pours.
Because I have a lot more going on in /var/www than just 'Pints I may have had some files owned by www-data and the rest owned by pi, and I'm guessing that the python script had a different owner than the database files. Which could 'splain why the script couldn't open the database.
Given others' experience I guess I won't know for sure until I reboot and pour another beer, but right now I'm semi-baked. I have two glasses of who-knows-what in front of me and I'll be damned if I pitch them, so until I knock these down the ultimate test case is on hold.
Honest to gawd, debugging this thing is wreaking havoc on my beer stocks and my liver! I'm a few pours away from kicking a keg, but in the meantime all 14 of them have beer in them so I can't do this *$&^#%@! testing with a keg filled with water...
Cheers!
[edit] Killed those two pints...hanging on for dear life...rebooted the 'Pi...poured a few more ounces of my double RIS...'Pints still works!
I'm totally toasted...G'Nite!
billybryson54
Well-Known Member
This does indeed work for me. If I reboot, open terminal, follow the steps for testing pours, then leave terminal open and open my taplist, it will indeed log pours correctly. I'm sure there is a better way of doing this, kinda stinks that for the moment I have to open terminal first. I don't know Linux well enough to try and debug this myself though but for the time being, I can live with it. My bigger issue right now is that I jumped the gun and installed my flowmeters in the coffin of my keezer BEFORE the instructions on the 'Pints website were updated, and told us "Don't put them at the end of the line" so now I have a massive foaming problem with ALL my lines, probably due to the extra turbulence in the lines from the meters. So for those of you that haven't done this install yet, DON'T put your meters at the end of the line! I'm gonna have to open the box back up and add a few feet of beer line to the front of the meters, for my situation it's the simplest solution.
Have you tried using the "Zoom" feature in the chromium window itself? I had the same problem before and this worked for me.
The last line of the lxde setup file just after launching chromium in kiosk mode I was unable to get it to run properly with the & after the line, once I removed it it worked fine. My symptoms were similar (it would register pours with it running in a terminal window.
Also if you press the F-11 key your chromium will go back into full screen mode. For some reason I have to hit Alt-F11 to get it to come out of full screen.
ratsathome
Well-Known Member
Got stuck on this.
Might have come up before but can not find anything on it.
Had no problem on the previous version with this.
Any ideas
I,m doing it from my pc(tried doing it from the pi with same results)
Might have come up before but can not find anything on it.
Had no problem on the previous version with this.
Any ideas
I,m doing it from my pc(tried doing it from the pi with same results)
OP
OP
skemp45
Well-Known Member
To address a few comments,
1.) As far as donations go, we talked about this as a team and in order for us to accept donations and stay on HBT we would need to get a vendors license. We decided the cost of the vendors license would be more than the donations in the long run and you guys and gals are way to valuable to us. The best donation you can do is use RaspberryPints and tell your friends, post online about it, GET IT SETUP. Without all of you RaspberryPints would have never came together and when it comes to finding bugs.... You are all TOO GOOD AT IT!!
2.) Adding beer abv, setting half full kegs, assigning pin numbers, etc. etc. Will all be looked at in the future releases, Please keep the suggestions coming, we love it!
3.) Day_Trippr, and mcangeli have been doing GREAT here in the forum answering question and giving suggestions. That is exhausting work but it needs to be done, we are not just going to leave you all high and dry. With that being said, I know the thread gets long and its a lot of reading but PLEASE go through and read before you post a question, odds are they may have answered it already. I know this is a bit inconvenient and I will work on a better way of support but for now lets all work together to lower the work load!
4.) Did I say how rewarding it is to see some of you getting this all setup and running As the late great kool-aid man once said, OHHHHHHHHHHHHHH YEAHHHHHHHHHHHHHHHHHH
1.) As far as donations go, we talked about this as a team and in order for us to accept donations and stay on HBT we would need to get a vendors license. We decided the cost of the vendors license would be more than the donations in the long run and you guys and gals are way to valuable to us. The best donation you can do is use RaspberryPints and tell your friends, post online about it, GET IT SETUP. Without all of you RaspberryPints would have never came together and when it comes to finding bugs.... You are all TOO GOOD AT IT!!
2.) Adding beer abv, setting half full kegs, assigning pin numbers, etc. etc. Will all be looked at in the future releases, Please keep the suggestions coming, we love it!
3.) Day_Trippr, and mcangeli have been doing GREAT here in the forum answering question and giving suggestions. That is exhausting work but it needs to be done, we are not just going to leave you all high and dry. With that being said, I know the thread gets long and its a lot of reading but PLEASE go through and read before you post a question, odds are they may have answered it already. I know this is a bit inconvenient and I will work on a better way of support but for now lets all work together to lower the work load!
4.) Did I say how rewarding it is to see some of you getting this all setup and running
As the late great kool-aid man once said, OHHHHHHHHHHHHHH YEAHHHHHHHHHHHHHHHHHH
I'm hosed with the flow sensors. No way to run them from the fridge to the taps and screen without drilling a huge hole through an external wall. Any way to setup flow meters for a wireless connection to the RPi?
I'm not used to having them, so I suppose I won't miss not having them. It would be nice to know how much beer remains in the kegs though. Not sure its wort drilling a hold though. I'd need a few holes as it turns out...
Anyways, thanks for all the hard work on this! Got mine all setup and working. Working on adding a motion sensor soon.
TD
Sent from my iPad using Home Brew
I'm not used to having them, so I suppose I won't miss not having them. It would be nice to know how much beer remains in the kegs though. Not sure its wort drilling a hold though. I'd need a few holes as it turns out...
Anyways, thanks for all the hard work on this! Got mine all setup and working. Working on adding a motion sensor soon.
TD
Sent from my iPad using Home Brew
That stinks. So, you do not have the beer line going through the wall and cant get the sensor wires to go through an existing one?
You'd lose the automagic screen refresh, but you could locate the RPi and AlaMode at your fridge and display the web gui remotely on whatever you have available - laptop, peecee, tablet, etc - or build another RPi sans AlaMode and use that as your display engine (you could literally stick it to the back of your tap list display in that case). If you stuck a mini wireless keyboard near your taps you can hit the F5 key to refresh the gui after a pour...
Cheers!
Or add in the autorefresh command like was done in V1 so that updates to the list would show.
Similar threads
