Three challenges that we’ll need to tackle unless we want the future of the IoT to to be a dumpster fire.
The Internet of things is here. To borrow a phrase from Gibson, it’s just not evenly distributed yet. From the right vantage point, you can observe enough of the future to forsee some looming problems. These are challenges before us that we ought to solve soon, before unfocused enthusiasm carries us into an Internet of Incomptatible, Insecure and Unmaintainable Things.
The core problem is interoperability. Right now if you have smart objects in your home or business, you’re lost in a maze of twisty little walled gardens, all, well, entirely different. Your Philips lightbulbs use one app. Your Nest thermostat needs another. There have been attempts from some players to build a connecting framework to talk to all your devices; Amazon, Google and Apple all have…competing incompatible frameworks. It’s incompatible turtles all the way down.
An ecosystem of a handful of incompatible frameworks might just be manageable, if distasteful, but we have a chance to agree on some minimum unifying characteristics that will become the bedrock of our connected homes and workplaces, allow a device to be interoperable with any third party hub, and free us from having to implement everything in triplicate (or worse) forever.
These are my demands.
ONE: Security first. Build SSL into everything. Besides being the keystone of confidentiality and authentication, the certificates that devices exchange will serve to identify them long after you forget whether that’s a Philips or a Samsung bulb up in the ceiling. This device is a lightbulb made by Acme Co of Armpit Springs Minnesota, _that _device is a temperature sensor from Blinkenlights GmbH. Your accountants will complain that it costs fifty cents more to use a chip that is powerful enough to handle SSL. Too bad, in a year, it will be zero.
TWO: Standard discovery and installation. Right now the least horrible setup experience is “use your laptop to join your lightbulb’s wifi access point and then visit a web page to configure the device, supplying credentials needed for the device to join your own wifi”. This won’t scale; nobody wants to do this over and over for every new lightbulb they buy from now ‘til the sun boils the oceans. We need to figure out a better way, for example a common meaningful network naming for unconfigured devices, and a DHCP payload that lets a hub push setup instructions to an unconfigured device.
THREE: Support HTTP and/or MQTT. At a minimum, everthing should support a simple self-documenting REST api, or the MQTT telemetry protocol. Both protocols should use well defined idioms to interact with hubs. No inventing your own half-baked UDP transport that only talks to your insecure proprietary cloud service. Remember how how the first generation of USB devices required unique drivers for every darn device, before camera, storage and other product groups got behind common class-based device schemes? Let’s not do that.
FOUR: Painless update management. (I know I promised three, but I lied). Since all our devices have signed security certificates (demand one) we know the identity of the device and its maker. All devices should be able to accept signed updates from home base or the hub. The hub can use the device identity to discover if the device is up to date. Manufacturers should publish version info to a distributed registry (I don’t see why we can’t use DNS for that, following in the steps of Sender Policy Framework) allowing hubs to check device status efficiently.
So, some basic steps to make our future lives much less frustrating. I’m adopting these principles in my own devices and hub. That right, now there are N+1 competing frameworks.
(This article originally appeared on Medium)
