Ich fragte, wie man die Konfigurationen speichert, Pierre-Giles sagte:
Du gehst in das Verzeichnis, in dem du deine Konfiguration gespeichert hast (schau dir das Docker-Volume an, das du verwendet hast)
Standardmäßig wird auf der Website alles in „/var/lib/gladysassistant“ gespeichert
In diesem Verzeichnis gibt es ein SQLite-Verzeichnis: das ist die Gladys-Datenbank, die deine gesamte Konfiguration enthält, du kannst sie beiseitelegen
Das Einzige, was nicht gespeichert wird, sind zusätzliche Container wie Zigbee2mqtt, wir haben keinen Prozess, um von der Datenbank auszugehen und diese Container wiederherzustellen, aber es wäre es wert, das zu verwalten
Wenn ich es wiederherstellen möchte, zeigt er mir alle Konfigurationen an, aber es ist unmöglich, Zigbee2mqtt zum Laufen zu bringen, tatsächlich sind die Verbindungen zwischen Gladys - mqtt und Zigbee2mqtt nicht funktionsfähig.
Während alles mit der Standarddatei gut funktioniert.
Wie kann ich die alte Datenbank wiederherstellen und sicherstellen, dass Zigbee2mqtt funktioniert?
Ich glaube, man muss Zigbee2mqtt in der Integration neu starten. Ich glaube nicht, dass es einen Prozess gibt, um die Container auf einer neuen Basis neu zu starten, leider!
Heißt das, ich muss die Erkennung aller meiner Elemente neu starten?
Oh Mann, das ist echt nervig, weil sie befestigt sind und nicht unbedingt zugänglich…
Meiner Meinung nach ist das ein echter Nachteil, dass man die Daten nicht speichern und wiederherstellen kann.
Löst Gladys Plus dieses Problem?
Ich frage, weil ich mir im Moment nicht vorstellen kann, 120€/Jahr nur für dieses Feature auszugeben, ich bin noch nicht so weit, dass ich die anderen brauche.
Das Problem kommt von der Integration von Gladys Zigbee2mqtt, die nicht in der Lage ist, sich im Falle eines Backups/Wiederherstellung auf einer anderen Instanz wieder aufzurappeln.
Es gibt eine GitHub-Issue, die schon seit einiger Zeit existiert, aber bisher hat sich noch niemand daran gewagt:
Cc @AlexTrovato@cicoub13 Es gibt immer mehr Anfragen, eine Instanz auf einer anderen Maschine neu zu starten, es ist wirklich gut, dass die network_key, pan_id und der Kanal in der Gladys-Datenbank gespeichert sind, das erspart es, alles neu zu konfigurieren, wenn man Gladys von einer Instanz zur anderen verschiebt
@AlexTrovato Danke! Ich habe dir auf Github geantwortet
Grundsätzlich geht es darum, dass der Dienst wieder auf die Beine kommen kann, wenn man die Datenbank einer Instanz nimmt und auf eine andere setzt. Gladys sollte Zigbee2mqtt mit denselben Parametern neu starten können, sonst muss der Benutzer seine gesamte Hardware neu paaren.
Zögere nicht, wenn du noch Fragen hast, wir können über die Implementierung diskutieren!
Und was ist in « data »? Kann man nicht einfach den network_key / channel / pan_id wiederherstellen, den man in der configuration.yml generieren würde?
Da ich gerade meinen RPI4 erhalten habe, konnte ich einige Tests durchführen.
Ich mag es, bei der Installation eines neuen Systems ein Backup-System zu haben, also habe ich Backuptests an der Gladys-Datenbank und an zigbee2mqtt durchgeführt. Es sollte erwähnt werden, dass ich Gladys zunächst auf einem alten PC mit Ubuntu installiert hatte, um mit meinen Tests zu beginnen, bis ich meinen RPI4 erhielt.
Bei Gladys gab es keine Probleme mit der .db-Datei. Auch bei zigbee2mqtt gab es keine Probleme. Ich habe einfach die Dateien configuration.yaml, coordinator_backup.json und database.db kopiert, bevor ich zigbee2mqtt in Gladys aktiviert habe.
Nach dem Kopieren dieser Dateien habe ich zigbee2mqtt aktiviert, Gladys hat die Installation durchgeführt und ich konnte meine Geräte wieder funktionsfähig nutzen, ohne sie neu zu paaren.
Mir bleibt nur noch, ein Bash-Skript zu schreiben, um diese Dateien automatisch und regelmäßig zu sichern und zu exportieren.
