Vorteil von der configdb

[Beta-User]

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.

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

[betateilchen]

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?

[Beta-User]

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

[plin]

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?

[Wernieman]

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)

[betateilchen]

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.

Code Auswählen Erweitern


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

Code Auswählen Erweitern


configdb attr private 0
attribute private set to value 0


Code Auswählen Erweitern


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.

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.

Unterstützt werden derzeit SQLite, MySQL und PostgreSQL.

es soll Leute geben, die haben auch schon HANA angebunden 

[Beta-User]

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!

[betateilchen]

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.

[Beta-User]

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

[betateilchen]

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

[Beta-User]

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

[Wzut]

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

[Frank_Huber]

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.

[Beta-User]

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

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

[Frank_Huber]

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.