Build a Geckoboard TV Dashboard with a Raspberry Pi

Part of the work I do on Postmark is helping make sure we know what’s going on inside the system at any given time. We built a real-time(ish) monitoring system using Geckoboard and a variety of Windows Performance Counters, API endpoints, and database calls. I’ll save those details for another post.

Geckoboard provides an easy-to-use suite of widgets that speak JSON and XML so if you shoot your data at it on an interval (or provide it an API to poll), it’ll display the data through charts and graphs in ways that are useful to an audience. We use it extensively at Wildbit to keep an eye on all the various Postmark systems.

Having this information on display at our office for everyone to see is important so we arranged to show our Geckobard dashboards on 40 inch televisions, 2 for Beanstalk and 1 for Postmark. We bought 3 Rikomagic MK802 Android devices which are convenient since they come equipped with HDMI out and can be powered by the USB ports on the TVs.

The original MK802 device.
The original MK802 device.

For the most part this worked well but there were some drawbacks to using the Android devices. The biggest problem was that we couldn’t seem to get a browser to run in full-screen or kiosk mode. A lot of screen real estate was taken up by the browser chrome and menus which meant less room was available for Geckoboard graphs. Last week the Android device powering the Postmark Geckoboard suffered some kind of disk encryption failure and stopped working. After a few failed attempts at restoring the MK802, I opted to try out my new Raspberry Pi to display the dashboard.

The way I saw it, there were no downsides to using the Pi instead of another MK802:

  • Cost is about the same.
  • Also comes with HDMI output and can be powered by the USB port on the TV.
  • Runs a full fledged Linux distro (Raspbian, among others) so it would be a familiar configuration setup.
  • Possible to run X11 and Chrome in kiosk mode for a more professional looking setup.
Raspberry Pi Model B
Raspberry Pi Model B

Following are the steps I took to create a fully automatic Raspberry Pi Geckoboard TV dashboard:

Software Setup:
  1. First you’ll need to install an operating system on your Pi. I’m using Raspbian ‘Wheezy’ which is a Debian derivative and one of the recommended choices. I won’t go into the installation details here. For that, I’ll direct you to their setup guide (PDF). You can go ahead and get through that first. It’s cool. I’ll wait. Make sure to get your wireless (or wired) networking going before trying to continue.
  2. Set your Pi to boot to ‘desktop mode’ by default. This will go straight into the X desktop and window manager when you turn your Pi on. To do that, you’ll need to go into your raspi-config tool by typing:
    sudo raspi-config

    Setting up to boot direction to desktop mode.
    Setting up to boot direction to desktop mode.


  3. Once that’s done, we’ll need to install a few things:
    sudo apt-get update && apt-get upgrade -y
    sudo apt-get install chromium x11-xserver-utils unclutter

    Now that we’ve got a few utilities installed and, more importantly, the Chromium browser, let’s make some configuration tweaks: (source)

  4. Edit the /etc/xdg/lxsession/LXDE/autostart file
    sudo nano /etc/xdg/lxsession/LXDE/autostart

    Comment out the @screensaver line with a “#”
    Add the following lines:

    @xset s off
    @xset -dpms
    @xset s noblank
    @chromium --kiosk --incognito

    That last line contains the link to which you want Chromium to be directed on bootup so put in the public link to your Geckoboard (or other dashboard).

  5. Finally, you may need to force your Pi to use HDMI out if you are getting power from the TV. The Pi doesn’t detect the HDMI signal from the TV fast enough when you turn it on and disables the port on some TVs (this happened to me).
    sudo nano /boot/config.txt

    Remove the comment from the line:


    That should keep your Pi outputting video to your HDMI output regardless if it detected the TV at first or not.

Final Product:

Our command center consists of 3 TVs, the middle is for Postmark. I still need to mount our Raspberry Pi properly since this was just a prototype setup. So far so good, however. I think we’ll replace the last two MK802s with Pis soon since it offers a superior dashboard experience.

Beanstalk and Postmark
Beanstalk and Postmark
Current setup. A little temporary.
Current setup. A little temporary.

Be Honest With Your Customers

Sometimes your product falls behind the curve. Or you’re forced to release a version that makes some compromises. It happens. And it’s not the end of the world.

Recently I’ve seen two examples of companies that have done an exemplary job releasing a product without a feature they were working on or admitting their product may have fallen behind another product’s feature set.

Last week Sparrow released Sparrow Mail App for iOS which, by just about any review, is an EXCELLENT Gmail-centric mail application. The user interface is stellar and it introduces some new and interesting ways to review threaded messages. I’ve been using it for a few days now and I’m very pleased with how nicely it has supplanted Apple’s Mail app. It IS missing one feature, however. Push. Sparrow had been beta testing push notifications but in the end, they decided to pull the feature because, in their best estimation, they couldn’t guarantee the security of users’ credentials.

On our side: if Sparrow was to do Push today, we would have to store your credentials (login/password) on our servers to frequently poll your accounts, and send you notifications.

This is a responsibility we’re not ready to take. As a startup focused on iOS/OS X development, we do not have the skills to secure your data on our servers and we do not want to put sensitive information at risk. That’s why Sparrow iPhone 1.0 doesn’t do push.

It’s very refreshing to read a post like that. Sparrow made a special effort to explain why they decided NOT to include a feature they didn’t feel was ready for production. They didn’t spin a PR yarn about why push isn’t needed or why removing push is better for users. It wasn’t ready. Apple won’t let them use the API they need. Here’s what’s going on.

Another recent example was Marco Arment‘s mea culpa regarding fonts (type-faces) in his excellent Instapaper iOS application. Readability, another very good “read later” app, introduced a competitive advantage by letting the user choose from a couple excellent font choices. At first Marco didn’t consider this feature much of an advantage but he eventually recognized that yes, in fact users may benefit greatly from being able to choose an agreeable type face.

I could have interpreted this defensively and complacently: “Georgia and Verdana are great, versatile, highly screen-readable fonts! I don’t need to do what competitors do! Newer isn’t always better! My crusty old fonts have some technical advantage that you don’t care about!” And so on.

Yesterday Instapaper 4.1 was released with some exceptionally nice-looking type-faces. Marco worked  hard to quickly bring a feature he felt he had fallen down on to his customers and the results are outstanding.

The lesson here is, if your product has fallen behind a competitor a bit, or was released without a feature you know your customers may been looking forward to, be honest with them. Most of them are your customers because they like you and your product. They’ll appreciate the transparency and, more often than not, will gladly be willing to stand by while you add the feature or polish you think your product needs.