Feb 01, 2011 By Kyle Rankin
Find out whether I can port my beer fridge controller from a laptop to a Pogoplug without losing my temper.
In my August 2010 column, I wrote about how I used an old laptop, some spare X10 devices I had and a TEMPer USB thermometer to control my fridge so I could ferment beer in a nice, controlled environment. Since then, I've received a number of e-mail messages from Linux Journal readers talking about their own projects to create the perfect beer fridge. After reading about Arduino-powered fridges and other hardware-hacking solutions, I became jealous and began to think that my laptop solution, although simple, was overkill. My hardware-hacking skills aren't quite to Arduino levels yet, so I ultimately decided to look at other, lower-powered Linux devices I had around (it turns out I had quite a few) to see if I couldn't coax one of them into controlling my fridge.
The kind of device I needed had to meet a few criteria. One, it should be able to run Linux. Second, it ideally would have at least one USB port that I could use (with a hub if necessary) to connect my USB thermometer, and if it didn't have a serial port, also connect a USB serial adapter so I could use my X10 serial dongle. Sorry, Spykee robot, but my final choice was a pink Pogoplug (Figure 1). The Pogoplug is a nifty little Linux-powered appliance that allows you to connect your own USB hard drives and then provide that data to you wherever you are, as long as you have an Internet connection. Think of it somewhat like a personal Dropbox, except you have full control of the storage and data. There's also a good-size community around the Pogoplug that provides third-party applications and even a custom Linux distribution based on Arch Linux.
Figure 1. Pogoplug—Little, Pink, Different
The best things about the Pogoplug for my purposes were that it was small, low-powered, had a custom Linux distribution with package management, and most important, it had four USB ports. Once I decided to use it instead of my laptop, the next step was to get the Arch Linux-based Plugbox Linux installed on it. This distribution is hosted on www.plugapps.com, and the site provides all sorts of third-party applications and packages for Pogoplug, DockStar and SheevaPlug devices. I simply followed the install document for Plugbox Linux verbatim, so instead of reposting it here, just follow the steps atwww.plugapps.com/index.php5?title=PlugApps:Pogoplug_Setboot. Be sure to follow the advice about setting up openntpd; otherwise, Plugbox's time will be way off, and you'll get strange warnings and errors as you try to install and compile software.
Essentially, Plugbox Linux installs itself on an external USB drive that you provide and then sets up the bootloader so that if the drive is inserted, it will attempt to boot from it; otherwise, it will boot from the native Pogoplug firmware. This provides a simple, relatively low-risk way to modify the device to do what you want while still being able to go back to defaults. Although I might have been able to get the native Linux install to do what I wanted, Plugbox has simple package management using Arch Linux's pacman, so I also could go back to the standard Pogoplug firmware at any time. In my case, I used a spare 1GB thumbdrive for the OS, and that seemed to be plenty.
After the Plugbox installation completed, I was able to boot in to the environment and configure everything over SSH. Now, all I needed to do was repeat my steps to get the CPAN modules my TEMPer device needed, install bottlerocket, and I should be done. I guess I'm spoiled by all the packages available in Debian, but then again, I didn't expect bottlerocket to be packaged for this custom distribution. I figured I'd be able to get the CPAN modules I needed, but the real question was whether I could get bottlerocket to compile. Without it, this project would be over. It turns out it wasn't too difficult. I just used pacman to install my build environment and then downloaded and compiled bottlerocket like you would in the old days:
# pacman -S gcc make# wget http://www.linuxha.com/bottlerocket/bottlerocket-current.tar.gz# tar xvfz bottlerocket-current.tar.gz # cd bottlerocket-0.04c/# ./configure # make# make install
When I tested bottlerocket, I noticed something interesting. The USB-to-serial adapter I plugged in was detected and appeared to work; however, after I ran bottlerocket the first time, any subsequent execution would result in an error for /dev/ttyUSB0. I had to unload and reload that particular USB-to-serial module between each bottlerocket execution for it to work properly. I know from experience that not all USB-to-serial adapters are created equal and that some do a better job, for instance, with sending break signals to your console, so I figured this was just a case of a cheap serial adapter without full serial port support. Instead of just living with the kludge of reloading the module each time, I replaced this adapter with another one I had that I knew had excellent support for break signals and overall had better compatibility. With this new adapter, I was able to power my fridge on and off without issues.
Note: a Quick Rant about Pacman
I have to admit that Plugbox was my first foray into the Arch Linux distribution. I know a number of people who really like Arch, and I don't really have an opinion one way or the other about the distribution itself, but I wanted to say a few words about pacman. First, I love the name. Second, who came up with the command arguments? In my experience, capital letters in arguments always are reserved for when you run out of lowercase arguments (or alternatively, to do the opposite of what the lowercase argument does), and although sometimes arguments have no relation to the action you are performing, at least for most programs, the most commonly used actions are the ones with the intuitive arguments. For instance, I fully expected pacman to use -i to install a package or possibly to use a longhand --install. The -S argument it does use simply makes no sense (I know it stands for “Sync” but that's a long way from “install”), and the -Ss argument to search for packages that match a keyword makes even less sense. I know it takes only a second to get used to it, but I'd still argue there are a number of more intuitive letters to choose.
Because it was so easy to build bottlerocket, I assumed it would be a relative cakewalk to install all the Perl modules I needed using CPAN. For those of you who aren't Perl hackers, Perl provides a vast repository of extra modules on-line atwww.cpan.org. If there is a particular Perl module you need, you can use the cpan binary on your local system to pull down and build those modules for your system much like a modern package manager. I figured that even if Plugbox didn't include a lot of Perl modules, I would identify the modules I needed and install them one by one, like in my previous TEMPer column. The reality was that although Plugbox did include Perl and even included the cpan binary, it didn't include a lot of the necessary modules you need for CPAN actually to work.
Honestly, everything else about this project was simple once I got CPAN working, but this part of the process took the most time and effort, and it really reminded me of what Linux was like back in the day when you would find a cool project on Freshmeat, download the source and then spend the next two days tracking down all the dependencies. I finally found the magic list of packages and libraries I needed, and in this case, I had to install a few packages from Plugbox along with a manual module compilation:
# pacman -S perl-yaml perl-xml-libxml# pacman -S perl-text-query perl-text-diff perl-text-reform# wget http://search.cpan.org/CPAN/authors/id/R/RC/RCLAMP/cd Text-Glob-0.08 # per↪Text-Glob-0.08.tar.gz # tar xfvz Text-Glob-0.08.tar.gz # l Build.PL # perl Build test# perl Build install
From this point, I was able to get the cpan binary to function, and I could follow the installation steps I laid out in my previous column to finish the process (I was glad I had that nicely documented for myself). Afterward, all I had to do was edit my temper.pl script so that it referenced /dev/ttyUSB0 instead of a local serial port and created a file called /etc/cron.d/temper that contained the following data:
* * * * * /usr/local/sbin/temper.pl
After I restarted cron (/etc/rc.d/crond restart), I was able to check my logs and see that the script was, in fact, reading the temperature and controlling the fridge just like my laptop. In case you'd like to do something similar with your Pogoplug, Listing 1 is the current iteration of the script.
Now that I've had this running without issues for a few weeks, I do like how quiet and low-power the device is. Plus, it takes up less space on the top of my fridge. The only real drawback I've seen is that there is no screen on the device. On my laptop if I wanted to check the temperature, I just had to open the lid; now, I have to ssh in to the Pogoplug. Although I used a Pogoplug for this, I imagine you could translate these steps for a number of other small Linux devices that have USB ports, like the NSLU2—provided it included Perl and a gcc build environment. Now I can use my old laptop for nobler pursuits—like maybe some day powering my smoker.
No comments:
Post a Comment