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
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
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
Zitat von: Beta-User am 17 September 2020, 08:40:20
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.
Zitat von: betateilchen am 17 September 2020, 11:23:47
[...] 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))
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.
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).
Zitat von: rudolfkoenig am 17 September 2020, 11:51:36
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...
Zitat von: Beta-User am 17 September 2020, 11:34:44
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.
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.
Zitat von: MadMax-FHEM am 16 September 2020, 22:14:28- 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.
Zitat von: Beta-User am 17 September 2020, 08:40:20Bin 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.
Zitat von: betateilchen am 17 September 2020, 11:23:47In 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.
Zitat von: rudolfkoenig am 17 September 2020, 11:51:36
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.
Zitat von: yersinia am 17 September 2020, 12:20:52
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!)
Zitat von: betateilchen am 17 September 2020, 12:14:20
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...
Zitat von: Wzut am 17 September 2020, 12:32:26
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.
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
Zitat von: Beta-User am 17 September 2020, 12:37:24Das "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.
Zitat von: yersinia am 17 September 2020, 13:33:46
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).
ZitatIch 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.
Zitat
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...).
Danke Beta-User, dann verstehe ich es ähnlich aber in die gleiche Richtung.
Zitat von: Beta-User am 17 September 2020, 14:08:40ERGO: 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.
[...]
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.
Heisst für mich als normaler Anwender: configDB bringt mir eigentlich offensichtlich erstmal keine Vorteile und ist einfacher zu Bedienen, wenn ich umziehe. Wenn man nicht gerade DB-affin bzw. eine entsprechende Infrastruktur hat bzw. haben möchte, sind die Vorteile begrenzt.
Zitat von: Beta-User am 17 September 2020, 14:08:40Anders 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!
Oooohja, insbesondere auch alle Pakete die man noch so nachinstallieren muss. Aber dafür macht man ja auch einmal einen Trockenlauf oder hat ein Testsystem - aber da sind wir mMn schon weg vom nicht-versierten Nutzer.
Ich hab eine (ungewöhnliche kurze) Liste und Dokumentation, was ich mitnehmen muss. Darüber hinaus spiele ich ein Backup ein. Das würde
bei mir auch mit configDB gehen, da diese im gleichen Verzeichnis wie FHEM wäre - und durch FHEM gesichert werden würde. Übrigens wöchentlich (https://forum.fhem.de/index.php/topic,87669.0.html) auf RAID1 NAS und diese wiederum wöchentlich auf ein RAID1 Backup NAS mit Versionierung.
Zitat von: hermann1514 am 17 September 2020, 12:41:34
In der Tat sehe ich für mich zur Zeit auch noch nicht wirklich einen klaren Vorteil, der die Migration zur ConfigDB zwingt.
Das kann ich nachvollziehen, denn für User, die die Grundlagen (mindestens einigermaßen) beherrschen, ist es im Prinzip völlig egal, welche Variante sie wählen - du, yersinia, ... und ich, wir werden uns (hoffentlich) immer irgendwie zu helfen wissen.
Die andere Frage, die mich mehr beschäftigt ist die, was man einem Einsteiger empfehlen sollte: configDB bietet (im Prinzip, derzeit noch ggf. wenige Module ausgenommen) eine zentrale Stelle, an der alle Konfigurationsdaten zu finden sind und eine Versionierung. Weiter verhindert es DEN Kardinalfehler, den viele Einsteiger (und auch der eine oder andere "gefühlte Fortgeschrittene") immer noch machen: Unmittelbares cfg-Editieren (auch hier wieder: für die, die wissen, WAS sie da tun, ist auch klar, WIE sie es tun müssen).
_Eigentlich_ sollte es daher keine Frage sein, DASS man Einsteigern diese Empfehlung gibt, das einzige, was ggf. hinderlich ist, ist die "DB-Skepsis" von uns etwas erfahreneren Anwendern, für die es keinen wirklichen Unterschied macht (außer dem Gefühl des unmittelbaren "Kontrollverlustes").
Von daher: ver-configDB't doch einfach mal eines eurer Testsysteme, wenn ihr mal Zeit und Lust zum "Spielen" habt und gebt bei Gelegenheit Rückmeldung, ob ihr das auch für eine gute Idee haltet, Anfänger in diese Richtung zu schubsen ;) .
(FHEM als Gesamtsystem wird dadurch nicht plötzlich einfach, im Gegenteil, es hebt ggf. die Einstiegshürde an der richtigen Stelle auf ein gewisses Niveau, das ggf. hilft, dass sich Leute _nicht_ an FHEM wagen, für die es (vermutlich) "nicht geeignet" ist.)
Bezüglich "Probleme beim SD-Defekt" o.Ä. sollte auf jedem Falle ein (automatisches) Backup bereitstehen, egal ob configDB oder File. Das ist doch ein Grundsatzfehler. Jeder Rechner kann defekt gehen (Egal ob SD, SSD oder sontiges).
Ob jetzt DB-Dump oder FileBackup besser ist (ich habe beides), darüber kann man sich streiten. Wegen Backup deshalb sehe ich da für mich persönlich kein Vorteil von configDB. Weiß auch nicht, ob es mich damals nicht auch verschreckt hätte ....
Wollte aber noch etwas bezüglich der FileXX Diskussion sagen:
So eine Kapselung durch FHEM ist insofern zu empfehlen, da dann eine Speicherung der Daten total irrelevant wird. Vielleicht gibt es in der Zukunft noch eine 3. Möglichkeit der Ablage (z.B. automatisches GIT ;o) ). Der entsprechende Entwickler müsste dann "nur" diese Funktionen erweitern und schon hätte FHEM die Funktion. Wenn dieses nicht verwendet wird ..... wäre es in Summe inkonsequent.
Zitat von: Wernieman am 18 September 2020, 08:15:12
[...] Weiß auch nicht, ob es mich damals nicht auch verschreckt hätte ....
...würde wetten, dass dich (und mich) das NICHT verschreckt hätte ;D . Zum einen ist es kein "Zwang", zum anderen gibt es ja immer noch die Option, einfach der Anleitung zu folgen und dann mal zu sehen, wo man landet ;) - du als erfahrener Admin/*nixer hättest gewußt, dass es auch ok ist, das nicht zu machen, ich hätte allenfalls früher bewußt wahrgenommen, dass "cfg" nicht alles ist oder hätte das halt einfach gemacht...
Zitat
Wollte aber noch etwas bezüglich der FileXX Diskussion sagen:
So eine Kapselung durch FHEM ist insofern zu empfehlen, da dann eine Speicherung der Daten total irrelevant wird. Vielleicht gibt es in der Zukunft noch eine 3. Möglichkeit der Ablage (z.B. automatisches GIT ;o) ). Der entsprechende Entwickler müsste dann "nur" diese Funktionen erweitern und schon hätte FHEM die Funktion. Wenn dieses nicht verwendet wird ..... wäre es in Summe inkonsequent.
Ebend: Es macht Sinn, die zentral zur Verfügung gestellten Funktionen zu nutzen. Ist zwar "lästig", wenn man "vorher" schon was eigenes implementiert hatte und jetzt irgendwie wieder was ändern muß, aber danach ist es eben für alle einfacher... Daher ist die Anfrage an den/die betreffenden Entwickler auch nicht eine digitale in Richtung configDB-Support (ja oder nein).
@hermann1514: Falls dir das OT-Geplapper (?) auf den Wecker geht, mußt du Laut geben, dann machen wir bei Bedarf an anderer Stelle weiter, und so oder so wäre ggf. so langsam aber sicher vermutlich ein [geklärt] oä. im Thread-Titel angebracht.
Zitat von: Beta-User am 18 September 2020, 07:43:06
Eigentlich_ sollte es daher keine Frage sein, DASS man Einsteigern diese Empfehlung gibt, das einzige, was ggf. hinderlich ist, ist die "DB-Skepsis" von uns etwas erfahreneren Anwendern, für die es keinen wirklichen Unterschied macht (außer dem Gefühl des unmittelbaren "Kontrollverlustes").
Ich sage mal so: Hätte Rudi bei der "Erfindung" von FHEM entschieden, die Konfiguration von Anfang an in eine Datenbank abzulegen, würde vermutlich keiner auf die Idee kommen, die Konfiguration in einer simplen Textdatei vornehmen zu wollen. Dann wäre eben die Datenbank der Standard und die Anwender würden nicht darüber nachdenken. Die Idee, dass dies hätte passieren können, ist auch gar nicht so abwegig, da selbst auf der von Rudi lange Zeit als Maß aller Dinge angesehenen Fritzkotz als FHEM-Basis die sqlite Datenbank von Haus aus vorhanden ist und verwendet wird. Und gerade bei sqlite ist die komplette Datenbank ja auch nur eine einzige Datei, also auch physisch kein großer Unterschied.
Dann hake ich doch mal ein (alles nur MEINE perönliche Sicht! ;) ):
Zitat von: betateilchen am 18 September 2020, 12:24:49
Ich sage mal so: Hätte Rudi bei der "Erfindung" von FHEM entschieden, die Konfiguration von Anfang an in eine Datenbank abzulegen, würde vermutlich keiner auf die Idee kommen, die Konfiguration in einer simplen Textdatei vornehmen zu wollen. Dann wäre eben die Datenbank der Standard und die Anwender würden nicht darüber nachdenken.
Hmmm, wäre drauf angekommen, ob dann alles (damals) schon automatisch installiert worden wäre, also DB inkl. notwendiger User etc.
So wie bei anderer Software, z.B. Unifi Controller auch, da ist mir egal, ob eine DB "drunter" läuft.
Ist aber ein "Firmen-Produkt" (also [auch] gedacht für Produktivbetrieb usw. / soll jetzt nicht "gegen" fhem gehen ;) ) und ich "schraub" da nicht dran rum (weil ich gar nicht will/muss/kann ;) )...
EDIT: mit dran "Rumschrauben" war jetzt die Contoller-SW (vgl. fhem) gemeint, nicht die DB (vgl. fhem.cfg: weil da schraub ich auch [nicht mehr] direkt dran rum / ABER: wenn ich müsste, könnte ich ;) :) )... ;)
Zitat von: betateilchen am 18 September 2020, 12:24:49
Und gerade bei sqlite ist die komplette Datenbank ja auch nur eine einzige Datei, also auch physisch kein großer Unterschied.
Ja physisch schon...
...aber (jaja "Old-School" ;) ): eine Textdatei ist halt eine Textdatei. Die kann man (auch ich :) ) zur "Not" mal "retten" ("gerade biegen" ;) )...
Wenn die DB-Datei "über den Jordan" ist, dann: also ich wüsste nicht weiter...
Noch mal: nur meine (old-School ;) ) Sicht...
Evtl. baue ich ja eines meiner Testsysteme mal um...
...wozu hab ich sie denn ;)
...mal sehen, vielleicht sehe ich es ja dann anders ;)
Gruß und nix für ungut, Joachim
ZitatHätte Rudi bei der "Erfindung" von FHEM entschieden, die Konfiguration von Anfang an in eine Datenbank abzulegen...
Ich will von so wenig Fremd-Komponenten abhaengen, wie moeglich, und die Konfiguration oder gar FHEM idiotensicher zu machen war nie mein Ziel. Ich habe auch ein Problem mit Systemen, die ich im Fehlerfall nicht fixen kann, oder wo ich ein Studium brauche, um die Konfiguration zu finden.
Finde ausserdem interessant, dass es zwar immer wieder fhem.cfg Editierer gibt, aber bisher kein SQL-Editierer gebeichtet hat. Geht naemlich genauso :)
Heisst nicht, dass ich gegen configDB bin, ich finde Vielfalt gut.
Zitat von: betateilchen am 18 September 2020, 12:24:49
Ich sage mal so: Hätte [...]
Keine Frage, wir alle leben mit Entscheidungen, die wir oder andere für uns irgendwann mal getroffen haben, aus welchen Gründen auch immer. (@Rudi: das war getippt, bevor du was geschrieben hattest, ist keine Wertung in irgendeine Richtung).
Das "Problem" ist eher, dass man sich - aus Gründen, die ich in der Sache nicht mal ansatzweise nachvollziehen kann - als configDB-Nutzer nicht ganz selten unterschwellig so vorkommt, als müsse man sich dafür rechtfertigen, weil "gefühlt" die Grundhaltung der ganz überwiegenden Mehrzahl der User eher so ist, dass man meinen könnte, die stellen sich die Frage "configDB, wieso das denn...?!?!?". (@MadMax-FHEM: Danke für die Bestätigung, bin mal gespannt, wann du das mit dem Testsystem umsetzt...)
Vor so einem "Grundraunen" macht es wenig Sinn darauf zu verweisen, dass es erwiesenermaßen und seit Jahren völlig gefahrlos machbar ist und es dem Anfänger leichter macht, "seine" Teile im "Heuhaufen" besser vom Rest unterscheiden zu können. Aber solange zu wenige potentielle Multiplikatoren hier gesehen haben, was bei "configdb filelist" rauskommt (oder diff, search oder ..., ...), tue ich mich etwas schwer, da sehr offensiv zu werben, zumal, wenn es gewisse (nicht configDB anzulastende!) Ausnahmen vom zu erwartenden Verhalten eines "guten" Moduls gibt, was die Ablage von Konfigurationsdaten angeht, und man dann als Anwender doch wieder aufpassen muß, dass man "alles beeinander" hat.
(@Rudi: Ich habe übrigens irgendwo eine Anleitung rumliegen, wie man das früher ziemlich "beliebte" Reihenfolgeproblem auf dem SQL-Weg beseitigen könnte - ich habe derartige Notfallmaßnahmen allerdings nie gebraucht, v.a. weil ich IO's tendenziell immer geändert, aber nie gelöscht habe...)
@all: Es kann durchaus sein, dass man ggf. configDB als Mechanismus auch noch verbessern kann oder muss, aber solange es nicht breiter genutzt wird bzw. nur von Leuten, die mit SQL auch "direkt könnten", werden wir das kaum rausfinden. Auch von daher nochmal: testen, nutzen, verbessern!
Apropos werben: das mit "private" muß ich mir auch nochmal bei Gelegenheit ansehen, vermutlich habe ich die Erklärung des Features entweder verpaßt oder mal wieder nicht verstanden...
(Und eigentlich wäre es mir am liebsten, wenn meine 99_myUtils.pm dann auch direkt in der DB abgelegt werden könnten, dann wäre wirklich alles "FHEM-betreffende von mir" beieinander (? oder übersehe ich auch da mal wieder was, muss wohl mal testen ::) ..).)
@MadMax-FHEM:
Ich mache gegegentlich auch File-Kopien aus der DB raus, das geht prinzipiell! (Ich habe mir damals was anhören dürfen, als ich nach dem "Notausgang" gefragt hatte, bevor ich den Schritt dann gegangen bin...)
Und bei Umzügen bin ich bisher - v.a. auch wegen der Frage der nachzuinstallierenden Perl-Module - auch eher erst über eine cfg-Version gegangen, habe nachinstalliert, was fehlt und habe dann erst den endgültigen Wechsel gemacht. Heute würde ich das anders machen, das Risiko, dass man sich "verspeichert" (und dann mühevoll wissen muss, wie man Teile "restauriert") ist nämlich zumindest gefühlt bei configDB deutlich weniger ausgeprägt, auch wenn das vermutlich jeder sachlichen Grundlage entbehrt...
Und ernsthaft: FHEM wird durch configDB nicht "idiotensicher", zumal es sich zwischenzeitlich sogar unter eingefleischten vi-Nutzern rumgesprochen hat, dass es komfortablere Wege gibt, seine Konfiguration zu bearbeiten...
Nach den vielen pro/con Argumenten mal eine ganz andere Sicht eines "noch fhem.cfg"-Nutzers:
Wenn ich mich auf den Gedanken der DB einlasse, würde ich
- mehrere FHEM-Instanzen vorsehen id ejweiles eine eindeutige ID erhalten
- alle Tabellen in der DB würden die ID mitführen
- alle FHEM-Instanzen schreiben in dieselben Tabellen (eindetig wird's durch die ID)
- über eine "copy"-Funktion wäre ich in der Lage Elemente aus einer Instanz (z.B. Test) in eine andere (z.B. Main) zu übertragen
- die Logs gehören dann auch direkt mit in die DB
- DB-Writes dürfen zu keinem lock der FHEM-Instanzführen
- auf Readings kann ich über <id><device><reading> zugreifen (dann spare ich mir in gewisser Weise FHEM2FHEM etc.
Dabei nich icht gelöst
- instanzübergreifende Events
VG Peter
P.S. Meine Landschaft sieht so aus https://wiki.fhem.de/wiki/Benutzer:Plin53177 (https://wiki.fhem.de/wiki/Benutzer:Plin53177)
Zitat von: rudolfkoenig am 18 September 2020, 13:11:08
Finde ausserdem interessant, dass es zwar immer wieder fhem.cfg Editierer gibt, aber bisher kein SQL-Editierer gebeichtet hat. Geht naemlich genauso :)
Ich beichte ;) Allerdings nicht als _regelmässiger_ SQL Editierer, sondern nur einmal als meine Konfig (die ich nw. ausschliesslich über Fhem-Oberfläsche mache) Fhem systemaitsch zum Absturz gebracht hat, und ich mit rescue mode oder recover es nicht geschafft habe.
Bei configDB finde ich nur Schade, dass das backup Kommando kein configdb dump im Vorfeld macht. Hat vielleicht seinen Grund, und backup sichert auch die DB Dateien bei SQLite, so dass es zumindest für Sqlite weniger problematisch ist.
PS: Logs in der (selben) DB bin ich komplett dagegen.
Zitat von: Beta-User am 18 September 2020, 13:24:06
(Und eigentlich wäre es mir am liebsten, wenn meine 99_myUtils.pm dann auch direkt in der DB abgelegt werden könnten, dann wäre wirklich alles "FHEM-betreffende von mir" beieinander (? oder übersehe ich auch da mal wieder was, muss wohl mal testen ::) ..).)
Das funktioniert schon, seit es die configDB gibt, wird aber bei einer Migration nicht automatisch durchgeführt.
Alles was Du tun musst, ist:
configdb filemove ./FHEM/99_myUtils.pmDas funktioniert natürlich nicht nur mit 99_myUtils.pm, sondern mit allen 99_.*Utils.pm Dateien.
Das mitlesen hier im Thread hat mich jetzt echt neugierig gemacht!
die nächsten Tage wird eine Test-Instanz umgestellt. :-)
Ich werde berichten.
schönes WE!
/Frank
Zitat von: plin am 18 September 2020, 14:47:56
Nach den vielen pro/con Argumenten mal eine ganz andere Sicht eines "noch fhem.cfg"-Nutzers:
Wenn ich mich auf den Gedanken der DB einlasse, würde ich
- mehrere FHEM-Instanzen vorsehen id ejweiles eine eindeutige ID erhalten
- alle Tabellen in der DB würden die ID mitführen
- alle FHEM-Instanzen schreiben in dieselben Tabellen (eindetig wird's durch die ID)
Das kann die configDB schon lange. Man kann beliebig viele FHEM Installationen in einer einzigen Datenbank ablegen, das funktioniert bei mir mit 12 Systemen problemlos.
Um nicht unnötig Verwirrung zu stiften und weil ich nicht unbegrenzt viel Support leisten kann (und will), ist dieses Feature bisher nicht dokumentiert.
Eine Vermischung von configDB und DbLog würde ich aber bis in alle Ewigkeiten ablehnen, dazu sind die Arbeitsweisen dieser beiden Datenbankszenarien innerhalb von FHEM einfach zu unterschiedlich.
Zitat von: amenomade am 18 September 2020, 15:03:11
Bei configDB finde ich nur Schade, dass das backup Kommando kein configdb dump im Vorfeld macht. Hat vielleicht seinen Grund,
Die grundsätzliche Integration der Datenbank in das FHEM-eigene backup wurde seinerzeit (bei der Entwicklung von configDB) durch Rudi vehement abgelehnt, wir hatten da mehrere Tage lange Diskussionen.
Zitat von: betateilchen am 18 September 2020, 16:33:47
Das kann die configDB schon lange. Man kann beliebig viele FHEM Installationen in einer einzigen Datenbank ablegen, das funktioniert bei mir mit 12 Systemen problemlos.
Um nicht unnötig Verwirrung zu stiften und weil ich nicht unbegrenzt viel Support leisten kann (und will), ist dieses Feature bisher nicht dokumentiert.
Falls mir configDB gefällt und ich die Produktiven Systeme umstelle würde ich darauf zurückkommen.
Du legst ja wie Du schreibst nicht für jede Instanz ne eigene Datenbank an, oder doch?
Zitat von: betateilchen am 18 September 2020, 16:30:15
Das funktioniert schon, seit es die configDB gibt, wird aber bei einer Migration nicht automatisch durchgeführt.
Alles was Du tun musst, ist:
configdb filemove ./FHEM/99_myUtils.pm
Das funktioniert natürlich nicht nur mit 99_myUtils.pm, sondern mit allen 99_.*Utils.pm Dateien.
...ich hatte geahnt, dass mir was entgangen war...
@all: das ist btw. mit vorhandenen .gplot und .holiday-Dateien usw. (mind. noch Templisten von CUL_HM) auch nicht anders, jedenfalls, soweit ich mich entsinne. Auch die kann/muss man ggf. importieren bzw. die werden erst dann in die DB gespeichert, sobald man an denen unter configDB was ändert (so jedenfalls der Spur nach, ist schon eine ganze Zeit her, dass ich mir darüber einen Kopp gemacht habe, und es funktioniert halt im wesentlichen fast alles automatisch, wenn's mal entsprechend aufgegleist ist...).
(@Rudi: Mein ansonsten nicht unbedingt in allen Punkten optimaler "mache mir eine .holiday"-Code schreibt btw. aus diesem Grund absichtlich nicht ins Filesystem, weil es für mich einleuchtender ist, die darin enthaltenen privaten Daten in der Datenbank zu haben; das war mir nur nicht mehr so direkt vor Augen gestanden, als du dazu neulich die Anmerkung gemacht hattest).
@Frank_Huber: :) .
Bzgl. des Logging wollte ich nochmal ausdrücklich betonen, dass ich das auch als Anwender nicht gut fände, wenn das "zwangsweise" mitkäme. An der Stelle finde ich Files eigentlich sympatischer, bin halt meinem "will ich wissen"-Trieb erlegen, als es die Hardware hergab...
Zitat von: Beta-User am 18 September 2020, 13:24:06
Apropos werben: das mit "private" muß ich mir auch nochmal bei Gelegenheit ansehen, vermutlich habe ich die Erklärung des Features entweder verpaßt oder mal wieder nicht verstanden...
was meinst Du damit?
Zitat von: betateilchen am 18 September 2020, 17:34:20
was meinst Du damit?
In der commandref ist ein "configdb attr private 1" zu finden, es ist aber wie bei so vielem: Man müßte sich intensiver damit befassen, und ich will hier auch kein weiteres Halbwissen verbreiten. Irgendwo im Hinterkopf hat sich mir festgesetzt, dass dann bei list usw. teilweise persönliche Daten, Passwörter usw. irgendwie anonymisiert werden würden (kann auch sein, dass das wieder entsprechende Modulunterstützung voraussetzt...).
Nochmal: ich habe das nur angesprochen, weil wir grade in so einer nette Diskussion über das für und wieder sind, und ggf. bietet das ja Gelegenheit, mich und andere (User oder auch Developer) kurz auf die richtige Spur zu bringen, wie man das eigentlich nutzt, ohne dass ich umfassende Recherche machen müßte, um dann wieder nur Halbwissen zu erwerben, weil ich's halt nicht besser verstehe ::) ...
Zitat von: betateilchen am 18 September 2020, 16:33:47
Eine Vermischung von configDB und DbLog würde ich aber bis in alle Ewigkeiten ablehnen, dazu sind die Arbeitsweisen dieser beiden Datenbankszenarien innerhalb von FHEM einfach zu unterschiedlich.
Na ja, was bedeutet "eine Datenbank"?
- Unterstützt werden derzeit SQLite, MySQL und PostgreSQL.
- Im Falle von MySQL würde es ein "create database fhem;" geben.
- Für configDB und DbLog gibt es selbstverständlich separate Tabellen.
Unter "in einer Datenbank" verstehe ich rein technisch eine MySQL-Instanz mit einer Database fhem. Ja die Anforderungen sind sehr unterschiedlich. Wo ist für Dich der Knackpunkt: Wäre eine Datenbank wie SQLite eher für die configDB und MySQL eher für's DbLog geeignet?
VG plin
P.S. Meine MariaDB-Instanz im Keller läuft auf einem x86-Server 7/24. Wieso sollte ich die nicht nutzen?
Er meinte wahrscheinlich, dbconfig und logdb sollten nicht in der kleichen Datenbank EINES DB-Servers liegen. Was immer wieder vergessen wird: Ein DB-Server kann verschiedene Datenbanken betreiben. Eben eine configDB und eine LogDB ... aber nicht eine FHEM-DB (Jedenfalls nicht empfohlen)
Zitat von: Beta-User am 18 September 2020, 17:50:50
In der commandref ist ein "configdb attr private 1" zu finden, es ist aber wie bei so vielem: Man müßte sich intensiver damit befassen,
Das Attribut dient lediglich dazu, bei der Ausgabe von "configdb info" die Benutzerdaten (user/password) zur Verbindung mit der Datenbank NICHT mit auszugeben. Eine weitere Funktion hat dieses Attribut nicht.
configdb info
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 22343 2020-07-04 09:23:54Z betateilchen $
c:$Id: 98_configdb.pm 22340 2020-07-03 11:01:06Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/sqldb/configDB.db
dbtype: SQLITE
dbsize: 324.00 KB
-----------------------------------------------------------------
lastReorg: Sat Jul 28 14:06:33 2018
config: 1831 entries
Ver 0 saved: Thu Jun 4 11:55:31 2020 def: 57 attr: 398
Ver 1 saved: Mon Apr 27 20:29:25 2020 def: 57 attr: 330
Ver 2 saved: Mon Apr 27 18:36:57 2020 def: 56 attr: 292
Ver 3 saved: Mon Mar 30 17:09:22 2020 def: 56 attr: 320
-----------------------------------------------------------------
state: 555 entries saved: Fri Sep 18 00:07:02 2020
-----------------------------------------------------------------
filesave: 12 files stored in database
-----------------------------------------------------------------
im Gegensatz zu
configdb attr private 0
attribute private set to value 0
configdb info
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 22343 2020-07-04 09:23:54Z betateilchen $
c:$Id: 98_configdb.pm 22340 2020-07-03 11:01:06Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/sqldb/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
dbsize: 324.00 KB
-----------------------------------------------------------------
lastReorg: Sat Jul 28 14:06:33 2018
config: 1831 entries
Ver 0 saved: Thu Jun 4 11:55:31 2020 def: 57 attr: 398
Ver 1 saved: Mon Apr 27 20:29:25 2020 def: 57 attr: 330
Ver 2 saved: Mon Apr 27 18:36:57 2020 def: 56 attr: 292
Ver 3 saved: Mon Mar 30 17:09:22 2020 def: 56 attr: 320
-----------------------------------------------------------------
state: 555 entries saved: Fri Sep 18 00:07:02 2020
-----------------------------------------------------------------
filesave: 12 files stored in database
-----------------------------------------------------------------
Bei sqlite werden ohnehin keine Benutzerdaten verwendet, aber bei mysql würden bei dbuser und dpbass die entsprechenden Werte stehen.
Zitat von: plin am 18 September 2020, 18:27:17
Meine MariaDB-Instanz im Keller läuft auf einem x86-Server 7/24. Wieso sollte ich die nicht nutzen?
Kannst Du ja machen.
Trotzdem solltest Du in Deine MariaDB-Instanz für configDB und DbLog jeweils ein eigenes "create database ..." verwenden.
Zitat von: plin am 18 September 2020, 18:27:17
Unterstützt werden derzeit SQLite, MySQL und PostgreSQL.
es soll Leute geben, die haben auch schon HANA angebunden 8)
Zitat von: betateilchen am 18 September 2020, 21:19:28
Das Attribut dient lediglich dazu, bei der Ausgabe von "configdb info" die Benutzerdaten (user/password) zur Verbindung mit der Datenbank NICHT mit auszugeben.
Danke für die Erhellung!
Das "Nicht-Ausgeben" der Benutzerdaten ist übrigens das Standardverhalten (privacy by default)
Man muss sich im Normalfall also gar nicht um das Attribut kümmern.
[ziemlich weit OT] Das mit der Privacy beschäftigt mich verstärkter, seit ich mich mit Twilight etwas näher beschäftigen darf. Da ist es so, dass typischweise recht genaue Koordinaten des Standorts im list stehen, was einereseits hilfreich ist, falls man einen simplen Rechenfehler suchen würde (den es aber hoffentlich nicht gibt, diese Code-Teile dürften uralt sein und daher hinreichend für ok befunden), andererseits ist das eben nicht unbedingt "privacy-freundlich".
Aber das ist eine ganz andere Baustelle und einen simplen Lösungsansatz für derartige Problemstellungen sehe ich nicht (klar, man müßte eine ganz andere Methode verwenden, um die Daten dann woanders als in der define/attr-cfg zu speichern, das ist aber ein ziemlicher Aufwand....)
Zitat von: Beta-User am 18 September 2020, 22:19:50
(klar, man müßte eine ganz andere Methode verwenden, um die Daten dann woanders als in der define/attr-cfg zu speichern, das ist aber ein ziemlicher Aufwand....)
Die zentralen Funktionen setKeyValue() und getKeyValue() kennst Du?
Sie sind genau für sowas gedacht und relativ wenig aufwändig.
Klar! (Rate mal, wo der Vorschlag herkam, im Wiki zum "Mail-Versenden"-Teil bei Pi (?) die credentials mit dieser Methode zu speichern?).
Bedeutet nur, dass man den Code komplett umbauen müßte (deletefn und renamfn entsprechend ergänzen) und so weiter, vermutlich am besten gleich iVm. parseparms, und dann noch eine Idee entwickelt, wie man bestehende Devices umbaut.
(sinnvoll wäre das ggf. auch schon deshalb, weil die Daten in 99,9% der Fälle sowieso aus global kommen bzw. dahin gehören und das erste (jetzt) sinnvolle Element erst an dritter Stelle der DEF kommt. Aber eigentlich wollte ich mir nicht unbedingt soviel "Spaß" reinziehen, als ich die Hand "für" das Modul gehoben habe...)
Ich komme ggf. an anderer Stelle nochmal darauf zurück, ist hier wirklich komplett OT...
Stichwort OT : @Udo es wäre schön wenn du unter https://forum.fhem.de/index.php/topic,114288.0.html eine Antwort/Lösung geben könntest ....
kleiner Erfahrungsbericht zur configdb Migration eines Testsystems.
ein zentraler MySQL war für dblog schon vorhanden.
Erstmal einlesen wie das geht, also Wiki öffnen. https://wiki.fhem.de/wiki/Configdb
Die Wiki Seite verweist auf die CommandRef: https://fhem.de/commandref_DE.html#configDB
dort findet man einen Verweis auf https://fhem.de/commandref_DE.html#configdb
dort "leider keine >Deutsche Doku, Link zur Englischen: https://fhem.de/commandref.html#configdb
Hier wäre es evtl besser im Wiki direkt die Englische CR zu verlinken.
Für die Einrichtung musste ich keine Pakete nachinstallieren, war alles schon vorhanden.
Das anlegen einer neuen MySQL Datenbank musste ich mir woanderst abschauen. war aber im dblog wiki schnell ein Hinweis gefunden.
leere DB angelegt, config file ins fhem Verzeichnis. (Kopie von dblog mit Anpassungen)
Die Migration lief dann Problemlos wie beschrieben. Ein Test mit manuellem Neustart war auch OK.
ABER: Bei einem System Reboot, oder auch einem Service Neustart läd er wieder die Config Datei.
Dass der System-Service angepasst werden muss ist im der CR nicht zu finden.
Den Service anzupassen war schnell erledigt.
Fazit:
Die Migration geht schnell von der Hand, aber nur mit ein bisschen Erfahrung auf Linux und mit SQL.
ein reiner "User" wäre hier sehr wahrscheinlich hilflos verloren beim anlegen einer Datenbank und/oder beim Ändern des Service.
vor allem falls noch keine Datenbank vorhanden ist.
Oder habe ich evtl die "richtige" Wiki Seite nicht gefunden?
Mein Test System ist jetzt jedenfalls umgestellt.
Holiday und gplot Dateien wurden nicht automatisch importiert.
zum Fileimport noch ein Feature Request:
Es gibt ja das Attribut "deleteimported", hier würde ich mir noch ein "renameimported" wünschen welches evtl ein "imported_" als Prefix an die Daten setzt.
Vorab mal Danke für die Rückmeldung.
Im Wiki habe ich gleich ein paar Kleinigkeiten dazu ergänzt, u.A. gibt es einen Workshop hier im Forum, bei dem am Ende auch das Thema "Startscript" zu finden ist: [Workshop] Umstieg von fhem.cfg auf configDB in 5 Schritten
(@betateilchen: Deine Meinung zum Thema Wiki ist bekannt, ich werde es knapp halten und habe nicht die Absicht, das wesentlich auszuweiten).
Der Weg über MySQL ist (vermutlich) etwas schwieriger, (lokales) SQlite ist easy und auch jeweils in D (Workshop) bzw. der cref (en) beschrieben (in der cref würde ich mir den Hinweis auf "make it permanent" auch wüschen).
Zitat von: Frank_Huber am 21 September 2020, 11:00:21
Holiday und gplot Dateien wurden nicht automatisch importiert.
Da habe ich mich vermutlich missverständlich ausgedrückt: Ich importiere nur meine _eigenen_ .gplot und .holiday. Alles, was zentral kommt (Feiertagskalender für das eigene Bundesland, z.B.), braucht man nicht in der DB, die sind ganz gut im Filesystem aufgehoben.
Wie geschrieben, sehe ich einen wesentlichen Vorteil darin, dass man seine eigenen und die allgemeinen Files besser getrennt hat...
Das mit den Dateien ist auch OK so.
Habe es nur erwähnt weil das im Thread hier vor kurzem nicht ganz klar war.
Wer einen zentralen MySQL am laufen hat bekommt das dann auch hin. ich konnte viel bei dblog abschaun. :-)
wer es ganz lokal mit sqlite macht hat die Anleitungen über den Thread und die CR. das passt dann schon. für mich gehört eine DB aber runter vom RasPi...
Im Workshop das "make it permanent" bezieht sich noch auf init.d. Aktuelle Systeme arbeiten mit systemd --> /etc/systemd/system/fhem.service
mit weiteren Dateien muss ich mal experimentieren wie sich das verhält. Ich sehe da nur eine Schwierigkeit, wenn ich z.B. zwei/drei gplot importiere sehe ich nicht wirklich welche in der DB und welche auf file sind. Daher vorhin auch der Vorschlag mit dem "imported_" ;-)
Wenn die Testphase rum ist und ich wirklich umsteige werde ich "deleteimported" setzen.
Aber dazu muss ich dann auch erst noch rauskriegen wie man mehrer Instanzen in die DB bekommt. :-)
weitere kleine Hürde:
gplot Dateien müssen importiert werden. sonst funktionieren sie nicht.
beim Importieren mit voller Pfadangebe funktionierren die gplot auch nicht. (/opt/fhem/www/gplot/...)
Es muss mit Pfad ./www/gplot/... importiert werden.
sehr schön:
Importierte Dateien sind auch unter "Edit files" verfügbar und Änderungen werden wieder in die DB gespeichert! :-)
Hallo Frank,
Einiges von dem, was Du hier so zusammenschreibst, sind schlichtweg falsche Behauptungen.
Zitat von: Frank_Huber am 21 September 2020, 15:28:57
gplot Dateien müssen importiert werden. sonst funktionieren sie nicht.
Um genau zu sein:
gplot Dateien, die zum Zeitpunkt der Migration in irgendeinem existierenden SVG device verwendet werden, werden sehr wohl automatisch importiert.
Vom Benutzer neu erstellte gplot Dateien werden automatisch in die configDB abgelegt.
Die Einschränkung "zum Zeitpunkt ... verwendet" gilt auch für die anderen Module, deren spezifische Dateien migriert werden.
Zitat von: Frank_Huber am 21 September 2020, 15:28:57
beim Importieren mit voller Pfadangebe funktionierren die gplot auch nicht. (/opt/fhem/www/gplot/...)
Es muss mit Pfad ./www/gplot/... importiert werden.
Das ist ein völlig logisches Verhalten, das von SVG vorgegeben ist und der größtmöglichen Transparenz geschuldet ist. Schließlich gibst Du bei der Definition eines SVG devices auch keinen vollständigen Pfad zur gplot Datei an.
Zitat von: Frank_Huber am 21 September 2020, 12:37:44
Ich sehe da nur eine Schwierigkeit, wenn ich z.B. zwei/drei gplot importiere sehe ich nicht wirklich welche in der DB und welche auf file sind.
Doch, man kann das erkennen. Zum Beispiel, wenn man den Mauszeiger auf den Link zur Datei bei "Edit files" stellt und sich den Link anschaut.
https://.../fhem?cmd=style%20edit%20SVG_dbLog_1.gplot%20configDB&fwcsrf=...wenn - wie im Beispiel - die Kennzeichnung "configDB" im Link steckt, kommt die Datei aus der Datenbank und wird auch wieder dorthin zurückgeschrieben.
Zitat von: Frank_Huber am 21 September 2020, 12:37:44
Wenn die Testphase rum ist und ich wirklich umsteige werde ich "deleteimported" setzen.
Davon rate ich regelmäßig ab und ich überlege sogar, dieses Attribut wieder zu entfernen.
Du solltest lieber "filemove" anstatt "fileimport" verwenden, dann brauchst Du das Attribut nicht.
Zitat von: Frank_Huber am 21 September 2020, 12:37:44
Aber dazu muss ich dann auch erst noch rauskriegen wie man mehrer Instanzen in die DB bekommt. :-)
Das wirst Du nicht rauskriegen und ich werde das nie zu einem offiziellen Feature machen.
Die damit verbundenen Risiken sind mir einfach zu groß, das ist nicht supportbar.
Zitat von: Beta-User am 21 September 2020, 11:51:14
Im Wiki habe ich gleich ein paar Kleinigkeiten dazu ergänzt,
...
(@betateilchen: Deine Meinung zum Thema Wiki ist bekannt, ich werde es knapp halten und habe nicht die Absicht, das wesentlich auszuweiten).
Der Blitz soll Dich beim Kacken treffen ...
---
Und damit ist mein configdb Test beendet, da bleibe ich dann lieber bei der cfg.
Gründe:
1. kein wirklicher Vorteil zu sehen. Es wird eher unübersichtlicher.
2. keine wirkliche Transparenz was in der DB ist und was nicht. (ich schaue nicht den Link jedes Elements an um zu sehen wo es liegt)
3. gpolt Dateien müssen in der DB sein. Eine Datei wird schlicht ohne Fehlermeldung ignoriert.
(ich könnte erklären wie es bei meinen Tests dazu kam, aber das interessiert ja eh nicht, is ja ne falsche Behauptung)
4. Doku. Ist für ein Modul das so zentral eingreift schlicht zu knapp gehalten und wichtige Themen fehlen gänzlich.
5. Mir persönlich fehlt ein Device in FHEM über das die Befehle abgesetzt werden, die Attribute zu sehen sind und evtl andere Status Readings.
6. Ich lege sicher nicht für jede Instanz eine eigene Datenbank an.
Danke auf alle Fälle für's testen!
Kurz meine Gedanken dazu:
Dass es insbesondere für erfahrenere User keine massiven Verbesserungen bringt, hatte ich hoffentlich hinreichend deutlich gemacht. Was Übersichtlichkeit angeht, hat das eine subjektive Komponente, das war mir bisher nicht in der Deutichkeit klar. Mir genügen z.B. die Ergebnisse aus "configdb filelist", aber ich mache eben auch vieles über die Kommandozeile und hatte bisher auch nicht den Wunsch, ein "Objekt" (ähnlich "global"?) zu haben, um irgendwelche Statusinfos zu dem zu haben, was in der DB ist. Aber andere Gewohnheiten, andere Erwartungen; das ist m.E. grundsätzlich ok.
Nutzt man configdb von Anfang an, sind in der Regel alle "externen" Konfigurationsfiles in der DB, und zwar automatisch. Von daher bin ich (als User) eher negativ überrascht, wenn ein Modul hier abweichendes Verhalten zeigt (und hatte in betateilchens Antwort das erste mal bewußt wahrgenommen, dass genutzte .plot importiert werden; das "was wird importiert" war (und ist in Teilen) auch eine der für mich offenen Fragen). "Direkteinsteigern" dürften sich daher Umstellungsfragen nicht in derselben Weise stellen und der Hinweis, dass man besser gleich "filemove" machen sollte, ist auch sehr wertvoll.
M.E. ist die ziemlich knappe Doku auch völlig ok, überbordende Detailinfos helfen in der Regel nicht weiter, aber grade die sehr spärlichen Infos, die man zu manchen Detailfragen finden kann (wenn man weiß, wonach man sucht?), empfinde ich auch als nicht unbedingt förderlich für den Gedanken, configDB auch Einsteigern zu empfehlen.
Wie dem auch sei, bin mal gespannt, ob es noch Rückmeldungen von weiteren Testern gibt...?
Ich hab heute ein neues frisches System aufgesetzt und wollte zum testen mal gleich mit configdb anfangen. Klappt soweit auch bis jetzt gut.
Eine Frage hätte ich vorab aber schon mal.
Das ist meine config:
%dbconfig= (
connection => "mysql:database=HausautomationConf;host=xx.xx.xx.xxx;port=3307",
user => "xxx",
password => "xxx"
);
dafür hatte ich statt database dbname drinstehen. Funktioniert wohl beide. Gibt es da einen unterschied was ist das richtige?
Eine Kleinigkeit noch. Ich hab den dump Befehl testen wollen. Leider wird da bei mir nichts gespeichert. Die aus gäbe ist 0byte. In der db ist aber was drin.
Im Logfile zeigt er nur folgendes an.
sh: 1: Syntax error: "&" unexpected
Ich hab den Dump Befehl jetzt nochmal mit einem anderen Datenbank Benutzer getestet. Wenn ich einen nehme der keine Sonderzeichen im Passwort hat funktioniert es wohl...
Zitat von: DJAlex am 23 Januar 2021, 03:13:56
dafür hatte ich statt database dbname drinstehen. Funktioniert wohl beide. Gibt es da einen unterschied was ist das richtige?
In der Dokumentation zum perl Datenbankmodul DBD::mysql ist nur "database" beschrieben.
Zitat von: DJAlex am 23 Januar 2021, 03:13:56
Ich hab den Dump Befehl jetzt nochmal mit einem anderen Datenbank Benutzer getestet. Wenn ich einen nehme der keine Sonderzeichen im Passwort hat funktioniert es wohl...
Dann hast Du die Lösung ja schon selbst gefunden :)
Zitat von: DJAlex am 23 Januar 2021, 03:13:56
Ich hab heute ein neues frisches System aufgesetzt und wollte zum testen mal gleich mit configdb anfangen. Klappt soweit auch bis jetzt gut.
Guter Plan!
ZitatDann hast Du die Lösung ja schon selbst gefunden :)
Das war eigentlich mehr ein Hinweis darauf das ich das nicht ganz konsistent finde, dass ich die Konfiguration zwar mit Sonderzeichen erstellen kann und alles normal funktioniert aber der "dump" Befehl damit nicht geht. Die Sonderzeichen sind bei mir mit \ maskiert. Ansonsten Scheint bis jetzt alles gut zu funktionieren :-)
Hast Du mal probiert, ob mysqldump auf der Betriebssystemebene mit Deinen Sonderzeichen klarkommt?