Vorteil von der configdb

[hermann1514]

Hallo zusammen,
Ich habe schon viel darüber gelesen wie man die Konfiguration von FHEM in eine Datenbank schreibt. Als gut und schön, aber was für Vorteile bringt das? Darüber habe ich noch nichts gefunden.
Lohnt sich die Umstellung?

Gruß
Hermann

[MadMax-FHEM]

Ich nutze ja (noch) die fhem.cfg aber:

- Versionierung
- Vergleich zwischen Versionen
- "Rollback" (falls ein Experiment) schief ging

Sind ein paar Dinge die ich so gelesen habe...

Habe aber (noch) nicht umgestellt weil: eine Datenbank ist halt eine Datenbank und eine Datei ist halt eine Datei...

Mit "korrupter" Datei kann ich einfach umgehen...
...mit einer korrupten DB naja...

EDIT: ist aber halt persönlich/subjektiv

Gruß, Joachim

[Beta-User]

Vorab: Ich gehörte auch mal zu denen, denen der Gedanke suspekt war, eine Datenbanklösung einzusetzen. Klang nach "kompliziert und intransparent". Hab's dann einfach ausgetestet und bin jetzt seit mehreren Jahren configDB-Nutzer, Datenbanken sind mir nach wie vor ein Gräul und ich würde wohl auch nicht wieder den Schwenk zu DbLog machen (was aber ein gänzlich anderes Thema ist!). Bin schon mehrfach umgezogen seit dem Wechsel zu configDB und immer dabei geblieben...

Weitere Vorbemerkung: Es gibt einen "Basisthread" zu der Frage unter Beteiligung des Entwicklers, https://forum.fhem.de/index.php/topic,24143.0.html

Meine Ergänzungen;
Grundsätzlich greift die Antwort von MadMax-FHEM m.E. zu kurz, es geht bei weitem nicht nur um eine "versionierte fhem.cfg"!

Mind. noch zwei Aspekte (von denen bei mir persönlich nur der 1. eine Rolle spielt):
- Schon in der "Basiskonfiguration" sind in der db mindestens 3 Teile der Konfiguration enthalten (spielt es auf einem Testsystem durch...), und es gibt auch einen Grund, warum die commandref weitere Module nennt, die die Speichermethode configDB unterstützen.
- Die DB muß sich nicht auf dem lokalen System befinden. Wer also entsprechende zentrale Infrastruktur hat, kann die (einschl. der dort evtl. vorhandenen Backup-Funktionen) nutzen...

Grüße, Beta-User

[betateilchen]

Grundsätzlich greift die Antwort von MadMax-FHEM m.E. zu kurz,

Mir geht die Antwort auch nicht weit genug, zumal sie von jemandem kommt, der die Datanbank selbst nicht einsetzt, sondern sein Halbwissen auch nur aus Gelesenem bezieht.

In der Konfigurationsdatenbank werden beispielsweise auch einige modulspezifische Dateien abgelegt, die ansonsten im Dateisystem liegen. Hier sind insbesondere die gplot Dateien zu nennen, die von SVG devices für die Plotgenerierung verwendet werden. Wie von Beta-User bereits geschrieben, findet sich in der commandref die Liste der Module, die ihre zugehörigen Dateien in der Datenbank ablegen.

Die Ablage solcher modulspezifischer Dateien vereinfacht die Datensicherung und den Umzug eines FHEM Systems von einer Plattform zu einer anderen, da solche vom Benutzer selbst angepaßte Dateien automatisch mit berücksichtigt werden.

[Beta-User]

[...] findet sich in der commandref die Liste der Module, die ihre zugehörigen Dateien in der Datenbank ablegen.

(etwas OT im verspäteten Nachgang zu der weekprofile-Aktion:
Sollte man das Thema nicht ggf. auch nochmal im Developer-Bereich etwas mehr "bewerben"? In der Liste in der commandref "fehlt mir" mind. ein Modul, das ggf. etwas weiter verbreitet ist... (was vermutlich nicht an dir als dem Pflegenden der commandref liegt))

[rudolfkoenig]

Wenn ein Modulautor Daten in "externe" Dateien schreiben will, sollte FileWrite und FileRead verwenden.
Damit landen die Dateien automatisch entweder in configDb oder in einer Datei, jenachdem of configDb verwendet wird.

[Beta-User]

Mir ist das soweit schon klar, und wir (u.a. betateilcen und ich) hatten das (Umstellungs-) Thema auch schon mal iVm. weekprofile. Ich will auch kein eigenes Modul umstellen, kenne aber mind. noch ein Modul eines anderen Entwicklers, das in eigene $statefile schreibt (mit open(FH,..) und close(FH); das wäre demnach jedenfalls nach meinem Codeverständnis nicht kompatibel).

