Earlier this week, when Broadcom briefed the press on its newly minted Internet of Things (IoT) strategy at the swanky Tank18 wine bar in San Francisco, one of the talking points had to do with WiFi’s suitability to IoT connectivity. As it turns out, of the various wireless technologies, WiFi is the theoretical front runner when it comes to getting such things connected. But there’s also a big challenge that if not managed correctly will result in death on arrival for many of the devices and their developers. Developers who are considering a leap into the IoT fray will need to carefully consider the out-of-box experience of the end product.
One of the benefits of WiFi is that it’s essentially wireless Ethernet. Ethernet addressable devices are innately Internet Protocol (IP) addressable which means that if your sweater button can connect to a WiFi network, it can also behave as a bona fide IP node on the Internet. As a node with an IP address on the Internet, a sweater button can talk directly to other nodes and other nodes can talk to it (for example, making an HTTP-based REST request).
Though they occasionally connect via WiFi, smartphones and other devices whose connectivity is provisioned by carriers like AT&T and Verizon are also IP addressable. However, compared to WiFi, the cost of wirelessly provisioning each device is expensive. In other words, the cell network [sic] isn’t a very good alternative for directly connecting things to the Internet. Even worse, in the case of battery-powered devices, today’s low-power WiFi radios can outlast an LTE radio (the kind that connects smartphones to the local cell tower) by months or, in some cases, more than a year according to Broadcom.
During Broadcom’s briefing, home automation connectivity solutions like ZigBee (used for connecting appliances, thermostats, gauges, meters, etc.) were denigrated as being too complex. Ashok Sabata, president of thing-maker Aginova described ZigBee as a “configuration nightmare.” Referring to the gateway that ZigBee-enabled devices must connect to (somewhat akin to a cable-modem), Sabata said “there’s too much in-between.” Lack of IP addressability could also be a dealbreaker if RESTful APIs are involved at the device-level.
You Want My Smartphone To Do What?!
Broadcom CEO Scott McGregor said that some things will connect via hyper-local wireless technologies like Bluetooth and NFC, relying on smartphone-tethering to route data and instructions to and from the Internet when required. But in that use case, the smartphone plays the same routing role as a ZigBee gateway would. Such smartphone tethering will also place an additional draw on some already-overtaxed smartphone batteries. But in response to my question about that issue, McGregor downplayed the impact as being negligible. As someone who relies on every ounce of power his smartphone can deliver and who religiously turns the Bluetooth radio off when it’s not needed just to preserve the battery, I’ll believe it when I see it.
Suffice to say, between the need for a go-between, the power issues in battery-powered situations, and lack of IP addressability for the such connected things, the hyper-local wireless tethering options are also less than ideal. So, it comes as little surprise that tiny low-power, IP-addressable WiFi devices that can run for many months, or even a year or more on a small battery are emerging as the preferred standard of IoT connectivity.
But, if you ask me, WiFi could also end up as one of IoT’s achilles heels too. Many IoT devices — especially wearable ones — will not have a keyboard or screen. Configuring a device for WiFi that has no keyboard or display can be challenging; particularly if the WiFi network is secured (very much the norm today).
In my case, my home WiFi network relies on both password protection and MAC address whitelisting (every Ethernet device has a unique hexadecimal MAC address and only known MAC addresses are allowed to associate with my network). Taking the connected sweater button as an example; with no keyboard or display, how would I configure it to connect to my network (which also requires discovery of its unique MAC address)?
The answer is that you’ll need another device, like your smartphone, to remotely configure the IoT device. According to Broadcom, when an IoT device powers up for the first time, it can power up as a WiFi access point to which a smartphone or tablet can directly connect. Once connected, the cell phone could browse to some configuration pages that are served by the device’s tiny Web server. Alternatively, the provider of the IoT device could offer a configuration application that runs on your smartphone or tablet (Google used the same approach for configuring the Nexus Q). Either way, once you’ve gained this sort of remote access to the device, theoretically you should be able to configure it.
But if you ask me, it’s a technical if not messy approach that will frighten many mortals. To the extent that a second device has to get involved, it already resembles the complexity of ZigBee and perhaps the pot calling the tea kettle black. If you’re a developer, engineer, or the person in your neighborhood that everyone turns to for tech support, then you’ll probably be able to figure it out. But a lot of people will get stuck, share their nightmare on the social networks, and return their things.
Then, apart from privacy concerns, for those of us who manage to configure our sweater buttons to connect to our own WiFi networks, what happens when we roam to another WiFi network? What if you don’t have your smartphone?
Now you know why I’m thinking that WiFi is both a blessing and curse for IoT. Whatever the solutions to these challenges will be, I look forward to trying them out and reporting on my findings here so that ProgrammableWeb.com’s developer audience can figure out how to best take advantage of the Internet of Things.
By David Berlind. David is the editor-in-chief of ProgrammableWeb.com. You can reach him at firstname.lastname@example.org. Connect to David on Twitter at @dberlind or Google+, or friend him on Facebook.