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

    Homebrewing Facebook Group

HOWTO - Make a BrewPi Fermentation Controller For Cheap

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Status
Not open for further replies.
No username change here Lee.

Thank you both - Lee and day, noting that I was probably on wheezy (which I was) got me halfway there. That little tidbit and this link https://www.datenreise.de/en/raspberry-pi-setting-up-wifi-edimax/ got me there.

Appreciate the quick responses btw. Super helpful. Obviously my set up is on an old build, do you recommend I upgrade? I’m going to dig through all of the pages in these threads and see what I can glean myself but wanted the short answer. I mean my OG setup works great, its running right now thanks to you both. So cheers!
 
The new releases are "supported" in that someone here is actively enhancing/supporting the code. This was originally needed because the OG will no longer install on current releases of Debian/Raspbian. The version of Raspbian you are on is very old, arguably not secure, etc.. For some this is reason enough to upgrade. For me, it is for instance, but I'm paranoid. :p

So, nothing says you can't continue till it dies. Make sure you have a good backup! If you have it exposed to the Internet I guarantee it's hackable though.

Um, let's see ... Tilt is supported in the new versions, as is an LCD which does not require a shield (I2C). Lots of other fixes but if you are "happy" now, those are the biggies.
 
No username change here Lee.

Thank you both - Lee and day, noting that I was probably on wheezy (which I was) got me halfway there. That little tidbit and this link https://www.datenreise.de/en/raspberry-pi-setting-up-wifi-edimax/ got me there.

Appreciate the quick responses btw. Super helpful. Obviously my set up is on an old build, do you recommend I upgrade? I’m going to dig through all of the pages in these threads and see what I can glean myself but wanted the short answer. I mean my OG setup works great, its running right now thanks to you both. So cheers!
https://www.brewpiremix.com/brewpi/
 
All good stuff - thx! I’ll ride this build out until it gets squirrelly on me and then just do a rebuild to the latest version and upgrade the works. ‘Predicate the info gents.
 
What I would do:
- create two backup SD cards of the running system. On Jessie, Stretch and probably Buster, there's a built-in SD Card Copier utility that comes with the desktop manager that works great. On Wheezy I use rpi-clone. It's a command line program and works great as well...
- Test each of the backup cards (as in boot off them) then tuck them away for safe keeping.

Now you can try pretty much anything you want while maintaining your lifeline.

fwiw, I'm still running the system (and its backup clone) that controls my keezer and three ferm chambers and my tap list manager on Wheezy because it works, and frankly I regard these systems as glorified toaster ovens. No reason to upgrade as there's no value added there...

Cheers!
 
Fair question and thanks for asking! I know trying to get information around here is like taking a sip of water from a firehose. So many of us have been through the conversation over years we forget how to provide an entry point for a newer person.

Probably the best overview is on the README on the GitHub for BrewPi-Tools-RMX.

But, yes, easier to install. As a matter of fact one could not simply install BrewPi Legacy anymore on current Raspbian versions. That's how this started. Then I started fixing other things, adding features, it never ends. :)

The support for hardware is backwards-compatible for the same functionality. The firmware has been updated in a few places, and for instance one may now use an LCD without having to create or use a shield (although it makes things a lot easier for all other things.)

Hi LBussy,

I'm also a new starter in brewing and for me all this information is a bit to much to read at this moment. I was currently working on trying to make my own temperature controlling system until I found out about BrewPi and BrewPi Remix. As you are far far ahead in this process it looks stupid to continue with mine. But after reading the first information there is a question that comes up and I could not find an answer in all your documentation: 'Why using an Arduino for reading the temperatures and controlling the 2-Channel Relay Module?'
You can easily control the DS18B20 sensors or a 2-Channel Relay Module directly from the RaspberryPi GPIO.
Or am I missing something?

Regards,

Wim DM.
 
Hi LBussy,

"Why using an Arduino for reading the temperatures and controlling the 2-Channel Relay Module?"
You can easily control the DS18B20 sensors or a 2-Channel Relay Module directly from the RaspberryPi GPIO.
Or am I missing something?

Regards,

Wim DM.

