Last week here in Backspin I discussed how real-world "things" that aren't easily augmented with digital instrumentation, such as bicycles, cars and even dogs, can be indirectly connected to the Internet of Things (IoT) using physical ID tags and online proxies. This is, as I pointed out, a powerful concept.
Even more powerful is the potential for new products, including bicycles and cars (dogs, maybe not so much), to be designed from the ground up to include instrumentation and the ability to connect directly to the Internet using more or less real time communications.
[ IN PICTURES: 25 weirdest things in the 'Internet of Things' ]
There are a few exciting new products that make connecting new things to the IoT relatively easy. For example, Electric Imp sells a device called the Imp, a simple, elegant, low-power and low-cost way to build connectivity into a product.
The Imp incorporates an ARM Cortex M3 SoC (system on a chip) with embedded 802.11b/g/n Wi-Fi (open networks are supported as well as 40- and 128-bit WEP, WPA with TKIP and AES, and WPA2 with AES and mixed along with WPS and WPS-PIN setup but not 802.1x yet) all in an SD card form factor.
The Imp hardware is powerful enough to have its own operating system and its own version of the scripting language Squirrel, which looks a lot like C and JavaScript mushed together.
Getting an Imp connected to the IoT is done using a technique Electric Imp calls "BlinkUp." This method uses a smartphone app to transfer network configuration and credentials for Wi-Fi and cloud services by flashing the phone screen on and off, rather like morse code, which the Imp picks up using an on-board optical sensor.
What's really important about the Imp is that it's cheap to buy and integrate: A basic prototyping board costs $7 and the hardware required to integrate with a vendor's product costs less than $1. This paves the way to add all sorts of devices to the Internet of Things not only easily but cheaply.
But, there's a problem with the Imp's communications strategy: All communications (both to and from the Imp) have to go via the Electric Imp online service (which, by the way, runs on Amazon Web Services). This means that messages between, for example, a smartphone app and an Imp-enabled device could be slow (delayed by online conditions), and if the Imp's local Internet connection is actually down even though the Imp and the smartphone app are on the same network, there's no possibility to control the Imp or read data from it.
Does this matter? You bet it does! Some time ago I reviewed a product that fails due to exactly these problems: Hunter Fan's rather grandly named Universal Internet Thermostat.
This product got a very low Gearhead rating (1 out of 5) for a number of reasons, including its mediocre physical design, its lack of built-in Wi-Fi (the thermostat connects to your wired network via a proprietary 900MHz wireless dongle that you plug into your router), and the poor design of the iOS-only control app and the online Web application (both of these mix up operational control with configuration and the result is a clunky interface).
In fact, a temperature schedule set up on the iOS app can't be changed or even seen in the Web app and the feature to add a schedule in the Web app (their Web site claims that it "Allows you to build unlimited schedules from anywhere, anytime") still doesn't work despite me reporting the problem to Hunter Fan's support last November when I reviewed it.
All of that aside, the real deal-breaker for the Universal Internet Thermostat is the lack of local connectivity and control. I've had my Internet service go down and, despite my Wi-Fi working just fine, there's no way from within my network to control the thermostat when I can't access the Hunter Fan server.
There were also two occasions when the Hunter Fan server wasn't visible online even though my connection was working fine; once due to an unspecified problem Hunter Fan had and once, I believe, due to some problem in the network between my connection and Hunter Fan.
This lack of local connectivity also means that any kind of integration with home automation systems just isn't possible. Moreover, Hunter Fan is naively excluding all third-party development, which is key if you want to become any kind of commercial force in the Internet of Things.
This architecture -- device to Internet server to app to Internet server to device -- raises the question: When is Internet service actually required at all? In the case of the Hunter Fan Universal Internet Thermostat it's not like the service is keeping track of any useful data for me or implementing some kind of control logic. In fact, the online service is really only providing a gateway for remote control, which is not that big a deal and hardly worth the $10 per year that Hunter wants after the first year.
Sure, if Internet connectivity is 99.99% available, operating at a decent speed, and if control during some kind of disaster or other major local problem isn't going to make the thing useless or, worse, uncontrollable, then a server-mediated architecture is great. But those goals aren't guaranteed, and when you combine the lack of any of them with the requirement to have a server mediate all communications and with the requirement to pay for service when the service doesn't significantly add value, then I'd suggest that products like that are doomed.
For products designed for the Internet of Things to really succeed they need to be capable of local control and interrogation, to have remote access, to be reliable, and to be useful and cost-effective. Is that too much to ask?
Gibbs is well-connected in Ventura, Calif. Communicate with him at gearhead@gibbs.com and follow him on Twitter and App.net (@quistuipater) and on Facebook (quistuipater).
Read more about anti-malware in Network World's Anti-malware section.