Your browser is not supported. Please update it.

16 January 2020

OCF bites back against new CHIP Alliance for the smart home

As we briefly covered in last week’s edition, Amazon, Apple and Google have come together to create a working group within the Zigbee Alliance to focus on a new open source standard for the smart home – with no sign of involvement from a far older group with a similar aim, the Open Connectivity Foundation (OCF). But the OCF quickly fired back, raising the specter of yet another standards battle in the smart home environment.

The new ZigBee initiative is called Connected Home over IP (CHIP). Rather than the current situation, in which multiple radio options are connected to multiple application layers via an IP connection, CHIP wants to create a common application layer, sitting above the common IP layer, which would simplify device and application integrations.

It is probable it will incorporate some of the evolutions within ZigBee and Thread (the protocol devised by Google’s Nest subsidiary, which shares ZigBee’s dotdot application layer and its physical layer, 802.15.4). Dotdot was already a step towards greater interoperability, because it replaced the old Zigbee Cluster Library (ZCL) application layer, but also allows users to choose a different network stack, such as Thread, WiFi or Bluetooth.

So dotdot is likely to play a major part in the new open source standard, while the CHIP website clarifies which technologies are being contributed – Amazon’s Alexa Smart Home, Apple’s HomeKit, Google’s Weave, and the Zigbee Alliance’s dotdot data models.

However, the website notably does not mention Zigbee in the scope, while citing Thread as a target. This might indicate that CHIP is something much bigger than the alliance that is housing its working group, and that Google’s support for Thread might finally have won out, emphasized by Apple’s recent joining of the Thread board. When dotdot appeared, there was a sense that it was meant to drive something larger than Zigbee, but given the Zigbee Alliance’s long history, it seems farfetched to think that it would cede to CHIP entirely.

In the scope, the CHIP website states: “The goal of the first specification release will be WiFi, up to and including 802.11ax (aka WiFi 6), that is 802.11a/b/g/n/ac/ax; Thread over 802.15.4-2006 at 2.4 GHz; and IP implementations for Bluetooth Low Energy, versions 4.1, 4.2, and 5.0 for the network and physical wireless protocols. The Project Connected Home over IP Working Group will likely also embrace other IP-bearing technologies like Ethernet, Cellular, broadband, and others.”

In another wrinkle, Silicon Labs announced that it will be making Z-Wave a fully open standard, adding the application and network layers as well as the host device communication protocol for other silicon and software vendors to use, as well as the ITU.G9959 PHY/MAC radio specification. This is a good step forward, and means that Z-Wave should more easily be incorporated into whatever CHIP ends up being. Silicon Labs has a foot in nearly every smart home radio camp, and as the owner of the Z-Wave intellectual property, opening it up to other vendors is wise.

This brings us to the OCF – the group formed by Intel to take on the Qualcomm-backed AllSeen Alliance. Initially called the Open Interconnect Consortium (OIC), the group rebranded as OCF and then later absorbed AllSeen, uniting the two efforts to create a common communication framework for device discovery and interoperability.

However, since publishing v2.0 of its IoTivity specification back in September 2018, the OCF hasn’t really accomplished much. This might explain why the CHIP initiative was kicked off, but it still means that IoTivity is kicking around – and to some extent, is being wasted if it is not incorporated. Interestingly, the IoTivity specification is the open source version of the OCF specification, which means that CHIP could just fork IoTivity into CHIP, but given the apparent hostility from the OCF to the CHIP announcement, it sounds like the two groups are a ways apart from full cooperation – despite many common members.

At CES, the OCF announced v2.1, calling it “the world’s first international standard for smart home”, and saying that BSC Computer, Commax, Haier, LG, Resideo, Samsung and Sure Universal are all set to soon complete OCF certification. It did note, however, that it supports Bluetooth, EnOcean, Zigbee and Z-Wave.

But the big new announcement was the OCF Universal Cloud Interface (UCI), which it is billing as the “industry’s first solution to unify the IoT ecosystem through cloud-to-cloud connectivity based on OCF’s work with open standards”. This is a set of API guides, which help adopters to create an interface with which other adopters can interact smoothly. Notably, it sits in the application layer, and not inside the home, which is something of a departure from the initial targets of the OIC and AllSeen – which were more focused on the home itself.

“Different configurations of the same OCF UCI can simplify collaboration between device manufacturers who wish to produce IoT devices but do not have the ability to develop and support their own cloud applications,” said John Park, executive director of the Foundation. “This configuration can also help companies that have cloud applications and wish to expand the number of devices that can connect to them. Specifically, the manufacturers can produce a single device that connects to any cloud application provided both implement the OCF UCI API. This enables a multitude of manufacturers to produce secure, interoperable IoT devices and delivers welcome flexibility to end users.”

A brief recap:

Essentially, we seem to have solved the problem of getting smart home devices to talk to their coordinating cloud platforms, but we have not yet managed to find a way to make all the different devices inside a home cooperate in an actually ‘smart’ fashion.

In the early days of the market, users paid a home automation service provider to build an ecosystem of compatible devices, install them within the home, and then spend hours programming the automations.

Now of course, we have cheaper devices and plentiful mass market sales channels, as well as Amazon and Google aggressively promoting their hubs. But these devices don’t have a network of professional installers supporting them, and so they rely on simple DIY installation.

What the professionals brought to the table was the ability to provide the ecosystem, with devices that would all work together. The direct-to-consumer offerings today don’t have this, and the market currently relies on the voice assistants to act as translators between the devices within a home, acting as the main point of contact.

To this end, the devices inside a home have no idea that there are other smart home devices nearby, nor do they have a way to reach out and speak to these devices directly. An easy example would be a connected door lock and a set of connected lightbulbs. If the door lock relies on a proprietary wireless gateway to connect to the home’s WiFi network, and the lights are running on a Zigbee network, then the lock and the lights have no direct way of interacting – as the WiFi gateway is almost certainly provided by the home’s broadband provider, which is almost certainly not serving up a smart home service based around this CPE.

The lock and the lights can interact once they are connected to the Internet. The trade-off is that this interaction takes place in a couple of cloud applications, mediated by Amazon or Google, acting as the middleman between the two brands of devices.

Because of this architecture, the devices need to be coddled by Google and Amazon, meaning that the consumer is reliant on these two gatekeepers for any of the ‘smart’ automatic automations to occur. In this dynamic, the consumer needs to manually program a function, such as the lights coming on when the door is unlocked, or they have to have this suggested to them by the assistants.

Many consumers will be fine with the suggestions, but the brands involved would like to be able to cut out these middlemen – just in case we get a cold war. If the smartphone app for the lights can check the local area networks for other devices it could interact with, the two brands could begin direct integrations without getting the gatekeepers involved.

However, this requires a framework like IoTivity or CHIP to work. These devices need to be able to find neighbors, and then tell them what actions and capabilities they can perform – ‘hello, I’m a bulb, and I have the following brightness settings’, and so on. So, if the connectivity side of things has been solved, and we accept that we aren’t going to be shifting the market onto one unified common radio protocol, then the likes of CHIP and IoTivity need to come to the fore, in order to bring a proper ‘smart’ home experience.