Note: I'd rate the difficulty of this build as medium, you need to be somewhat proficient with a soldering iron and comfortable with Arduino C++ code and whichever language you use to talk to the Arduino. Prior experience loading sketchs onto the Arduino is a must.
Everyone knows that in homebrew one big quality factor is fermentation temperature control.
A couple of years ago I invested in a chest freezer to use as a fermentation chamber and the quality of my ale improved markedly.
I typically only brew in summer and the ambient temperature inside my house swings quite a bit over the course of the day making it hard to maintain a consistent fermentation temperature.
When I bought the freezer I built a simple STC1000 based controller to maintain fermentation temps, usually around a constant 65 degrees F. and that system has worked great for Ale fermentation.
At the time I set up the chamber I had thought that someday I would build a controller that I could program to run Lagering temperature profiles, and recently did so.
Lagering profiles
Lager requires changes in temperature during fermentation. While it would not be hard to manually set those temperature changes the idea of having a system that automatically made those changes unattended appealed to me.
There are several controllers available commercially that accomplish this and most are far more sophisticated than the one I've built, but I enjoy building things so I came up with my own version.
Datalogger shield
My first idea was to make the controller self contained on an Arduino, this requires using a "datalogger" shield which adds a RTC ( real time clock ) and a SD card reader/writer to the Arduino. The RTC is needed to be able to control the amount of time the chamber is to remain at a specific temperature and the SD card to store the temperature probe readings for later review.
After having started the project I decided it would be nice to view the temperature in a graph while the program was running. This possibly could be done with just the Arduino alone but would require purchasing an Arduino LCD monitor kit ( a purchase I was reluctant to make ) and a lot more coding.
One option I seriously considered was using a micro computer such as a Raspberry Pi or a PCDuino Nano3 to handle the video out duties as I had both a Pi and a Nano available. But as the project progressed it seemed the logistics of supplying power, USB keyboard and mouse input to the micro and video out from the micro would mean a lot of cables running into the enclosure holding the electronics.
Opting for a cleaner setup I decided to use a spare netbook instead, a Lenovo S10.
Note: Once I had added the S10 to the configuration I did not have to use the SD card reader/writer on the shield as it was redundant using the S10.
The Arduino C++ sketch and the Python code I wrote for the S10 are at the bottom of this write up. I used Python since I've used it on other projects but I'd think the same results can be accomplished with any programming language.
Note: each temperature step must have it's own subroutine in the Arduino sketch; the code below only shows two steps, just copy/paste additional steps and edit the run length ( in seconds ) and the temperature setpoint for each step.
I loaded a flavor of Linux ( Xubuntu ) on the S10 for this project as I've had better success with the Python serial module using Linux than with the Windows version but again you can use any OS you're comfortable with.
To handle the Graphing duties I'm using a Java app called "LiveGraph", it's a nifty little program that can be set to read a data file at specific intervals to update a live graph, hence the name I'd suppose.
BIG NOTE: This project involves using household 110V electricity. If you are not experienced/comfortable working with potentially life threatening equipment then please refer this project to someone else. As always proceed at your own risk and never work on energized equipment.
The probes are a couple of spare DS18B20 units left over from a previous project, these probes have unique serial numbers used to access their readings, this allows them to be used on a single wire system. Rather than go through all the setup steps here that are required to use thes probes I'll refer you to a Google search for "Arduino DS18B20".
I'm using one probe as a "dry" probe to monitor and control chamber temperature and the second as a "wet" probe to monitor liquid temperature, this probe is not necessary to control the chamber but merely used for information. The wet probe can be put in the brew or in a separate container of water if you don't want stuff in your beer.
I mounted the hardware for the temperature probes on the Datalogger shield using terminal blocks to facilitate setup and replacement of probes in the event one fails.
Fritzing wiring layout and Actual wiring layout
( Note: the layout shows digital pins 5 and 7 used for the relay control lines but later in the project I changed to 5 and 6 instead. It doesn't really matter which you use as long as the software calls the right pin. )
The only other piece of special hardware required is a relay board used to turn power on/off to the heating/cooling equipment.
Originally I was going to use a relay board that had removable connectors but I could not get reliable connections using that board and replaced it with a relay board with standard terminal blocks.
Replacement board
The enclosure is a clear plastic box from Wallyworld, since there's live 110V in the box I wanted to make sure nothing could move around and possibly short out so I cut an aluminum plate that fits in the box and then attached the electronics to that plate. I got creative with the standoffs to save space by positioning the relay board above the Arduino assembly.
electronics mounted to aluminum plate
To assist in mounting the AC outlet to the box I cut a plastic faceplate down to size, it also covers up the rather ragged looking hole I cut in the enclosure.
completed project
in place
The way it works is the Arduino runs through individual "steps" for each temperature setting, each step has a setpoint value that the Arduino maintains by turning on either cooling or heating as required.
It accomplishes this is by taking a reading from the dry probe and comparing that value to the setpoint using a high and low value ( plus/minus 1 degree C. to prevent the heating/cooling circuit from constantly cycling ) depending on the temperature it will either turn on heating/cooling or do nothing. Following this comparison the Arduino writes the time, setpoint and current temperature values to the serial port where the Python program retrieves it and writes that data to a text file read by the LiveGraph app.
Over the course of testing the setup I found that occasionally the serial port would not be available when the Python program tried to access it, this generated an error which was causing the Python program to stop running.
I suspect a collision where the Python code is trying to read the serial port while the Arduino is still writing to it.
After extensive research I concluded that these errors could not be eliminated so I added error handling code in the Python program to deal with them. Sometimes the program will run days without getting an error and other times only minutes. Since each error only accounts for 10 seconds of run time on the Graph I chose not to try to compensate for the loss of data. Each Lager run is several days long so even if there were hundreds of errors we're only talking about less than an hour of lost Graph data and more importantly the actual length of the lagering profile is unaffected.
LiveGraph output
The top graph is a short 36 hour run, four 6 hour steps and a 12 hour hold at the end. The dry probe ( red line ) shows that the freezer runs for about 20 minutes per hour with about a 40 minute rest between at the 12C steps; on the 2C step, I'd guess it's about 15-20 minutes each on and off.
The bottom graph is a run lasting over 7 days long with the dry probe info turned off to better see the
liquid temp in relationship to the setpoint. The liquid temp doesn't fluctuate a lot once the target temp is achieved, note that it takes the liquid temperature as long as 12 hours to get to the target temp, since a real lagering profile holds several days per step this is not a problem and I suspect slamming the liquid from one temperature to another would not be good for the brew. The significant overshoot going to a colder setpoint as seen in the top graph is irrelevant as the liquid temp is not affected by it.
On the longer run you'll note that the liquid temperature is between .5 and 1 degree warmer than the setpoint once it's settled, if the liquid temperature needs to be closer to the setpoint then the plus/minus temperature offsets could be changed to better accomplish this.
As always, this project could easily be enhanced/improved. For example, you could add WiFi or Bluetooth connectivity to be able to monitor the process from a remote location or you could add a GUI front end to enter the setpoint data or anything else that you believe would be worth adding.
But if you really want or need these additions then save yourself a lot of time/work and buy a BrewPi.
I am amazed by the amount and quality of work/code involved in the BrewPi, it is truly an awesome program!
Arduino code
Python code
Everyone knows that in homebrew one big quality factor is fermentation temperature control.
A couple of years ago I invested in a chest freezer to use as a fermentation chamber and the quality of my ale improved markedly.
I typically only brew in summer and the ambient temperature inside my house swings quite a bit over the course of the day making it hard to maintain a consistent fermentation temperature.
When I bought the freezer I built a simple STC1000 based controller to maintain fermentation temps, usually around a constant 65 degrees F. and that system has worked great for Ale fermentation.
At the time I set up the chamber I had thought that someday I would build a controller that I could program to run Lagering temperature profiles, and recently did so.
Lagering profiles
Lager requires changes in temperature during fermentation. While it would not be hard to manually set those temperature changes the idea of having a system that automatically made those changes unattended appealed to me.
There are several controllers available commercially that accomplish this and most are far more sophisticated than the one I've built, but I enjoy building things so I came up with my own version.
Datalogger shieldMy first idea was to make the controller self contained on an Arduino, this requires using a "datalogger" shield which adds a RTC ( real time clock ) and a SD card reader/writer to the Arduino. The RTC is needed to be able to control the amount of time the chamber is to remain at a specific temperature and the SD card to store the temperature probe readings for later review.
After having started the project I decided it would be nice to view the temperature in a graph while the program was running. This possibly could be done with just the Arduino alone but would require purchasing an Arduino LCD monitor kit ( a purchase I was reluctant to make ) and a lot more coding.
One option I seriously considered was using a micro computer such as a Raspberry Pi or a PCDuino Nano3 to handle the video out duties as I had both a Pi and a Nano available. But as the project progressed it seemed the logistics of supplying power, USB keyboard and mouse input to the micro and video out from the micro would mean a lot of cables running into the enclosure holding the electronics.
Opting for a cleaner setup I decided to use a spare netbook instead, a Lenovo S10.
Note: Once I had added the S10 to the configuration I did not have to use the SD card reader/writer on the shield as it was redundant using the S10.
The Arduino C++ sketch and the Python code I wrote for the S10 are at the bottom of this write up. I used Python since I've used it on other projects but I'd think the same results can be accomplished with any programming language.
Note: each temperature step must have it's own subroutine in the Arduino sketch; the code below only shows two steps, just copy/paste additional steps and edit the run length ( in seconds ) and the temperature setpoint for each step.
I loaded a flavor of Linux ( Xubuntu ) on the S10 for this project as I've had better success with the Python serial module using Linux than with the Windows version but again you can use any OS you're comfortable with.
To handle the Graphing duties I'm using a Java app called "LiveGraph", it's a nifty little program that can be set to read a data file at specific intervals to update a live graph, hence the name I'd suppose.
BIG NOTE: This project involves using household 110V electricity. If you are not experienced/comfortable working with potentially life threatening equipment then please refer this project to someone else. As always proceed at your own risk and never work on energized equipment.
The probes are a couple of spare DS18B20 units left over from a previous project, these probes have unique serial numbers used to access their readings, this allows them to be used on a single wire system. Rather than go through all the setup steps here that are required to use thes probes I'll refer you to a Google search for "Arduino DS18B20".
I'm using one probe as a "dry" probe to monitor and control chamber temperature and the second as a "wet" probe to monitor liquid temperature, this probe is not necessary to control the chamber but merely used for information. The wet probe can be put in the brew or in a separate container of water if you don't want stuff in your beer.
I mounted the hardware for the temperature probes on the Datalogger shield using terminal blocks to facilitate setup and replacement of probes in the event one fails.
Fritzing wiring layout and Actual wiring layout( Note: the layout shows digital pins 5 and 7 used for the relay control lines but later in the project I changed to 5 and 6 instead. It doesn't really matter which you use as long as the software calls the right pin. )
The only other piece of special hardware required is a relay board used to turn power on/off to the heating/cooling equipment.
Originally I was going to use a relay board that had removable connectors but I could not get reliable connections using that board and replaced it with a relay board with standard terminal blocks.
Replacement boardThe enclosure is a clear plastic box from Wallyworld, since there's live 110V in the box I wanted to make sure nothing could move around and possibly short out so I cut an aluminum plate that fits in the box and then attached the electronics to that plate. I got creative with the standoffs to save space by positioning the relay board above the Arduino assembly.
electronics mounted to aluminum plateTo assist in mounting the AC outlet to the box I cut a plastic faceplate down to size, it also covers up the rather ragged looking hole I cut in the enclosure.
completed project
in placeThe way it works is the Arduino runs through individual "steps" for each temperature setting, each step has a setpoint value that the Arduino maintains by turning on either cooling or heating as required.
It accomplishes this is by taking a reading from the dry probe and comparing that value to the setpoint using a high and low value ( plus/minus 1 degree C. to prevent the heating/cooling circuit from constantly cycling ) depending on the temperature it will either turn on heating/cooling or do nothing. Following this comparison the Arduino writes the time, setpoint and current temperature values to the serial port where the Python program retrieves it and writes that data to a text file read by the LiveGraph app.
Over the course of testing the setup I found that occasionally the serial port would not be available when the Python program tried to access it, this generated an error which was causing the Python program to stop running.
I suspect a collision where the Python code is trying to read the serial port while the Arduino is still writing to it.
After extensive research I concluded that these errors could not be eliminated so I added error handling code in the Python program to deal with them. Sometimes the program will run days without getting an error and other times only minutes. Since each error only accounts for 10 seconds of run time on the Graph I chose not to try to compensate for the loss of data. Each Lager run is several days long so even if there were hundreds of errors we're only talking about less than an hour of lost Graph data and more importantly the actual length of the lagering profile is unaffected.
LiveGraph outputThe top graph is a short 36 hour run, four 6 hour steps and a 12 hour hold at the end. The dry probe ( red line ) shows that the freezer runs for about 20 minutes per hour with about a 40 minute rest between at the 12C steps; on the 2C step, I'd guess it's about 15-20 minutes each on and off.
The bottom graph is a run lasting over 7 days long with the dry probe info turned off to better see the
liquid temp in relationship to the setpoint. The liquid temp doesn't fluctuate a lot once the target temp is achieved, note that it takes the liquid temperature as long as 12 hours to get to the target temp, since a real lagering profile holds several days per step this is not a problem and I suspect slamming the liquid from one temperature to another would not be good for the brew. The significant overshoot going to a colder setpoint as seen in the top graph is irrelevant as the liquid temp is not affected by it.
On the longer run you'll note that the liquid temperature is between .5 and 1 degree warmer than the setpoint once it's settled, if the liquid temperature needs to be closer to the setpoint then the plus/minus temperature offsets could be changed to better accomplish this.
As always, this project could easily be enhanced/improved. For example, you could add WiFi or Bluetooth connectivity to be able to monitor the process from a remote location or you could add a GUI front end to enter the setpoint data or anything else that you believe would be worth adding.
But if you really want or need these additions then save yourself a lot of time/work and buy a BrewPi.
I am amazed by the amount and quality of work/code involved in the BrewPi, it is truly an awesome program!
Arduino code
Python code
