posts tagged with the keyword ‘perl’


Sir Like-A-Lot

My latest project was sort of a failure, but I’m going to post about it anyway, because such things are important.

For a recent event I wanted to create a unique way for people to LIKE something, and get a reward for it, so I grabbed a Raspberry Pi and got to work. The idea was pretty simple, a full screen display showing the number of Facebook likes, with the URL for people to visit the page (on their mobile devices) and like it. The display would then update in “near” real-time (Well, every 10 seconds) and there would also be a surprise…

Step #1 is always configuring the Raspberry Pi. I installed Raspbian, had it set to boot to the desktop, and installed the packages I needed, mainly Apache and Chromium, since I’d be using a local web server and web browser for the display.

Getting the Raspberry Pi to work as a kiosk display was next. I didn’t want any menus or OS parts showing, so I used Chromium running in kiosk mode. My /etc/xdg/lxsession/LXDE/autostart file looked like this:

# config to launch Chromium in kiosk mode and load our application
@xset s off
@xset -dpms
@xset s noblank
@chromium --kiosk --incognito

We got rid of the part that lets a screensaver run, and added in the bits to fire up Chromium in full-screen kiosk mode. (Oh, one note about Kiosk mode, it does not hide the mouse pointer, but we’ll deal with that later.)


The results on the screen looked like this. Full screen, no browser or OS bits showing. I like this solution as it can be used for pretty much anything you can code up as a web page.

The display is set to refresh every 10 seconds, so it’s pretty up-to-date, and you’re really only limited by what you can display in a browser (Chromium) running on Linux (on a Raspberry Pi, in this case.)

As for the code, it’s less than 50 lines of Perl running as a CGI, and about a dozen lines of HTML in an HTML::Template file. There’s also a little CSS and an image.

Speaking of the CSS, it was the solution to hiding the mouse pointer for Chromium running in kiosk mode. I just added this bit:

 * using CSS to hide the pointer
* { cursor: none !important }

For an informational kiosk you just want people to look at and not have to interact with using a mouse or keyboard, this solution works well.


You might be saying “Hey! How do you get the number of likes!?” Well, you just ask JSON, or to be more precise. Facebook Graph API data holds the key, you just need the value.

Oh, there was one more really fun bit! When someone liked the page and the page refreshed and the number increased, you’d hear applause!

The original idea was to just have the CGI do a system call to play the file using aplay. That did not work. I also tried mpg321 and that didn’t work. In the end I went the other way around and added… another Perl script! There’s a cron job that runs on startup, which launches a Perl script, which loops forever and looks at the counter file that the CGI uses. Every time the counter file changes (due to the CGI updating the number) the Perl script uses aplay to play the applause file.

The end result is pretty good. A person sees the display, goes to Facebook, likes the page, and within 10 seconds the display updates and you hear some applause!

I planned on making a sign or adding some text to entice people take action and get a “reward”. And of course the URL isn’t as helpful on a mobile device where you probably use an app instead of a browser, but this is all a good start.

Now, I mentioned a failure, so I should explain that part. For anything like this, where it needs to run for hours reliably and not just be a quick technology demo, you need some burn-in time. I had this running for a week with no issue. The first issue that came up was, what to do if you lose the Internet connection. (Hey, we use Time Warner, it happens!) You really don’t want to see a default Apache 500 error page, so the error page looked just like the main page, but with a message that said ‘Please stand by…”. That 500 page was set to redirect to the main page after 10 seconds, which would deal with occasional Internet or network outage situations. Since we were also using a WiFi connection with the Raspberry Pi, there’s always the chance of losing the WiFi connection. This didn’t seem to happen much, but it’s something you may need to deal with.

I also set Apache to not do any logging, as there’s really nothing valuable gained from logging after you’ve got everything running. It also helps to write less data to the SD card that holds the system because… corruption.

Oh yes, corruption! Every now and then I would reboot the system to make sure it would start up properly. It almost always did. Except when it didn’t. Once the Pi booted and there was a warning that the file system needed repair, so I repaired it, and all seemed well. I tested again for another week, and things seemed good. But then…

The day of the event, I had to move the system into place, and when I did that, and started it up, Linux would not boot. Even after 13 years I am still not enough of a Linux expert to fix every problem it throws at me, and I was stuck, and had a dozen other things to do, so it was dead.

