The Ultimate Guide to Smart Home Protocols

Updated on 17th Oct 2020 16:52 in General, Smart

Home automation is primarily supported by the interconnection of many different devices, all talking to each other to make your life easier. Each connected device needs to be able to talk to other nodes on around it, but how? This is where protocols come in, they specify how to communicate and ensure compatibility. One decision that every smart homeowner needs to make is which protocols will be used, which can be pretty difficult as there are so many. Here we are going to list every smart home protocol available and provide some insight about why you might pick each one.

A note on protocols

According to Oxford languages, a protocol is "a set of rules governing the exchange or transmission of data between devices.", which is a fancy way of saying it is a policy that specifies how equipment should communicate. That said, there is a lot left to interpret within that definition, so it's important to understand the subtle differences. As an example, "WiFi" is a protocol, but it does not do too much on its own as most devices communicate over IP (Internet Protocol). This layered situation is not unusual and is actually how the protocols are designed! We will be considering protocols in a way that you see them typically advertised, but keep in mind that technically, calling the device "WiFi" may be misleading.

The types of protocols

We are going to call them types, but they are a lot more like layers. Each layer is concerned with a specific part of the process, such that the higher levels can ignore physical things like radio waves and focus only on their primary role. The bottom layer takes care of sending the electrical signals that transport information, while the top layer sits in software generating the information. Most of these protocols reach multiple layers, but we will be placing them in categories based on whether they have smart-home specifications. The ones that do will have a software part responsible for establishing how devices should be controlled.

An example could be that the protocol specifies that to the turn on a light, you need to send the "LIGHT 1 ON" command, or something similar. Then any connected controllers will know, without being from the same brand, how to turn on the light by sending the right command. The point is that any manufacturer can make products that respect those rules meaning that now any of their devices will work with any other brand out of the box, so long as they use the same protocol.

Communications only

These protocols were designed to be used to communicate between point A and B. They don't specify what the standard commands are to perform a specific action, leaving that up to the manufacturer. Many devices will be sold as compatible with protocols from this category. Still, in reality, they are compatible with some higher-level protocol and simply make use of these to communicate.

WiFi

WiFi is more specifically a family of wireless network protocols first introduced in 1998. Within this family exist the specifications for all the different versions of WiFi you may find, from 2.4GHz to 5GHz. It is by far one of the most common protocols, likely as a result of most homes already having the infrastructure to support it. The standard uses the Internet Protocol (IP) to communicate with other devices, just as laptops or mobile phones would. It is possible to use with mesh networking but typically will require many expensive access points to setup.

In the world of smart homes, WiFi is the wild west of protocols. Products that list compatibility with "WiFi" could be any number of things, as the protocol only specifies the communication, not the control aspect. As a result, most devices specify their own protocols making compatibility difficult, to say the least. Will it work with Smartthings or Home Assistant? Who knows! Another big advantage is access to the internet, which allows "hubless" products that rely instead on remote servers to allow automations and remote control.

Ethernet

Usually used to connect computers to the Local Area Network (LAN) with a wire, the specification was first introduced in 1980. While it is less common, it is still widely used in certain larger fixed equipment. One nice advantage of Ethernet is that Power over Ethernet (PoE) can be used to provide a device both with a network connection and with power. PoE is common in security camera installations as only one wire is required for a stable connection and power. As with WiFi, it uses the Internet Protocol (IP) to communicate from one device to another but does not provide a higher level standard on how commands should be sent.

Being a wired protocol, Ethernet will typically offer a higher degree of reliability when compared with wireless standards. As each wire will typically only be used for communication, the chances something interferes is rather low. For some uses, the increased reliability offered by Ethernet is worth the extra effort involved with a wired solution. The wired aspect of this solution is, of course, the biggest drawback. Most homes will have wiring already in place for Ethernet as it is quite common, but otherwise, new wires will need to be installed.

Bluetooth

Bluetooth is a wireless standard developed by the Bluetooth Special Interest Group in 1989. Originally made for short-distance point to point communication, the protocol has since expanded into many different facets. Often the cheapest smart devices will use Bluetooth, making it a good choice for a budget smart home. Modern versions support native mesh networking, but unfortunately, this is not too common in the smart home industry yet. That means that the minimal range will likely be a big issue for most as without a connection to a controller none of the smart functionality will work. As with the other protocols in this category, Bluetooth does not specify any commands making compatibility a challenge.

Communications and control

In this category are all of the protocols that have been designed for use with smart homes. They enable both communications from point A to point B and specify what the commands should be for standard devices such as a light or a switch. This typically means that any company that builds a compatible light will just work when it connects to the network since all the controls are standard.

Z-Wave

Z-Wave is a wireless standard designed by Zensys in 1999. It is very commonly used for smart devices due to its extensive feature set which provides almost everything smart devices need. The protocol is specially designed to be low power which makes it perfect for use in battery-powered equipment such as sensors or locks. Each non-battery powered node in a Z-Wave network natively acts as a repeater within the mesh network, extending the range beyond what would otherwise be possible. Another benefit is that Z-Wave specifies the commands and capabilities of each device on the network, allowing the use of any controller.

One of the staples of Z-Wave is the strong inter-device compatibility, as any product with the "works with Z-Wave" logo is guaranteed to work with your existing system. All of these features make this a solid choice, although compatible products will typically be quite a bit more expensive than some competing protocols. Part of the reason is that to ensure compatibility, the Z-Wave Alliance requires the certification of each device before it can be sold as compatible.

Zigbee

