Skip to content

Commit

Permalink
Mention another Zigbee limitation in ZHA docs
Browse files Browse the repository at this point in the history
Mention another Zigbee limitation in ZHA docs
  • Loading branch information
Hedda authored Jun 26, 2024
1 parent 185d779 commit 0d26fc2
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion source/_integrations/zha.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -495,7 +495,9 @@ To help resolve any kinks or compatibility problems, report bugs as issues with

Note that ZHA only supports connecting a single dedicated Zigbee Coordinator radio adapter or module with a single Zigbee network and that the Zigbee Coordinator cannot already be connected or used by any other application. Any devices that are or have previously been connected to another Zigbee implementation will also need to first be reset to their factory default settings before they can be paired/joined to ZHA, please see each device manufacturer's documentation.

Any Zigbee device can only be connected to a single Zigbee Coordinator (only one Zigbee gateway). This is a limitation in the current (as well as previous) Zigbee protocol specifications, governed by the [CSA (Connectivity Standards Alliance)](https://csa-iot.org/all-solutions/zigbee/). As such, it is a limit that applies to all Zigbee implementations, not just the ZHA implementation.
Any Zigbee device is limited to only be paired/joined to one Zigbee Coordinator and only be part of one Zigbee network, meaning that Zigbee devices can only be connected to a single Zigbee gateway. If you want to move a Zigbee device to a different Zigbee network then you need to factory reset that Zigbee device and re-pair/re-join it to the other Zigbee Gateway. This is a limitation in the current (as well as previous) Zigbee protocol specifications, governed by the [CSA (Connectivity Standards Alliance)](https://csa-iot.org/all-solutions/zigbee/), and as such, that limitation applies to all Zigbee implementations, not just the ZHA implementation. This also makes the Zigbee Coordinator a SPOF (Single-Point-Of-Failure) in your Zigbee network, so it needs to be available for your Zigbee devices to stay connected.

Another limitation that applies to all Zigbee implementations is that there is no such thing as "Zigbee over IP" or "Zigbee over LAN/WAN" in the Zigbee protocol specifications. It is therefore not possible to extend the same Zigbee network to two separate locations or sites that can not be reached directly via Zigbee radio signals within the Zigbee network mesh. That means that there is no way to use a so-called "Zigbee network adapter" or similar solutions to convert and bridge a single Zigbee network communication over a different medium such as Ethernet or VPN. As such there are no network-attached remote Zigbee adapters that can span a Zigbee network to remote sites, regardless if the marketing material of such products makes it sound like they can do in "Zigbee Router" mode. The fact is that the "Zigbee Router" feature of such "Zigbee network adapter" products puts their Zigbee radio chip into stand-alone mode so it works like any Zigbee Router device, disconnected from the Ethernet network part in those products.

Support for commissioning Zigbee 3.0 devices via "Install Code" or "QR Code" via the 'zha.permit' service has so far only been implemented for 'ezsp' (Silicon Labs EmberZNet) or 'znp' (Texas Instruments) radio type in ZHA. Other radio types are missing support in their respective [radio libraries for zigpy](https://github.com/zigpy/) or manufacturer's firmware commands/APIs.

Expand Down

0 comments on commit 0d26fc2

Please sign in to comment.