I did the dozen other things and then ended up reinstalling Raspbian and trying to quickly reconfigure it, and get all my files in place, and got everything working except the audio… and the WiFi. There are a few tricks to getting audio working properly on the Raspberry Pi. I eventually got it working, but it was too late to deploy it. Oh well…

So next time, I will have a BACKUP SD card ready to put in place when the first one destroys itself. Or maybe I’ll just build two complete Raspberry Pi systems. Backups are good. Backups are good. Backups are good.

But don’t worry, I’ll take all the successful bits of this project and re-implement it in some other way in the future.



Here’s my CheerLight 2012 device, which I call the CheerLCD! And what is CheerLights you say?

CheerLights is an ioBridge Labs project that allows people’s lights all across the world to synchronize, stay linked based on social networking trends. It’s a way to connect physical things with social networking experiences and spread cheer at the same time.

Much like last year, I’ve opted for a small desktop display—a USB-powered computer peripheral—rather than some giant string of multicolored lights…


With the combined power of 3D printing, affordable electronics, and the duct tape of programming languages that is Perl, we’ve developed a device that informs you of what color the CheerLights around the globe are, not only with color, but with words!

(Though we’ve not yet done extensive testing, the text should be legible even by those suffering from color blindness. Accessibility, FTW!)


The CheerLCD consists of a USB + Serial Backpack Kit and LCD Display from our friends at Adafruit Industries. But you can’t just have a display without some sort of thingy to display the display properly… enter the 3D Printer!


The CheerTree was designed specifically to hold the LCD Display. I utilized Inkscape for the design of the front plate, and then brought that shape into OpenSCAD to add the base and create an STL file for printing. (It ended up warping a bit but that just adds to the charm and aesthetic of the overall device.)

I know what you’re saying, “This is all well and good… but we need to see the CheerLCD in action!” As you wish, my friends… as you wish.

There’s some code over on github/CheerLCD, and some files on Thingiverse for the CheerTree.

Enjoy the Holiday Cheer!


Temperature and Humidity

I’m always annoyed with myself when I don’t publish my code, so this is a follow-up to my Logging the temperature and humidity post.

This whole thing is definitely a work in progress. The hardware has exposed wires, and the software is all just cobbled together pieces. Making something that works is much different than making something that will continue to work, and work properly, and efficiently. Making something that works is a first step. It’s an important step, but it’s only the first step. So let’s begin!

I started with the example from Adafruit over on GitHub and about the only changes I made was to the format output of the data.

// Example testing sketch for various DHT humidity/temperature sensors
// Written by ladyada, public domain

#include "DHT.h"
#define DHTPIN 2     // what pin we're connected to
#define DHTTYPE DHT22   // DHT 22  (AM2302)


