Vorteil von der configdb

[yersinia]

Danke Beta-User, dann verstehe ich es ähnlich aber in die gleiche Richtung.

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.
[...]
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.

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!

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 auf RAID1 NAS und diese wiederum wöchentlich auf ein RAID1 Backup NAS mit Versionierung.

[Beta-User]

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.)

[Wernieman]

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.

[Beta-User]

[...] Weiß auch nicht, ob es mich damals nicht auch verschreckt hätte ....

...würde wetten, dass dich (und mich) das NICHT verschreckt hätte . 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...

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.

[betateilchen]

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.

[MadMax-FHEM]

Dann hake ich doch mal ein (alles nur MEINE perönliche Sicht!   ):

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 )...

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

[rudolfkoenig]

Hä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.

[Beta-User]

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...

[plin]

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

[amenomade]

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.

[betateilchen]

(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:

Code Auswählen Erweitern

configdb filemove ./FHEM/99_myUtils.pm

Das funktioniert natürlich nicht nur mit 99_myUtils.pm, sondern mit allen 99_.*Utils.pm Dateien.

[Frank_Huber]

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

[betateilchen]

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.

[betateilchen]

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.

[Frank_Huber]

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?