Protocol wars in home automation could reach an armistice



Multiprotocol chips are allowing creation of IoT devices that seamlessly switch among competing connectivity channels

By Richard Quinnell, editor-in-chief

IoT developers targeting home and building automation once needed to choose which wireless connectivity option to implement. Wi-Fi, Zigbee, Thread, Bluetooth, and others competed for several years to become the de facto standard for home automation by virtue of superior market acceptance, yet none have won a decisive victory. The advent of multi-protocol wireless SoCs may now be resolving that conflict, but not by declaring a winner. Instead, the new devices are allowing an armistice in which the competing wireless approaches co-exist and interoperate without surrendering any market share.

One reason for the long standoff has been the diversity of requirements on home automation design. Wi-Fi has the advantage that it is already in the home servicing computers, tablets, and streaming media devices. But for the IoT node, the power requirements of Wi-Fi are unsupportable when battery operation is needed. Low-power applications, instead, have turned to Zigbee or one of the other 802.15.4 wireless protocols to maximize battery life or have opted to use an NFC or Bluetooth connection to a smartphone. In these cases, connection to the internet requires an additional hub device (the phone can serve as that hub). For the devices to communicate with one another, they typically would exchange data in the cloud rather than directly.

The competing technologies were all trying to encourage consumers to pick them, thereby defining a winner in the protocol wars. But consumers didn’t flock to any one approach in droves. Confused and unwilling to risk investing in something that could become obsolete, they mostly just held off purchasing anything.

But the landscape has changed in the past year with the advent of SoCs that implement multiple wireless protocols. What began with families of code-compatible devices that allowed a single design to offer a range of connectivity options quickly became single SoCs that provided several options in the same chip, first for gateways and then for edge-node devices. With the ability to switch among the protocols as needed, these SoCs have enabled the design of devices that can be configured to work within a home automation system regardless of the protocol that the consumer has adopted.

Multi-protocol SoCs are enabling design of home automation products like the Homey that can connect to several wireless network types, allowing cooperation instead of competition among technologies. Image source: Kickstarter.

In the most recent example, Redpine Signals has implemented three different wireless protocols in a module containing only one active radio. Furthermore, the devices utilize a “big-little” architecture for their processing and wireless connectivity, allowing rapid transitions between high-performance and low-power operating modes. The result is a combination of low power and multiple channel operation that allows even battery-powered edge-node devices to support a multitude of wireless protocols essentially simultaneously.

Redpine’s multi-protocol devices come in three flavors. The WiSeMCU RS14100 is a low-power, enhanced-security wireless subsystem available in both SoC and module forms. The RS9116 is available as n-Link, which provides a connectivity subsystem for designs with large host processors running application code under Android, Linux, or Windows, and as WiSeConnect, which targets embedded applications and provides its own MCU, allowing it to operate with smaller host MCUs or as a standalone processor running the application code. All three devices are equipped with a wireless transceiver capable of running dual-band (2.4-GHz/5-GHz) Wi-Fi (802.11a/b/g/n), Bluetooth 5, and 802.15.4 wireless protocols, which include Zigbee and Thread.

The advent of multi-protocol radio modules is bringing an armistice to the protocol wars in home automation. Vendors will no longer need to be concerned that their chosen approach will get edged out of the market, and consumers will no longer need to worry about their choices becoming obsolete. It’s a relief for all concerned.

What will be happening instead is that home automation devices will increasingly be able to connect with a single hub that supports all the various wireless protocols, and devices themselves will be start becoming able to connect via several different protocols without suffering cost or power penalties. Instead of needing separate networks for each connectivity type, consumers will have a heterogeneous network that supports whatever device choices they choose to make. Furthermore, these devices will be able to communicate directly, increasing device responsiveness and freeing them from dependence on the cloud for their coordination.

The first building blocks of this multi-protocol approach are already available and were on display at CES 2018. Both LG Electronics and Samsung announced televisions and appliances that could serve as hubs for home automation systems. The Open Connectivity Forum was demonstrating the middleware that allows home automation devices using different protocols to interoperate through such hubs.

Personal voice assistants were also on display that could serve as a multi-protocol hub for home automation. Chipmaker Qorvo, in conjunction with device maker Humax, announced the creation of a voice assistant that links Zigbee and Thread networks to the device and through it to the cloud. European device maker Athom also had a multi-protocol voice assistant on display: its Homey platform. This device bridges six major home automation wireless channels, including Wi-Fi, Zigbee, Z-Wave, and even infrared.

The diversity in wireless protocol options will remain in place for some time to come because each offering addresses a different set of needs. But the competition among them to become the dominant technology should ease considerably with their newfound ability to work together rather than in isolation. The protocol wars are not quite over, but at least there is a ceasefire in place, allowing both developers and consumers to embrace the options that they prefer without risk of being on a losing side.