BrewPi Remix is a fermentation temperature controller that can monitor and regulate your beer or wine fermentation with 0.1°C precision. It runs on a Raspberry Pi and a microcontroller; currently, an Arduino Uno or an ESP8266. BrewPi Remix offers precise temperature control, data logging, a web interface, and graphs in your browser. All the software is open source.
The Raspberry Pi is a credit card-sized computer that runs Linux. In BrewPi Remix, it runs the webserver and a python script to log data and manage settings. The Arduino and the ESP8266 are microcontroller boards that read the temperature sensors and activates the heating and cooling to control the temperature. You may also use an LCD and knob to display and change settings independent of the web interface.
The controller runs the temperature control algorithm autonomously. If you do not care about data logging, it can control your beer without the Raspberry Pi. The controller is very stable: if the Raspberry Pi crashes, the controller will keep your brew temperature precisely at the setpoint.
The Raspberry Pi runs a local web server that provides an interface to change settings, view brewing data, and configure your controller. The web interface shows interactive graphs of your current brew or previous brews. You can quickly start a new run, view what the control algorithm is doing, check the logs, load or save temperature profiles, edit the active profile, etc.
Instead of just heating when the beer is too cold and cooling when the beer is too warm, BrewPi Remix calculates what the fridge temperature should be to keep your beer temperature in check. This predictive adjustment prevents wide fluctuations in the beer temperature. It’s like cruise control for your fermentation.
With BrewPi Remix, you have much more control than just keeping a constant beer temperature: you can define a temperature profile over time. An example of what you can do with a temperature profile:
You start at 20°C for 36 hours, right in the middle of the temperature range for your yeast to make it easy for them to start up and multiply.
After 36 hours, when your beer is bubbling well, drop the temperature to reduce ester formation with a setting of 17°C for three days.
You decide to keep the beer at 17°C for three days, but the fermentation slows down.
Yeast is more active at higher temperatures, so you slowly raise it to 22°C over five days: as the yeast consumes more complex sugars, it can do this at a higher temperature.
After reaching 22°C, you keep it at that temp for two days for a diacetyl rest, before cold crashing at 3°C.
Using temperature profiles, you can do gradual temperature changes. Yeast is sensitive to sudden temperature changes: a sudden drop in temperature can cause them to drop out of suspension because they need time to adapt to a new set point.
BrewPi Remix also supports cutting-edge brewing technology, including:
Finally, I would like to thank Elco Jacobs (@elkoe) for having the vision to create BrewPi originally, and for making it open source so that the community could continue working with it after he moved on to new projects.
I have to go searching for how to do this every time. This time I thought I would memorialize the instructions. I found this in an article written by Stacy Prowell on Medium.com.
The first thing you need is some additional software. I am going to use Postfix, which is a mail transfer agent (MTA) — that is, something that knows how to talk to other MTAs to send and receive email. In particular, Postfix supports the simple mail transfer protocol (SMTP), so it can talk to nearly any other MTA out there, including Google’s Gmail. In case you don’t like Gmail, there are guides online like this one for getting Postfix to talk to other SMTP servers.
1. Install Postfix
Run the following command at the prompt to install Postfix along with simple authentication layer security (SASL), which Postfix will use to connect to Gmail.
sudo apt install postfix libsasl2-modules
During the installation, you will be asked about how the mail server should operate. You want an Internet Site, where email is sent and received directly using SMTP, so select that option.
So many choices
Now you’ll be asked for the “system mail name.” You should use your hostname (raspberrypi, for instance) or, if you have a fully-qualified domain name for your network via your ISP or a service like DYN, then you can use that. Don’t stress over this; you can modify it later by editing the /etc/postfix/main.cf file if you need to.
Set the server name
2. Get an Application Password for Postfix from Google
have Google set up for two-factor authentication (2FA), so how will the Pi be able to send an email? Well, it turns out you can get Google to generate an application password, which is a password to allow a specific application to connect.
Note that I have two-step verification turned on. You might or might not; either way, creating an application password for each application is a good idea. If you lose a device or it is stolen, you can revoke the application password and not have to change your existing password or passwords for other applications.
There should be a box for “Signing in to Google” that contains an option for “App passwords.” Click on that. You might have to sign in again at this point (I did). This should take you to the page to manage application passwords. The example account I am using doesn’t have any.
Create a new application password
Now click on “Select app” and select Mail. Then click on “Select device” and select Other. You’ll need to enter the name of the device (for this example it is raspberrypi4). Click Generate to create the application password.
A new application password! Don’t get excited; I’ve already deleted it.
You should now be presented with a new application password. This is the text in the yellow block in the image above. Success! Do not click done! Copy the app password first, or write it down. You’ll need it and you can’t display it again.
3. Configure SASL
(A lot of the content of this section is taken from the Postfix SASL HowTo.)
We are almost done. The next thing to do is to add the app password you just generated to the SASL configuration. Run the following command.
sudo nano -B /etc/postfix/sasl/sasl_passwd
This command will open the file in an editor. It is likely the file does not exist, and you will see an empty file. Add the following line, replacing username and password with your Gmail username and the application password you just generated (don’t include the spaces).
[smtp.gmail.com]:587 username@gmail.com:password
This line tells SASL that when it connects to the host smtp.gmail.com at port 587 to download mail, it should use the given username and password to connect. Exit and save with CTRL+x, y, and Enter.
This file contains a “clear text” password. Run the following command to protect that file.
sudo chmod u=rw,go= /etc/postfix/sasl/sasl_passwd
This command sets the user permissions (root) to read and write and removes any permissions for the group and others. (Fans of the numerical form of chmod will recognize this as 0600.)
Now turn this file into a hash file for Postfix. Run the following command.
sudo postmap /etc/postfix/sasl/sasl_passwd
This command will create a new file named sasl_passwd.db in the same directory. It should already have the permissions set correctly, but just in case, let’s also explicitly set the permissions.
Find the line (near the bottom) that starts with relayhost =. Here is where we specify that we want to use Google’s SMTP server as our relay host, and this must match what we put in /etc/postfix/sasl/sasl_passwd. Change the line so it looks as follows.
relayhost = [smtp.gmail.com]:587
Next, add the following to the end of the file. (Documentation for these options and others can be found here.)
# Enable authentication using SASL. smtp_sasl_auth_enable = yes # Use transport layer security (TLS) encryption. smtp_tls_security_level = encrypt # Do not allow anonymous authentication. smtp_sasl_security_options = noanonymous # Specify where to find the login information. smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd # Where to find the certificate authority (CA) certificates. smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
Save and exit with CTRL+x, y, and Enter, and then restart Postfix with the following command.
sudo systemctl restart postfix
5. Testing Email
Next, let’s verify that we can send an email via Google’s SMTP server. Type the following at the command line, replacing username with your Gmail user name (so the email goes to you).
sendmail username@gmail.com Subject: It works! Hey, it works! .
The first line uses the sendmail command to send an email to the specified recipients (you can list more than one). The subsequent lines optionally specify mail headers like the subject, and then the body of the email. The entire thing is terminated by a period. Note that this is just one way to send email using the sendmail command. Later we will use sendmail to send the output of commands.
Check your email. If you got an email from yourself (remember: Postfix is using your credentials) then everything is working. If you didn’t, then you should check a few places on the system.
Checking for Problems
The most obvious problems are an inability to reach the Gmail server and a failure to authenticate with the Gmail server.
Inability to reach the Gmail SMTP servers
Make sure the network is connected and see if you can reach the Gmail SMTP server. The easiest way to do this is to “ping” smtp.gmail.com. If you see a failure message like “ping: smtp.gmail.com: Name or service not known,” then you should check your network connectivity. (It is possible that your ISP or the Google service itself is down… but this is less likely.)
Failure to authenticate with the Gmail SMTP servers
To see this, check the file /var/log/syslog for messages from postfix. If you see a message like the one below, your credentials were not accepted.
Dec 10 08:04:01 raspberrypi postfix/smtp[18329]: 331F960582: SASL authentication failed; server smtp.gmail.com[108.177.122.108] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8 https://support.google.com/mail/?p=BadCredentials c188sm1372198ywb.56 - gsmtp
Check that the content of /etc/postfix/sasl/sasl_passwd is exactly what it should be, and make sure you ran the postmap command to create the hash file. If everything looks correct, or if you don’t have your application password written down, go back to Google account management and delete the old application password, create a new one, and carefully add it to /etc/postfix/sasl/sasl_passwd and then run the postmap command given earlier.
Adding Email Aliases
You can add email aliases by editing the file /etc/aliases and then running the newaliases command. This can be used to tell Postfix how to handle local email addresses.
For example, perhaps you want email to the pi user to go to your Gmail account. You would run the following command to edit the aliases file.
sudo nano -R /etc/aliases
Next, you would add the following line, where username is your Gmail username.
pi: username@gmail.com
Finally, tell the system about the new mail aliases by running the following command.
sudo newaliases
Now mail sent to pi will be forwarded along by Postfix to your Gmail account.
Depending on what you are using the Pi for, you might forward postmaster, webmaster, or other names. Note that these don’t have to correspond to any local account.
Sending Text Messages
A computer in our server room sends me a text message each morning using a dedicated cellular long term evolution (LTE) modem. The Pi doesn’t have one (though you can buy them; for instance, here’s one), but if you’ve successfully followed the above instructions, your Pi can send email, and it turns out you can send a text message by first sending an email.
First, a word of warning. Sending an email over a connection to Gmail isn’t likely to cost you any more than you are already paying for internet connectivity. But receiving a text message on your phone just might. Check your plans, and be courteous of other people who might not want unsolicited text messages from you.
Email to Text
Cellular providers will convert emails sent to a special address into text messages, and forward them along. Text replies may be converted back to a return email, but this is less certain. The two articles below cover this in some detail and provide information for both short message service (SMS) and multimedia message service (MMS), where supported.
Here are the top four North American providers and the information for each. (Apologies to non-North American readers; there are far too many wireless services around the world for me to try to include them all.)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
You use these by finding the provider for the recipient of the message, and then sending an email to the ten-digit (North American) phone number followed by the appropriate email suffix.
For instance, suppose your cell phone number is (724) 555–1212, and your provider is Verizon. Then you can send yourself a text by sending an email message to the address 7245551212@vtext.com. These SMS messages are typically limited to 140 characters.
You can also send MMS messages, but this is a bit more complex.
Email to Text from the Raspberry Pi
My carrier is Sprint, and my number is (not really) 724–555–1212. So to send a text to my phone I can send a short text email to 7245551212@messaging.sprintpcs.com. Let’s try a test.
At the prompt of the Raspberry Pi, try the following (replacing the address with whatever is correct for your cell phone).
Great! If you don’t, check your Gmail for a delivery failure notice, and make sure you are using the correct address for the recipient (you, in this case).
Reply to Text
What happens if you reply to a text? Well, that depends on your service provider. For my provider (Sprint) an email is created and sent.
Talking back to the text
You can reply to this email, and the result will be a (possibly very ugly) text message. Communication achieved!
Note that if you are getting your hopes up on automatically processing the replies, you should be careful. The reply above was sent as a base 64 encoded rich text file. That is, you may have to do some work if you want true two-way communication.
Things to Say
Now that you can send email and text messages from the Pi, what should the Pi say? Well, as mentioned at the start, I set my Pi up to be a file server, and so one thing I would like is a report on the file system usage each morning when I get up. I’m also mildly paranoid, so I’d like to know when someone logs into the Pi. One is almost trivial. The other requires a bit more work.
This would be a good time to add an alias for text messages. For example, you might add the following line to your /etc/aliases and then run sudo newaliases as described previously.
alert: 7245551212@messaging.sprintpcs.com
From now on you can just send email to alert, and Postfix will turn it into a text message to your phone.
Reporting File System Usage
I am using two drives to store information: /data/a and /data/b (I’m not that creative). I can check on the file system used with the following command.
df --output=target,pcent /data/a /data/b
(I only want to know about those two file systems; if I did not include them, the df command would list all the mounted file systems… which might be what you want in some cases.)
This tells me exactly what I want to know: how much space is used in each file system. If this space gets too high, I know I need to add more storage. This is the output from the above command as I write this.
Mounted on Use% /data/a 3% /data/b 2%
It’s short and simple, under 140 characters, and a perfect thing to text to me in the morning to let me know the status of my file server. I can drop the header line and send the output with the following command, using the alert alias we created at the start of this section.
Success! Information you can ignore until it gets out of hand.
(The tail +2 tells the system to copy all output from the prior command, starting at the second line… so this skips the header line.)
Great! Now I want this to run as a command every morning at 6:00 am. For that, I will use the Linux cron utility.
Every user has a special file called the crontab that contains information on commands to execute, when, how often, etc. Do not edit this file directly! There is a special command, crontab, for examining and editing this file.
The following command will list the content of the user’s crontab file.
crontab -l
By default, each user gets a crontab file with a helpful usage message as a series of comments. You should leave these comments in for reference!
# Edit this file to introduce tasks to be run by cron. # # Each task to run has to be defined through a single line # indicating with different fields when the task will be run # and what command to run for the task # # To define the time you can provide concrete values for # minute (m), hour (h), day of month (dom), month (mon), # and day of week (dow) or use '*' in these fields (for 'any'). # # Notice that tasks will be started based on the cron's system # daemon's notion of time and timezones. # # Output of the crontab jobs (including errors) is sent through # email to the user the crontab file belongs to (unless redirected). # # For example, you can run a backup of all your user accounts # at 5 a.m every week with: # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/ # # For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command
Now let’s add a line to generate the file system usage message every morning at 6:00 am. Note that we want to run more than one command, so we need to enclose the whole thing in parentheses. If we were running a single command we would not need the parentheses.
To edit the crontab, run crontab -e. This will open your crontab in an editor. Add the following line, below the format comment, save, and exit.
# m h dom mon dow command 0 6 * * * ( df --output=target,pcent /data/a /data/b | tail +2 | /usr/sbin/sendmail alert )
The minutes (m) is zero, the hour (h) is 6 (using 24 hour time), we want every day of the month (dom), every month (mon), and every day of the week (dow), so we set those three to asterisks (*). Alternately, if I just wanted a report every Friday afternoon at 5:30 pm, I would write the following.
# m h dom mon dow command 30 17 * * FRI ( df --output=target,pcent /data/a /data/b | tail +2 | /usr/sbin/sendmail alert )
If this seems much too tricky, don’t lose hope. Head over to the Crontab Guru site for help. You can (and I do) have multiple lines in your crontab to do a variety of things. If you want to know more about how crontab works, the file format, etc., see Ranjan Bajracharya’s article on cron jobs.
Because the Pi is accessible remotely, I’d like to be alerted when someone logs in via SSH. Doing that is pretty easy, it turns out. (Of course, this is only going to work is you have enabled SSH.)
First, create a new script. We’ll put this in the /etc folder.
sudo nano /etc/notify-ssh-login.sh
The content of the file should be as follows. (Note that this script depends on the alert alias created at the start of this section. It is a Really Good Idea to try to capture this sort of information in a single place and not scatter it around the system!)
#!/bin/bashPATH=/bin:/usr/bin:/usr/sbin SUBJ="Alert - Remote SSH access from ${PAM_USER}"if [ -z "$PAM_TYPE" -o "$PAM_TYPE" == "open_session" ] thensendmail alert <<END $(hostname) $(date): LOGIN by ${PAM_USER} from ${PAM_RHOST} $(who) ENDelsesendmail alert <<END $(hostname) $(date): LOG OUT by ${PAM_USER} from ${PAM_RHOST} ENDfi
Next, we need to arrange for the Linux pluggable authentication module (PAM) system to invoke this script whenever someone logs in or logs out via an SSH session. Run the following command.
Now log into the Pi via SSH and make sure you get a text message. You should get a shorter message when you log out.
Watching log in and log out. The list of users in the first message includes the console user (tty1)
You can do a lot of other things with PAM; details are beyond this short document, but there are many excellent articles that cover this important system.
There’s been some recent discussions/arguments on forums about the use of Unix variants for these DIY projects. There is no argument that Windows has a crushing lead in the desktop OS market share. Those of us who do this, with some notable (notorious?) exceptions, do this for free. In essence, we do it just for the happiness we get seeing others use our work. If that’s our goal, why not “cater to the masses?” Surely it would increase the adoption rate?
I’m going to use BrewPi Remix as an example since I’m most familiar with it. Unless someone has a better example, I believe it is the oldest surviving DIY/Open Source project, released in 2011. As such, I believe it was also the original project which brought the Raspberry Pi to our projects. While Elco did the original BrewPi work on an old router, the Raspberry Pi released in 2012 and, by February 2015, had sold more than 5 million boards. It was arguably the perfect platform for his use.
I deliver IT projects professionally. When it all comes down to it, my clients are concerned with three things: Cost, schedule, and performance. My experience is that this method of determining success and value applies to these DIY projects as well. I’ll attempt to use the same method to demonstrate the reasons behind these decisions, and hopefully explain why Elco and then the rest of us have chosen this ecosphere.
Cost
Right this moment (January 11th, 2020), the Raspberry Pi Zero W (a wireless variant) is $31.99 on Amazon (US), including a case, SD card, and power supply. That is everything you need if you already have a monitor mouse and keyboard lying around. I dare someone to show me another network-capable computer with the OS license included at that price point.
At this point in the argument, a few people generally point out that they have an old Whizbang 2000 computer with Windows 95 on it that’s perfectly capable of doing the work. This counter-argument is called “confirmation bias.” Applied to our problem, it is exceedingly easy on the Internet today to find someone to disprove any statement. That does not mean that this is true for everyone or even the majority of people. In my experience, it is quite the contrary. The most common thing I hear is, “can you give me a 1 to n list of everything I need?” People are buying this for these projects and startup cost is important.
Even if a person has an old computer, that old computer has value. Otherwise, they would not have saved it in the first place. That value necessarily needs to be applied to the equation. If it is a “perfectly good computer,” it’s likely worth more than $31. If I completely ignore that argument, I am still left with a “cost” to prepare that old computer for use. That cost is my (or my users’) time.
I’ve not stumbled across an “old but useful” computer that was not set aside for a good reason. Maybe it is slow, maybe it is out of space, but before we use it, it needs a little work. Uninstall old programs, update the antivirus, apply patches, maybe run the system recovery to revert it to factory state. That takes a few hours of one’s time. There is always a balancing act for people to determine how much value their time has. This balance is certainly a personal decision, but one that the individual should consider carefully.
Licensing is a cost. Granted, most people forget about this when they buy their PC’s, but those licenses have value. A retail copy of Windows 10 Home edition is currently about $130. A copy of Raspbian is free as in free beer. There is no cost for Raspbian.
There is also a cost for the power consumed by a computer. I do not know many people who consider this, but the impact is not insignificant. According to one person who took the time to measure, 100 watts is a good average to use for cost estimation.
If you take an average of all 50 states, 13.31 cents per kilowatt-hour (kWh) is a good number to use. That 100-watt average for the PC equals 2.4 kWh per day or 876 kWh for a year. Running that PC costs $116.60 for the year. The Raspberry Pi Zero power supply I listed above uses a maximum (the PC was a measured average) of 2.5 Amps of 5V power, which is 12.5 watts. If that humble Pi (see what I did there?) were running at full tilt for a year, it would cost $14.57 per year. The Pi comes in saving you $102.03 per year. If you only count a single year and you count your “perfectly good PC” as entirely free, you still save $70.04 a year after buying a brand new Pi.
If you only count expenses, the Raspberry Pi running Raspbian saves you ~$70.04 in your first year. That’s a rather definitive advantage to Raspberry Pi.
Schedule
Schedule is always a tough one when it comes to DIY projects. Ultimately, the success and value of these DIY projects rely upon your time being free. That said, there’s a balance between the satisfaction one gets from doing work, and the frustration that comes in when things do not go according to plan. I am going to assume that any frustration is bad, and conversely, lack of frustration is good.
To make this argument, I will compare installing Apache on Windows to installing Apache on a Raspberry Pi. Apache is a web server used by a large number of projects.
Saving myself a good deal of writing in the process, I’m going to link you to the Apache Software Foundation’s instructions to install Apache on Windows. Have a look at this and then come back.
Now then, the same install on a Raspberry Pi requires you to type the following into the command line and press <enter>:
sudo apt install apache2 -y
Raspbian is based upon Debian, which is a Linux variant. Linux (and it’s progenitor: Unix) generally depends upon what is called a CLI – Command Line Interface. Using this interface allows us to script various processes, and the example above is one such process. Even if that CLI is intimidating to you, (after all a mouse is more intuitive than a CLI) I think you agree that typing that line three times (to account for typos) is still easier and quicker than following the Windows instructions.
If a project ends up needing even hundreds of commands at the CLI to install and configure all of the packages required, those commands may be scripted into a single file. Here is an example of one such script used to install BrewPi Remix:
Windows allows you to download and install a file with just a few clicks. That script I showed is on GitHub. How does a person used to Windows get that file onto a Raspberry Pi and run it to even begin? Enter the strength of the CLI again:
curl -L install.brewpiremix.com | sudo bash
Entering one command downloads (curl) the file (install.brewpiremix.com) and runs it (pipe through bash) as root (sudo). I’ll admit that’s not as “pretty” as opening a web page and clicking a link, but that’s the part that’s “not as easy” as Windows, and the price we ask you to pay for all the rest.
The example I gave above to install Apache was just a fraction of the work that goes into installing BrewPi Remix. Imagine on Windows if I told you that you need to:
Run Windows update and install all patches
Install:
Git
Python3
Pip3
Arduino
Apache2
php
pyserial
psutil
simplejson
configobj
gitpython
sentry-sdk
Each of those has its website and install/configure instructions. Linux, on the other hand, has the concept of “repositories,” which are essentially a “one-stop-shop” for applications. MS Windows does not have that construct (although the Windows Store hopes to bring some of that.)
There are methods under Windows, known as bundling, by which one may create an installer to do all that work for you. Because there are no standards or rules about how Windows applications install, each may have it’s own peculiarities and conditions by which you install it. Linux does have standards. If I want to create a bundle for Apache and PHP under Windows, I essentially have to write a program that goes to each website, downloads the most current version, executes the individual installers, and then somehow clicks the right buttons for you.
If I want to do the same work, install Apache and PHP under Linux, I need only to issue a one-line command:
sudo apt install apache2 php -y
To bring this all together: When a component used by a Linux-based Open-Source project changes, the developer generally only needs to change a line or two of text within a script. When a component changes in the Windows ecosphere, the end-user needs to relive all the fun of going to individual websites.
Now, consider when a change in a component breaks things in others. All of the components need to work together. Under Windows, the best you can hope for is someone telling you: “don’t upgrade this yet, it will break other things” Under Linux, I can create dependencies in my scripts, conditional flows, which either use the proper versions together or make a different decision if another version is present.
All of this goes to “Schedule.” Your schedule and mine. You want to spend your time brewing and enjoying beer. You do not want to learn to program.
The purpose of an installer is to quickly and easily take a user from “wants to run” to “running” as quickly, efficiently, and simply as possible. In such a complex system of systems, being able to script this experience, and effectively maintain that script, is one of the most important aspects of a project.
Sadly, not all developers make an effort to use these tools to make your experience easier. That makes me sad because the installer is the very first experience people have with your work. If the installation is a mess, there is a good likelihood that you will lose users because they will just drop the whole thing. If a developer spends some time polishing the install process, there’s a much higher chance you will have people up and running and enjoying your hard work.
Finally, I can find no credible evidence that a person who ignores the user experience during the install process on Linux does any better providing a clean experience on Windows. Simply put: a pig wearing lipstick is not going to kiss any better.
Therefore, and since I’m the one writing, I give the advantage to Linux for complex system integration.
Performance
Once the user pays for a system, once the user installs a system, the user needs to operate that system. To me, that embodies performance.
I started this article with the assumption that there needed to be a separate computer to run one of these projects. I have yet to explain why. Many folks will never get to this part of the article, but hopefully, some will. I’ll explain why, when a person spends $1,000+ on a personal computer, it should not be the one to host the project.
A good deal of brewing-related projects in the ecosphere use what is called a “controller” in order to interface with the physical world. This interface may turn a refrigerator on and off to control fermentation temperature, turn on a burner to raise mash temperature, turn on a pump, or track beer as it is dispensed. That interface requires either a physical connection or what’s known as a service. The physical connection is often the decision point that necessitates a dedicated computer for users. Most people do not have a computer in their garage, den, shed, or basement.
In this case, a service or daemon is a fancy name for a program. That program runs and talks to the controller. It needs to be running while the controller is being used. In many cases, for example, BrewPi Remix, the controller is being used continuously. This necessitates a constantly available interface.
Simply put, a little Raspberry Pi (or any dedicated server) is going to be more consistently available than your home computer that is typically shared for several uses. You might be paying bills, playing games, video chatting with your parents, or playing a first-person shooter. Any of these processes may impact the availability or performance of that service.
One also needs to consider how the application is going to be accessed. As a developer, I have no idea whether my users will be running a Windows, Mac, or Linux desktop. Many users have and depend upon smartphones. This variety of user systems has led to a preponderance of applications that present a web-based user interface. A web browser is ubiquitous and, in many cases, provides a consistent application environment for the developer. The project needs to have a web server accessible by any computer on the network. Having a dedicated computer makes this easier, although admittedly, it’s not impossible to have a web server on nearly any PC. Avoiding conflicts are still a consideration. User PC’s are optimized for the user interface, not to be a server of other PC’s on the network.
Above I’ve presented arguments related to the so-called “separation of duties” theory. If you have one tool doing one job, it can be optimized to do that well. You also won’t have an issue when one of its other jobs necessitates maintenance. Spending $31 on a Raspberry Pi gives you quite a bit of flexibility in this respect.
One of the things I see often is a desire to present the web interface on the Internet. People think it’s cool, and want to show their project to people at work, or maybe follow along while on a family trip. I won’t go into the danger of exposing an endpoint to the Internet here, but rather just assume people will do it no matter what I say. If it’s going to happen, having that access method connect to a small dedicated computer is far better than having the Internet able to access the same computer with credit card information, medical records, and maybe even “those pictures” nobody else knows you have.
Finally, there’s the issue of the development environment. If I intend to present an application to the homebrew community, I need to know upon what they will be running that application. Big companies can afford to develop for two different platforms, but I’m doing this for free. Assuming one and only one environment is probably going to allow me to focus more deeply on the functionality of the application. If I have to choose one, it is more likely to be accepted if I choose one that runs on a $31 computer by itself than to require a Mac user to buy a PC.
Summary
I am one guy. There are exceptions to rules. Everyone is different. Your mileage may vary. Will not treat or prevent sexually transmitted infections. What I have shared here are only some of the arguments, but the ones which guide me. I may not convince you I am 100% right, but hopefully, I will have convinced you there are good reasons for the decisions I and others have made.
This is taken from an article which I originally found on thejh.net. I’ve cleaned it up and shared it here to make sure my own documents are able to reference it.
Here’s the deal. You want to clone someone’s GitHub and you think you found the command; it looks like this:
git clone
/dev/null; clear; echo -n “Hello “;whoami|tr -d ‘\n’;echo -e ‘!\nThat was a bad idea. Don'”‘”‘t copy code from websites you don'”‘”‘t trust! Here'”‘”‘s the first line of your /etc/passwd: ‘;head -n1 /etc/passwd git clone
git://git.kernel.org/pub/scm/utils/kup/kup.git
Try running this command in your terminal. It’s supposed to be harmless, right? It is harmless, yes, but what happens still isn’t what you’d expect and demonstrates the dangers in doing stuff like that. Select it with your mouse, copy it somehow (e.g. using CTRL+C) and paste it into a terminal. What happens?
There are some good comments and suggestions on how you can mitigate this kind of attack on Reddit and Hacker News. Have a read if you have time.
So, the Internet is scary. Be informed, be careful. Most of all, be ready for anything.
Over on Homebrew Talk, @day_trippr shared a way to connect the Arduino to your Raspberry Pi over Bluetooth. That was December 14, 2014 and a lot pf people have been successful with that. I personally found a couple of the steps a little challenging. To be fair, that’s a personal shortcoming and not one of the original article. Still I searched for a way to make it a little easier and I think I’ve found it. I’ll share here what I’ve come up with in the hopes that someone else will find it useful.
This tutorial is for Windows users. I expect Mac and Linux users will have to use the “old fashioned” way.
On Amazon I found a package with an HC-05 Bluetooth Module, a case for that module, Dupont jumpers, and a CP2102 USB to TTL Converter for $12.99 on Prime. That seems like a pretty good deal and provides some pretty good value for a person new to it. When you get a drawer full of “crap”, the Dupont wires certainly have less value, but I kinda like the case. So, I’m writing this with that USB to TTL Converter being used:
Without further adieu, let’s get started. Don’t plug the adapter in your computer yet. You’ll need to download some software to get going. You’ll probably need the CP2102 drivers, and to follow this you will definitely need the DSD TECH Bluetooth Tools Software. Download and install both of these (actually the “Bluetooth Tools” doesn’t install, just unzip to a handy directory):
Don’t plug the converter into the USB on your computer yet. Connect the TTL converter and the BT module like so:
I actually used the 3.3v the first time, the module will run on 3.3-6v for VIN I believe, but the data channel needs to be 3.3 volts. No worries, the USB to TTL converter handles that for you. Here’s the connections in text form:
Converter Pin
HC-05 Pin
3v3
VIN
TXD
RXD
RXD
TXD
GND
GND
Basically, remember to connect transmit to receive and vice versa. When you are ready and the jumpers are connected properly, connect the device and set programming mode (called “AT mode”) by doing the following:
Input low level to PIN34, supply power to the module, input high level to PIN34, then the module will enter to AT mode.
Just kidding, I have no idea what that means either. I promised this would be for mortals. 🙂
Hold the button down on the Bluetooth Module (note about some of the modules sold elsewhere which are insulated with shrink-tube: You may have to cut the tube away from the button in order for it to function correctly)
Plug in the USB to TTL Converter
The light will come on for about a second, and then shut off
Let go of the button on the Bluetooth Module
If you have done this correctly, the module should be flashing on and off slowly. Done incorrectly, the device will be flashing rapidly. If you don’t get it the first time, unplug the converter and try again.
Now run the “DSD TECH Bluetooth Tools Software” you unzipped. You will be executing “SHTester.exe”.
Select the last tab which is “HC-05”.
Drop down the UART box and select the port. On most systems there will be only one. If you have some other COM port device installed there may be more than one listed. If this is the case you will need to open Windows’ “Device Manager”, look under “Ports (COM & LPT)”, and see what COM port is associated with the “Silicon Labs CP210x” device.
Set Baud Rate to 38400, then click “Open”.
Click the “Test” button, and in the status windows you will see the “AT” command being sent and “OK” received. This will not work unless you are in AT mode (slow flashing). If you don’t get anything back it’s likely a Baud Rate mismatch. Click on “Close”, select a different Baud Rate, “Open” and try testing again till you get an “OK” back.
Now set “Bluetooth Name” to whatever you’d like it to be, Baud Rate to 57600, PIN (really no reason to change the PIN but if you do, remember it), and set Role to “Slave”. Click “Set” after each change.
Now “Close” the UART up top again with the red “X” and you can close the app.
If you’d like, you can test the device over Bluetooth from your computer:
Unplug the USB dongle and unplug the two TX and RX wires.
Plug it back in and now the Bluetooth Module will be flashing rapidly indicating it’s ready to be paired.
Open the Windows Bluetooth settings and click “Add a device.”
Select the name you gave the module above and enter the PIN you used.
Click “Connect” and if successful, the device will flash briefly every two seconds or so.
Congratulations! You can unplug the device now, it’s ready to be connected to your Arduino.
This is where you can go a couple different ways. In order to connect to your Arduino you do need to either use a voltage splitter to step the voltage down to 3.3v, or if you are using @CadiBrewer’s shield, this is done for you. This has to be done because the logic on the HC-05 module can only handle 3.3 volts, and the TX channel on your Arduino is at 5 volts.
If you are using the shield version 1.1, connect as follows:
Shield Pin
HC-05 Pin
VCC
VIN
TXD
RXD
RXD
TXD
GND
GND
If you are using the shield version 1.2, reportedly the RX/TX line up directly so connect as follows:
Shield Pin
HC-05 Pin
VCC
VIN
TXD
TXD
RXD
RXD
GND
GND
If you are going all rogue and want to do it without a shield, at least you were able to skip the whole Arduino sketch setup thing initially. You will need the following:
1 x 1K ohm resistor (1/8W axial)
1 x 2K ohm resistor (1/8W axial)
Assorted Dupont jumpers
Wire them according to this diagram so that the voltage into the RXD pin on the module is cut to 3.3v:
Software Setup
Setting this all up changed since the article @day_trippr posted. I am NOT sure when this changed. @day_trippr is running Wheezy and Jessie and his original article uses the “old” way of setting up a Bluetooth device. I’m using Stretch with bluetoothd 5.43 and the method by which you set up /dev/rfcomm* devices with the rfcomm.conf file in /etc/bluetooth in Wheezy and Jessie is no longer supported. I’m sure someone somewhere could tell me WHY this is better. I’m sure we’d hear some crap about “cloud-enabled” like they tell me with all my favorite Ubuntu items that no longer work.
Anyway, here’s how you can get the devices enabled with Stretch. To start with, make sure your HC-05/6 is powered up in its production configuration (i.e. baud rate and slave mode as detailed above). At this point it’s probably flashing 2-3 times per second. Then, prove to yourself that there’s no rfcomm* devices:
pi@brewpi:~ $ ls -al /dev/rfc* ls: cannot access '/dev/rfc*': No such file or directory
Next, execute the new CLI for bluez, “bluetoothctl”:
The controller listed is your local Raspberry Pi’s controller. We need to turn on and configure the “agent” which is the process that allows you to enter the pairing codes with Bluetooth devices when required:
The next thing to do is allow the system to scan for local devices. If you have a “busy” area bluetooth-wise, you may get a lot of spam. Just let it run about 10 seconds and if you are living a clean life you will see your target Bluetooth device and it’s MAC address. After that you can turn off the scan.
[bluetooth]# scan on Discovery started [CHG] Controller XX:XX:XX:XX:XX:XX Discovering: yes [NEW] Device XX:XX:XX:XX:XX:XX XX-XX-XX-XX-XX-XX [NEW] Device XX:XX:XX:XX:XX:XX [TV] Living room [NEW] Device XX:XX:XX:XX:XX:XX Chamber 1 […] [bluetooth]# scan off […] Discovery stopped [CHG] Controller XX:XX:XX:XX:XX:XX Discovering: no
You may have to scroll up to find it, but if you gave your HC-05 a friendly name when you set it up (“Chamber 1” in my case), you should see the MAC followed by that name. Next, you will pair with your device with the pair command followed by the MAC address. It will prompt you to enter the code which is generally 1234 or 0000 unless you changed it:
[bluetooth]# pair XX:XX:XX:XX:XX:XX Attempting to pair with XX:XX:XX:XX:XX:XX [CHG] Device XX:XX:XX:XX:XX:XX Connected: yes Request PIN code [agent] Enter PIN code: 1234 [CHG] Device XX:XX:XX:XX:XX:XX UUIDs: 00001101-0000-1000-8000-00805f9b34fb [CHG] Device XX:XX:XX:XX:XX:XX ServicesResolved: yes [CHG] Device XX:XX:XX:XX:XX:XX Paired: yes Pairing successful [CHG] Device XX:XX:XX:XX:XX:XX ServicesResolved: no [CHG] Device XX:XX:XX:XX:XX:XX Connected: no
At this point your BT dongle is probably flashing once every two seconds. It’s paired and trusted as you can see by issuing the ‘info’ command:
[bluetooth]# info XX:XX:XX:XX:XX:XX Device XX:XX:XX:XX:XX:XX Name: Chamber 1 Alias: Chamber 1 Class: 0x001f00 Paired: yes Trusted: yes Blocked: no Connected: no LegacyPairing: yes UUID: Serial Port (00001101-0000-1000-8000-00805f9b34fb)
I noticed that if you power-cycle the Bluetooth device at this point, it will go back to flashing 2-3 times/second but that doesn’t seem to affect things. You can exit or quit back to the shell prompt:
It seems like the command runs till something touches the device (which is why we background it with the trailing ‘&’.) In that command the ‘0’ is the rfcomm device we want to assign (i.e. /dev/rfcomm0), the MAC address should be obvious, and the 1 is the channel. Unless you know why you want to change the channel, use ‘1’. Now prove there is a device in the list (and see the background process exit):
Power-cycling the BT device at this point proves the device will reconnect after a power failure after about 10 seconds. What does not happen however is the connection will not re-establish to the device after a Raspberry Pi reboot or power failure. We need a way to issue the rfcomm command after every reboot (and after the bluetoothd starts.) Create a file named ‘rfcomm0.service’ in the ‘/etc/systemd/system/’ directory:
This will allow systemd to execute the rfcomm command binding that MAC to rfcomm0 after the bluetooth.service starts. To enable this unit file, issue the commands:
You can start it with the ‘sudo systemctl start rfcomm0’ command, but there’s no reason to since it’s already bound (assuming you ran the bind command above and have not rebooted – it will not hurt if you run it again). If you check the status of this daemon after system reboot it will not be running, because it ran once and exited – which is all we needed it to do:
pi@brewpi:~ $ sudo systemctl status rfcomm0 ● rfcomm0.service Loaded: loaded (/etc/systemd/system/rfcomm0.service; enabled; vendor preset: Active: inactive (dead) since Sat 2019-03-16 13:43:59 CDT; 40s ago Process: 290 ExecStart=/usr/bin/rfcomm bind 0 XX:XX:XX:XX:XX:XX 1 > /dev/null 2>&1 & (code=exited, status=0/SUCCESS) Main PID: 290 (code=exited, status=0/SUCCESS) Mar 16 13:43:59 brewpi systemd[1]: Started rfcomm0.service.
That’s how you set up your BT devices now in Stretch! You’ll notice that using the graphical interface is also not needed. Using this method, no additional packages are required as a matter of fact, all the packages are part of the stock Raspbian Stretch distribution.
If you have multiple Bluetooth devices, you’d change the above steps using 1, 2, 3, etc., instead of 0. You would also need a systemd unit file for each device named appropriately.
Testing
If you want to give it a test outside of BrewPi, you will need to install a program called “screens”:
sudo apt install screen
Next, run ‘screen’ and connect to that device with the proper baud rate:
sudo screen /dev/rfcomm0 57600
If you are living a clean life, you are now connected to your Arduino. Issue the command ‘l’ (lower-case L) and the controller should print the LCD screen information; something like this:
L:["Mode Off ","Beer 60.7 --.- �F","Fridge 61.2 --.- �F","Idling for 03m08"
You need to type “ctrl-a” and then “k” to kill the screen session.
Configure BrewPi
In order to connect this to BrewPi, you will edit (or create) your config.cnf file to look something like the following:
scriptPath = /home/brewpi wwwPath = /var/www/html port = /dev/rfcomm0
This works in Legacy BrewPi as well as all versions of BrewPi Remix.
One of the most common “wishes” for BrewPi users is to be able to connect the Raspberry Pi to the Arduino wirelessly. This makes even more sense and is more desirable when you leverage a multi-chamber setup. The Arduino Uno did not have WiFi originally, although the nice folks over there in Italy have a Rev 2 of a WiFi enabled Uno for the low low price of $44.90. I don’t know for sure, but since (I believe) this is a native implementation, I suspect any Uno sketches would need to be re-written for WiFi.
That’s a problem for BrewPi where we are getting close on storage space anyway.
Not to fear though! Back in 2015, @thekraken on HomebrewTalk started talking about how to make an ESP8266 work as a serial bridge. That was really just sort of a technical discussion, and it never quite rose to the level of something that seemed practical for most end users. About four months after that, @day_trippr took a swing at it and came up with a start to finish method of doing it for the courageous, but let me just tell you that dude is “wicked smaht” and what’s easy for him is not generally easy for a guy like me.
People kept pecking at it but rather than me give you the blow by blow, you can read it yourself on HomebrewTalk. BUT, I figure you want to know how to do it, or else, why are you here. Amirite?
So, here’s what you need:
A Raspberry Pi (duh!)
A combo ATmega328P+ESP8266 card direct from China. The ATmega328 is the guts of an Uno. The ESP8266 is a controller in its own right, but we are using it as a WiFi/Serial bridge. I used this one from Banggood in my project. I don’t have any reason to believe that there are not many others that would work. I paid $6.49 + shipping so I bought a couple just in case one arrived DOA.
To start with, go ahead and install BrewPi Remix if you don’t have it installed already. No need to connect the Arduino just yet. Take the defaults, smile and nod your head if the script tells you there’s no Arduino, and don’t worry about flashing the controller (yet.)
You might need to Google up some drivers for the CH340 chip if you will be using your PC for this (and expect my instructions to work), unless you’ve messed with one of the Uno clones before. The “official” drivers appear to be on this page in Chinese. You can either translate or click on the very obvious download button and throw caution to the wind.
Install those drivers, and find yourself a USB micro cable because this board ditched the HUGE type “B” plug. Before you plug it in, you need to set the DIP switches as follows to let the CH340 talk to the ESP8266:
Switch Number
Position
1
Off
3
Off
3
Off
4
Off
5
On
6
On
7
On
8 (Do Not Use)
Off
Go ahead and plug the board in to your PC to hear the pleasing “boing” letting you know that it connected. You’ll need the NodeMCU Firmware Programmer if you have not already downloaded it before. You can get it here. If you don’t know whether you are on a 32 or 64-bit system, just grab the ESP8266Flasher.exe file from the Win32/Release directory.
You will also need some firmware for the ESP8266 side. First, download “ESP-Link” version 3.0.14 from the releases page (read the notes and get the latest stable version.) Previous versions of this article had instructions to use 2.2.3 versions, but the 3.0.14 firmware seems quite stable. Unzip those files somewhere handy and continue.
Go ahead and execute the NodeMCU Firmware Programmer (“ESP8266Flasher.exe”) and set up the following firmware files at the addresses indicated on the “Config” tab:
File Name
Memory Address
Description
boot_v1.6.bin
0x00000
Bootloader
user1.bin
0x01000
ESP-Link Firmware v3.0.14
esp_init_data_default.bin
0x3FC000
Expressif Default BIN
blank.bin
0x3FE000
Blank WiFi Settings
The numbers are memory addresses so do be careful and don’t select the wrong one. At best things will not work. At worst you will brick your card.
If you are curious about the “Advanced” tab, I did not make any changes. The settings were:
Setting Name
Setting
Baud Rate
230400
Flash Size
4MByte
Flash Speed
40MHz
SPIO Mode
DIO
On the “Operation” tab, select the proper COM port, then click “Flash”.
When complete, go ahead and close the programmer, unplug the card, and set the switches to connect the CH340 to the ATmega328 (upload sketch to the ATmega328):
Switch Number
Position
1
Off
3
Off
3
On
4
On
5
Off
6
Off
7
Off
8 (Do Not Use)
Off
Now flash the BrewPi Remix firmware with whatever tool you like. I just plugged it into my Pi and used “sudo /home/brewpi/tools/updateFirmware.py” since that script downloads the latest firmware automatically. In theory this board will allow flashing the ATmega328 over the air, I’ve just not tried that yet. Once you have the BrewPi firmware loaded, unplug and set the switches to connect the ESP8266 to the ATmega328 (serial bridge mode):
Switch Number
Position
1
On
3
On
3
Off
4
Off
5
Off
6
Off
7
Off
8 (Do Not Use)
Off
Power the board up separate from your PC or Pi. Now from your computer, phone, or whatever; search for the access point created by the board. It will be something like ESP_XXXXXX. Connect to it, no password needed. Open your web browser and navigate to 192.168.4.1. After a moment the esp-link page will show up. Go to the “WiFi Station” tab, and follow along. Click the link under “WiFi State” to switch to STA+AP Mode:
Select your desired wireless network (if they do not show up, refresh the page) and provide the proper password. When done click the Connect! button:
After it connects successfully, record the WiFi IP Address under “WiFi State.” For the purposes of demonstration, we’ll assume it’s 192.168.168.143.
Now connect your PC to your normal network and connect to the board again via it’s new address (192.168.168.143). Go to the µC Console tab and set the following:
Switch Baud Rate to 57600
Click the Reset µC button to commit the change.
Now press the MCU RESET button on the controller (or simply power-cycle by pulling the plug.) If you left it on the µC Console tab, you should see json from the controller in the console window after reset is complete. Success!
The last step is to configure your BrewPi instance for the controller. Assuming you are using a custom config (config.cfg), change the port to point to your board’s IP address and port 23 like this:
scriptPath = /home/brewpi wwwPath = /var/www/html port = socket://192.168.168.143:23
This will work on all versions of BrewPi Remix starting with 0.5.2.0. Changes to the python scripts would be necessary to use this with Legacy BrewPi. Re-start your script and you should be connected via WiFi!
One thing I came across which requires a small hardware change: If you are using one of @CadiBrewer’s shields with the LCD you will notice that the LCD does not work. This is because the shield attempts to separate the power for the shift register and LCD from the rest of the board by taking power off the ICSP header. This header does not line up with the ICSP header on the combo board. So, you must jumper 5 volts and a ground (+5V and GND) off the header on the shield to the ICSP header on the shield and all will be well.
Obviously this shows the Arduino and not the shield, but the headers are all in the same place.
The Raspberry Pi is an awesome little platform with uses from education to home automation. If you rely upon it to host a process or application wirelessly, you will sooner or later find it unavailable on the network. If you search the Internet you’ll find several “solutions”, some work a little, some not at all.
I’ve developed a script and a process to keep it running which will shut off power management for the wireless adapter and try to ping the gateway on interval. If the ping fails for a certain number of times, it will reset the adapter. If it continues to fail it can (optionally) reboot the Pi.
Install with the following command:
curl -L wifi.brewpiremix.com | sudo bash
If you wish to enable the reboot function, edit these lines:
# Reboot on failure REBOOT=false
Add change to:
# Reboot on failure REBOOT=true
After that change, reboot, or restart the daemon with the following command:
There’s two very important points I need to share about this:
Without the start FuzzeWuzze gave us on the “Mega Thread” on Homebrewtalk.com, a lot of us would never have successfully made our first rig. The first post is dated, the thread incredibly long (but still full of AWESOME info), the various fan Wiki’s also dated, so I wanted to persist for as long as I could how a person can put together the hardware
There are as many ways to do this as there are people doing it. This is ONE WAY it can be done. If you are smart enough to deviate from this, you should be smart enough to figure it out yourself. Please don’t ask me why your new idea doesn’t work
This post will share how to put the hardware supporting BrewPi together in the most basic way with which I believe a person can be successful. It is not meant to be “production ready”, it’s meant to show how it works on the bench so that the DIYer can add a case, etc., and use it on their fermentation chamber.
What you need
I’m not going to suggest which ones of these to buy, but I will give you some pictures that, along with the name/description, should be about all you need to find them on the Internet. I’ll give you a hint: I got all of these pictures except for the thermowell off Amazon. For the thermowell, seek out Brewers Hardware:
A fridge that you can “hack”. This can be as simple as keeping a fridge’s thermostat all the way on cold and plugging it into the system so that it only turns on by the BrewPi system. Most modern refrigerators use timers and such which make using them a little less straightforward. If you have what is commonly sold as a “kegerator”, it will work pretty well as it lacks auto-defrost, etc. This article will not detail how to hack a fridge (maybe some future article will), it will assume you are using one of those “kegerator” style boxes.
A working Raspberry Pi. This article will not detail how to setup the Raspberry Pi, nor address the software part of the build – that’s done
elsewhere.
An Arduino Uno. I recommend not trying to get the cheapest one possible straight from China, and until you know why; avoid the ones that state they have a “CH340”. You can get a genuine Arduino Uno R3 on Amazon for $20, and decent clones for about $11. Get a USB A to B cable while you are at it if it does not come with one.
A 2-channel 5-volt relay, commonly the “SainSmart 2-Channel Relay Module” or a similar model.
A 15A 115v electrical outlet (if you are not in North America, modify this accordingly).
A “euro-style” wire connector strip, three stations will be needed. You can do this with anything, a breadboard, wire nuts, go wild. The first time I made this, this is what I used and it worked well.
One 4.7k Ω 1/4 watt axial resistor (sometimres you see this called a 4k7 Ω ). You are unlikely to find a single of these for purchase, they are pennies a piece. Pretty much anything you find that says 4.7k Ω 1/4 watt that looks remotely like the ones on the left will be fine.
Some 22 gauge Dupont jumper wires in male to female and male to male. You can generally get an assortment of gender combinations in various colors for a few bucks.
Some 16 or 18 gauge stranded wire, in black and red. You won’t need much of this, maybe a foot each. You can even cannibalize some from the next item.
A 16 or 18 gauge (16/3 or 18/3) grounded power cord. An old computer cord is a pretty good item for this if you have one.
(Optional) a “Ceramic Heat Emitter” in 60 or 75 Watts, commonly sold as a reptile heater bulb. Many indoor implementations will never need a heater, but if you have this in an unheated garage or shed in a cold climate, some form of heating will be required. Some folks have used a “personal heater” but even 100w is pretty hefty for this application – a light bulb is enough heat but you don’t want light in the chamber to prevent skunking your beer.
You’ll also need a lamp/cord/receptacle to support a lamp inside the fridge (if you decide to use one.)
(Optional) a small “personal sized” fan for inside the fridge to eliminate dead spots. Nothing large, whatever you have and will fit will work.
At least two DS18B20 sensors (called “one-wire”). Getting “waterproof” sensors with leads is important. Make sure they are directly powered and not parasitic. Searching the reviews and/or BrewPi threads will help you get known good items. Also make note of the wiring/color scheme from the manufacturer. You will need this. It’s nearly always listed with the item’s description.
(Optional but HIGHLY recommended) a stainless-steel thermowell. You won’t need this for bench-testing this of course, but using a thermowell for the “beer” sensor is much better than any of the other methods for getting a good beer temp. Make sure the sensors fit in the well.
Putting it Together
I could blather on about how to put this together, but I think a picture is worth a thousand words. This is a diagram done by 100Amps on Homebrewtalk that suffices for those 1000 words:
There are few things that while clear on this diagram I have managed to screw them up or allowed them to confuse me (or allowed me to confuse myself):
You can tie all of the One-Wire sensors together as shown since they are digital and have their own internal addresses
The “data” leg of the one-wire sensors go to the A4 terminal on the Arduino, power the terminal marked “5v” and the ground to “GND”. Each manufacturer of the sensors seems to change the colors around, so you will have to refer to the manufacturer for which color is which
A one-wire sensor (or many of them tied together) requires a single 4.7k Ω resistor between power and data in order to function correctly. This is called a “pull-up resistor” if you want to Google it. It looks strange but it’s necessary
There is a jumper on the hot side of the outlet that can be broken off with a pair of pliers which allows them to be powered separately – we use this to independently turn on and off the heat and cool
Step by Step Wiring
Refer to the wiring image above as you go through these instructions. The colors need not be the same, but if you keep them consistent you will thank yourself for it later. Print the pic (in color) to make it even easier to reference as you follow along.
Low Voltage Wiring
Get your Raspberry Pi running, get logged in, play with it if you want. You can follow these instructions in the Raspberry Pi pages. You need not make it headless, do it however you want. The videos on the Raspberry Pi website are really good as well. All you need is the Raspberry Pi running, and able to connect to the Internet.
Connect your Arduino to your Raspberry Pi with a USB A to B cable. This serves for both communications and power. Nothing will really happen yet other than an LED lighting up on the Arduino.
Install BrewPi Remix just to make sure your primary pieces are working correctly. Doing it now avoids any confusion later on when you add the rest of the wiring. You’ll know it works before you end up adding more “stuff.” When you are done, the screen will tell you the URL you may use to access your new BrewPi installation. Open it up in a web browser and enjoy it for a moment! When you are satisfied it works enough to open up the page, you can come back here and worry about the rest of the hardware.
Unplug your Arduino from your Raspberry Pi (you do not need to power down the Raspberry Pi first) before you proceed.
You are now going to use your Dupont wires. Grab three different colors of your male to male wires and plug one each in the Arduino’s 5V, GND and A4 (this is your “data” port). These are all on the same side of the Arduino, on the same side as the black power inlet. Pick separate terminals on your Euro-connector, whichever ones you like, and run them there. No need to tighten things up right now.
Take a couple of Dupont wires, male to female, which match your 5v and GND wires. Put the male ends into the corresponding Euro-connector terminals (obviously easier here if you use the same colors as your first two wires.) Again, just snug, no need to tighten.
Take your 4.7k Ω 1/4 watt resistor and connect it between your A4 (data) connector and your power (5V) connector.
You should now have two wires coming into the ground (GND) terminal, two wires plus one side of the resistor into your power (5V) terminal, and one wire plus the other end of the resistor into your data terminal (A4). You can snug them down now if you wish.
Now take at least one (I recommend two) of your temp sensors and referencing the manufacturer’s layout, connect all of the ground leads into the other side of the GND terminal. Connect all of the power leads (may be referenced as VCC) to the other side of the power (5V) terminal. Connect all of the data leads to the other side of the data (A4) terminal. One sensor will be your “beer” sensor and the other the “chamber” sensor.
Now you will connect your 2-channel relay. Take a look at the low-voltage side first. It will have two small male pin strips; one three pins and one four. The three pin strip should have a jumper (probably a small blue or black cap) between JD-VCC and VCC on the strip of three pins. This allows the relay to be powered by the Arduino.
Now you will connect your leads from power (5V) and ground (GND) out of the terminal block to the relay. 5V goes to VCC, GND goes to GND.
Take two more Dupont jumpers, male to female, of differing colors. These will represent heat and cool so maybe blue and orange would be good. Connect one to digital pin 5 and one to digital pin 6 (likely marked ~5 and ~6) on the opposite side of the other connections (USB connector side). At this point it doesn’t matter which is which, you will be able to set the pins later.
The other ends of these jumpers will go to the IN1 and IN2 terminals on the 4-pin strip on the relay.
Your low-voltage wiring is now complete. You can go ahead and plug your Arduino back into your Pi. Refer to the instructions to set up your probes and relay pins and get to know your system. Experiment and test now before proceeding. I recommend a digital multi-meter to test the continuity at the high-voltage side of the relays so you can get the hang of how things work before actually applying high voltage. You can also view the LEDs on the relay card.
There’s nothing about any of the low voltage we’ve done so far which will be harmful to you. You might short some of the circuit logic if you are careless and allow things to touch each other, but I’ve had a lot of these systems laying around, in my lap, on a coffee table, even laying on the carpet, while I test.
High Voltage Wiring
This is where you can destroy your equipment, home wiring, start a fire, harm or kill yourself. BE CAREFUL and if you do not understand what you are doing find someone to help. This is something most home brewers will find trivial, but if there’s any doubt; don’t.
Look at the “hot” side of your outlet. On North American outlets with the ground terminal towards the bottom, this will be on the right side of the outlet between the two terminals. These terminals are generally gold. There is a jumper there which you can grab with a pair of pliers and break off. Do so. This allows you to power each outlet separately, one for heat and one for cool. If you do not do this, you will be running your heater and your fridge at the same time and wondering WTH is going on. This is called a “split receptacle” or sometimes a “switched receptacle.” When you buy your outlet at the local big box store, the people that work in electrical (if you can ever find one) can point this out for you as well.
Take two lengths of stranded wire, 16-18 gauge and preferably red. These will go between the relays and the outlet so maybe a foot or two long. Some crimp-on terminals (called “spade” connectors) would help here but are not absolutely necessary. If you do not use spade terminals, it would be better to use solid core wire for this part. Connect them one each to the hot terminals on the side of the outlet (where you broke off the jumper.)
Connect the other ends of those wires to the “NO” (this doesn’t mean “don’t do it”, it means “Normally Open”) side of the two terminal blocks on the high-voltage side of the relay board. I’d recommend crimping on what’s called “bootlace ferrules” or tinning the ends of the wire (melting solder on the end) if you are using stranded wire. You can do without the ferrule or tinning for testing, but for production use, it’s highly recommended.
Take a piece of black stranded (tinned or ferrules on the ends) or solid-core wire and run it between the NC (Normally Closed) terminal of relay number one (on the top as you look at the relay board with the high-voltage on the right) and the COM terminal on relay number two. Refer to the diagram above for clarification.
Take your power cord and strip enough of the main insulation to work with the three leads. Strip the tips of the three leads. A spade terminal would be good on the ground (green) and the common/neutral (white) leads. The hot lead (normally black) should get tinned or a ferrule.
Connect the ground to the ground lug on the outlet. Connect the common/neutral lead to the neutral side of the outlet.
Run the hot lead from the power cord to the COM terminal on relay number one.
If you are using a metal box for your outlet, run an additional (preferably green) lead between the ground lug on the outlet to the ground lug on the box.
At this point your high voltage side is complete, at least enough for testing. Test BEFORE you plug in your power cord! I am not responsible for anything that goes wrong here so make sure you know what you are doing or have a licensed electrician do the work or check your work. One outlet is going to be controlled for heat, one for cool. Your (optional) fan can be plugged in any convenient outlet – it should run 100% of the time.
I’d highly recommend you mount the outlet to something that’s not going to move, put it in an outlet box, something to protect you and your belongings from the high voltage terminals.
As one final step before plugging in your refrigerator or heater, grab a couple of cheap outlet testers with lights, or even a couple of table lamps, and test some more to make sure things work like you expect.
Work Complete
The work above, and putting the “guts” into a suitable box, are all I did for my fermentation chambers. I plug my kegerator (set on 100% cold) into the “cool” outlet, and my heater (a 60w lightbulb in a paint can) in the “heat” outlet, and let magic happen.
From here there are many ways to go … 3-D printed cases are getting pretty popular. I’ve also seen folks come up with really nice setups from just a trip to the big-box hardware store. The sky is the limit!
“Hacking a Fridge”
This sort of setup relies on being able to directly turn on and off the compressor on the refrigerator. Normal modern fridges often are “frost free” which is accomplished by using a timer and a small heater on the coils to defrost the tubes. It should be obvious that this would not work well for this application. As described here we use what ends up being a “switched power cord” and leaving the fridge wiring intact. There are MUCH more elaborate ways to do this. One of the best write-ups is on the original BrewPi website under Fridge Hacking Guide.
If you do follow the instructions here, you will need a way to get the wiring for the sensors, heater and fan inside the fridge. These methods range from obvious (a kegerator has a hole on the top for the beer lines which may be used for our purposes) to the exceedingly elaborate (some people drill through the sides and use surface-mount electrical connectors.) If you do drill your fridge, make sure you know where the coolant lines are. Piercing one of these is a one-way ticket to the junkyard.
(This article is written for BrewPi Legacy Remix version 0.5.2.0, it likely applies to other versions but there may be some differences.)
You’re here for one of a few reasons:
You’re just curious about how things work
You hate easy things and want to do this the most difficult way possible
You are exceeding (perhaps justifiably) paranoid and refuse to run scrips as root. Maybe starting at the bottom of this article is a good place to start?
You are one of those people that find some twisted satisfaction in running something named BrewPi on something other than a Raspberry Pi
We’re not here to judge (or am I silently judging you right now?), we’re just here to help. Just like the government. Here’s what you have to go through to replicate most of the scripting in the BPR tool set. Note that this only addresses a single-chamber setup. I’m not sure I feel like describing what has to be done to do multi-chamber but a smart person can figure it out from the information that’s out there for the Legacy BrewPi.
Finally before we dig in, these instructions are written for Debian-based Linux distributions (of which Raspbian is one.) If you use something else, chances are you already understand the differences.
Prerequisites
The bootstrap especially does some checking which may not specifically be strictly required, but is highly recommended:
Check to see if the default password of ‘raspberry’ is still current for the ‘pi’ user. If so, prompt to change it.
Prompt to set the proper timezone. Since BrewPi works on schedules and the graph is of course time-based, having the proper system time is important. Yes, I could do some work to allow UTC and display in the user time zone … but why?
If the hostname is still ‘raspberrypi’, prompt to change it. More than a few folks have more than one Raspberry Pi, and being able to use a nice name like “brewpi.local” to get to the system is handy. Plus, you should never have two machines with the same name on the same network segment. It confuses anything with an ARP table (like your router.)
APT Repositories
Manipulation of APT repositories is required to support this product. This obviously needs to be done as root, however the repos are GPG signed so in theory there’s an added level of security.
As with any other apt packages, it is always good practice to refresh your local apt indexes before doing any installs, updates, or uninstalls. This command will re-synchronize the package index files from their sources. The indexes of available packages are fetched from the location(s) specified in /etc/apt/sources.list.
sudo apt update
There are some packages known to conflict with the solution as well; namely nginx and anything related to php5. This should not be a surprise since we use apache2 as a web server and nginx is a web server itself. Yes a crafty person can make them coexist, if you’re that crafty you don’t need my tutorials. Some of the packages I suggest to reinstall will be reinstalled again with apache2 and that’s fine. The process may also suggest removing other packages which are included by dependency; remove those as well. To uninstall nginx, use the following command:
To uninstall php5, I could give you a script but you’re here because you either don’t trust my scripts or you can’t use them for some reason. You can use the following command to find php5 packages which may be installed:
The web root should be /var/www/html but new versions may change that. Clean out that directory (it probably has a default index.html file there) and clone the website as the www-data user with the following command:
You can download the precompiled firmware (sorry, not going to go into how to compile it on your own here) from the GitHub repo. For instance here’s how to download the latest Arduino Uno firmware:
You would now flash your connected Arduino with the following command. Be sure to update the port (following the ‘-P’) with the port where your Arduino resides:
BrewPi and a checker for the WiFi connection run as a systemd daemon. The following files must be placed in the /etc/systemd/system directory. The first is named brewpi.service and contains the following text:
In theory, you should now have a working BrewPi Remix running in single chamber mode. I will however leave you with some final thoughts.
If you are one of those folks who got here and followed these instructions out of some sense of increased security by not running my install scripts I’ve got bad news for you. You are still running scripts from some random person on the Internet and some start as root.
With thanks to the folks at Sandstorm.io, I’m going to paraphrase a few of their sentences:
Using curl|bash or curl|sudo bash certainly seems insecure. To anyone with a basic understanding of Unix, the construction makes it really obvious: This command will give the named web site direct access to your system, with the ability to do anything that you could do. This feels very wrong: We should be able to install software without giving the developers full access to our systems, right?
I would be the first to agree that software you install should not be automatically fully trusted. Unfortunately, however, traditional Unix software is always granted the full authority of the user who runs it (and in the case of a stock Raspbian OS this implies passwordless sudo). When you install software on Linux, no matter what package manager you use, you are giving that software permission to act as you. Most package managers will even execute scripts from the package at install time – as root. So in reality, although curl|bash looks scary, it’s really just laying bare the reality that applies to every popular package manager out there: anything you install can pwn you.
If you wish to install any software without giving it full access to your system, you must install it on a dedicated machine, VM, or (perhaps, with caveats) an isolated user account. In truth it’s more work than a lot of people want to deal with and in my experience people spend a lot more time complaining about it than actually taking steps to be secure.
The reality is this:
This is free software and you are invited to not run it if you are that concerned. I’d argue however that even the most paranoid among you have downloaded and run applications from the Internet with no additional security. At best, maybe you scanned it for viruses, but I’d be willing to bet a normal home user would not perform a source-code scan. If you are a person who really does a source-code scan, this is all written in bash, PHP, Python and the firmware in a proprietary C-ish language. It’s all there and all able to be downloaded freely and handled however you wish under the terms of the GNU General Public License.
This is intended to be run on dedicated hardware. A Raspberry Pi is really perfect for this and a Pi Zero W is about $20. There’s no reason to try to run this on some other rig on which you do other things that could be compromised by rogue code.
The last significant vector at risk here is the network to which the BrewPi machine is attached. If you have IoT devices, surely you have a separate wireless LAN segment for them? Put this there. Tom has a great article about IoT security. You can also choose to not have your BrewPi connected to your home network at all. Sure you lose some functionality, but you can always disconnect the network and just use it with a local keyboard, mouse and monitor.
I’m not making fun of people displaying a healthy dose of paranoia. At last count I am tracking 552 website credential pairs, all using unique highly complex passwords. Yes that’s right, I have over 500 passwords to keep track of. In addition I use two-factor whenever possible. Believe me when I say I am a fan of security. Sometimes though you gotta pick your fights and mitigate risk when you do.
One last word: As a fan of security I do have several ideas how to make this application more secure. I don’t have a schedule and nobody is paying for this so who knows what I’ll get done. Stay tuned though, surely the battle will be won in small skirmishes.
“What about some other scenario, when will you test that?” – Maybe never. This is not a commercial venture; chances are once I’m “done enough” making it work on the target system, I’ll be done for good. The original/current BrewPi is a far more capable system, with a wider adoption base, and excellent support. That’s probably a better choice for you if you want to venture from this path I’ve created for you.
“Do you plan to create/implement/merge {insert cool idea here} functionality?” – No I do not. I’m not a software developer by trade, and this is not a commercial venture so there’s probably little reason to implement something I’ll never use. To be embarrassingly and brutally honest, I hardly get a chance to even brew anymore. I started this initially to make it easier for a friend of mine to get going again after his Pi ate his SD card. I’ll repeat: The original/current BrewPi is a far more capable system, with a wider adoption base, and excellent support. That’s probably a better choice for you if you want expanded capabilities.
“Will you accept pull requests?” – Maybe. Here’s the honest truth however: Not being a software developer by trade means that working with typical software development tools in a collaborative environment like GitHub is new to me. I am probably doing this wrong/poorly and in a way that doesn’t easily allow such collaboration. If you’re willing to work with someone who does not have these skills in order that you may contribute your own work, it’s likely best to contact me directly before you start so we can work out the details to avoid frustration for both of us (mostly you.)
“What about older versions of the Pi or Raspbian Stretch, etc.?” – I’ve no reason to believe older versions will not work, but they’ve not been tested. In theory it should work fine, but at some point, on a platform like Raspberry Pi, you just need to say “flash a new card and get over it.” These are not desktop machines that accumulate “stuff” over the years. If you have a Pi that’s on it’s original SD card for more than a couple years you have a rare bird indeed. I’d be more than happy to discuss why it didn’t work if you run into an issue, it would be interesting I think, but it might not be something I choose to address.
