2. Conbee II als “hot”-Zigbee-Netz-Fallback, 2 ioBs

[ptr]

1x ioBroker im Proxmox LXC auf Server1 mit ConbeeII-Stick. Funktioniert.
Als Fallback gibt es eine zweite Server-HW auf die Proxmox z.B. per migration den ioBroker-LXC schieben kann.
Die Frage ist, wie ich dann den zweiten Conbee2-Zigbee-Stick einbinde, dass dieser auf dem HW-Server2 direkt läuft nach der Migration.

Bisher habe ich über deConz alle möglichen IDs der beiden Conbee-Sticks “gleichgemacht”. Also z.B. die MAC. Das ist jedoch nicht die Lösung anscheinend. Was ich bisher nicht einstellen konnte ist die “NWK-Address”, hier lässt sich kein genauer wert einstellen. Außer wohl 0x0000. Static. Wenn man das tut funktioniert jedoch bei mir kein Geräteanlernen mehr.

-> Die Frage bleibt also, wie man das Zigbee-Netz so “verarscht”, dass es denkt dass der zweite Conbee2-Stick eigentlich der erste wäre und damit einfach genau den gleichen job macht…

Ergebnis wäre eine geniale Fallback-Lösung, falls z.B. der erste Conbee2-Stick einen HW-Schaden hat.

[Asgothian]

@ptr sagte in 2. Conbee II als “hot”-Zigbee-Netz-Fallback, 2 ioBs:

-> Die Frage bleibt also, wie man das Zigbee-Netz so “verarscht”, dass es denkt dass der zweite Conbee2-Stick eigentlich der erste wäre und damit einfach genau den gleichen job macht…

Mir ist für deconz da keine Option bekannt. Ich bin auch nicht sicher ob deconz es erlaubt das gesamte Netzwerk per "backup" zu sichern und dann per "restore" mit anderer Hardware wieder zu restaurieren. Bei gleicher Hardware geht es.

Diese Funktionalität kann der Zigbee Adapter aktuell bieten, allerdings ausschliesslich mit den TI basierten Chips (und da auch nicht mit dem cc2531). Um ein Netz von einem Koordinator auf den anderen zu transferieren reichen da die Dateien nvbackup.json und shepherd.db.

A.

[bommel_030]

Bin kürzlich von Raspbee2 auf Conbee2 gewechselt. Backup und Restore in Phoscon ging erschreckend einfach und läuft alles.

[ptr]

@bommel_030 aus irgendeinem Grund geht das Backup in Phoscon bei mir mit beiden Conbee2-Sticks nicht. Neuste stable Firmware drauf. Undifferenzierte Fehlermeldung "Backup ist fehlgeschlagen". Habe auch schon den Stick über 30min laufen lassen. -> daher habe ich keinerlei Erfahrung mit der Backup-Option.

@Asgothian Zur genaueren Beschreibung:

• Ich nutze im ioB-produktiv-System den Zigbee-Adapter, daran direkt also den Conbee2 im LXC, USB-durchgeschliffen. zweiter proxmox-node/HW hat einen eigenen Conbee2, ebenfalls durchgeschliffen.
• die deConz/Phoscon-Geschichte ist unter Windows nur fürs "Gleichmachen" aufgesetzt.
• bisher bin ich davon ausgegangen, dass das Netzwerk(-teilnehmer) nicht IM Stick gespeichert ist, nur eigene IDs - eben die in deConz editierbares unter Netzwerkeinstellungen... -> wenn das nicht so ist, könnte Fallback etwas komplizierter werden, da dann zusätzlich zum LXC-Replicat auch ein Conbee2-Backup regelmäßig durchgeführt werden müsste, dass dann im Fallbackfall wieder eingespielt werden müsste.
  -> Daher ist dein Hinweis auf andere HW sehr interessant: Verstehe ich richtig, dass damit die LXC-Migration auf die Fallback-Server-HW reichen würde für ein "Erhalt" des Zigbeenetz - aber mit dem Fallback-Stick in HW2? Oder müsste man noch was mit Zigbee-Stick machen?
  -> Wäre z.B. Sonoff ZIGBEE 3.0 USB DONGLE PLUS da der richtige?

[Asgothian]

@ptr sagte in 2. Conbee II als “hot”-Zigbee-Netz-Fallback, 2 ioBs:

bisher bin ich davon ausgegangen, dass das Netzwerk(-teilnehmer) nicht IM Stick gespeichert ist, nur eigene IDs - eben die in deConz editierbares unter Netzwerkeinstellungen... -> wenn das nicht so ist, könnte Fallback etwas komplizierter werden, da dann zusätzlich zum LXC-Replicat auch ein Conbee2-Backup regelmäßig durchgeführt werden müsste, dass dann im Fallbackfall wieder eingespielt werden müsste.