I know this thread is daunting, but it has been covered. As well as on the official BrewPi forum. The arduino is much more stable than the Raspberry Pi and will continue to control the chamber, even if the Pi crashes or freezes up. If you are interested in eliminating the arduino, you would want to use the Brewpiless branch that @pocketmon created.

Edit: Actually, I think BrewPiLess was created to run completely on an ESP8266, without the Pi or the Arduino. But i believe there is a Pi only version somewhere.
 
Last edited:
I know this thread is daunting, but it has been covered. As well as on the official BrewPi forum. The arduino is much more stable than the Raspberry Pi and will continue to control the chamber, even if the Pi crashes or freezes up. If you are interested in eliminating the arduino, you would want to use the Brewpiless branch that @pocketmon created.

Edit: Actually, I think BrewPiLess was created to run completely on an ESP8266, without the Pi or the Arduino. But i believe there is a Pi only version somewhere.

Donnie,

thanks for the quick reply. I can confirm that the RaspberryPi is not stable although I do not have any experience with the arduino.
But it makes sense now for me!

Regards,

Wim DM
 
Last edited:
Do I need it to start the installation or can I buy and add it later? I already have an 20x4 I2C LCD currently connected directly to my RPI.
You can always add the shield and an LCD later. For the 20x4 I2C you do not necessarily even need the shield. It does make hooking some things up a lot easier, I find it easier to use DuPont jumpers than bailing wire and bubblegum (I'm looking at you 4k7 resistor!) but definitely not needed.
 
You can always add the shield and an LCD later. For the 20x4 I2C you do not necessarily even need the shield. It does make hooking some things up a lot easier, I find it easier to use DuPont jumpers than bailing wire and bubblegum (I'm looking at you 4k7 resistor!) but definitely not needed.

Thanks for the info! I will be using other parts like Solid State Relays and an PCB experimental board so I will be using DuPont jumper wires to connect everything together. Maybe in a later stage I will try the new shield.

As already mentioned I'm pretty new here and I still need to read a lot of information but if you can tell me were I can find some more information on how to connect the I2C LCD without the shield I would appreciate it a lot.

Wim.
 
Thanks for the info! I will be using other parts like Solid State Relays and an PCB experimental board so I will be using DuPont jumper wires to connect everything together. Maybe in a later stage I will try the new shield.
Just out of curiosity, why SSDs? The ones I have seen seem to cause more problems than they solve. They typically don't have the power capacity the relays have.

As already mentioned I'm pretty new here and I still need to read a lot of information but if you can tell me were I can find some more information on how to connect the I2C LCD without the shield I would appreciate it a lot.
Well ....the right answer should be docs.brewpiremix.com however I've not yet updated them for I2C. I also have a fairly extensive hardware prep writeup here (also not updated for I2C, but still a good starting point). My assumption was the majority of folks would use a shield if using an LCD and there the setup using a shield is pretty obvious. However, one of the benefits of the I2C is NOT needing a shield, so your question is a reasonable one.

@100amps is working on an updated I2C diagram when he has time, but in the meantime, I think I can describe it fairly well:
  • Most importantly, use the I2C firmware, not RevC
  • Data in for the OneWire goes to A0 instead of A4
  • The I2C LCD connects to:
    • GND <-> GND
    • VCC <-> 5V
    • SDA <-> A4
    • SCL <-> A5
I think that's it ...
 
Just out of curiosity, why SSDs? The ones I have seen seem to cause more problems than they solve. They typically don't have the power capacity the relays have.
A colleague advised me to use SSR instead of relays because mainly for power consumption but they are triggered at low voltage instead of the relays so I probably need to find a solution for that. And because I've already bought them so I prefer to use them instead of relays.

Well ....the right answer should be docs.brewpiremix.com however I've not yet updated them for I2C. I also have a fairly extensive hardware prep writeup here (also not updated for I2C, but still a good starting point). My assumption was the majority of folks would use a shield if using an LCD and there the setup using a shield is pretty obvious. However, one of the benefits of the I2C is NOT needing a shield, so your question is a reasonable one.

@100amps is working on an updated I2C diagram when he has time, but in the meantime, I think I can describe it fairly well:
  • Most importantly, use the I2C firmware, not RevC
  • Data in for the OneWire goes to A0 instead of A4
  • The I2C LCD connects to:
    • GND <-> GND
    • VCC <-> 5V
    • SDA <-> A4
    • SCL <-> A5
I think that's it ...

Many thanks for this info I will try it out and keep you posted.
 
Last edited:
Hello been following this thread for a long time now with very keen interest. Had a NUC lying around so installed Debian 9 and tested the BrewPiRemix install script which worked faultlessly (thank you LBussy) and have now ordered all the other bits to go with it.

My question is can we use an extra temp probe for a second FV in the same chamber and have the averages smoothed between the 3 probes? So normal chamber probe (one of) and one probe in each of two FV with the same brew or at least expecting the same temp schedule.

And another question is where can you get good starting data for a particular brew? I can find a lot of instructions for xyz lager or abc ale with mash steps and boil times, hop additions, etc. but they all seem to lack proper temp schedules for fermenting.

Thanks to everyone for all the effort you have put into this so far, you really must love mucking around with this type of stuff. :)
Cheers,
 
- There is no support for more than one chamber, one beer, and one room temperature probe.
- I'm guessing you're looking for Beer Profiles. There've been a few attempts to gather BrewPi profiles over the years here but frankly there never was much traction. Tbh I suspect most folks don't use profiles and instead just manually change temps as fermentation progresses...

Cheers!
 
Hi Dotball. Glad the install went well for you. That's the intent of course, but its a big world with lots of variables.

day_trippr is exactly right, of course. I'd like to elaborate while I wait for my coffee to brew:
And another question is where can you get good starting data for a particular brew? I can find a lot of instructions for xyz lager or abc ale with mash steps and boil times, hop additions, etc. but they all seem to lack proper temp schedules for fermenting.
I think 95% of this is technique and research rather than software. The first place to go for the proper fermentation temps is the yeast supplier. If you look at White Labs' page for WLP001 California Ale Yeast, you'll see that proper temps for this particular yeast are 68°F - 73°F. If you skip over to Wyeast's most popular yeast in the same category, you'll see that the 1056 American Ale yeast prefers temps in the 60°F - 70°F range. So, where you might choose 70°F for a middle-range setting for the WLP001, it would be at the top end of what's okay for the 1056. Even though I've been brewing since '91 (I prefer not to do the math on how many years that is anymore) and a judge since '95, me choosing the temp you should be fermenting your beers is a responsibility I do not want. So, the quick answer is to ask the yeast guys. All of the suppliers I have used will have this data on their website. That's where you should be looking.

You mention temp profiles too and this is a subject to which I've been directing a few brain cells as of late. It's easy as humans to say "Hold it at 70°F till fermentation is finished, then ramp it up to 75°F for 3 days, then cold crash at 55°F. My question about such an algorithm is: "When is it finished fermenting?" Time is a bad judge as we all learn sooner or later. One batch will go gangbusters and be 90% attenuated in two days. The next will take four days to do the same work. So, time is out.

What about the specific gravity? Taking my "house ale" as an example, it's an American Amber which starts at 1.042 (yes that's low, it's intended to be a session beer.) I use Wyeast 1056 for this which has an attenuation rate of 73-77% - in the lab. That means if I do my part right, the FG will be 1.113-1.097. As a human, it's easy for me to watch the gravity curve (especially with a Tilt which I think everyone should have!) and see if it's "done." When I do so I'm not really looking at the number so much as the flattening of the curve indicating my yeasties are finished. Computers do not really look at shapes, they look at numbers. There's a 0.006 point gravity range in there where my beer might be done (again, that's assuming I have perfect conditions.)

