Raspberry Pi Status Board
It was only a matter of time. I’ve had two Pi boards sat around for a while now; so long, in fact, that they’re both the 256MB Model B types and weren’t made in Wales. This summer, as part of the annual revamp in our studios, the much-neglected information screen finally bobbed high enough up on the to-do list to be in danger of actually getting done. Combine that with a collection of retired portrait-capable plasma screens in the basement and we’ve got ourselves a project!
What started this all off was the buzz there had been around Panic’s latest offering: Status Board. What I found a little uncomfortable was the fact that you needed to dedicate an iPad to the job, which just seemed downright weird. I’m up to my ears in old Macs, but iPads are rather more difficult to find without being attached to a protective owner. Nevertheless, there was an option for having one that shouldn’t have needed to be unplugged and used elsewhere too often, so I hurried off and bought Status Board.
Weighing The Options
I quickly realised that while Status Board may be a great app in the right environment, to do the kind of thing I had in mind would mean writing most of the code myself anyway. There is, of course, no magic button that creates displays for monitoring studios. When you add to that the extra fee for HDMI output (which is galling enough without having to be reminded about it every time you use AirPlay for the output), plus the cost of an iPad HDMI converter and the fact that the display was standard-def and only had VGA and composite inputs; it was a non-starter.
Update! I was completely unaware that Midori uses WebKit as its rendering engine, which makes it perfect for my requirements! I have since ditched Chromium, as it really was way too resource hungry. Full instructions are on the StatusBoard GitHub page.
Here came the trick. How to get that basic user and status information from each studio? The easiest way I could think of was to run a simple Bash script every 10 seconds, checking on the logged in username, idle status and load averages, then writing that out as HTML to a file in
/Library/WebServer/Documents. This gets served out by Apache on each system. Every minute the load average from each system gets sent to StatHat so a graph over 24 hours can be pulled down and used as a background for each studio block.
As a last minute thought, I added a free space reading for each of the workspace drives. Even with terabytes of storage, multiple users with lots of really high quality audio files chews through drive space on the console systems in no time, so it’s nice to be able to show people how much is left. The Bash script also checks against the local Active Directory database for the current user’s real name.
The Pi itself hides out of sight and luckily there was a network port on the wall to feed it data. The files it actually fetches and displays are hosted on one of the studios’ servers, though they could just as easily be stored locally on the Pi and (optionally) made available with lighthttpd or other web server. A little RCA cable connects Pi and screen, though one of the longest parts of the project was searching for an elusive RCA to BNC adapter!
There’s an added bonus. After setting everything up in the lobby, I rather missed having that instant feedback on the facilities in my office. But because it’s just a web page, I can use the often-forgotten ‘Open in Dashboard’ feature of Safari to have my own mini status screen on my Mac. Magic!
All of the code is up on the StatusBoard GitHub page, so you could be displaying stats for your own systems in no time. If you do, definitely tweet a picture my way; I’d love to see what you’re monitoring!