void setup() {

void loop() {
  int h = dht.readHumidity();
  int t = dht.readTemperature();

  // check if returns are valid, if they are NaN (not a number) then something went wrong!
  if (isnan(t) || isnan(h)) {
    Serial.println("Failed to read from DHT");
  } else {
    int temperatureF = (t * 9 / 5) + 32.5;

So this outputs the value for the humidity, then a tab, then the value for the temperature, and then a line return. Oh, I did change the code to output the temperature in Fahrenheit instead of Celcius. If we get a bad value, it’ll print “Failed to read from DHT” though I’ve yet to see that in the log files, I should probably take it out. Also, the Arduino just streams data at a fast rate, much faster than I need. I typically put the sleep functions (to limit the amount of data logged) in my reading code which runs on the computer. I think this is the right way to go, but if you have other ideas, please let me know.

Here’s a fairly simple Processing sketch that will read the data coming in from the Arduino. (Obviously you need the Arduino connected to the computer via USB.)

import processing.serial.*;

PrintWriter output;

Serial myPort;    // The serial port: 
PFont myFont;     // The display font: 
String inString;  // Input string from serial port: 
int lf = 10;      // ASCII linefeed 

void setup () {
  // set the window size:
  myPort = new Serial(this, Serial.list()[0], 9600);
  // don't generate a serialEvent() unless you get a newline character:
  output = createWriter("output.txt");

void draw () {
  // everything happens in the serialEvent()

void serialEvent (Serial myPort) {
  // get the ASCII string:
  String inString = myPort.readStringUntil('\n');
    String[] words = split(inString, '\t');
    String humid = words[0];
    String tempe = words[1];
    text("   Humidity: " + humid, 40,90);
    text("Temperature: " + tempe, 40,160);

   output.printf("%d-%02d-%02d %02d:%02d:%02d\t%s", year(), month(), day(), hour(), minute(), second(), inString); // Write to the file
   output.flush(); // flush output

Besides displaying a small window with the humidity and temperature (seen at the top of this post) it will also log the data to a file named output.txt

Processing Output

2011-07-25 19:09:14     44      91
2011-07-25 19:09:14     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:15     44      91
2011-07-25 19:09:16     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:17     44      91
2011-07-25 19:09:18     44      91
2011-07-25 19:09:18     44      91

This is pretty terrible, as we’re getting way too much data. I should probably add some delay into the Processing sketch, as it’s creating a log file line much faster than the sensor can even output data! This will result in large log files and is just wasteful. If all I wanted was the window showing the current temperature and humidity, I’d probably just delete the logging part of the sketch. Add that to the TODO list. Anyway, it works, and as a proof of concept, it’s a start.

Here’s the Perl code I was using:


use Device::SerialPort;
use IO::Handle; FILE->autoflush(1);
my $port = Device::SerialPort->new("/dev/tty.usbmodemfd411");


my $fileout = './templight.log';
my $filerec = './templight-recent.log';

open (FILE, ">>$fileout") or die ("Ooops! Could not open $fileout: $!");

while () {
    # Poll to see if any data is coming in
    my $char = $port->lookfor();

    # If we get data, then print it
    if ($char) {
	$time = localtime(time);
	if (length($char) > 1) {

		my $str = ($time . "\t" . $char . "\n");
		print FILE $str;

		open (FREC, ">$filerec") or die ("Ooops! Could not open $filerec: $!");
		print FREC $str;
		close (FREC);
    # Uncomment the following lines, for slower reading, 
    # but lower CPU usage, and to avoid 
    # buffer overflow due to sleep function. 

    sleep (10);
close (FILE);

The logging here is a little better than the Processing sketch, at least we add some delay with that sleep at the bottom so our log files won’t be quite as large. We’re saving to two files, templight.log and templight-recent.log. The second one just saves the current data, this just enables us to grab the data from that file and do something else with it, like… send it to Twitter or something.

Perl Output

Tue Jul 26 04:30:39 2011        46      89
Tue Jul 26 04:30:49 2011        46      89
Tue Jul 26 04:30:59 2011        46      89
Tue Jul 26 04:31:09 2011        46      89
Tue Jul 26 04:31:19 2011        46      89
Tue Jul 26 04:31:29 2011        46      89
Tue Jul 26 04:31:39 2011        46      89
Tue Jul 26 04:31:49 2011        46      89
Tue Jul 26 04:31:59 2011        46      89

So our output from Perl looks similar, though we have much less data (but still plenty of data) and the date format is a little different. (Chalk that up to laziness.) Oh, the Perl code also has the serial port hardcoded to /dev/tty.usbmodemfd411, which is lame, and I do have code somewhere to grab the serial port dynamically, but I didn’t implement it yet.

Whew! It feels so liberating to publish all that terrible code… (I mean my own code, not Adafruit’s!) Now I feel the need to start re-writing it and making it less terrible.



I needed this script last week… See, our ISP had a bit of downtime, roughly 7 hours of downtime actually, but throughout the day there were some periods where our connection would be up for a few minutes before it went down again.


use Net::Ping;

$p = Net::Ping->new("tcp", 2);
$p->{port_num} = getservbyname("http", "tcp");
$host = '';

while (1) {
if ($p->ping($host)) {
print "Internet is up!\n";
# the next two lines will only be useful on osx
$cmd = 'say -v Victoria "Internet is up"';
system ($cmd);
else {
print "...\n";

To alert me to these few golden minutes of Internet connectivity I whipped up this script. It keeps trying to reach some server (in this example I’m using the highly-available waiting just 5 seconds between each check, and if it reaches the server (meaning our Internet connection is up) it prints “Internet is up!” and on Mac OS X it also says “Internet is up.” I made it say that so I could keep staring at what I was working on and be alerted audibly when the connection returned.

I was tempted to run this on our Mac jukebox so it would announce to the entire office when the connection was up, but by that time things seemed back to normal.

Obviously you could reverse this code to check if a server is up instead of down, and in fact one of my monitoring systems does just that. If you’re ever at the 2XL Networks office and hear “Attention! The server is not responding!” being yelled from one of the Macs… you know there’s a problem.



Back when I revealed the Twitter Monkey I had a dark secret… I got the Perl script to work, but just barely, and I really didn’t grok exactly how the code worked. I was just thankful MCQN Ltd. published the Alertuino code for me to get started.

I’m happy to say that I’ve made some good progress in getting Perl and the Arduino to talk to each other, and if you keep reading, you’ll see what I’ve got so far.

I’ll be using a ShiftBrite from macetech for this example. You can buy direct for $4.99, get them from Adafruit for $5.00 or use your #freeday money to get one from Sparkfun.


To connect the ShiftBrite, you just run it’s GND to the GND on the Arduino, the V+ to the 5V on the Arduino, and the run DI, LI, CI, EI to digital pins 10, 11, 12, 13 respectively, on the Arduino. Just 6 wires… pretty simple.

Once again, I stand on the shoulders of others… a hacker named Ashley Hughes wrote a post titled ShiftBrites and the Arduino and provided a library named shiftbritehughesyarduino. Grab it and drop it in your Arduino/libraries folder before we get started.

The library makes it pretty easy to send a color to the ShiftBrite using a command like this:


Where the colors are in R,G,B value. Though the scale is not 0-255, or 0-100, but 0-1023. I’m not great at math, so I’m going to use the 0-100 scale and just multiply by 10. So for the line above we’d be sending a RED value of 200, a GREEN value of 400, and a BLUE value of 600.

Here’s the code for the Arduino:

 * ShiftBrite.pde

#include "HughesyShiftBrite.h";

HughesyShiftBrite sb;

void setup() {
  sb = HughesyShiftBrite(10,11,12,13);

void loop() {

  int input =;

  switch (input) {
  case 48:
  case 49:
  case 50:
  case 51:
  case 52:
  case 53:
  case 54:
  case 55:
  case 56:
  case 57:

See all those “case” commands followed by numbers? They are looking for the ASCII code being sent from the serial port. Don’t have an ASCII chart handy? Look at this simple one and you’ll see that the decimal value for 0 is 48, for 1 is 49, etc. So our case statements are looking for anything between 0 and 9, which is a nice scale to use.

OK, if you’ve uploaded the code, you should see the ShiftBrite lit up, since the initialization sent this:


The code on the Arduino is now listening to the serial port waiting for some input. The input should be a number between 0 and 9. We should probably send it some numbers… that’s where Perl comes in:


use Device::SerialPort;

my $port = Device::SerialPort->new("/dev/tty.usbmodem1d21");


for ($i = 0; $i <= 9; $i++) {
	print $i . "\n";


This is the shortest, simplest example I’ve got. You’ll obviously need the Device::SerialPort module installed. If you’ve written anything in Perl (or other languages) this should make some sense. We’re connecting to the serial port (/dev/tty.usbmodem1d21) and sending characters (0 through 9) to it, as well as printing them to the console so you can see them.

When you run the Perl script you should see the ShiftBrite light up and change about once per second, cycling through various levels of blue, green, and red.

Note: We got the port /dev/tty.usbmodem1d21 from the Arduino IDE (though I’ll show you another way to get it) and the sleep command is in there to give things time to initialize. I’ve found that without it, the serial port communication may miss the first commands.

ShiftBrite: Red, Green, Blue

Gotchas: The serial port may change. Mine is ‘/dev/tty.usbmodem1d21′ but it will be different on different machines, and may even change after a reboot. We’ll have a fix for that next time. The other gotcha is that when the Perl script is running, it’s using the serial port, so if you try to upload a new sketch to the Arduino, you will get an error. Since this script only runs for about 13 seconds, you probably won’t hit that problem here… for scripts that loop, you probably will.

I hope that wasn’t too complex. In theory, you could write the Perl part using Ruby, Python, or any scripting language that can do serial communications. In the future I’d like to try to use seriality to see if I can do it via HTML/JavaScript.

In a future installment I’ll have a complete project using all the bits we just covered…. stay tuned!

See Also: Arduino + ShiftBrite Light Organ

« Older Entries |

buy the button:

Buy The Button

recently at:

top recent artists: