Category Archives: chumby

“Ultimate” Arduino Doorbell – part 2 (Software)

As mentioned in the previous post about my arduino doorbell I wanted to get the doorbell and my Chumby talking.

As the Chumby runs Linux, is on the network and is able to run a recent version of Python (2.6) it seemed like it would be pretty easy to get it to send Growl notifications to the local network.

This did indeed prove fairly easy and involved three main activities:

  • Listening to the serial port for the doorbell to ring
  • Using Bonjour (formally Rendezvous)/Zeroconf to find computers on the network
  • Sending network Growl notifications to those computers

Getting Python and PySerial running on the Chumby is pretty easy. The Chumby simply listens for the doorbell to send the string ‘DING DONG’ and can then react as needed.

def listen_on_serial_port(port, network):
    ser = serial.Serial(port, 9600, timeout=1)
        while True:
            line = ser.readline()
            if line is not None:
                line = line.strip()
            if line == 'DING DONG':
        if ser:

port is the string representing the serial port (e.g. /dev/ttyUSB0). network is an object that handles the network notifications (see below).

The network object (an instance of Network) has two jobs. Firstly to find computers on the network (using PicoRendezvous – now called PicoBonjour) and secondly to send network growl notifications to those computers.

A background thread periodically calls Network.find, which uses multicast DNS (Bonjour/Zeroconf) to find the IP addresses of computers to notify:

class Network(object):
    title = 'Ding-Dong'
    description = 'Someone is at the door'
    password = None
    def __init__(self):
        self.growl_ips = []
        self.gntp_ips = []

    def _rendezvous(self, service):
        pr = PicoRendezvous()
        pr.replies = []
        return pr.query(service)
    def find(self):
        self.growl_ips = self._rendezvous('_growl._tcp.local.')
        self.gntp_ips  = self._rendezvous('_gntp._tcp.local.')
        def start(self):
        import threading
        t = threading.Thread(target=self._run)
    def _run(self):
        while True:

_growl._tcp.local. are computers that can handle Growl UDP packets and _gntp._tcp.local. those that can handle the newer GNTP protocol. Currently the former will be Mac OS X computers (running Growl) and the latter Windows computers (running Growl for Windows).

I had to tweak PicoRendezvous slightly to work round a bug on the Chumby version of Python, where socket.gethostname was returning the string '(None)', but otherwise this worked ok.

When the doorbell activates netgrowl is used to send Growl UDP packets to the IP addresses in growl_ips and the Python gntp library to notify those IP addresses in gntp_ips (but not those duplicated in growl_ips). For some reason my Macbook was appearing in both lists of IP addresses, so I made sure that the growl_ips took precedence.

    def send_growl_notification(self):
        growl_ips = self.growl_ips
        reg = GrowlRegistrationPacket(password=self.password)
        notify = GrowlNotificationPacket(title=self.title,
                    sticky=True, password=self.password)
        for ip in growl_ips:
            addr = (ip, GROWL_UDP_PORT)
            s = socket(AF_INET, SOCK_DGRAM)
            s.sendto(reg.payload(), addr)
            s.sendto(notify.payload(), addr)

    def send_gntp_notification(self):
        growl_ips = self.growl_ips
        gntp_ips  = self.gntp_ips
        # don't send to gntp if we can use growl
        gntp_ips = [ip for ip in gntp_ips if (ip not in growl_ips)]
        for ip in gntp_ips:
            growl = GrowlNotifier(
                applicationName = 'Doorbell',
                notifications = ['doorbell'],
                defaultNotifications = ['doorbell'],
                hostname = ip,
                password = self.password,
            result = growl.register()
            if not result:
            result = growl.notify(
                noteType = 'doorbell',
                title = self.title,
                description = self.description,
                sticky = True,

    def send_notification(self):
        send notification over the network

The code is pretty simple and will need some more tweaking. The notification has failed for some reason a couple of times, but does usually seem to work. I’ll need to start logging the doorbell activity to see what’s going on, but I suspect the Bonjour/Zeroconf is sometimes finding no computers. If so I’ll want to keep the previous found addresses hanging around for a little longer – just in case it’s a temporary glitch.

You can see the full code in my doorbell repository.

Chumby to Arduino communication using PySerial

So here are a few notes on getting a Chumby to talk to an Arduino using PySerial (and Python). It’s pretty easy, but I’ll document it to make it obvious. As the Chumby is sometimes a bit slow with a few of these steps, it’s good to know it will work in the end.

First you’ll want Python on the Chumby. At the time the latest version already compiled for the Chumby is Python 2.6, so it’s pretty up-to-date.

Once you’ve got Python installed and on a USB stick you’ll also want to download PySerial – I picked the latest version PySerial-2.5-rc2.

With PySerial expanded and on the USB stick (alongside Python) you’ll want to put the USB stick in the Chumby and connect to it via SSH.

Change to the directory for the USB stick (e.g. cd /mnt/usb).

You should see (at least) two directories, one for Python and one for PySerial:

chumby:/mnt/usb-EC5C-3D0A# ls -l
drwxr-xr-x    6 root     root         4096 Jun 26 21:15 pyserial-2.5-rc2
drwxrwxrwx    4 root     root         4096 Jan 10 13:51 python2.6-chumby

You’re first instinct may be to try and install PySerial via the usual call to python install. However this appears not to work.

All is not lost though – just manually copy the relevant directory (serial) from PySerial to the python site-packages directory, e.g.:

cp -r pyserial-2.5-rc2/serial python2.6-chumby/lib/python2.6/site-packages/

Know to check that’s worked open a python prompt and try to import the serial library:

chumby:/mnt/usb-EC5C-3D0A# python2.6-chumby/bin/python
Python 2.6.2 (r262:71600, May 23 2009, 22:28:43) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial

If you don’t see any errors (as above) then everything has installed ok.

Next step is to try out connecting an Arduino.

So first off you’ll want to ensure the Arduino has a program that can read from the serial port – to show that everything is working ok. In my case I picked my Morse Code program. This will read bytes from the serial port and toggle the built-in LED (on pin 13), so it’s handy for verifying the serial port is working.

So now you have a program loaded on the Arduino, connect it to the Chumby. The Arduino should get enough power from the Chumby to start up ok.

You need to work out which serial port the Arduino is using on the Chumby. List the tty’s in /dev and pick the most likely looking one (should have USB in it’s name):

chumby:/mnt/usb-EC5C-3D0A# ls /dev/tty*
/dev/tty      /dev/ttyS00   /dev/ttyS02   /dev/ttyS1    /dev/ttyS3
/dev/ttyS0    /dev/ttyS01   /dev/ttyS03   /dev/ttyS2    /dev/ttyUSB0

On my Chumby the serial port was /dev/ttyUSB0.

Now open up a python prompt again and try talking to the Arduino. You’ll need to configure the baud-rate of the serial port to match the program on the Chumby. In my case this was 9600.

chumby:/mnt/usb-EC5C-3D0A# python2.6-chumby/bin/python
Python 2.6.2 (r262:71600, May 23 2009, 22:28:43) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
>>> ser = serial.Serial('/dev/ttyUSB0', 9600, timeout=1)   
>>> ser.write('sos')

If you are using the same morse code program you should see the LED blink out ‘DOT-DOT-DOT DASH-DASH-DASH DOT-DOT-DOT’ – confirming that the serial port works.

This is really quite handy, as the Chumby is a small low-power Linux server. Coupled with Python this means it’s really easy to get any Arduino based project online, without needing a “normal” computer constantly running. Not quite as self-contained as using an Ethernet Shield, but the Chumby is fairly small, so it and an Arduino will easily sit on a window ledge (for example).

Chumby Podcast Client Source Code

Ok so I blogged about a podcatcher/podcast client for the Chumby quite a while ago (August 2008 to be precise). At the time I said I’d tidy things up and release the source code etc. Well that didn’t quite happen, but I figured I might as well release the source code. So seeing as I’ve been using git a lot lately and github is easy to use I thought that’d I’d best just put online what I had.

So you can now find the hybrid Python, Javascript and Flash Chumby postcast client I dubbed chumbycast, on github. I’m providing the code just for the curious – I’ve had at least one request for it, but I’m not really going to detail too much of how it works. Though some of this is outlined in the original post where I mentioned the project.

I am tempted to revive this project a bit, but probably by trying a different approach. I mostly gave up on this as I was creating a UI on the Chumby in Flash and my Flash skills aren’t exactly great, plus I was trying to use mtasc which hampered things further. Which is not to belittle mtasc – it’s just with limited time and no previous Flash experience I wasn’t exactly helping myself by not using some nice friendly Flash IDE.

I’ve since realised that if I ditched the Flash UI I could probably get quite a bit done. The Python httpserver side of things was pretty easy. So if I focussed on that I would then have a few of ways of providing a UI by hijacking existing functionality on the Chumby.

  • The Chumby runs a httpserver on port 8080 when an ipod is plugged in, which the UI uses to access playlists etc. I could mimic this approach and effectively make the podcast client look like an iPod as far as the Chumby’s UI was concerned. By plugging in a USB stick loaded up with the podcast client everything would behave the same as if you had plugged in an iPod.
  • It’s possible to create playlist files and edit the “My Streams” section programmatically. Each podcast subscribed to would create a matching pls or m3u file and be added to the “My Streams” section.
  • Create a javascript/web UI for controlling the playback and subscriptions to podcasts and other podcast management tasks (like removing old files, manually downloading older episodes etc) from another computer. Possibly adding bonjour/zero-conf support so the Chumby can be browsed to easily

I would need to see whether those first two could be made to work for my purpose, but it would make sense to just use the existing UI on the Chumby – rather than creating a new one. The existing chumbycast code already provides a javascript/web UI for controlling the playback on the Chumby. This was originally done so I could remote control the chumby, but also so that I could easily create and debug an API for the Flash UI to use.

The other major missing feature is allowing the podcasts to be paused part way through. The current client does not support this, as the audio files are streamed and not downloaded. So that would be the first change to make. Now that I’ve dug out the code maybe I’ll be inspired to play around some more. I’ve also been listening to a lot more podcasts (thanks to Huffduffer) so it might happen yet.

Chumby podcatcher

Here’s a video of my Chumby podcatcher (podcasting client) in action:

And a couple of photos:

Chumby USB stick for podcatcher Chumby Podcatcher

Just finished getting a UI working on the Chumby. Last week I had the basic http server running in the Chumby and I could browse to it from my laptop and control it that way. Today I managed to get a simple flash widget written that interacts with that server, so a laptop isn’t needed.

The http server is written in Python (see here for info on running Python on the chumby). It has the job of downloading the feeds and interacting with the audio server on the chumby (called btplay). It’s all pretty standard, except that the version of Python I was using didn’t have BaseHTTPServer. This meant I had to roll my own (thankfully pretty easy) using the SocketServer module.

The UI is written in flash (using swfmill and MTASC) and talks to the server to find out about available episodes and to stop/start the audio.

Once I’ve used it for a bit and made sure it’s ready for use I’ll release it and the code behind it. Hopefully other people will find it useful. I know for me this has been one feature that I wish the Chumby already supported. That’s the great thing about the Chumby though – if you want a feature bad enough you can just get in there and write it yourself!

I should also be talking about this app at the next £5app (which should be late September).

A Second Chumby Widget

I finally had a chance to do some more Actionscript coding for the Chumby again. The last widget I did was the bare minimum to get going and this one is only a little more advanced. In particular it’s a simple analogue clock. All it does is show the current time, nothing more, but it does involve a few more “moving parts” than were involved in the “Hello World” widget from last time.

So to start off with here’s the scaled down scan I used for the clock face and hands:

I cut out the face and hands and put them into separate files (see .tar.gz below) for using in the Actionscript. All images were 24bit PNGs with variable alpha transparency, so that the edges look nice and smooth on the Chumby screen (which is relatively low resolution).

The Actionscript ( is very simple and looks like this:

class ChumbyClock extends MovieClip {
	var hourHand:MovieClip;
	var minHand:MovieClip;
	var secHand:MovieClip;
	function onLoad() {
		this.hourHand = loadHand('hour_hand');
		this.minHand  = loadHand('minute_hand');
		this.secHand  = loadHand('second_hand');
	function loadHand(hand_id:String) {
		var clip = this.createEmptyMovieClip("clip", this.getNextHighestDepth());
		clip._x = 160;
		clip._y = 120;
		// load image an shift it to be in 12 o'clock position
		// with 0,0 as middle of bottom of image
		var hand = clip.attachMovie(hand_id, 'hand', clip.getNextHighestDepth());
		hand._x = -hand._width/2;
		hand._y = -hand._height + (hand._width/2);
		return clip;
	function toDegrees(val:Number, range:Number) {
		return (360*(val % range))/range;
	function onEnterFrame() {
		var now:Date = new Date();
		var sec:Number = now.getSeconds();
		secHand._rotation = toDegrees(sec, 60);
		var min:Number = now.getMinutes();
		minHand._rotation = toDegrees(min, 60);
		// let hour hand move a little bit with min hand
		var hourWithMin:Number = now.getHours() + min/60.0;
		hourHand._rotation = toDegrees(hourWithMin, 12);


All this does is create three movies which contain the hand images, placed so they are in the 12 O’Clock position. At each timestep (onEnterFrame) the current time is queried and the hand rotations are updated. The second and minute hands are just rotated in proportion with the relevant values. The hour hand is also slightly rotated with the current minute. As we get nearer the end of the hour, the hour hand moves nearer to the next hour. Much as you’d expected for a real clock. That’s it. I did play around with having smoother animation for the hands, but it looked a bit eery.

To tie the Actionscript and images together there is an xml file (app.xml) used by swfmill:

<?xml version="1.0" encoding="utf-8" ?>
<movie width="320" height="240" framerate="12">
  <background color="#ffffff"/>
  <clip import="build/classes.swf" />
      <clip id="face"        import="images/hand_drawn/face.png" />
      <clip id="hour_hand"   import="images/hand_drawn/hour_hand.png"  />
      <clip id="minute_hand" import="images/hand_drawn/minute_hand.png"/>
      <clip id="second_hand" import="images/hand_drawn/second_hand.png"/>
      <clip id="app" class="ChumbyClock" />

    <place id="face" name="clockFace" depth="0" />
    <place id="app" name="myApp" depth="1" />

This will allow us to embed the PNGs in the generated SWF file and reference them from the Actionscript. In addition the clock face image is placed statically behind the main movie of the hands.

These files are then run through a build script to generate the SWF:

~/bin/mtasc-1.12-osx/mtasc -swf build/classes.swf -header 320:240:12
~/bin/swfmill-0.2.12-macosx/swfmill simple app.xml chumbyclock.swf

Here’s the generated SWF:

To test this on the Chumby I put the SWF on a memory stick along with this debugchumby script:

chumbyflashplayer.x -i /mnt/usb/chumbyclock.swf

Then when the Chumby is rebooted with the memory stick in the clock displays and all is good.

So there you go that’s a simple clock widget for the Chumby – using open source tools.

Download Widget Source Code and Images.

Hello Chumby! (a first widget)

So now that I’ve got the Chumby it seemed like a good idea to test out creating and uploading my first widget.

This is my first foray into flash development, so for the moment I’m just cribbing from other sources. I’m hoping that as Actionscript is a cousin of Javascript it won’t be too tricky to pick up. Though of course much of the learning will be related to the various APIs.

To get started I ran over to Open Source Flash and read the article on setting up a flash project without using the Flash IDE (seeing as I don’t want to buy Flash – for now at least). I then followed through from there to the MTASC site and looked at the example tutorial and realised that may be all I needed to get a simple “Hello World” widget working.

So here’s the Actionscript I used (saved in

class Tuto {

    static var app : Tuto;

    function Tuto() {
        // write some text into it = "Hello\nChumby!";
        // make the text appear bigger on the screen
        var format = new TextFormat();
        format.size = 64;;

    // entry point
    static function main(mc) {
        app = new Tuto();

Which is based on the code in the MTASC tutorial.

Then with MTASC downloaded and installed in ~/bin/mtasc-1.12-osx/ on my Powerbook, I compiled the code using:

~/bin/mtasc-1.12-osx/mtasc -swf tuto.swf -main -header 320:240:12

Which creates the SWF file tuto.swf.

Note the -header 320:240:12 option. This is to set the size (320×240) and framerate (12fps) of the resulting SWF. These are the settings as required for the Chumby.

With that done I then tried out tuto.swf in my web-browser to make sure it worked. Next I uploaded the widget via (which meant I had to create an 80×60 pixel icon too). I made sure that the widget was set to private when uploading (seeing as only I wanted to see the widget) and then added it to my “development” channel.

Then I selected the “development” channel on my chumby to see the results:

I did run into a little trouble getting the widget to refresh after uploading. It seemed to work sometimes, but in the end I started sshd on the chumby so I could stop and start the control panel (after connecting via ssh):

chumby:~# stop_control_panel 
chumby:~# start_control_panel 

Which seemed to solve the trick. I’ll have to investigate other means of deploying to the chumby when I’m properly developing, but overall it wasn’t too much effort going via the chumby site.

Unpacking Chumby

So the Chumby finally arrived today. Heather had very kindly and sneakily managed to arrange for it to be sent from the US (seeing as it’s not yet available over here in the UK) for my 30th. I have to say that so far I’m pretty impressed.

It’s got that geek gadget factor working for it very well. Lots of options to configure, but at the same time it’s pretty easy to use. Lots more exploring to do, but even just the fact that it’ll play Radio Paradise out of the box is enough for me…




See more chumby photos