Beim schnellen Durchlesen habe ich den Eindruck, dass uns die breaking changes nicht betreffen, aber natürlich müssen wir alles testen.
2 Möglichkeiten:
Entweder wir führen die Tests vor dem 3. Januar durch, und wenn wir der Meinung sind, dass die 2.0.0 nichts an Gladys ändert, dann lassen wir alles wie es ist, und Zigbee2mqtt wird automatisch bei den Nutzern aktualisiert
Ich bin einverstanden! Ja, der aktuelle Code zwingt die Installationen tatsächlich, ihre Container zu ersetzen
damit bin ich mir allerdings weniger sicher, wenn wir das hinzufügen, wird es in 1.x genau das gleiche Verhalten wie in 2.0 geben, ich denke, wir sollten die Version in Gladys vorerst einfrieren und das war’s.
Auf unserer Seite können wir parallel das 2.0-Image testen (unter dem Tag latest-dev bei Z2M)
Stabilität ist die Mutter der Sicherheit, besonders während der Schulferien. Wenn also manche nicht zu Hause sind, kann das Heizung, Alarmanlage usw. beeinflussen.
Da ich meinen Docker z2m außerhalb von Gladys verwaltet habe, habe ich mich für die Version 1.42.0 entschieden, anstatt wie empfohlen auf „latest“ zu setzen, und das war eine sehr gute Entscheidung
Das ist wie bei der Verwaltung eines kritischen Unternehmenssystems (Netzwerk, Sicherheitswerkzeug, etc.), es ist besser, die anderen die Scherben aufräumen zu lassen und direkt auf die gepatchte Hauptversion zu wechseln
Danke @pierre-gilles, dass du das mit Gladys gemacht hast! Das erspart uns eine Menge Ärger!
Ich weiß nicht, ob das Thema auf eurer Seite vorangekommen ist, aber ich denke, ich werde meine gesamte Installation überarbeiten, um auf ein externes zigbee2mqtt umzusteigen und den SLZB-MR1 zu kaufen/verwenden, über den @mutmut hier sprach: Quel hub pour Matter? - #5 par mutmut
Damit kann ich eine zweite Z2M-Version 2 zum Testen mit einem Test-Gladys daneben einrichten, ohne die Pairings zu beeinträchtigen, und auch Matter-kompatibel sein