Building a remote-control for real cars
[[!meta date="2011-05-01"]]
[[!tag debian msg blog editorial]]
SMS is used to lock car doors
Copenhagen Carpool soon receive a new batch of electric cars.
The new cars will contain a cellphone tied to the door locks,
to only let into the car the member who booked its current timeslot.
I am setting up the system to connect the cars with their booking calendar.
The general idea is to...
- Connect a standard cellphone to a computer.
- Forward sms messages received on the phone to the calendar.
- Send messages from the calendar through the phone.
- Leave the system in a corner, turned on 24/7.
[[!graph src="""
rankdir=LR
phone -> computer -> "calendar" [dir="both"];
"""]]
Most of my work is in trying to avoid ways things might go wrong
-- which so often happens when computers are involved.
What if...
- messages are delayed or lost?
- a chain of messages arrive out of order?
- messages are sent faster than they can be delivered?
Reliable conversation
Human conversation is most reliable when using plain speak.
Slang, sarcasm or jokes raise the risk of misunderstandings.
This is quite similar in computer conversation.
When surfing the Web,
you normally "GET" a web page or "POST" new data like a search query.
The words "GET" and "POST" are "plain speak" of the World Wide Web
-- defined as a principle called "REST" or "RESTful design".
[[!graph src="""
rankdir=LR
"fetch document" -> website [label="GET", dir="back"];
"provide info" -> website [label="POST"];
"""]]
I use the Kannel tool to talk directly to the phones.
When an sms arrives on the phone,
Kannel "GET"s it to the calendar.
That's weakly expressed
-- better if it had "POST"ed the message instead.
[[!graph src="""
rankdir=LR
"provide sms info" -> "calendar" [label="GET" style="dotted"];
"""]]
Kannel is a quite reliable tool, but not RESTful in conversations.
That requires extra attention at other parts of the setup
to avoid breakage in special situations.
That worries me.
Each car has a blog
So I setup a gateway from Kannel to RESTful conversation.
And choose classic blogging as style of conversation:
- The carpool fleet is a blogroll
- each car has a blog
- each sms emitted from a car is a blog entry
Blogging comes in two flavors,
-- RSS and Atom.
Both cover distribution of messages.
I use Atom because it is newest and coolest,
and because it also covers creating and editing meesages
with the AtomPub extension.
AtomPub allows the calendar to create an empty message
-- which then triggers an sms from the car which "fills it in."
AtomPub also let the calendar "PUT" tags onto existing messages,
to mark them as processed, read etc.,
and let an admin or a cleanup script "DELETE" outdated entries or blogs.
The words "PUT" and "DELETE" are RESTful conversation as well.
The system is dancing!
My sms-to-blog gateway is written in Perl,
using the Dancer toolkit.
Dancer makes it simple to setup a RESTful web conversation,
and when I contacted the authors on IRC,
they swiftly added support for the non-RESTful quirk that I needed.
[[!graph src="""
rankdir=LR
phone -> "sms gateway" [dir="both"];
"sms gateway" -> "blog gateway" [dir="both", style="dotted"];
"blog gateway" -> calendar [dir="both"];
"""]]
My sms-to-blog gateway is not yet ready, but basic routines work.
The project is public, and code is Free Software.
