As what as you like
The premise of this project is simple - my family lives in London, there’s a bus route that runs along our road, and we use it a lot to take the kids places. The reality of using the bus is a little more complex - getting three kids ready to go out, is a nightmare and it’s not made any easier by checking a travel app on your phone to see how close the bus is.
I don’t think there is much I can do to make the preparation of the children any less manic, but I can certainly do something about the visibility of information about buses, mainly thanks to the excellent open APIs/data provided by Transport For London. So, armed with their API, a Python 3 interpreter and a Raspberry Pi, I set out to make a little box for the kitchen wall which will show when the next 3 buses are due to arrive outside our house. The code itself is easy enough to throw together because Python has libraries for everything (it also helps if you don’t bother to design a decent architecture!). Requests to fetch the bus data from TfL, json/iso8601 to parse the data, Pillow to render it as an image, and APScheduler to give it a simple run-loop. The question then becomes, how to display the data. The easiest answer would be a little LCD screen, but that brings with it the downside of having a backlight in the kitchen, which would be ugly and distracting, and it also raises the question of viewing angles. Another answer would be some kind of physical indicator, but that requires skills I don’t have time for. Instead, I decided to look for an E-Ink display (think Kindle) - it would let me display simple images without producing light. The first option I looked at was the PaPiRus, but it’s in the window between its crowdfunding drive having finished, and being available to buy. The only other option I could find was the E-Paper HAT, from Percheron Electronics, which also started life as a crowdfunding project, but is actually available to buy. Unfortunately, these displays are super fragile, which I discovered by destroying the first one, but Neil at Percheron was super helpful and I quickly had a new display and some tips about how to avoid cracking it. My visualisation of this data isn’t going to win any awards for beauty, but it serves its purpose by showing a big number to tell us how many minutes we have, and I managed to minimise the number of times you see the white-black-white refresh cycle of the eInk display with partial screen updates. Here are some photos of the project in various stages of construction: | | |————————————————————————————————————————————————————————————————————————————| | | | Freshly assembled out of the box |
The smallest USB WiFi adapter I’ve ever seen Sadly I had to make some modifications to the
PiBow case to fit this particular rPi
Running one of the eInk display test programs
Initially I was rather hoping I could use the famous font that TfL (and London Transport before it) use, which is known as Johnston, but sadly they will not licence the font outside their own use and use by contracted partners. There is a third party clone of the font, but it may have legal issues, presumably because TfL values their braaaaaand. Instead, I decided to just drop the idea of shipping a font with the code, and exported Courier.ttf from my laptop to the Pi directly.
This would have been nice, but I cannot have nice font things.
I did briefly try Ubuntu Mono, which is a lovely font, but the zeros look like eyes and it freaked me out.
PIBUS IS WATCHING YOU
The display needs to handle various different situations, most obviously, when no data can be fetched from the API. Rather than get too bogged down in the details of whether our Internet connection is down, TfL’s API servers are down, London is on fire, or it’s just night time and there are no buses, I went for a simple message with a timestamp. Once this has been displayed, the code skips any further screen updates until it has valid data again. This makes it easy to see when a problem occurred.
Maybe aliens stole the Internet, maybe it's a bus strike.
It doesn't matter.
I also render a small timestamp on valid data screens too, showing when the last data fetch happened. This is mostly so I can be sure that the fetching code isn’t stuck somehow. Once I trust the system a bit more, this can probably come out.
The final design, showing a fallback for when there is data for 0 < x < 3 buses Data for three buses, plenty of time to get ready for the second one!
So there it is, project completed! Grab the code from https://github.com/cmsj/pibus, install the requirements on a Pi, give money to the awesome Percheron Electronics for the E-Paper HAT (and matching PiBow case), throw a font in the directory and edit the scripts for the bus stop and bus route that you care about!
I was searching around for ways to automate sending iMessages, so I could write a plugin for Hammerspoon. I found various scripts lurking around the place for sending iMessages, but I also found one that can send SMS if you have SMS Relay enabled (which means you need OS X 10.10 and an iPhone running iOS 8.1). I figured I’d collect them as a single post, to help future searchers, so without further ado, here are two stripped down AppleScript snippets that let you control Messages.app to send either an iMessage, or an SMS. Firstly, sending an iMessage:
tell application "Messages" send "This is an iMessage" to buddy "email@example.com" of (service 1 whose service type is iMessage) end tell
The buddy address can be either an email or a phone number that’s registered with Apple for use with iMessage. Secondly, sending an SMS:
tell application "Messages" send "This is an SMS" to buddy "+1234567890" of service "SMS" end tell
Here, the buddy address should be a phone number. Simple! (and for the Hammerspoon users, you’ll find hs.messages available in the next release, 0.9.23)
Comparing the Moto X to the Nexus 4 is interesting in one particular respect - the price. The Nexus 4 (made by LG, sold by Google) had very respectable specs when it was launched, but its price was surprisingly low ($300 off contract). We were told this was because it was being sold very close to cost price. The Moto X (made by Motorola, which is owned by Google) has mid-range specs, but its price is surprisingly high ($200 up front *and* an expensive two year contract). Overall Motorola is probably getting something like $400-$600 for each Moto X sold, when you factor in the carrier subsidy. The inevitable question is why Google is happy to make almost no money off the Nexus 4, but wants to have its Motorola division make a respectable margin on the Moto X.
- Is it because doing otherwise would undermine the carriers’ abilities to sell other phones, so they would refuse to do it?
- Is it because Google wants the Motorola division to look good in their accounts, which is easier if you are selling mid-range phones for the kind of money that an iPhone sells for?
- Something else?
I’ve started using Keyboard Maestro recently and it is one impressive piece of software. Here are a couple of the macros I’ve written that aren’t completely tied to my system:
- This will type the URL of the frontmost Safari tab/window into your current application. Handy if you’re chatting with someone and want to paste them a hilarious YouTube URL without switching apps, copying the URL to the clipboard and switching back.
- It does not use the clipboard, it actually types the URL into the current application, so any modifier keys you hold will change what is being typed. I’ve configured the macro to fire when the specified hotkey is released, to minimise the chances of this happening.
- Very simple, just toggles the state of Caffeine with a hotkey.
Anyone who’s been following Terminator knows this post has been a long time coming and should not be surprised by it.
As of a few days ago, I have handed over the reigns of the project to the very capable Stephen J Boddy (a name that will be no stranger to followers of the Terminator changelogs - he has contributed a great deal over the last few years).
We’re still working out the actual details of the handover, so for now the website is still here and I am still technically the owner of the Launchpad team that runs the project, but going forward all code/release decisions will come from Stephen and we’ll move the various administrivia over to new ownership in due course.
Everyone please grab your bug trackers and your python interpreters and go send Stephen patches and feature requests! :D