It's about the little (internet of) things
After moving into my new place I decided that I wanted to start down the treacherous path of home automation. I’d dabbled with a WeMo switch previously (see here), but that was more of a toe in the water. Now I wanted to jump in. My hesitation with home automtion/IoT in the past has been that it’s difficult to find a use case where it would actually enhanced my life. In addition, I don’t want any IoT automation to interfere with the day-to-day operation of how a reasonable person expects the device to operate. For example, if you’ve installed Philips Hue lights throughout your house, and your automations don’t work because somebody has turned off your globe at the switch, that’s a problem with the automation, not with the switch.
I luckily live near a tram line, and I catch the tram to get to work. Melbourne’s tram network is run by Yarra Trams, and they produce a pretty good app which provides arrival information for tram stops. Just an aside, the arrival information isn’t calculated by GPS, but rather a series of radio-based timing gates relative to your stop. The problem I have is that even during peak frequency, the trams are spaced 10–12 minutes apart. You don’t want to have to wait at the stop for 10–12 minutes. As a result, when I get ready in the morning, I usually have the iOS app up checking the tram arrival time. Constantly sliding down to refresh is giving me RSI, and although there is a notification system, it requires my input initially. This is my use case!
Now I can remember Werner Vogels at last year’s AWS Architect & Developer Day in Melbourne talking about natural interfaces, and this is a perfect example of where one can apply. My idea was to use a connected light globe, in this case one from LIFX (more on that later), and connect it to the Yarra Trams API. As the tram got closer, I wanted the light to get brighter, and then when it was absolutely time to leave, I wanted it to flash to warn me.
Parts
Yarra Trams API
Yarra Trams had a public API before it was cool, so although it’s SOAP-based, it provides data for all your tram network needs. Bang in the stop number and you’re good to get your predicted arrival information: GetNextPredictedRoutesCollection . Before you call that, you need to get a ClientGuid by calling GetNewClientGuid, and then you’re good to go. Simple.
LIFX
One of my fundamental home automation rules, is that the devices must be controllable locally. I don’t want to have to communicate over the internet to talk to a device which is running on my local network; it’s unnecessary. LIFX have a pretty robust looking Remote API, but luckily they also have a local LAN protocol for communicating with globes. LIFX Globes are standalone, so the protocol has a discovery mechanism using UDP for finding globes. NPM has (almost) everything, including a NodeJS implementation of the protocol.
Docker
Although Docker is supported on Raspberry Pesis , Docker Machine doesn’t just work out the box. I followed this guide to trick it into working. Probably not production grade, but I haven’t had too many issues with it.
Lazily Gluing It Together
My implementation is fairly rudimentary; it’s on Github. The application runs on a timer, and effectively runs for 30 minutes over my departure window. When a tram is within 7.5 minutes, the light is turned on, and then as the tram gets closer, the brightness increases. When it’s really close the light pulses to signify it’s now time to leave. If the tram is arriving in less than 4 minutes, the light is then turned off, as I won’t be able to make it in time.
Conclusion
The real benefit of this “thing” is that it allows me to continue my morning routine without needing to constantly refresh my phone for tram arrival information. It’s non-invasive, yet still informative. This is how we should think of IoT devices, they need to enhance, not inhibit our lives.