This weeks guestblog is brought to us by Daniel Messer, aka the Cyberpunk librarian. Find out more about Daniel, his podcast and his awesome website over at Cyberpunk librarian.Com
Digital signage is a passion of mine which is odd because, for the most part, I hate advertising. When you think “digital signs” you have to think about advertising because the two go hand and hand, right? You see them all over the place from your local big box store where they use monitors on end-caps to sell you stuff you don’t need to the trendy Apple store where they’ll use an iPad Air 2 as a digital sign.
That’s a baseline US$500 device sitting there. It kicked off the tablet revolution and ushered in a so-called “Post PC Era.” And there it is, bolted to a table, telling you why you’d want to buy a PC. That’s irony so thick you could spread it on toast.
But it doesn’t have to be this way.
As a public library webmaster, one of my jobs is managing the digital signs in our branches. I don’t create the content so much anymore, but I handle the tech side when needed. These things run off of small, dedicated PCs running Windows 7. Their administrative interface is lousy, the PCs are overkill as they’re rolling glorified PowerPoint presentations, and the big screen monitor and PCs kick out enough heat to keep you warm in the winter.
For the record, I live in Phoenix. We really don’t have a winter here.
When I first got my hands on a Pi, I knew this would be better for getting the library’s messages out on digital signs. They’re tiny, produce little heat, could be velcroed to the back of a monitor, and they run on free software. Diving into different software packages I played withScreenly OSE, Concerto, RiseVision, and others before landing on something I really liked — an idea I got at an airport.
The Phoenix Mesa Gateway Airport, aka AZA, uses Pis for almost all of their digital signs from the ones dropping ads to the ones that tell you when your flight departs and from what gate. Even the monitors beside the gates use Raspberry Pis to display the gate number, flight number, destination, and so on. I talked with a couple of their IT staff to find out what they used and the answer was surprising and refreshing.
They use a web browser. When you look at those signs, you’re simply looking at a website, in a browser, in full screen mode. The website refreshes itself every so often, and there’s a quick blank screen while it does this, but then you’re presented with the latest information.
I went back to my desk and got to work.
An old server bound for surplus found new life in our racks with an Ubuntu Server installation. I knew I’d have to do things slightly different as our library district covers a huge area while the airport covers a single large building. Instead of using the Pis to call a website, I’d have them bring up web content stored locally, but synced from the server.
I installed Chromium on the Pis because I like how easily you can feed it switches through a command line. That’ll be useful later. I also need to make sure that the screens don’t go blank or into power-save mode. Turns out there are a couple of ways to worry about this, but an easy way to handle it is to simply install XScreenSaver and then disable it.
My Pi OS of choice is Raspbian, which uses LXDE as its desktop environment. That’s excellent because to make all the necessary changes I just need to edit a couple of files, maybe three if you’re running the latest version. Opening up LXTerminal and then running
sudo nano /etc/xdg/lxsession/LXDE/autostart
I added the following lines:
@xset s off
@xset s noblank
@chromium --kiosk --incognito /home/pi/display/index.html
(Depending on your version of Raspbian, you might need to put the @chromium line in
The other three can go in the first file.)
The first three lines disable all the screen blanking stuff that Raspbian would normally do, which forces our screen to stay on. The last one launches Chromium, in a full screen kiosk mode which. When you launch Chromium in incognito mode it won’t remember any previous shutdown errors and thus, never throws an error on startup. Then it displays my index.html in a local directory. Since we’ve put these in the autostart file(s), they will automatically happen when the pi user logs into the GUI. (Which you can set to happen immediately after boot up through
But how to update it?
Since the geographic area covered by the library district is bigger than some east coast states, I wanted things to update quickly, in the background, on a schedule, while reliably pulling down the data and resuming the odd failed transfer. Fortunately, you can do all of that with rsync and cron.
Remember that old server now running Ubuntu? That’s the only place I update the code and content. I can change and add slides, modify the code, save everything, and ten minutes later all the Pi displays are updated. Here’s how that works:
On each Pi, I set up rsync to talk to the server. To do this without a password you need to set up a keypair for the Pi and the server. First thing to do is make sure ssh works between the Pi and server. If so, generate a keypair on the Pi using ssh-keygen. Don’t use a password to generate the keypair and don’t use sudo as the user pi will be doing all the work. Once you have the keypair transfer it to the server using:
ssh-copy-id -i ~/.ssh/id_rsa.pub user@servername
Replace the user@servername with the user on the server where you’re hosting these files. In this case, the syncing directory is under my own username, dan, in a directory called display.
ssh-copy-id will ask for your login password to the server and, if all goes well, that’ll be the last time it asks for it. Once the keypair is set up between the Pi and the server, you should be able to ssh and rsync without a password.
Now we’re ready to sync things up! Set up a cron job using:
crontab -e -u pi
This will launch nano and you can set up a cron job to call rsync as you like. Me, I do it every ten minutes. That means that, on the very outside, any change I make to the master files will take up to twenty minutes to reflect on the monitors in the branches. I could set it to go more often, but there’s nothing so critical as flight information on those screens. So my cron job looks like this:
*/10 * * * * rsync -az --partial dan@piserver:/home/dan/display /home/display/
Looking back, let’s see what we’ve built. We’ve got a Raspberry Pi, connected to a monitor in a remote location. It’s running a slide show through Chromium and all the content is local, so it comes up fast with no lag. That content is synced to a server via rsync running as a cron job and everything updates every ten minutes, both the browser and the content.
So in the end, we’ve used no software geared specifically towards digital signage. The digital sign is powered by open source operating systems, running open source software, on open source hardware. As a librarian into open access, that’s the kind of thing that really makes my day.