The latest buzzword around is "Internet of Things" (or as Andrew Binstock called it, the "Internet of Overhyped Things"). I tend to agree with Andrew that it is overhyped. But I also think it isn't necessarily anything new — just a logical extension of what we've quietly been doing for years. Of course, things get better and more pervasive. But we've been connecting computers to the real world for quite a long time.
That's not to say that there aren't new things to think about. If you really start connecting everything, you have bandwidth, security, and data volume issues to consider. There's also a host of new technologies (as always) that are trying to solve one or more of these problems.
When you think of a network for devices, you might think of WiFi. It is certainly ubiquitous. But using it to connect everything reminds me of mobile phones. When I was a kid, a mobile phone was a curiosity. Only large cities had "radio phone" service. It was expensive and required a car radio. Only a few people could use it at one time. One radio tower served one city (or, at least, parts of it). The bigger the tower, the more places you could use your phone.
One reason the service was expensive is because it couldn't handle a lot of customers. Each call ate up a channel over the entire city. If you were a radio engineer back then, you might have thought about how you could free up more channels to use for phone calls.
That would be the wrong approach. The modern cell system doesn't use up more channels to handle the millions of cell phones in use. Instead it uses smaller antennas that cover less area. Because the antennas deliberately don't radiate a signal very far, it is possible to reuse those same channels nearby (just not too nearby). On the old system, 30 channels could handle 30 calls over the entire town. But in the new system, you might break up the city into cells of 5 channels each. That allows 6 channels per cell. By reusing channel groups, you might have, say, 32 cells, none of which share a border with a cell that uses the same group. Now you can handle 160 calls on those same 30 channels! A good example of the old saying "less is more."
WiFi might be like the old mobile phone system. Your AP is the tower and the bigger the better, right? Maybe not. The future may belong to wireless networking that has a small range and lots of reuse.
A limited wireless network already exists: Bluetooth. Traditional Bluetooth, though, isn't always terribly efficient of channel use or power. Because of this, Bluetooth 4.0 introduced BLE (Bluetooth Low Energy). This is a Bluetooth profile made just for the Internet of Whatever, since it is economical both in terms of bandwidth and power. I recently had the chance to play with a Nordic nRF51822 board. This is an inexpensive demo board that contains an ARM processor and a 2.4 GHz radio suitable for creating BLE devices. I was pretty impressed with it. I like that it was mbed enabled. That means it looks like a USB storage device, and you can just copy a download file to it over USB to program it. It is also supported by the mbed libraries, so it is easy to put together an application.
In BLE parlance, a device can be a broadcaster that spews data out or a peripheral that other devices connect to. A central device (like a phone) controls peripherals and an observer listens for broadcasts. An example might be a broadcaster that sends out a temperature periodically. This tiny device would be the server and a phone that receives the broadcast would be an observer.
All peripherals and broadcasters send out advertisements. These are very short messages that inform interested parties that the device is there. The payload (which is only 31 bytes of data) allows other devices to know what kind of device is present and information like what services it provides. In the case of a temperature sensor, the data might be in the advertisement itself. If you need more data, there is a second kind of broadcast data — the scan data — that a remote machine can ask for after receiving an advertisement.
Another piece of data in the advertisement tells the remote machine if the device offers any services. If so, you can connect to the device and exercise the service. There are some predefined services (battery status, for example) or you can define your own. In general, these services tend to be just bits of data (known as characteristics). A temperature sensor might not offer any services and just allow anyone to read the value straight from the advertisement.
Next time I'll show you some of the bits of the API that you can use from within mbed to access the board's BLE radio. Like most of mbed, a lot of complexity is hidden behind a few pretty simple API calls.