Zigbee is a wireless standard designed by Zigbee Alliance in 2004. It is commonly used by smart devices and is a classic competitor to Z-Wave as they both share many similarities. The protocol is supported by many popular hubs such as Smartthings, some models of the Echo hub, and some models of Google Home. One of the reasons for this adoption is the open nature of Zigbee, which is a lot less strict about what is allowed and what isn't. It is also great for low power applications, perfect for battery-operated devices such as sensors and locks. The protocol natively supports mesh networking and allows a huge number of devices on the network, supporting upwards of 64,000 nodes in theory.

Unlike Z-Wave, Zigbee does not specify commands nearly as much and instead relies on manufacturers to follow guidelines to make things interoperable. In most situations, things will work just fine, but it is important to keep in mind that it is possible for Zigbee compatible products to not work properly together. Despite this, the list of compatible products is very long, making it a thriving ecosystem that has plenty of options for every situation. Devices tend to be a bit cheaper too!

KNX

KNX is a protocol administrated by the KNX Association, which was formed in 1999. It supports the use of Twisted pair wiring, Power-line networking, Radio Frequency (RF), or Internet Protocol (IP). The vast amount of options in communication mediums is one of the benefits of using KNX as the same protocol can be used in many different situations. If there are no wires that reach a certain location, the RF feature can be used while the rest of the home makes use of IP, as an example. KNX provides the full system, from the communications to the software allowing tight integration for some awesome features.

One such feature is the decentralized network structure, which can increase the reliability as things continue to work if the WiFi goes out or if someone unplugs the wrong power bar. The ecosystem is also highly compatible as everything is standardized meaning devices that are sold as compatible with KNX will easily integrate into the rest of the system. An important note is that due to the nature of this protocol, it is typically installed professionally by an installer, as opposed to being something you put together yourself piece by piece. (DIY is allowed, but it can be complicated)

Universal Powerline Bus (UPB)

UPB is a software protocol developed by Powerline Control Systems in 1999. It is designed to allow communication over the powerlines that already exist within your home. That means you can have wired home automation without rewiring your home using existing wires! An obvious advantage is the increased reliability provided by a wired protocol. However, it should be noted that as the powerlines are shared with a lot of equipment, something can cause interference. Normally this would be pretty rare though as manufacturers try to keep their products from messing with the mains.

Another advantage is that things can continue to operate without a central controller, communicating directly to each other instead of going through the main node. This can be useful to keep certain functionality going when the controller goes offline or is otherwise unavailable. The biggest downside with UPB is that it is not very popular and has a relatively small number of compatible devices. The lower rate of adoption and difficulty of finding a compatible hub might take this protocol off the list, especially if you want plug-and-play functionality and integration with things like Alexa.

Thread

Thread is an IPv6-based wireless protocol developed by the Thread Group in 2014. There is not much to be said about Thread as it stands as the protocol is still very new and has yet to see widespread adoption. Currently, only the Google Home hubs support Thread with no other hub having support for it. That limited hub support is matched with a tiny list of devices, which will hopefully grow in the future. The protocol is low power making it good for battery-powered devices. It is similar to WiFi in many ways but makes improvements to reduce the power draw.

Also, the system fully supports mesh networking out of the box and was designed to support it natively. Those considering Thread will want to carefully check the list of supported devices as the selection is quite limited at the moment. In the future, the ecosystem could become much more adopted, but as it stands, there are not too many options. Typically when systems are more exclusive (less competition), they are also more expensive, this is likely the case here. 

Insteon

Insteon makes use of powerlines or radio frequency (RF) to communicate and was introduced by Smartlabs in 2005. It provides native support for mesh networking and is a generally closed ecosystem. As a general rule, most devices compatible with Insteon will also be manufactured and sold by Insteon with limited support for non-Insteon products. The advantage of this is that everything is very compatible and any device will work with your hub without much fuss. The downside is that everything must be purchased from one company which can increase the price and make some feel they have too much reliance on a single entity.

Another interesting feature is the support for HomeKit via the HomeKit-enabled Insteon hub, allowing the use of Apple devices such as Siri within the ecosystem. There are a few cases of partnerships like this, such as with the Logitech Harmony hub, but they are quite limited, so don't expect to find loads of cheap devices on Amazon. The cost is perhaps one of the biggest downsides is the prices are almost all set by Insteon offering little competition. I would only recommend using this protocol if you value plug-and-play more than anything else.

Software protocol

This category is for protocols that do not worry about how device A talks to B. Instead, they only take care of the control aspect, allowing various devices to be operated with a single language. They could use WiFi or Bluetooth or any other communications protocol to talk, but what matters is that they respond in the way specified by the software protocol.

HomeKit

HomeKit is a popular software framework introduced by Apple in 2014. It can use both WiFi and Bluetooth to communicate with compatible devices and can operate entirely offline. HomeKit leverages the local network, typically over WiFi, to establish a connection with smart devices. The smart device will then send messages to the HomeKit hub directly instead of using the internet, as many competing standards do. Bluetooth obviously normally used to connect from one node to another within a relatively short distance meaning almost every one of these devices is already offline.

Hubs are required with HomeKit to set up automations and to control devices remotely over the internet. A unique feature of HomeKit is the ability to use an iPad, Apple TV, or a HomePod as a hub which can be a huge benefit if you already have one of these devices. One of the biggest downsides is that the protocol is relatively new and has a way to go in terms of compatibility, although it has already done a lot more than Thread. A program called Homebridge can also allow the integration of devices that are not officially compatible, as seen in my article here.