gadgets

A timely discovery

I have been interested in automated backups of computer data since the mid 90’s, when I had a very well-timed hard disk failure. By pure chance, I had been working on a script that would copy my “important files” from my hard disk to a 100MB “Zip Drive”. I finished my script after testing it several times, and then I went to bed. The next morning, I woke up to find that my hard disk had crashed. Fortunately, I had a very recent backup!

I have often marveled at how easy it would be to lose invaluable files in a single mishap… countless memories, photos, financial records and project work.  Backups are important.

BackupPC

When I worked at “the oven place” (TMIO), I was tasked with evaluating backup schemes for their factory and office PC’s. So I looked at several open source packages, with emphasis on being server-centric and automatic. That is, the backup server would decide when to make the backups, and the employees would never have to remember to do anything special. Any process that relies on a human to remember to kick it off is destined to be run once-a-year.

We ended up choosing “BackupPC“, which runs on a modest server with a large storage disk. It would wake up every so often and run through its list of clients and pick one to back up.

For several years, I ran BackupPC at home, too. At first, I ran it on a discarded PC. But later, I migrated to low-power fanless embedded boards.

Flashback

In 2013, I decided that BackupPC was taking too long to make backups. I would bring my laptop home from work and turn it on, and BackupPC would notice it and start backing it up. But the backups were taking so long that they would still be running when I was ready to leave for work the next morning!  I ran a few tests with rsync to see if the problem was with BackupPC or the file compression or their crazy idea of how “incremental backups” should work.  So I wrote what started out to be a speed test, and then a wrapper around “rsback”, and finally a very minimal python script that I named “Flashback“.  “Flash” because it’s fast.  My laptop backup, which was taking all night using BackupPC, usually completes in a half hour or less.

You can find Flashback on github.

The Pogo Plug v4

This week, I tried out a new hardware gadget called a Pogo Plug.  It is a very close cousin to the SheevaPlug, an embedded Linux board which I had been BackupPC and Flashback on.  What caught my attention about the Pogo Plug v4 was:

• It has two USB3 ports.
• It has gigabit ethernet.
• It was on sale for just $20.

The only bad part is that it only has 128MB of RAM… that’s only a quarter of what the SheevaPlug has.  But I am not really using the memory for anything.  I am just running rsync.

I did not spend any time using the stock firmware.  Instead, I immediate enabled SSH and then followed these instructions for installing Arch Linux on a USB stick, which I plugged into the top plug (the bootable USB2 one).  I plugged the 1-terabyte USB2 hard disk into the back of the Pogo Plug.

Then I installed Flashback and I modified the monitor script to take advantage of the three-color LED on the front (green for sleeping, yellow for backing up, red for error).

It’s been running for about a week now, and I think it has proven itself worthy.

I’d like to try it with a USB3 hard disk, and see if it’s any faster.

How many times have I gone outside in the morning, only to find that I had left my garage door open all night? Too many. I hate that uneasy feeling that I have just invited thieves into the garage for some easy pickin’s (truth be told, I’d be happy if they took some of that junk, but still).

For a long time, I had thought of rigging up a light upstairs that would come on whenever the garage door was open. That way, at night, it would be pretty obvious that I had left the door open. But I let that idea sit dormant for a long time.

Then I read an article in Make magazine (“12,000-Mile Universal Remote“, issue 30, page 66). In it, the author built a board called an “XBee Pulse I/O” that watched a door sensor, tapped the opener’s switch, and communicated with an XBee internet gateway. These talked to a cloud service called iDigi. This was not exactly what I wanted to do, but it pushed me in the direction I needed.

I decided that I wanted to build an Arduino board that would monitor my garage door. I wanted it to communicate with my home Linux server, “Bender”, which I consider to be sort of a digital butler, keeping track of stuff around the house and reminding me of stuff that I need to know.

PONDERING WIRELESS SOLUTIONS

For the next few weeks, I pondered how I would hook the Arduino board in the garage to Bender, which lives in the bonus room over the garage. I was not too fond of the idea of running a wire, even though the distance is very short. I scoured the internet for ZigBee boards, but soon decided that these were very pricey for what they did.