Da entprechende Umstellungen auch vom jeweiligen Entwickler gewollt sein müssen und ggf. in der Umstellungszeit auch Entwicklerseitig betreut werden müssen, will ich das hier nicht weiter vertiefen, wie geschrieben ist eben eher die Frage, ob man das nicht nochmal "anschubsen" sollte, damit ggf. in diese Richtung ein einheitliches Verhalten über alle Module erreicht werden kann; es ist nicht so toll, wenn das eine Modul das so macht und das andere anders. That's all...

(Grundsätzlich tendiere ich nämlich zwischenzeitlich auch (schwankend) dazu, Einsteigern (nach den ersten Schritten) direkt die Migration zu configDB zu empfehlen. Und da sind solche "Inkonsistenzen" hinderlich...
@betateilchen: in der commandref würde sich m.E. nach "restart fhem with keyword configDB" noch der Hinweis auf "make it permanent by changing the startup script, e.g. ..." gut machen, auch wenn mir klar ist, dass das eher ein Linux-Grundlagen-Thema ist denn ein wirklicher Anwendungshinweis zu configDB).

[betateilchen]

Wenn ein Modulautor Daten in "externe" Dateien schreiben will, sollte FileWrite und FileRead verwenden.
Damit landen die Dateien automatisch entweder in configDb oder in einer Datei, jenachdem of configDb verwendet wird.

Ja, schon...

Sollte man das Thema nicht ggf. auch nochmal im Developer-Bereich etwas mehr "bewerben"?

... auch das ist richtig.

Mehrere Versuche in der Vergangenheit, das zu bewerben, sind daran gescheitert, dass Modulautoren /FHEM-Entwickler einfach nicht bereit waren, sich mit dem Thema überhaupt befassen zu wollen und einfach nicht verstehen, dass es bereits seit Jahren die von Rudi genannten zentralen Funktionen gibt, die dem Entwickler sogar das Verständnis dessen, was im Hintergrund bei der Verwendung von FileWrite() und FileRead() passiert, abnehmen. Grundsätzlich finde ich die mangelnde Akzeptanz dieser Funktionen sehr bedauerlich und ich kann immer wieder nur den Kopf darüber schütteln, wenn ich sehe, dass ein Entwickler zwar File...() verwendet, dann aber einen forceType erzwingt und damit den eigentlichen Nutzen dieser Funktionen absichtlich blockiert.



Langsam sind wir aber ein ganzes Stück weit weg von der eigentlichen Frage, um die es hier im Thread ursprünglich ging.

[yersinia]

Vorweg: ich nutze keine configDB weil mir -wie dem TE- die Vorteile (noch) nicht ganz klar sind. Ich habe mich auch bisher damit nicht weitergehend beschäftigt, möglicherweise gibt es hier Halb- oder gar ganz fehlendes Wissen.
Ich nutze DBLog mit sqlite weil ich im Logging hier durchaus Vorteile sehe (Geschwindigkeit sowie Größe). Auf manuelles Bearbeiten der fhem.cfg steht der Tod, von daher editiere ich auch nichts direkt in der Datei - Struktur sowie Inhalt werden also ausschließlich durch FHEM vorgegeben.

- Versionierung
- Vergleich zwischen Versionen
- "Rollback" (falls ein Experiment) schief ging

Dafür brauch' ich aber auch keine Datenbank - Versionierung geht mit Backup (oder C&P); Vergleich von Versionen geht mit OS-Bordmitteln (zB diff); Rollback über einspielen eines Backups.
Zumal man diese Funktionen auch bei einer Datenbank einstellen muss - per se muss es diese Funktionen nicht geben.

Bin schon mehrfach umgezogen seit dem Wechsel zu configDB und immer dabei geblieben...

Mind. noch zwei Aspekte (von denen bei mir persönlich nur der 1. eine Rolle spielt):
- Schon in der "Basiskonfiguration" sind in der db mindestens 3 Teile der Konfiguration enthalten (spielt es auf einem Testsystem durch...), und es gibt auch einen Grund, warum die commandref weitere Module nennt, die die Speichermethode configDB unterstützen.
- Die DB muß sich nicht auf dem lokalen System befinden. Wer also entsprechende zentrale Infrastruktur hat, kann die (einschl. der dort evtl. vorhandenen Backup-Funktionen) nutzen...

Ich bin auch mit der fhem.cfg mehrfach umgezogen, bisher Problemlos.
Die fhem.cfg muss sich auch nicht auf dem lokalen System befinden, symlink würde auch gehen. Gern auch zentralisiert irgendwo.
Umziehen kann ich durch Backup&Restore auch. Ja, es gibt Module, welche in configDb schreiben können - aber sie schreiben auch in Files bzw fhem.cfg. Und das per default.

