Failover / High Availability für ZigBee Devices?

[Raven]

Servus,

da Zigbee nur einen einzigen Koordinator pro Netzwerk unterstützt, ist eine Failover-Lösung wohl nicht so einfach, wie bspw. mit der VCCU für Homematic Geräten.

Ich hatte zu diesem Thema hier im Sub-Forum nichts gefunden, daher mal ChatGPT befragt.
Demnach gibt es einige Ansätze und hier musss ich mich in diese noch reinfuchsen:

- Zigbee2MQTT mit OpenThread Border Router
- Zwei Zigbee-Netzwerke parallel

Welche Failover / High Availability Lösungen für ZigBee Geräten habt ihr im FHEM Umfeld eingesetzt?

Meine FHEM-Lösung (hauptsächlich Homematic und Hue-Geräte) läuft seit über 10Jahren und "langsam" muss man damit rechnen, daß die Hub/Bridges (HMLan, Hue brigde etc.) irgendwann nun technisch ausfallen, daher die Frage nach einer ZigBee Failover Lösung.


Danke vorab.

[Beta-User]

Nun ja, als echte "Failover/High Availability"-Lösung würde ich das nicht bezeichen, aber hier mal meine bisherigen Erkenntnisse:

- zwei Netze parallel sind eher nicht hilfreich, und (v.a.): man kann auch nicht ein Gerät _gleichzeitig_ an mehreren ZigBee-Netzen anmelden. Dieser "Tipp" dürfte also eher eine Sackgasse sein (es sei denn, du kannst alles doppeln und mit den Parallel-Geräten dasselbe machen wie mit den Hauptgeräten ).

- Bei zigbee2mqtt (und übrigens auch deconz) kann man einfach ein backup nehmen und (mindestens) ein gleiches IO statt des "defekten" verwenden. Dazu muss die jeweilige Installation nicht auf derselben Hardware laufen, und es scheint auch nicht so zu sein, dass irgendwas zum Netz auf den IO's gespeichert wird (anders als bei ZWave, z.B.).
Getestet habe ich in diese Richtung: z2m mit (normalem CC2652p-?) USB-Dongle (gleiche Installation, Startparameter für den Container geändert, die "Kennung" steht in der yaml/Devices-Liste) und deconz/ConBee II (Backup auf anderer Hardware, anderer Dongle).
Das ist also ähnlich wie in der BidCoS-Welt: man kann einfach ein anderes IO nehmen und dem die "Kennung" der Installation verpassen, (nur dass man bei BidCoS nicht auf ein IO beschränkt ist).

[DeeSPe]

Ich benutze Zigbee2MQTT in einem Proxmox Container.
Meine Proxmox Umgebung besteht aus 2 Hosts an die jeweils ein "SONOFF Zigbee 3.0 USB Dongle Plus" angeschlossen und eingebunden ist. Somit kann ich den Zigbee2MQTT Container zwischen den beiden Hosts hin und her migrieren und die Funktionalität bleibt erhalten. Es werden ja, wie Beta-User schon geschrieben hat, keine Daten auf dem Dongle gespeichert, sondern nur in der Software.

Gruß
Dan

[Raven]

Vielen vielen Dank für die beiden Kommentare.
Darauf basierend hab ich mir nochmals die ChatGTP Vorschläge angesehen und denke nun, daß hier die AI "mal wieder" Mumpitz liefert.

Einige Auszüge aus dem Chat:

Einige Zigbee-Stacks wie Zigbee2MQTT mit OpenThread oder Silicon Labs Multiprotocol erlauben mehrere Koordinatoren, die sich gegenseitig als Backup dienen können.

Multiprotocol-Firmware (Silicon Labs / TI)
Ermöglicht parallele Zigbee- und Thread-Netzwerke mit mehreren Backup-Koordinatoren.
Silicon Labs (z. B. EFR32MG) und Texas Instruments Chips (z. B. CC2652) können Multiprotocol-Firmware nutzen.
Mehrere Geräte mit derselben Firmware können als Koordinatoren arbeiten.
Der Primary Koordinator verwaltet das Netzwerk, aber ein Backup-Koordinator kann übernehmen.

Zigbee2MQTT so konfigurieren, dass es den primären und sekundären Koordinator nutzt
In configuration.yaml:
serial:
  port: "tcp://192.168.1.100:8888"  # Primärer Koordinator
  adapter: "zstack"  # Für CC2652P

backup:
  port: "tcp://192.168.1.101:8888"  # Sekundärer Koordinator
  adapter: "zstack"

Basierend auf Euren Antworten und meinen anderen Web-Recherchen bzgl. Failover für ZigBee, bin ich überrascht, dass hier im ZigBee Umfeld grundsätzlich keine (besseren) Lösungen existieren.

Fazit für mich: Ich werde mir noch einen zweiten SMLIGHT Ethernet Koordinator zulegen und noch mehr Fokus auf ein Backup von den Z2M Daten legen und (automatisierten) Failover testen.

[Nighthawk]

Eine kleine Korrektur, es wird durchaus etwas auf dem IO gespeichert, nämlich die bekannten iee Adressen in den NVRam.
Zigbee2Mqtt sichert allerdings immer wieder den Inhalt dessen in der Datei coordinator_backup.json und schreibt es bei einem neuen IO einfach zurück.
Solange das zweite IO den gleichen Chip nutzt wie z.B. CC2652 von TI, gibt es keine Probleme, hat der zweite Koordinator einen anderen Chip, wie z.B. SONOFF ZBDongle-E der den SiLabs Chip EFR32MG21 beherbergt würde es nicht funktionieren.