Es ist leider so das die Netzwerkparameter unter anderem auch im NVRam des Koordinators gespeichert werden, nicht nur in der angeschlossenen Software.

-> Daher ist dein Hinweis auf andere HW sehr interessant: Verstehe ich richtig, dass damit die LXC-Migration auf die Fallback-Server-HW reichen würde für ein "Erhalt" des Zigbeenetz - aber mit dem Fallback-Stick in HW2? Oder müsste man noch was mit Zigbee-Stick machen?

Nein, mit dem Zigbee Stick muss man in dieser Situation soweit ich das verstanden habe nichts weiter tun.

-> Wäre z.B. Sonoff ZIGBEE 3.0 USB DONGLE PLUS da der richtige?

Der Sonoff Stick sollte das können, ja.

A.

[ptr]

@asgothian So, habe das jetzt mal umgesetzt. 2x Sonoff 3.0 v2-1.2.7.1. rev 20211217.
Ergebnis zuerst: Es klappt!
Dann: Ernüchterung. Es klappt nur mit den Aqara-Sensoren. Die IKEA-Steckdose, genauso wie die Philips Hue-Lampe funktionieren weiterhin nur den node1-Stick.
Dann erinnerte ich mich, dass ich die Aqaras mit den ConbeeIIs garnicht getestet hatte. Also ggf. die gleich Situation?

Was ich gemacht habe: letztendlich habe ich im Setup nur die ConbeeII-Sticks durch die Sonoffs ersetzt. Dafür musste das USB-Durchschleifen und die Konfiguration des Zigbee-Adapters angepasst werden.

Der Test: den ioB-LXC von node1 und node2 migrated. Dann gehen nurnoch die Aqara-Sensoren. Zurück-migraten auf node1. Alle geht wieder (IKEA Einzelsteckdose, 2 Aqara-Sensoren, 1x Philips Hue-Lampe).

-> Was könnte ich noch tun? Und warum geht das mit den Aqara-Sensoren. Hat das was mit Security-Countern zu tun, die mal schon, mal nicht beachten werden?

Ergänzung: Habe zur Vollständigkeit getestet den node1-Stick1 parallel zur Migration "rüberwandern" zu lassen auf node2. Voilà es geht. Aber das war ja nicht die Aufgabe, da so kein automatischer Fallback möglich ist (wenn die Knoten räumlich getrennt sind - was sehr viel Sinn macht).

Ergänzung2: Netzwerkkarte zeigt alles rot, keine Verbindungen also, in dem Zustand, in dem NUR die Aqara-Sensoren funktionieren.
Ergänzung2.1: Nach mehreren Minuten Wartezeit ist die Netzwerkkarte vollständig grün geworden. Auch die Ikea-Steckdose und die Hue-Lampe. Die Ikea-Steckdose hat jedoch keine grüne Linie. Am Ende: Funktional leider kein Unterschied.

[ptr]

Habe mir mal den NV-RAM der beiden Sticks angeschaut.
NV-RAM vom Sonoff-Stick1 auf den Sonoff-Stick2 geschrieben.
-> Dann kann ich den Stick2 vollumfänglich verwenden.
Sah wie eine Lösung aus, jedoch hat dann Stick1 irgendwie seinen Zugriff auf den IKEA-Steckdose und die Hue-Lampe verloren.
1. Lösungidee:
Es müsste also aktuell immer im Fallback-Fall der NV-Ram des Fallback-Sticks geflasht werden. z.b. mit einem nightly-dump des Stick1.
Ob das funktioniert habe ich noch nicht getestet.
-> wie häufig kann denn ein NVRAM bei so einem Sonoff geschrieben werden? Sind da am Ende 100erte full-writes ok?
Die Frage rührt daher, da die normale Fallback-Routine des ioB-Systems ein automatischer Komplettwechsel der HW & SW(1d zurück) wäre. In experimentelleren Phasen des Systemaufbaus könnte ja häufiger passieren...

2. Lösungidee:
Da ich gerne verstehen würde warum Stick1 dann nichtmehr geht. Vllt ergibt sich daraus eine cleverere, stabilere Lösung.
Folgendes gemacht:

1. Schreibe NV-RAM von Stick1 auf Stick2. -> NV-RAMs gleich
2. Dann tritt die Funktionsreduktion auf Stick1 auf.
3. Dumpe NV-RAM1 und NV-RAM2 -> Vergleich hier als DIFF-report - nur die Stelle die anders sind.

