[REQUEST] Fault Tolerance / High-Availability feature to support multiple RCP radio adapters with automatic fail-over and fail-back between two or more physical OpenThread RCP radios

[Hedda]

Is your feature request related to a problem? Please describe.

This is a feature/function request that is not related to a problem but instead rather asking to workaround limitation in Zigbee specification.

Please consider implementing support for some kind of "Fault Tolerance" (FT) or "High-Availability" (HA) feature to enable having redundent RCP radio adapters and allow automatic fail-over and fail-back (a.k.a. fall-back) between two or more physical OpenThread RCP radios.

Hopefully this fail-safe switching would be implemened to it would work regardless if the physical OpenThread RCP radio adapters are connected directly to the host computer via serial (via UART-to-USB conveter) or via Serial-over-IP over a LAN.

What this feature in combination with Zigbee-on-Host architecture would achieve from an end-users point-of-view is working around the Zigbee specification limitation of not supporting multiple Zigbee Coordinators. As while with this Zigbee-on-Host architecture the user would still only a single Zigbee Coordinator, but that would be by allowing automatic and graceful failover to a secondary RCP radio adapter in case there is a failure discovered with the serial connection to the primary RCP adapter.

Describe the solution you'd like

Allow the user to connect two or more OpenThread RCP radio adapters to Zigbee2MQTT and zigbee-herdsman + allow them to set prioritation of in which order they should be used in case of failure(s), .i.e. primary RCP radio adapter, secondary RCP radio adapter, then have Zigbee2MQTT and zigbee-herdsman only use the first working RCP radio adapter in that list (so that it is still only using a single radio at any one time). If and when connection to the radio fails then make Zigbee2MQTT and zigbee-herdsman failover and establish connection to the secondary adapter.

By moving all processing to the host with his Zigbee-on-Host architecture you have already eliminated most limitations imposed by microcontroller-based Zigbee stacks, but what is left as SPOF (Single-Point-Of-Failure) is still the physical radio adapter, however if you would allow users to add multiple OpenThread RCP radios to the solution (with perhaps a preference list of which should be used as primary, secondary, etc.) and then have the solution failover to the next OpenThread RCP radio adapter in that queue you could at least have a robust setup with redudant hardware radio adapters.

Suggest add GUI buttons for "fail-over" and "fail-back" to allow testing of failover and failback (a.k.a. fallback).

Note that if this feature would be implemented then I believe the most popular use case will be to connect multiple Serial-over-IP bridge network-attached radio adapters using TCP over LAN (with all radios flashed with OpenThread), such as those from TubeZB, ZigStar, and SMLIGHT

• https://tubeszb.com
• https://zig-star.com/projects/
• https://smlight.tech/

Describe alternatives you've considered

Ther aternative is to manually reconfigure the OpenThread RCP adpater connection in Zigbee2MQTT (if possible).

Additional context

Such a "High-Availability" (HA) feature to enable use of redundent Zigbee radio adapter is highly requested. See example:

• https://community.home-assistant.io/t/high-availability-or-getting-rid-of-the-most-critical-spof/802489/

PS: This type of robustness with redundent hardware with are very common in commercial mission-critical Enterprise solutions:

• https://en.wikipedia.org/wiki/Failover
• https://en.wikipedia.org/wiki/Fault_tolerance
• https://en.wikipedia.org/wiki/Redundancy_(engineering)
• https://en.wikipedia.org/wiki/High_availability

[Nerivec]

ZigBee on Host has no concept of adapter or even serial/tcp (except for the minimal adapter but that is only for dev testing).
It just parses whatever data is given to it. This is for the "above" application to implement.

Note: ZigBee coordinators can actually move between router/coordinator jobs. There is also a concept of primary/backup trust center. But I guess no one ever looked very closely at the feature, so no application has support for any of this.

[Hedda]

ZigBee on Host has no concept of adapter or even serial/tcp (except for the minimal adapter but that is only for dev testing).
It just parses whatever data is given to it. This is for the "above" application to implement.

So this feature request should belong to zigbee-herdsman then for its zoh adapter or even at a higher application level?

• https://github.com/Koenkk/zigbee-herdsman/tree/master/src/adapter

  • https://github.com/Koenkk/zigbee-herdsman/tree/master/src/adapter/zoh/adapter

[Hedda]

FYI, the latest ESPHome 2025.10.0 release contains an experimental "Z-Wave Proxy" component which is a custom Serial-to-LAN bridge that proxies UART communication between Z-Wave MCU/SoC hardware and Z-Wave JS via ESPHome’s native API for serial tunneling over LAN:

• https://www.home-assistant.io/blog/2025/10/13/portable-z-wave-with-wifi-and-poe/

  • https://esphome.io/changelog/2025.10.0/

    • https://esphome.io/components/zwave_proxy/

Most interestingly that Serial-over-IP proxy implements "Protobuf" (Protocol Buffers) for serializing and buffering of the Silabs Z-Wave serial communication, which is what makes it a reliable connection (even over WiFi), so wondering if it would be a good idea to use same kind of ESPHome-based solution for this zigbee-on-host project to talk to Silicon Labs hardware for OpenThread RCP?

That way could potentially have multiple Silicon Labs hardware for OpenThread RCP on your network and allow zigbee-on-host to switch?

Recommend that you watch their "ESPHome's Latest Innovations" video from the 14th of October if want a better technical explaination:

• https://www.youtube.com/watch?v=9YfRkqCdD4c

Wondering if that concept could be used in combination with this zigbee-on-host solution to achieve high-availability with two adapters?

tube0013 (from TubesZB) has also been experimenting with that feature for his network-attatched Zigbee Coordinator and Z-Wave adapters:

• Make an ESPHome-based universal USB-to-Ethernet Bridge, a USB to Serial-over-IP (Serial-over-LAN) proxy appliance compatible with standard Z-Wave Controller and Zigbee Coordinator USB adapters tube0013/tube_gateways#239

Very cool setup for this is running ESPHome on a Waveshare ESP32-P4-ETH (ESP32 PoE adapter with USB-host) dev board which allows you to utilize ESPHome's ”USB Host” and ”USB UART” features (i.e. USB-to-Serial converter functionality) as a USB-host to enable you to connect a external USB-serial adapter which you can then proxy. Which I believe could in theory also work with Zigbee adapter too?