To get my five gallons of American Amber to the style-appropriate 2.3 volumes of CO2, if I were bottling I would use ~107g of corn sugar. That equates to roughly 0.002 in specific gravity. I think you can begin to see the issue here. If I tell a computer that my beer is done fermenting at 1.010 but it could really have gone to 1.097, I might cold crash a beer that's not fermented out with 0.003 points of SG to go. Then if I add in my 107 grams of corn sugar I've now got a surplus of 0.005 which equals about 5.1 volumes of CO2 when it's bottled. That's not quite a bottle-bomb, but it's a fizzy gusher and not what you are looking for.

There are other projects which have begun to add in gravity-based temperature profiles, but I think you can see the issue here now that I have put some numbers to "paper." Teaching a human to judge "done" and a computer to do the same is a pretty different prospect. The results are important and despite a computer being "precise", it could lead to a widely varying result.

One way is to do some math and figure out that the gravity drop has levelled out and at some arbitrary level of change over time, determine it "done." As you begin to peel back the layers of the onion, however, you see that the original problem hides several others. For instance, the gravity will bounce up and down even sitting in water. Remember that 0.002 is the level at which I would carbonate, so a variance of 0.001 even would make a difference. So now I have to add some form of smoothing (something that humans do well, but computers have all sorts of ways and choices for formulae, all offering different results.)

