Just before the industry headed into the holidays, and just as we were putting the finishing touches to our article about Ikea joining the Zigbee Alliance, the news broke that Amazon, Apple, and Google had 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 the venerable Open Connectivity Foundation’s involvement. Well, over the break, the OCF has fired back, and while the Zigbee news is promising, we are still stuck in a protracted standards war.
The new initiative is called Connected Home over IP (CHIP), and an image from The Thread Group perhaps best illustrates the proposition. In the stack, you can see that in the current world, on the left hand side, there are multiple radio choices at the bottom of the stack, with an internet connection (IP) sitting above them that then connects them to the different application layers . In the new proposed dynamic, on the right side, there would be a common application layer, sitting above the common IP layer, which should help with device and application integrations.
This image from Volansys handily conveys some of the evolutions in Zigbee and Thread (left to right, old to newer), in the wake of Zigbee’s dotdot proposition. Essentially, dotdot replaces the old Zigbee Cluster Library (ZCL) application layer, but also allows users to choose a different network stack, in this case the Thread one, as seen on the right, or WiFi, Bluetooth, and so on.
So, it seems sensible to conclude that CHIP is going to feature some combination of components, contributed by its collaborators, to create a common tongue for IP-compatible smart home networking – ‘built from existing and market-proven technologies.’
Zigbee’s dotdot is likely going to play a major part in the new open source standard, given that CHIP is a working group within the alliance, but Thread really seems to be enthusiastic about the project – but it maintains that it will remain agnostic to the application layer. 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 CHIP website notably does not mention Zigbee in the scope – which is glaring, given that Thread is directly cited as a target. Without wanting to sound too conspiratorial, this might then indicate that CHIP is something much bigger than the alliance that is housing its working group – 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 an air that it was something meant to be larger than Zigbee, but given the Zigbee Alliance’s history, it seems farfetched to think that the alliance would cede to CHIP.
In the scope, the CHIP website’s FAQ asks what technologies will be the focus. The answer is that the “goal of the first specification release will be Wi-Fi, up to and including 802.11ax (aka Wi-Fi 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 then, finally, brings us to the Open Connectivity Foundation – the group formed by Intel to take on the Qualcomm-backed AllSeen Alliance. Initially called the Open Interconnect Consortium (OIC), the group rebranded to the 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 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 for the OCF is 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.” It’s essentially a set of API guides, which guide adopters to create an interface that other adopters will be able to properly interact with. Notably, it sits at 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 much 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, Open Connectivity 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.
Back in the day, you 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 so that your house would exhibit signs of being smart. You would easily pay five-figures for this service, with much of the cost being allocated to the man-hours spent installing and then supporting the installation once the technicians had left. The devices themselves weren’t actually that expensive.
Now of course, we have cheaper devices and plentiful mass market sales channels, as well as Amazon and Google aggressively promoting the hubs – nearly giving them away, at times. But, these devices don’t have a network of professional installers supporting them, and so they rely on DIY installation, as well as making the installation itself as simple as possible.
But what the professionals brought to the table was the ability to provide the ecosystem, with devices that would all work in tandem – mostly because of a lot of hard work before the sale, and also likely due to sticking to one networking protocol. 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 (lock to gateway to WiFi box), and the lights are running on a Zigbee network (light to light to Zigbee gateway to WiFi box), 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.
But the lock and the lights can interact once they are connected to the internet. The tradeoff is that this interaction actually takes place in a couple of cloud applications, hosted in some faraway location, and 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 …’
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 to the fore. The smartphone platforms also need to take advantage of these frameworks, and natively integrate them into the handset experience, but this risks leaving Amazon out in the dark, and because of this, that is yet another battle that needs to be fought, in time – with a hint of irony, in that Amazon’s dominance in the smart home came from its failure in smartphones.