{
    "LEGACY": {
        alt: "NIB": "280502330f33001e0000000105018f000700020d1e0000000f0000000000000000000000d2040800008000000f0f0400010000000100000000fd082345ac23b234010000000000000000000000000000000000000000000000000000000000000000000000000f050001640a01000000d2010000",
        neu: "NIB": "400502330f33001e0000000105018f000700020d1e0000000f0000000000000000000000d2040800008000000f0f0400010000000100000000fd082345ac23b234010000000000000000000000000000000000000000000000000000000000000000000000000f050001640a01000000f6010000",
...
        alt: "0x00BC": "b00000000000000037b72507008d1500ff010c00",
        neu: "0x00BC": "080100000000000037b72507008d1500ff010c00",
...
        alt: "0x00C5": "5800000000000000f10626080188170002000500",
        alt: "0x00C6": "6e000000000000001486d307008d1500ff010c00",
        alt: "0x00C7": "6e00000000000000c94987feffec86cc02000b00"
        neu: "0x00C5": "b000000000000000f10626080188170002000500",
        neu: "0x00C6": "c6000000000000001486d307008d1500ff010c00",
        neu: "0x00C7": "c600000000000000c94987feffec86cc02000b00"
    },
    },
    "NWK_SEC_MATERIAL_TABLE": {
        alt: "0x0000": "7b3f0000fd082345ac23b234",
        neu: "0x0000": "03530000fd082345ac23b234",
    }
}

[arteck]

@ptr sagte in 2. Conbee II als “hot”-Zigbee-Netz-Fallback, 2 ioBs:

NVRAM

wird immer dann auf den stick geschrieben wenn dieser LEER ist. also dirket nach dem flashen.. oder hardreset (wobei ich mir hier nicht sicher bin)

und wenn du neu geflasht hast und den neuen stick betreiben willst dauert es paar minuten bis das NVRAM aufgespielt wurde UND WICHTIG bis die Router sich mit diesem verbinden.. das kann dauern.. also nix rein und erwarten es soll DIREKT alles laufen..

nachtrag: für dich auch nochmal... die Karte ist nicht aussgekräftig ..also vergiss die Karte

[ptr]

@arteck

wird immer dann auf den stick geschrieben wenn dieser LEER ist. also dirket nach dem flashen.. oder hardreset (wobei ich mir hier nicht sicher bin)

Ich verstehe nicht genau. Jedoch habe ich die Testszenarien gefahren per hotplug im laufenden Betrieb & als „Zigbee-Adapter-runterfahr“-Variante.

und wenn du neu geflasht hast und den neuen stick betreiben willst dauert es paar minuten bis das NVRAM aufgespielt wurde UND WICHTIG bis die Router sich mit diesem verbinden.. das kann dauern.. also nix rein und erwarten es soll DIREKT alles laufen..

ok, danke. Habe in allen möglichen Szenarien längere Wartezeiten eingebaut.
Ergebnis nach längeren Testreihen: Es funktioniert! - jedoch mit einigen Bedingungen:

Stick 1 braucht zum Netzaufbauzeitpunkt, den Stick2 stromoffline. Jedoch nur, falls er vorher nicht bereits das Netz „coordinated“ hat. Wenn Vorher Stick2 koordiniert hatte, brauche Stick 1 den Stick2 stromoffline. Zeit bis alle 4 Geräte online sind: 6 Sekunden ab Stick1 einfach einstecken - mehrfach reproduzierbar.

Stick 2 verhält sich anders. Er ist penibler. Braucht nicht 6 Sekunden ab anstecken, sondern durcheinander 20-100 Sekunden. Er benötigt auch mehr als nur anstecken, er braucht immer einen Adapterneustart, wenn vorher Stick1 koordiniert hatte. Stick1 muss zum Netzaufbauzeitpunkt ebenfalls Stromlos sein.

Das Lösungsszenario sieht nun also wie folgt aus.
Der Fallbackmanager triggert den Fallback. Dann wird nun als erstes die „down“-HW per Shelly-plug komplett vom Strom genommen. Dann fährt erst die andere HW den Fallback-LXC hoch. Das hat im manuellen Durchgang nun mehrfach funktioniert. Rückwärts geht das auch.

Ich bin weiter am Stabilitätstesten.

Verbesserungsmöglichkeiten?
-> Das Stick1-Verhalten ist super! Kann das irgendwie auf Stick2 übertragen werden??
Ich verstehe es nicht wirklich, weil Stick1 ebenfalls in 6 Sekunden „hochfährt“ falls Stick2 gerade noch koordiniert hat (und dann stromlos geschaltet wird). Oder klingt das für euch plausibel?

@Asgothian: danke schonmal bis hierher!
@arteck: ebenfalls danke, das hat ebenfalls zum aktuellen Lösungsweg beigetragen!