It was inevitable. Back when the Raspberry Pi was announced, I knew I eventually would use one to power a beer fridge. If you have been following my column through the years, you know that three years ago (see my Hack and / column titled "Temper Temper" in the August 2010 issue), I set up a temperature controller for my beer fermenting fridge with an X10 serial controller to control the power to the fridge and a heating pad, an inexpensive TEMPer USB thermometer to take the fridge temperature, and a simple Perl script.
As described in the original article, everything was connected to a spare Debian laptop I had lying around, and the setup worked great. Every minute, my Perl script would launch, take the temperature and control the power to a heating pad at the bottom of the fridge or the fridge itself, depending on whether it needed to be warmer or cooler. A few months later (see my December 2010 Hack and / column "Working on My Temper"), I decided that the laptop was overkill for this use case, so I replaced it with a low-power Pogoplug NAS device that was modified to boot Plugbox Linux, an Arch derivative. The Pogoplug has been powering my beer fridge reliably ever since.
That brings us to today. I just happened to have a spare insulated
cabinet on the other side of the garage that I wanted to use as excess
fermentation capacity. Unfortunately, the cabinet is too far away from
the fridge for me to use the Pogoplug with an additional temperature
probe, so I had to work out a different solution. I happened to have a
spare Raspberry Pi lying around and realized it would be perfect for the
job. All I needed to do was buy a new TEMPer USB probe and copy over
my Perl script. The only big change I'd need was to have the script
back in to the Pogoplug so it could control the X10 devices (I have
only one X10 serial adapter).
Prepare the Raspberry Pi
I didn't really need anything fancy for this setup. In fact, Arduino fans who read this probably would say that even the Raspberry Pi is overkill for such a simple project. I decided to use the standard Raspbian "wheezy" Debian distribution. This procedure has been documented many times before, so I won't document it here. Because I was using a Debian-based release, I figured I even could follow the same steps from my original "Temper Temper" column.
New TEMPer Thermometers
The problem with cheap electronics is that sometimes the internals change without your knowing. Apparently, there are different USB thermometers all under the TEMPer name with the same packaging and overall look. Although I'm sure they all work with their included Windows software, it turns out that they need completely different software under Linux. Wouldn't you know it, the second TEMPer probe I bought turned out to be a different revision, so it requires a completely different set of software.
You can tell which TEMPer thermometer you have with
dmesg output looks like this:
input: PCsensor Temper as /devices/platform/orion-ehci.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input0 generic-usb 0003:1130:660C.0001: input: USB HID v1.10 Keyboard ↪[ PCsensor Temper] on usb-orion-ehci.0-1.1/input0 usb 1-1.3: new high speed USB device using orion-ehci and address 5 input: PCsensor Temper as /devices/platform/orion-ehci.0/usb1/1-1/1-1.1/1-1.1:1.1/input/input1 generic-usb 0003:1130:660C.0002: input: USB HID v1.10 Device ↪[ PCsensor Temper] on usb-orion-ehci.0-1.1/input1
and you see something like this in
$ lsusb Bus 001 Device 051: ID 1130:660c Tenx Technology, Inc.
you have the older version of the TEMPer probe, and you can follow the steps from my original "Temper Temper" column.
dmesg says this:
[ 3.213110] usb 1-1.3: new low-speed USB device number ↪4 using dwc_otg [ 3.339127] usb 1-1.3: New USB device found, ↪idVendor=0c45, idProduct=7401 [ 3.355218] usb 1-1.3: New USB device strings: ↪Mfr=1, Product=2, SerialNumber=0 [ 3.377771] usb 1-1.3: Product: TEMPerV1.2 [ 3.392684] usb 1-1.3: Manufacturer: RDing [ 3.420037] input: RDing TEMPerV1.2 as ↪/devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.0/input/input0 [ 3.436838] generic-usb 0003:0C45:7401.0001: input: ↪USB HID v1.10 Keyboard [RDing TEMPerV1.2] on usb-bcm2708_usb-1.3/input0 [ 3.465103] generic-usb 0003:0C45:7401.0002: hiddev0: ↪USB HID v1.10 Device [RDing TEMPerV1.2] on usb-bcm2708_usb-1.3/input1
$ lsusb Bus 001 Device 005: ID 0c45:7401 Microdia
then congratulations, you have the new TEMPer probe and will have to use completely different software.
The original software project to control these new-style TEMPer probes was at http://www.isp-sl.com/pcsensor-1.0.0.tgz, but right before I started writing this article, I got word from Philipp Adelt that he had updated that project recently to work with Python. The updated project is hosted on Github at https://github.com/padelt/pcsensor-temper, and the Python version is at https://github.com/padelt/temper-python and has additional features, such as multiple probe management and SNMP support. So to get started with this project, I first needed to install git and then install a few Python libraries to provide USB support:
$ sudo apt-get install git python-usb
(Note that the project page also tells you to install the python-setuptools package and the snmp-passpersist Python library, but as I'm not planning to use SNMP, I skipped that step.)
With git installed, I pulled down the latest release of temper-python:
$ git clone git://github.com/padelt/temper-python.git Cloning into 'temper-python'... remote: Counting objects: 17, done. remote: Compressing objects: 100% (13/13), done. remote: Total 17 (delta 4), reused 15 (delta 2) Receiving objects: 100% (17/17), 19.07 KiB, done. Resolving deltas: 100% (4/4), done.
The main Python program can be found under temper-python/src/temper.py, and the project also includes a sample udev rule you can copy to /etc/udev/rules.d if you want access to the TEMPer probe by a user other than root. I my case, I was fine with root-only access, so I left the udev rules alone.
If you install the python-usb libraries correctly, and you have the supported TEMPer device, you should see output like the following:
$ sudo ./temper-python/src/temper.py Found 1 devices Device #0: 17.6°C 63.7°F
Once you see this, you know the temperature probe is working. I don't like running system programs like this within a home directory, so I decided to copy it up to /usr/local/sbin:
$ sudo cp ./temper-python/src/temper.py /usr/local/sbin/
Now in my case, I wanted to act on this temperature output, and I realized that my old temper.pl wrapper script wasn't going to cut it. Although I certainly could just modify it a bit to work with the new output, I figured a Perl script that called a Python script was just asking for too much hate mail. Instead, I decided to write a new simple wrapper script in bash called /usr/local/sbin/temper:
#!/bin/bash TEMP_MIN="55" TEMP_MAX="65" LOGFILE='/var/log/temper.log' TIME=`date +"%b %d %T"` TEMPERATURE=`/usr/local/sbin/temper.py 2>/dev/null | ↪tail -n1 | cut -f4 -d ' ' | sed 's/.F$//'` if [[ $TEMPERATURE == "" ]]; then echo ERROR exit 1 fi # B6 = peltier cooler B7 = heater if [[ $TEMPERATURE < $(( $TEMP_MIN - 1 )) ]]; then ssh pogoplug "/usr/local/bin/br --port /dev/ttyUSB0 B7 ON" ssh pogoplug "/usr/local/bin/br --port /dev/ttyUSB0 B6 OFF" echo -e "$TIME\t$TEMPERATURE\tHON" >> $LOGFILE elif [[ $TEMPERATURE < $TEMP_MIN ]]; then ssh pogoplug "/usr/local/bin/br --port /dev/ttyUSB0 B6 OFF" ssh pogoplug "/usr/local/bin/br --port /dev/ttyUSB0 B7 OFF" echo -e "$TIME\t$TEMPERATURE\tOFF" >> $LOGFILE elif [[ $TEMPERATURE > $TEMP_MAX ]]; then ssh pogoplug "/usr/local/bin/br --port /dev/ttyUSB0 B6 ON" ssh pogoplug "/usr/local/bin/br --port /dev/ttyUSB0 B7 OFF" echo -e "$TIME\t$TEMPERATURE\tCON" >> $LOGFILE else echo -e "$TIME\t$TEMPERATURE\t" >> $LOGFILE fi
Although the logic of this script is similar to my old temper.pl, I just call
the temper.py script and use some pipes to pull out the temperature data I
need. In this case, I also have to
ssh back to my
machine named "pogoplug"
to run /usr/local/bin/br (the bottlerocket software that controls my
X10 devices). This means I need to run
ssh-keygen as the root user and
ssh-copy-id to copy my public key to the pogoplug host. If I
had wanted to replace my existing Pogoplug with a Raspberry Pi, I could
apt-get install bottlerocket, connect a USB-to-serial adapter with
my X10 serial controller and run the br commands directly.
The final step is set up a cronjob. For that, I just create a file in called /etc/cron.d/temper with these contents:
* * * * * root /usr/local/sbin/temper 2>/dev/null
With that file in place, every minute, my script will probe the temperature and control the power to extra X10 appliances I have in place via the Pogoplug. It seems like I keep replacing these temperature probe systems with simpler and cheaper Linux machines. I wonder what's next?
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide