Adrian Short
Design, citizenship and the city
My thermometer has got an API
2 March 2009
Meet my thermometer.
It’s an old-school analogue device, probably at least 50 years old. I don’t expect it’s very accurate, certainly not by scientific standards. It hangs outside my door and every now and then I take a look at it and record its reading.
But this is no ordinary thermometer. It’s eqiupped with a capability that would have probably been inconceivable to the people that made it: it has its own API so that programs can “read” it, automatically, across the Internet.
Before explaining how you can use the API I should explain why I’ve bothered to do this.
By any sensible standard, this project in itself is almost completely useless. I haven’t created any kind of clever link between the thermometer and the database in which I store its readings. I just read it when I feel like it. Some days I might get five or six readings. (You can get more sophsiticated computer-connected thermometers that do this automatically but I don’t have one.) Then I might go for five or six days without reading it at all. Combined with what I assume is a fairly low level of accuracy as a result of the device itself, its positioning and the possibility of human error when reading it and recording its value, the data produced seems almost worthless.
There is a crucial difference between almost and completely worthless.
This project is my first contribution towards the Internet of Things. The thermometer is a very simple sensor, producing, as I’ve explained, very low quality data. The API is incredibly basic. There is only one query: read the thermometer. And the result is the following hash:
| temperature_c | Latest (not current) temperature, in centigrade |
| ts | Unix timestamp of the latest reading |
| lat | Approximate latitude of the thermometer |
| lng | Approximate longitude of the thermometer |
This thermometer is a very simple device with a very basic interface. If you’re relying on it to provide up-to-date, accurate temperature data, you’re a fool. But imagine if a dozen people in my neighbourhood did exactly the same thing — all reading their not-particularly-accurate thermometers whenever they felt like it and updating their databases. As the number of thermometers increases the chance of being able to find a sufficiently-recent reading from one of them improves. And as the data from all these thermometers is being read by a program (or programs), it’s quite possible to use statistical techniques to smooth out any apparent errors.
This is the opportunity afforded by the Internet of Things (sometimes known more generally as ubiquitous computing or everyware). The model is almost completely opposite to current ideas in server and desktop computing, which are focused on a relatively small number of devices with ever-increasing computing power, storage capacity and sophistication. IoT takes a very large number of fairly stupid devices that have, as a minimum, the ability to network with other things and serve up just one piece of useful information, and then mashes them up into something that’s infinitely more powerful than the sum of its parts.
Imagine a world in which most objects know who they are, where they are and can serve up very basic reports on their status to other objects. Such a “system” would be massively redundant. Like the cells in a body, no one object would be necessarily particularly important in the grand scheme of things. It’s the power of being able to combine these things together — and of them being able to combine themselves — that opens up a wealth of new directions. A city in which every lamppost could transmit its precise location would likely be more accurate than GPS. Lampposts don’t move and they don’t get obscured by clouds.
Making this happen won’t require any fundamentally new technological advances, just small improvements to the cost of existing ones. Platforms like Pachube already exist to enable people to network these kinds of devices and build complex, emergent systems on top of them.
Grand schemes aside, using the thermometer’s API is very simple. Just send an HTTP GET request to:
http://www.stonecothillnews.co.uk/thermometer.php
and you’ll get back a JSON-encoded hash as described above. This is the latest reading that has been taken on the thermometer. It could have been a minute or a month ago.
Here’s how you do it in PHP:
<?php
define('ENDPOINT', 'http://www.stonecothillnews.co.uk/thermometer.php');
$handle = fopen(ENDPOINT, 'r');
$contents = fread($handle, 8192);
fclose($handle);
$data = json_decode($contents);
print_r($data);
?>
and here’s a Ruby example:
require 'open-uri' # URI wrapper for File.open
require 'activesupport' # for JSON decoding
require 'pp' # pretty printer
ENDPOINT = 'http://www.stonecothillnews.co.uk/thermometer.php'
handle = open(ENDPOINT)
output = handle.read
handle.close
data = ActiveSupport::JSON.decode(output)
pp data
I don’t imagine many readers will have a great deal of use for irregularly-updated temperature data from my neighbourhood. But imagine what could be possible with the contributions of millions of devices like this.