In der Konfigurationsdatenbank werden beispielsweise auch einige modulspezifische Dateien abgelegt, die ansonsten im Dateisystem liegen. Hier sind insbesondere die gplot Dateien zu nennen, die von SVG devices für die Plotgenerierung verwendet werden. Wie von Beta-User bereits geschrieben, findet sich in der commandref die Liste der Module, die ihre zugehörigen Dateien in der Datenbank ablegen.

Die Ablage solcher modulspezifischer Dateien vereinfacht die Datensicherung und den Umzug eines FHEM Systems von einer Plattform zu einer anderen, da solche vom Benutzer selbst angepaßte Dateien automatisch mit berücksichtigt werden.

Welchen Vorteil bring es mir als Anwender wenn fhem die SVG-Plot-Konfiguration aus einer DB anstelle aus einem File ausliest? Gibt es hier Performance-Vorteile? Hab ich die I/O-last auf den Datenträger (SD/SSD/NAS) reduziert?
Eine Vereinfachung der Datensicherung einer DB versus Backup via fhem sehe ich auch nicht - außer man kopiert von einer DB direkt in eine andere.

Die Themen Versionierung, Ausfallsicherheit, Backups, Restore, Rollback usw. kann ich auch mit einem filesystem abbilden. Möglicherweise nicht so elegant wie in einer DB, aber dafür benötige ich auch keine zusätzliche DB.
Wie gesagt, ich weiss vlt nicht viel über configDB, aber ich sehe bisher für mich keinen Vorteil, fhem.cfg (über einen vielleicht holprigen Weg?) auf configDB zu migrieren - die fhem.cfg läuft out-of-the-box.

[Wzut]

sollte FileWrite und FileRead verwenden.

Das ist doch eigenlich Udos Mantra, zumindest hat er oft genug uns hier vorgebetet, irgendwann hab es ich auch mal begriffen und nach und nach geändert.
Allerdings wäre es schön wenn die drei Brüder FileWrite, FileRead & FileDelete noch eine Schwester FileList(filter) hätten,
denn so muss man beim erstellen von Datei Listen schon noch beachten ob configDBUsed wahr ist und dann mit _cfgDB_Filelist arbeiten.

[Beta-User]

Welchen Vorteil bring es mir als Anwender wenn fhem die SVG-Plot-Konfiguration aus einer DB anstelle aus einem File ausliest?

Das "Problem" ist auch, dass jeder Modulautor etwas andere Vorstellungen davon hat, WO die Konfigurationsdaten denn sinnigerweise abgespeichert werden, manches ist auch historisch bedingt usw. usf.. Das Ergebnis ist ggf. ein ziemlicher Flickenteppich, über den weniger versierte User spätestens dann stolpern, wenn sie das erste Mal versuchen, OHNE backup/restore umzuziehen.

In der einen db-file ist dagegen dann alles drin (so es von dem betreffenden Modul unterstützt wird).

(Außerdem ist die %search%-Option klasse!)

Langsam sind wir aber ein ganzes Stück weit weg von der eigentlichen Frage, um die es hier im Thread ursprünglich ging.

Agreed!

fyi:
Ich habe den betreffenden Modulautor mal direkt angeschrieben, vielleicht hat er ja Zeit und Lust, sich darum zu kümmern...

[betateilchen]

denn so muss man beim erstellen von Datei Listen schon noch beachten ob configDBUsed wahr ist und dann mit _cfgDB_Filelist arbeiten.

Kein Entwickler sollte jemals interne Funktionen der configDB.pm in seinen eigenen Modulen direkt verwenden und aufrufen. Die Freiheit, solche Funktionen umzubenennen oder deren Schnittstelle zu ändern, nehme ich mir jederzeit.

[hermann1514]

Oh man...da habe ich ja was ausgelöst

Vielen Dank für die rege Diskussion.

In der Tat sehe ich für mich zur Zeit auch noch nicht wirklich einen klaren Vorteil, der die Migration zur ConfigDB zwingt.
Bei dem ein oder anderen kann ich die Migration verstehen.

Ich betreibe FHEM in einer VM, die täglich gesichert wird. Alle Performance Daten schreibe ich in eine INFLUXDB und die Graphen erzeuge ich mit Grafana.

Ich würde die Migration eigentlich nur machen, um mal wieder was anderes zu machen

Vielleicht mache ich das einfach einmal um zu sehen wie sich alles verhält

Gruß
Hermann

[yersinia]

