Send Mail from your Raspberry Pi

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

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.

Screenshot of package configuration screen
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/ file if you need to.

Screenshot of a package configuration dialog
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.

To get an application password head to: and log in.

Screenshot of Google account options
Account security settings

Select “Security” from the list on the left.

Screenshot of Google account security options
Manage your application passwords

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.

Screenshot of app password manager
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.

Screenshot of new 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).


This line tells SASL that when it connects to the host 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.

sudo chmod u=rw,go= /etc/postfix/sasl/sasl_passwd.db

4. Configure Postfix

Now let’s finish up the configuration of Postfix. Run the following commands.

sudo cp /etc/postfix/ !#$.dist
sudo nano /etc/postfix/

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 = []: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).

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” If you see a failure message like “ping: 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[] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8 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.


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.)

Service Name SMS Email Suffix MMS Email Suffix
AT&T Mobility
Verizon Wireless
T-Mobile (same)
Sprint Corporation

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 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 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).

echo "Test" | sendmail

You should receive a text on your phone.

Screenshot of a text message

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.

Reply email
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.


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.

df --output=target,pcent /data/a /data/b | \
tail +2 | /usr/sbin/sendmail alert
A screenshot of text messages
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.

Reporting SSH Logins

I have the Pi set up to allow remote logins using two-factor authentication. I wrote a short article on how to do that, too.

Setting Up SSH and 2FA on a Raspberry PiLog in from anywhere using SSH and Google

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/

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!)

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}
ENDelsesendmail alert <<END
$(hostname) $(date): LOG OUT by ${PAM_USER} from ${PAM_RHOST}

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.

sudo nano -R /etc/pam.d/sshd

Let’s protect the file against changes.

sudo chmod go-w /etc/

Add the following lines at the end of the file.

# Notify on successful login / log out.
session optional /etc/

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.

Screenshot of text messages reporting login and 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.

Why do you guys insist on using Linux?

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.


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 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 | sudo bash

Entering one command downloads (curl) the file ( 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.


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.


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.

BrewPi on Bluetooth

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:

You can find it on Amazon here. Buy that and come back.

Hardware Setup

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 PinHC-05 Pin

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. 🙂

  1. 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)
  2. Plug in the USB to TTL Converter
  3. The light will come on for about a second, and then shut off
  4. 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”.

  1. Select the last tab which is “HC-05”.
  2. 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.
  3. Set Baud Rate to 38400, then click “Open”.
  4. 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.
  5. 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.
  6. 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 PinHC-05 Pin

If you are using the shield version 1.2, reportedly the RX/TX line up directly so connect as follows:

Shield PinHC-05 Pin

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”:

pi@brewpi:~ $ sudo bluetoothctl
[NEW] Controller XX:XX:XX:XX:XX:XX brewpi [default]

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:

[bluetooth] # agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful

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

Next you will “trust” the HC-05:

[bluetooth]# trust XX:XX:XX:XX:XX:XX
[CHG] Device XX:XX:XX:XX:XX:XX Trusted: yes
Changing XX:XX:XX:XX:XX:XX trust succeeded

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
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:

[bluetooth]# exit
Agent unregistered
[DEL] Controller XX:XX:XX:XX:XX:XX brewpi [default]
pi@brewpi:~ $

So, it’s paired and trusted but still not visible in the device list as you can see if you list it out:

pi@brewpi:~ $ ls -al /dev/rfc*
ls: cannot access '/dev/rfc*': No such file or directory

To add it to the device list, we need to bind it to a device with the following command:

pi@brewpi:~ $ sudo rfcomm bind 0 XX:XX:XX:XX:XX:XX 1 > /dev/null 2>&1 &
[1] 3345

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):

pi@brewpi:~ $ ls -al /dev/rfc*
crw-rw---- 1 root dialout 216, 0 Mar 16 13:31 /dev/rfcomm0
[1]+ Done sudo rfcomm bind 0 XX:XX:XX:XX:XX:XX 1 > /dev/null 2>&1
pi@brewpi:~ $

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:

sudo nano /etc/systemd/system/rfcomm0.service

Add the following information:


ExecStart=/usr/bin/rfcomm bind 0 XX:XX:XX:XX:XX:XX 1 > /dev/null 2>&1 &


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:

pi@brewpi:~ $ sudo chown root:root /etc/systemd/system/rfcomm0.service
pi@brewpi:~ $ sudo chmod 664 /etc/systemd/system/rfcomm0.service
pi@brewpi:~ $ sudo systemctl daemon-reload
pi@brewpi:~ $ sudo systemctl enable rfcomm0
Created symlink /etc/systemd/system/ → /etc/systemd/system/rfcomm0.service.
pi@brewpi:~ $

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.


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.

Raspberry Pi Wireless Connectivity

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 | sudo bash

If you wish to enable the reboot function, edit these lines:

# Reboot on failure

Add change to:

# Reboot on failure

After that change, reboot, or restart the daemon with the following command:

sudo systemctl restart wificheck

The git repository may be found here.