Here's a brief assessment of the technologies I've had hands-on experience with:
Bluetooth and Bluetooth Low Energy (BTLE) require a smartphone and/or an always-on base station that communicates to a server. That likely means an app on the major smartphone platforms and a service/daemon on the base-station OSs. Plus, to collect and act upon the device's data will probably require a cloud server. On the plus side, configuration is relatively simple -- as long as you have a display on the device. Battery usage is minimal, which makes this a good choice for pedometers and other pocket devices.
Connecting to a WiFi processor using a TCP/IP stack on your processor makes for a reasonably complex system requiring an RTOS. It also can drive up the cost of the MCU by moving the application from a Cortex-M0 to a Cortex-M3 with the associated battery drain. Configuration is very difficult, usually requiring the user to switch to the device-as-a-server (a.k.a. device-as-an-access-point) to set the SSID and password. Also, the quality team (if you have one) is going to need to verify functionality with a wide range of home routers and (seemingly standard) web browsers. The battery usage is high when the radio is on, which means that intelligent local processing is needed, along with some message batching if possible. This option works well for printers (plugged in) and scales (which spend most of their time sleeping).
Connecting to a WiFi processor via serial means the processor can remain smaller, which is a cheaper and more power-efficient option. However, configuration is still difficult, probably even worse since the setup will not be as customizable as running a local stack. There are often fewer power optimizations for the WiFi processor so, oddly enough, limiting connectivity is often a priority for developers.
Electric Imp provides an interesting configuration option for 802.11 WiFi. It requires a smartphone, blinking the screen to send the SSID and password to a receiver on the device. It also takes some of the burden from the device developers by creating a WiFi + system cloud solution. However, it still requires many parts: device software (developed in Squirrel), a monitoring agent on the software (also Squirrel), and a web interface (Ajax, HTML5, etc.). The power levels are in line with other often-asleep devices, so batteries will do fine if you use enough of them. This option is great for the home hobbyist hacking together a monitor to see if the stove has been turned off. But using the Electric Imp in large scale means letting someone else store your data and working with them to connect users with devices in manufacturing.
Cell data modems are easier for the user, but they require coverage and are expensive (who needs another cell plan?). Connecting to the user account is still non-trivial, particularly if the user doesn't have a keyboard. Note that Amazon did cell modems for the initial Kindles (though the current Kindles are WiFi instead of cell modem now -- it is much cheaper for the OEM). Battery usage is higher than on WiFi, though the distance is greater. This option is excellent for devices that need to always be available, even when WiFi coverage is unlikely, such as traffic light cameras, cars, and smartphones.
Some products create their own wireless networks, running a base station or small server. This makes configuration much easier. However, the server likely has to use one of the above options or a wired connection to get to the Internet. And creating a device solely to communicate with other devices is expensive; it is primarily an option for systems with lots of little devices (such as home lighting). This option isn't scalable to true connectivity, rather it is a stopgap along the path to true device connectivity.
The Internet of Things is supposed to describe a world where connected devices improve our lives: The refrigerator tells the phone to put a needed item on the shopping list; the house detects there is no one home and turns off unneeded appliances (especially the oven!); the car tells the thermostat that it is 15 minutes from home arrival, to make for efficient climate control; the possibilities are endless and endlessly amazing. But we aren't there yet.
Too many connected devices cause more headaches than help. They are unreliable, too difficult to use, dangerously insecure, or impossible to configure. I know what I'm asking -- security and ease-of-use are natural enemies. But I'm tired of being the target audience, using my engineering skills to make not-quite-there products work for my home.
Let me know when your four-year-old and my grandma, working together, can put the device on the Iinternet. Then tell me again about the Internet of Things.
Logical Elegance is a small consulting company specializing in embedded system design and software. Under those auspices, I work for a few different client companies, designing new systems, bringing up boards, writing code, and generally doing what needs to be done to ship neat gadgets.
@Caleb: IoT has been here for a few years now, it is just that recent development activities have been more mobile-centric. Building automation (BACNet, LANNet, etc.) and process automation (OLE for process control -OPC) have been connecting "things" for many years and working as a developer in these is more clear than what the author alludes to in mobile-centric applications.
It's an embarassment of riches, I think. Too many wireless PHYs, protocols, software stacks.
Now we are getting to many aporoaches to unifying it: Oracle pitches Java, Qualcomm pitches AllJoyn, the 6LoWPAN folks have high level glue of their own. Even little starup WigWag has its DeviceJS. Whew!
I hear what you are saying from a developers point of view, but I also think about things from a user's perspective.
It's not so long ago that achieving any sort of connectiving (like linking two PCs together via a cable (using plug-in ISA boards) brought one to one's knees ... I was in an airport yesterday and connected my iPad to a free WiFi network to send an email to my mom and thought "wow, how things have changed!"
But as you say, from an embedded designer / developer's point of view, there's a bunch of stuff to wrap one's brain around ... I'm glad it's not me doing it :-)
I see what you're saying. Obviously the IoT isn't here yet. People are getting excited about the prospects, but pretty much anyone who understands the underlying idea will agree.
I think that maybe more important than the tech that connects will be the software systems that analyse data and pull intereting information from it. We KNOW that you amazing engineers will come up with a plethora of ways to transfer some bits. however, we don't know whether the refrigerator manufacturer will open the data in a way that the phone provider can use that data well.