Update on multiprotocol

Multiprotocol will remain an experimental feature and is not recommended for use.

When we launched Home Assistant SkyConnect, we announced our intent to release firmware supporting multiprotocol, which allows the device's Silicon Labs chip to connect to both Zigbee and Thread networks with one radio.

This experimental firmware has been available since December 2022. Through extensive testing, we have found that although it works in some circumstances, it has technical limitations that lead to a worse user experience. We now do not recommend using this firmware, and it will be experimental for the foreseeable future. Instead, we will focus on making sure the dedicated Zigbee and Thread firmwares for Home Assistant SkyConnect deliver the best experience to users.

If you currently have the multiprotocol firmware installed but don't actively use it to connect to Thread devices, we recommend that you disable multiprotocol. Nothing changes for current users of the multiprotocol firmware who are happy with their experience. The experimental multiprotocol firmware will remain available, but we will not recommend it to new users.

Introduction

Home Assistant SkyConnect's integrated wireless chip supports Zigbee by default. By using the experimental (and not recommended) firmware, the wireless chip can be used in a multiprotocol setup supporting Zigbee and Thread at the same time. There are two major limitations: The two networks have to be on the same channel and share the bandwidth. This page explains the background.

About channels

Both Zigbee and Thread are low-rate wireless personal area networks (LR-WPAN, IEEE 802.15.4). The standard specifies 16 channels in the 2.4 GHz spectrum (channel number 11-25). The standard supports multiple networks on the same channel. Each network is identified by a PAN-ID (personal area network identifier).

The wireless chip in Home Assistant SkyConnect supports all 16 channels. However, it can only communicate on one single channel at a time. Due to this limitation it is crucial that Zigbee and Thread run on the same channel for reliable operation! Thanks to the PAN-ID, the Zigbee and Thread networks are still separated and therefore won't interfere with each other.

The illustration below shows on which frequency range each channel operates. It also shows on which channels a specific protocol operates.

Zigbee/Thread channels 15, 20, and 25 are less likely to be affected by Wi-Fi interference since they are in between the most commonly Wi-Fi channels 1, 6 and 11.


Illustration by Radhakrishnan & Zand, Pouria & Nabi, Majid. (2016). Analysis of coexistence between IEEE 802.15.4, BLE and IEEE 802.11 in the 2.4 GHz ISM band. 6025-6032. 10.1109/IECON.2016.7793984.

About bandwidth

IEEE 802.15.4 (so both Zigbee and Thread) support a transfer rate of up to 250 kbit/s. For typical Zigbee and Thread networks this is sufficient. However, in the multiprotocol setup Zigbee and Thread networks need to share the same channel, and therefor share the 250 kbit/s transfer rate. Furthermore, if Wi-Fi or other 2.4 GHz networks are running in a similar frequency range, transfer rate might be further limited.

For large networks it is advisable to add a second wireless chip. This allows to run Zigbee and Thread each on a dedicated wireless chip and on separate channels.

Resolve channel conflict

You may get a notification stating that the OTBR (OpenThread border router) and ZHA share the same radio, but use different channels. This mode of operation may cause an unreliable network connection. To resolve this issue, you can try one of the following methods:

Related topics