This may not be the IoT standard you were looking for

The Open Connectivity Foundation (OCF), which manages the IoTivity specification, last week finally released an update to its long-awaited standard for the internet of things. The new standard, called IoTivity 2.0, adds a layer of security and addresses the uncomfortable fact that the earlier IoTivity standard couldn’t run on the smaller devices that make up many of the “things” in the internet of things.

The question now is whether the spec offers too little too late, or if it can deliver on the promise to create an interoperable internet of things that has so far stymied adoption and frustrated users.

First, some history.

The precursor to the OCF was created in 2014 by a group of companies including Samsung and Intel; its goal was to develop a way to enable a variety of connected devices talk to one another. The organization wanted to create standard data schemas that could describe a connected device and allow the device to communicate its device type and properties to other gadgets.

For example, a light bulb schema would note that the device is a light bulb, that it can be turned on or off, dimmed, and perhaps handle different colors or types of white light. Currently, light bulbs from different manufacturers have their own unique APIs that can communicate with other devices or software about such properties. But because each API is unique, anyone building software for the smart home has to bring in dozens of APIs just to control lights. Multiply that by any number of connected devices, and you can see why a standard is needed.

But that same promise of interoperability also scares vendors. Most companies would love to lock consumers into buying all Philips Hue bulbs or all Lutron light switches. Not only can a standard boost individual sales, it can give the companies that “win” in each category more power to get other companies to use their APIs and work with them.

And because getting and keeping data from these devices is so important, it can also help companies when they are trying to negotiate terms around what gets shared and how two devices interoperate together. Basically, the tech companies are taking the philosophies they learned from the mobile OS and app ecosystem and trying to apply them to every mundane device they can.

Consumers, meanwhile, hated the standard. They found it confusing to have to think about what light bulbs they have when trying to buy a thermostat. It’s also frustrating when devices don’t easily work together. Frankly, it has held the entire industry back.

With IoTivity, the OCF was supposed to change all that. Devices that had the certification would automatically be able to communicate, no matter the manufacturer. But that standard was a long time coming.

And now that it’s here, the 2.0 version of the spec seems fragmented. I spoke with several people who have worked with the OCF on IoT standards-setting efforts, and there’s a mix of optimism and angst that makes it hard to see whether or not IoTivity will achieve what it was designed to do.

Noah Harlan, partner at Two Bulls, which helps businesses build internet-connected devices, said his company gave up its OCF membership “in frustration with the political infighting and slowing progress on usable code.” Harlan has somewhat of an ax to grind. He was president of the AllSeen Alliance, a group that was working on a rival standard that eventually joined forces with the folks working on IoTivity.

On the other hand, French industrial company Legrand has been building OCF-compatible products (or products it hoped would be compatible once the standard was set) for the last few years. And I’ve met two entrepreneurs planning startups that will build enterprise and smart home management tools on top of IoTivty and OCF standards. Moreover, OCF on Thursday said members Haier, Electrolux, Samsung, and LG Electronics are building IoTivity-certified products due for release in 2019.

And the security challenges that were holding up the standard have been solved by the OCF offering public key encryption for compatible devices. Which means manufacturers can host the certificates required for this security scheme in their own clouds or an OCF cloud. So that’s a good step. But it only secures the way devices can trust which other devices they can share data with. It doesn’t deal with how data is stored in the cloud or even if the data is encrypted during transfer. David McCall, chair of the strategy work group at OCF, says that the OCF has a security checklist it offers to members, but doesn’t mandate their adherence to it.

So manufacturers will still have to handle a lot of their own security. That’s not a deal killer, though, and many companies are building more secure devices. After all, IoTivity is an interoperability standard, not a security standard. But less experienced device makers probably could have used the extra help.

The question I still have about the new standard is how it handles smaller devices, those with less memory and processing power. There is now something called IoTivity Lite, which doesn’t include all of the features of the latest version of the IoTivity specification. Originally, the IoTivity standard ran on Intel-powered computers. An application using version 2.0 of the IoTivity standard launched this week requires 573 kilobytes of data, whereas IoTivity Lite uses 160 kilobytes. But the Lite version does let the specification run on embedded operating systems.

Finally, it’s not clear how interoperable the spec will be. It covers 115 different device types (the OCF calls these Resource Types), and it seems relatively easy for someone (even a non-member) to submit new device types to the group, which should help people who create new products get them listed in the standard and working with all of the other products.

However, the pitch that one could assemble a group of IoTivity devices together and they would all work under one app in a fairly seamless way may not be as seamless as the organization makes it sound. While the different schemas will control basic functionality such as the on/off function of a light bulb, they may not provide deeper-level data such as specific colors or the role of the bulb in specific lighting scenes.

Currently this is a challenge that many of the standardization efforts face. Again, every company wants user data, and the best way to get it is to force the consumer to use the company app. So even if a device function works in a standard, it may not have access to all of the features.

I had hoped for more. I think most consumers did, too, which is why I’m going to watch the rollout of these products next year like a hawk. I’ll be looking for the number of products launched and how well they work together without having to resort to dedicated apps or linking various accounts. In short, I’ll be looking for an internet of things that just works.