Hallo Zusammen,
nachdem ich mein FHEM erfolgreich nach configdb migriert habe, stellen sich mir noch zwei Fragen:
- Kommt man theoretisch wieder zurück, zu einer fhem.cfg (und save)?
- configdb list -> sieht stark nach dem ehemaligen Inhalt der fhem.cfg aus - vollständig?
- Wie verhält es sich mit den Versionen? Wird hier bei jedem "save" eine komplette Kopie/Version angelegt?
Ich habe an mehreren Stellen save-Befehle im FHEM, um temperaturabhängige "Zeiten" zu setzen. (zb attr von DoIFs und Watchdog)
-> Diese schließe ich immer mit einem "save" ab, da sonst nach Reboot die Zeiten weg waren. (eben weil nicht in die fhem.cfg übernommen wurde)
- Werden Änderungen an Attributen eines Devices direkt in die configDB geschrieben, oder auch nur mit "save"?
- Ich laufe hier vermutlich Gefahr in kurzer Zeit sehr sehr viele Versionen in der DB zu haben und diese damit aufzublähen?
Danke,
Kharim
configDB speichert auch nur Änderungen ab, wenn du das mit save anstößt. Die Zahl der Versionen ist einstellbar (comandref: maxversions).
Die configDB wird ansonsten - wie die fhem.cfg auch - nur beim Start gelesen.
Du kannst die aktuelle cfg exportieren, indem du in "global" einen Ort für die config angibst und dann save drückst - so mache ich auch "backups", z.B. mit "fhem_2018_03_11.cfg". Danach halt wieder einen restart@configDB anstoßen, nicht dass da was durcheinander kommt. Das "list" ist dagegen alphanummerisch. Da kann man dann zwar evtl. auch wieder eine cfg draus basteln, aber die Reihenfolge ist uU. so, dass es nicht funktioniert...
Viel Spaß,
Beta-User
Zitat von: Beta-User am 11 März 2018, 17:32:19
configDB speichert auch nur Änderungen ab, wenn du das mit save anstößt. Die Zahl der Versionen ist einstellbar (comandref: maxversions).
Bist du dir da sicher? Also mit den Änderungen?
Weil gerade wenn nur die Änderungen gespeicherst werden, aber die Anzahl an Konfigurationen begrenzt ist....dann läuft das doch auf unvollständige Konfiguration hinaus?!
Weil es muss ja dann "irgendwann" die Basis gelöscht werden, weil maxversions erreicht wird?
So war das nicht gemeint, sondern es ist wie bei der normalen cfg: Es wird nur gespeichert, wenn der Benutzer das anstößt, auch configDB hat keine autosave-Funktion (sowas wäre nach meinem Verständnis gegen das Konzept von FHEM, das genau die Änderung der Konfigruation zur Laufzeit zuläßt und es dem Nutzer überläßt, den beim Start vorhandenen Zustand festzulegen).
Ich nutze zwar maxversions nicht, aber du solltest keine Furcht haben, dass dir irgendwas abhanden kommt... Das ist mir eher mit fhem.cfg schon passiert (da war aber vermutlich OWX schuld, pah hat das neulich gefixt). Jedenfalls ist die letzte auch eine komplette Konfiguration, sonst könnte man die nicht so rausspeichern wie beschrieben.
Alles klar. Dank dir. :-)
Du könntest auch einfach mal die Doku lesen...
Zitat von: Beta-User am 11 März 2018, 19:40:18
Jedenfalls ist die letzte auch eine komplette Konfiguration, sonst könnte man die nicht so rausspeichern wie beschrieben.
Gefährliches Halbwissen....
Kharim für Dich ist einfach nur wichtig zu wissen das wenn Du save drückst die komplette Konfiguration zum Zeitpunkt des save gespeichert wird. Sowohl alle defines (ausser temporäre) als auch die entsprechenden Attributzuweisungen.
Was dann da noch so passiert ist für Dich nicht wichtig. Du kannst zu jedem Zeitpunkt Dein FHEM bei einem Fehler wieder herstellen.
Genau so ist es.
Und statt mit maxversions zu arbeiten, kann man auch jede nacht per at-device ein "configdb reorg 5" ausführen, um alle überzähligen gespeicherten Konfigurationen zu entfernen und die letzten 5 (als Beispiel) zu behalten.
Aus Performancegründen ist die Lösung mit dem nächtlichen reorg die bessere Empfehlung im Vergleich zu maxversions.
Aber warum man ein "save" innerhlab der Konfiguration selbst braucht, wird sich mir in diesem Leben wohl nicht mehr erschliessen.