Inside the garage, I would need an “XBee” ZigBee radio module, which costs about $24~$40. But I would also need a controller board for another $10. This controller board acts as a front-end, providing a simple serial port to my project, and taking care of all of the ZigBee protocol stuff.

Then, on Bender’s end, I would need a similar XBee module ($24) and a USB adaptor ($20).

That’s a total of $78~$110, just for the wireless link!

Surely, dropping a Ben Franklin down for a home project is not such a big deal. But I was concerned that as my project grew, I might be adding many wireless links to it. And at $50 a pop, I figured it would be worthwhile to broaden my search a bit.

WHAT ABOUT BLUETOOTH?

I worked for Ericsson from 1998 until 2003, when they were first developing the Bluetooth standard. I remember reading presentations about the technology before they had come up with the Bluetooth name… internally they referred to it as “MC Link”, and occasionally, (my favorite) “wireless wire”! I knew that the goal for Bluetooth was to make these communication chips so low-power and so cheap that every device would include one… WORLD DOMINATION!

With that in mind, I wondered whether there were simple Bluetooth serial communication boards that would work with an Arduino. I found one, called the “BT2S” from Virtuabotix. It was only $15, and it looked pretty easy to use. AND… I would only need ONE on the garage monitor side, because I could use Bender’s existing Bluetooth interface!

I ordered two BT2S sticks from Virtuabotix. Later, I found another source for almost-identical boards. DealExtreme has the JY-MCU Arduino Bluetooth Wireless Serial Port Module for $8.60! (Be careful not to get the TTL version that looks very similar).

PUTTING IT TOGETHER – THE HARDWARE

I am not too fond of crawling up a ladder to reprogram my Arduino in my garage, so I decided to make the Arduino end of this project as simple and generic as possible.

The BT2S module plugs in to the Arduino’s serial port, and the program on the Arduino simply listens for serial commands and responds. I decided to implement three commands: read digital, write digital and read analog. That way, nothing would be hard-coded into the Arduino. Instead, all of the smarts would be in the client program that runs on Bender.

Schematic

Reed switch.

I plugged in a magnetic reed switch to one of the digital inputs, and an LED to a digital output. While I was at it, I put a light sensor on one of the analog inputs.

Then I hung it up on the garage door frame. I stuck a very strong hard drive magnet on the door so it would be close to the reed switch whenever the door was open.

TALKING TO IT VIA BLUETOOTH

Door, magnet, reed switch.

Bender is a Linux machine, and so I needed a Linux-based program that would open a Bluetooth serial connection to the Arduino and then send serial commands to it. I needed a mixture of shell commands to configure the Bluetooth connection and low-level communication to the serial port. So I chose Python.

Bluetooth is a complex protocol that supports a lot of different uses: real-time audio, serial communication, keyboard/mouse, dial-up networking, and more. We’re using a simple serial link, which they call “rfcomm”. In Linux, we establish the serial link using the rfcomm command. It makes a Bluetooth connection to the device and creates a serial port device named /dev/rfcomm0.

Once we have created a serial device, the python program simply reads and writes to that device just like any other file. I structured my program as a big loop with timers. Every so-many seconds, it sends a command to read the magnetic reed switch. It also sends commands to blink the LED, so I can tell from the garage that the python program is still running. When the reed switch response comes back, it writes the door status to a file. If I put that file in an area that is shared via my web server (/var/www/ or $HOME/public_html/), I can check on my door from any browser.

If the door state has changed since the last time it was read, the python program sends a push notification (like a text message) to my phone. This is another idea that I stole from the same issue of Make magazine (“You’ve Got (Snail) Mail“, page 76). This uses an iPhone app called “Prowl” and a web service that goes along with it.

COMPLETING THE LOOP

Sure, it’s cool to hear my phone “bling” when someone opens the door at home. But my original motivation was to be warned when I had left the door open.

Fortunately, that’s an easy job. I wrote a simple “cron” job that reads that status file at certain times of day (or night). If the door is open, it sends me another push notification saying “hey dummy, your garage door is still open!”.

Breadboard, with “Boarduino” and BT2S, sensors and LEDs

RESOURCES

Source code and other resources can be found on github.