There's a huge void at the heart of the Internet of Things

Closed systems do not an internet make. It's time to change that before it's too late.
Written by Simon Bisson, Contributor

Everything is smart, but how connected is it really?

It's a couple of months or so since the end of the 2016 CES, and the big themes from the show are finally starting to become clearer to me. Unusually, though, the biggest theme of the year is actually an absence, a technology that's clearly desperately needed, but which hasn't made its way out of the lab into the wider world - a technology that the later it arrives, the harder it will be to implement.

The show was full of dumb screens and smart devices - but with no way to bring them together. Sensors are everywhere, but they're solitary devices, unable to be part of a holistic web of devices that exposes the world around us, giving us the measurements we need to understand and control our environments.

While there are moves to develop communication and API standards for these devices, through standards like AllJoyn and Open Connectivity Foundation, the backbone is still missing: a service that will allow us to work with all the devices in our homes.

Take my home for example: currently I have a bunch of Arlo security cameras, some Greenwave LED lightbulbs, a Nest smoke alarm, an Amazon Echo, and a Netatmo weather and pollution sensor. They're all smart devices, all online, and all completely incompatible, mixing Zigbee, wi-fi, and low-power wi-fi. I could connect one, or maybe two of them together using cloud services like IFTTT, but complex rule sets are out of the question. Some connect to my wi-fi network directly, while others have their own proprietary gateways.

Now, I've got enough of a background as a developer to track down the appropriate APIs for each device and build an app or two to co-ordinate specific actions. That'd allow me to turn the lights on if my smoke alarm triggered, or to check its sensors if there was an unexpected pollution alert, or ask Alexa to dim the room and play some ambient electronica when I open a new file in my ZDNet blog post folder on OneDrive. After all, that's the ubiquitous computing world I was promising in the internal papers I wrote back when I was doing research at one of the UK's main telecoms labs in the early 1990s.

I've even got plenty of tools and hardware I can use, from a collection of Raspberry Pis, and Intel Galileos, to a set of Arduinos and Arduino-compatible devices from a range of vendors, including some that offer wi-fi and cellular connectivity. Then there are plenty of programming tools, with languages and libraries that are designed to work with asynchronous message-driven connections, letting me write the code I need to bring devices, sensors, and the rest of the web together.

Building that code isn't hard, either. One of the more interesting IoT development platforms is Node-RED. It's a semi-visual programming environment that allows you to drag and drop code modules, linking them to a range of inputs and outputs, combining multiple APIs into a node.js-based application that can run on a PC, or in the cloud, or even on devices like the Raspberry Pi.

The nascent IoT world needs more tools like NodeRed for home, hobbyists, and makers. It also needs more tooling like the Azure IoT framework for working with data at scale, or AWS Lambda for handling message-driven actions. With various IoT-focused tooling from the main cloud platforms, there's really no excuse for why we can't fill this yawning chasm.

So why shouldn't the APIs and protocols open up? Why do we have to be trusted partners to connections to the devices we own?

Sadly, it's often poor security architectures that lead to this type of thinking from vendors. Designing for security-by-obscurity leads to laziness; and your control apps end up hard coding user IDs and passwords, as was found in the control software for a common set of networked LED lightbulbs.

It's sad that this still happens, as we've spent much of the last couple of decades training desktop and mobile software developers to avoid these situations (sometimes successfully!). IoT API developers need to consider how to build secure APIs that can be shared publicly. One option is to offer different levels of functionality to different classes of user, perhaps using an API management platform to add an extra layer of control.

The road to an interoperable Internet of Things isn't hard to find. We just need to remember that our things are now software, and apply the lessons we've learnt about building secure and interoperable systems to those software things. And once we've got that secure, interoperable set of things, we can start to build the promised world of ubiquitous computing and ambient intelligence.

More on the Internet of Things

Editorial standards