[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