Das "Problem" ist auch, dass jeder Modulautor etwas andere Vorstellungen davon hat, WO die Konfigurationsdaten denn sinnigerweise abgespeichert werden, manches ist auch historisch bedingt usw. usf.. Das Ergebnis ist ggf. ein ziemlicher Flickenteppich, über den weniger versierte User spätestens dann stolpern, wenn sie das erste Mal versuchen, OHNE backup/restore umzuziehen.

In der einen db-file ist dagegen dann alles drin (so es von dem betreffenden Modul unterstützt wird).

(Außerdem ist die %search%-Option klasse!)

Ja, genau, wenn das Modul es unterstützt, ist es entweder in der configDB drin oder in der fhem.cfg oder irgendwo anders. Diese Problematik ist aber unabhängig vom Speicherort der fhem config.
Ich wage zu bezweifeln, dass weniger versierte Nutzer, welche ohne backup/restore umziehen wollen, mit einer nicht gesicherten/geschriebenen (commit) configDB besser dran wären.

Ich will hier auch kein "pöse configDB! Hoch lebe fhem.cfg!" lostreten - ich möchte nur die Vorteile der configDb gegenüber fhem.cfg verstehen. Auch warum sich der Aufwand (und Risiko) eines Umstiegs lohnt.

[Beta-User]

Ja, genau, wenn das Modul es unterstützt, ist es entweder in der configDB drin oder in der fhem.cfg oder irgendwo anders. Diese Problematik ist aber unabhängig vom Speicherort der fhem config.

Jein.
fhem.cfg und alle dort (eigentlich!) zulässigen defines, attr und setuuid-Anweisungen sind entweder in der DB oder in der cfg-file. Alles andere ist IRGENDWO im Filesystem, und die beiden Befehle, die Rudi genannt hatte, führen einfach dazu, dass der Modulautor sich nicht mehr darum kümmern muss, wohin er eigentlich speichert.

ERGO: ein Modul, das die zentralen fhem.pl-Funktionen nutzt, wird es automatisch "richtig" machen und der Anwender bräuchte dann NUR NOCH die DB auf ein anderes System umziehen (und einbinden). Umzug hieße dann nach meinem Verständnis: OS aufziehen und aktualisieren, FHEM installieren und update, DB+entsprechende "Linkfile" mit den Zugangsdaten reinkopieren, die myUtils-Files und ggf. zusätzliche contrib+externe Module kopieren, Startscript anpassen,  ggf. Logs mitnehmen (je nachdem, was man haben möchte), FHEM über das Startscript neu starten, done. (ich bin früher immer ohne direktes Mitnehmen der DB umgezogen, sondern habe die cfg rausgespeichert; das hat aber damit zu tun, dass ich (früher) relativ wenig "drumrum"-Konfiguration hatte und dann zum Teil auch wieder aufgeräumt habe).

Ich wage zu bezweifeln, dass weniger versierte Nutzer, welche ohne backup/restore umziehen wollen, mit einer nicht gesicherten/geschriebenen (commit) configDB besser dran wären.

Na ja, eine fertig nach configDB geschriebene Konfiguration ist in sich konsistent. Hat man die, ist es m.E. einfacher wie wenn man nur einen Satz (verstreuter) Einzelfiles hat, aber letztlich ist das wohl auch eine Frage des "Wohlfühlens". Aber eigentlich ist es auch nicht wesentlich anders wie beim filesystem: man muß sich darauf verlassen, dass der "Treiber" schon wissen wird, was er auf der nächstunteren Ebene an Aktivitäten auslösen muß, damit am Ende alles auf dem Speichermedium seinen definierten Platz hat...

FHEM ist jedenfalls darauf vorbereitet, alles für den Anwender einfach zu machen, es sind eben (m.E. leider) nur noch nicht alle Module auf diesem Stand.

Ich will hier auch kein "pöse configDB! Hoch lebe fhem.cfg!" lostreten - ich möchte nur die Vorteile der configDb gegenüber fhem.cfg verstehen. Auch warum sich der Aufwand (und Risiko) eines Umstiegs lohnt.

Schon klar, deswegen schreibe ich ja hier auch ausführlicher, was meine Gedanken so sind - eher aus der Anwenderperspektive, btw..

Anders gesagt: Mach' mal eine Liste der Einzelfiles, die du (mit fhem.cfg) auf einem neuen System haben müßtest, damit (ohne Logs) FHEM wieder 1:1 so funktioniert wie auf dem alten... Bei mir wären das in der Zwischenzeit einige!
(Und ja, wenn man weitere Services braucht für ZigBee, Sprachsteuerung, ..., wird der Vorteil ggf. auch relativer, ist auch klar, und wieviel "ungeplanten Spaß" man haben kann, wenn die SD-Karte unvorbereitet hopps geht, erleben wir ja alle 1-2 Monate hier auch hautnah mit, von daher sind geplante Umzüge immer irgendwie machbar...).