Then, of course, remember that there are points where we might want to make changes for which gravity is the only determining factor. So now I would have two different choices - a schedule that takes pure attenuation into account, plus the "shape of the curve." If I coded that, how much time would I spend explaining it?

The point being, there's a sort of diminishing return here. How many hours to do this, versus the hours I need to allocate to do the Python 2.7 to 3.x uplift which is becoming more mandatory every day? There are few people who really use the temp profile the way it was originally intended I think. I personally use it when I am ready to ramp a large change. For instance, when I think it's done, I might crash 10°F over 24 hours. Until that point, I use Beer Constant.

Long story short: Select a Beer Constant temp that your yeast supplier recommends, and then you be the judge of when the beer is done in order to cold crash or whatever else you will do. Someone else's curve might not be the right one for your recipe, your equipment, your process and your yeast. Using temp control to keep what the yeast supplier recommends will be a large improvement in your process and your beer. The last 0.1% you might get from automating that last part is likely not something to which I'll be devoting a lot of time. Who knows though? I love a challenge.
My question is can we use an extra temp probe for a second FV in the same chamber and have the averages smoothed between the 3 probes? So normal chamber probe (one of) and one probe in each of two FV with the same brew or at least expecting the same temp schedule.
So now I have my coffee in hand and I thought about this while pouring a cup. There are two issues here I believe:
  1. Let's say you have one fermenter that's really taken off and the second has not yet. The first will be generating its own heat, that can be 3-5 degrees maybe if it really gets going. The second one will be very close to the chamber temp until it starts going well. If you lower the chamber temp based on an average, you will also be chilling down the one that's not fermenting as well yet, further slowing it down. The strength of a temp controller like this is the ability to keep a fermenting liquid +-0.1°F or so. If you average between two fermenters you're removing that advantage and honestly making it worse. My recommendation for that scenario would be:
    • Get a larger fermenter and do it in one vessel; or
    • Use a second fermentation chamber and control both correctly; or
    • Use chamber constant and at least know that the chamber is being well controlled. That's an "average" of sorts, and will at least not penalize the second fermenter based on the activity of the first. A fan in the chamber will really help here.
  2. Program Space - the Arduino Uno is severely limited and the last change I made necessitated me going through alk the code and finding a way to remove 27 characters of string storage (27 letters that were in messages) so I could get it to run without crashing. Adding new functionality in the controler itself is unlikely without switching to a new platform.
Yikes, that's a lot of typing. It was an interesting set of questions though which present some challenges that are likely not well/optimally solved by computers. I enjoyed "talking" it out.
 
After receiving my 3th arduino uno (first was a clone, second never arrived and the third found in a local store),
I finally got my own working BrewPi Remix with I2c LCD and 2x SSR.
Can't wait to tried it with my next brew.

Just a small question about the LCD, the brightness drops after 40sec.
I can get is back on by restarting the script but is there another way? Or can I change the time?
 
After receiving my 3th arduino uno (first was a clone, second never arrived and the third found in a local store),
I finally got my own working BrewPi Remix with I2c LCD and 2x SSR.
Congratulations!
Just a small question about the LCD, the brightness drops after 40sec.
I can get is back on by restarting the script but is there another way? Or can I change the time?
With I2C firmware, if you are not using a rotary encoder (pressing the knob turns the backlight back on normally) you can short pin D7 to GND and it will disable the backlight timer (after a reset). If you are using the shield, you can jumper PSH and GND on the encoder pins.

With RevC firmware, there's a backlight jumper on the board above the trimmer to do the same thing. You jump it to PB for the encoder, or ON for no timeout.
 
Status
Not open for further replies.
Back
Top