fhem configuration in sql-DB ablegen - besteht Interesse?

[betateilchen]

Irgendwie nervt mich das Rumgehampel mit den cfg-Dateien. Deshalb habe ich mich hingesetzt und die gesamte Konfiguration in eine sql-Datenbank (bei mir: sqlite) gepackt.

Dazu habe ich die fhem.pl durchforstet und an den entsprechenden Stellen angepaßt. Der Aufwand dafür ist überschaubar, Anpassungen werden benötigt

• beim fhem Start
• beim Setzen der globalen Attribute
• beim save
• beim rereadcfg

Derzeit starte ich mein fhem mit

Code Auswählen Erweitern

perl fhem.pl configDB

und das funktioniert auch prima ("configDB" ist als Schlüsselwort zu verstehen) und parallel zur bisherigen Funktionsweise (es kann immer noch mit fhem.cfg gestartet werden, dann bleibt die Datenbank komplett unberücksichtigt). Die Datenbankverbindung ist derzeit noch hartverdrahtet, die müsste man natürlich noch konfigurierbar machen.
Desweiteren muss das Editieren der Konfiguration im Frontend (Edit Files) noch angepaßt werden.

Grundsätzliche Frage: Besteht Interesse, diesen Ansatz weiterzuverfolgen und zu einer richtigen Lösung auszubauen?

Ich würde dann eine entsprechende pm-Datei erstellen, in der die notwendigen Funktionen außerhalb der fhem.pl liegen und die von fhem.pl benutzt wird, falls die Konfiguration per Datenbank angefordert wird.

Die notwendigen Anpassungen in der fhem.pl bestehen dann lediglich darin, an den entsprechenden Stellen anstatt der vorhandenen Abläufe die configDB Funktionen zu verwenden. Damit wäre die ganze Lösung abwärtskompatibel und niemand wird gezwungen, eine Datenbank zu verwenden.

Offen ist derzeit auch noch die Frage der Tabellenstrukturen, im Moment verwende ich einfach ein langes Feld und schreibe die bisherige Konfiguration zeilenweise in die Tabelle. Selbst das erlaubt mir schon eine sehr viel einfacher Handhabung der Konfiguration. Und JA, es gibt bereits zwei Tabellen, eine für die Konfiguration und eine für die States.

Das Schöne an sqlite ist, dass es auf nahezu allen Plattformen problemlos verfügbar ist.

Aus Performancegründen könnte man dann 93_DbLog irgendwann dahingehend anpassen, bei aktivierter configDB die gleiche Datenbank zu verwenden und die Logtabellen dort zu schreiben, anstatt zwei Datenbanken zu verwenden.

Das Ganze ist derzeit als proof-of-concept zu verstehen und stellt eine reine Diskussionsgrundlage dar.
Ich freue mich auf regen Ideenaustausch.

[rudolfkoenig]

Falls allgemeine Interesse besteht, dann werde ich Patches fuer fhem.pl/FHEMWEB uebernehmen.
Eine Loesung mit moeglichst wenig if oder unless in fhem.pl wuerde ich bevorzugen.

[betateilchen]

Eine Loesung mit moeglichst wenig if oder unless in fhem.pl wuerde ich bevorzugen.

Ich auch. Aber um künftig beide Konfigurationsvarianten zu ermöglichen, werden wir um eine geringe Anzahl Fallunterscheidungen (an den genannten Stellen) nicht rumkommen.

[svenson08]

Grundsätzliche Frage: Besteht Interesse, diesen Ansatz weiterzuverfolgen und zu einer richtigen Lösung auszubauen?

Vom meiner Seite besteht daran Interesse. Wenn das Ablegen der configs als default angesehen wird und irgendwann die cfgs Dateien komplett wegfallen. Hier fallen einem evlt. noch andere Ansätze ein (Log per Default in DB, Module in die DB und nicht ins Dateisystem, o.ä.).

Offen ist derzeit auch noch die Frage der Tabellenstrukturen

Sollte besprochen werden, aber in meinen Augen von den Main-Developer. Bei dem Thema würde ich mich durch mein FHEM Fehlwissen raushalten. Das von betateilchen vorgestellte Konstrukt wird sicherlich funktionieren, der Einsatz einer Datenbank sollte aber mehr als nur das schreiben der Configs in ein Datenbankfeld sein.

Wie sehen die Nachteile aus, das sollte auch abgesprochen werden. Auf die ein oder andere minimal Konfiguration sollte dazu geschaut werden.

Bleibt die Frage ob man diese "Baustelle" aufmacht. Je nach dem ist das eine gewaltige Aktion.

P.S.: An vielen Stellen wird immer wieder auf wichtigere Baustellen verwiesen, aber ich kann nur raten welche das sein sollten. Es wäre zu überlegen ob man diese "Baustellen" benennt und mal eine Übersicht erstellt.

Gruß svenson

[betateilchen]

und irgendwann die cfgs Dateien komplett wegfallen.

Meine fhem.cfg ist inzwischen komplett leer.

der Einsatz einer Datenbank sollte aber mehr als nur das schreiben der Configs in ein Datenbankfeld sein.

Logisch. Mir ging es in meinem ersten Schritt nur darum, herauszufinden, wie groß der Aufwand für die Einbindung überhaupt ist. Die Strukturen der Tabellen betrachte ich schon als "Feinarbeit".

die config-Tabelle könnte beispielsweise aus vier Feldern bestehen:

Code Auswählen Erweitern


CMD    DEVICE PARAMETER VALUE
define grmpf  abcmodul  DEF-string
attr   grmpf  verbose   3


[rudolfkoenig]

werden wir um eine geringe Anzahl Fallunterscheidungen (an den genannten Stellen) nicht rumkommen.

Es sei denn, man modularisiert diese auch. Bin aber z.Zt. eher fuer die if's

irgendwann die cfgs Dateien komplett wegfallen.

Das sehe ich noch nicht, weil damit eine sqlite/etc Bibliothek Voraussetzung fuer die Installation waere.

[betateilchen]

Es sei denn, man modularisiert diese auch.

dazu müsstes Du aber die fhem.pl tiefgreifend umbauen

Das sehe ich noch nicht

Das sehe ich auch noch in weiter Ferne, wobei ich die Abhängigkeit von einer db-Library nicht unbedingt als das größte Hindernis ansehe.

[betateilchen]

Ich bin jetzt bei insgesamt fünf if-Abfragen in der fhem.pl und (funktional) fertig mit der Implementierung, basierend auf dieser fhem.pl:

Code Auswählen Erweitern

# $Id: fhem.pl 4891 2014-02-12 09:10:01Z rudolfkoenig $

Es funktioniert grundsätzlich alles wie geplant, aber ein paar Feinarbeiten sind noch zu erledigen. Wer hat Lust zum Testen? Ich würde dann im Testbereich des Forums einen entsprechenden Thread eröffnen, um Files und Anleitung bereitzustellen und technische Fragen zu beantworten.

Noch einige grundsätzliche Anmerkungen:

• Die Umsetzung ist für den Anwender absolut transparent, d.h. an den Befehlen ändert sich nichts. "save" und "rereadcfg" funktionieren exakt wie vorher.
• Die Änderung für den Anwender besteht lediglich im Starten von fhem: Anstatt "perl fhem.pl fhem.cfg" wird mit "perl fhem.pl configDB" gestartet.
• Die Migration einer bestehenden Konfiguration ist ebenfalls implementiert.

@Rudi:

Könntest Du mal bitte über den Patch schauen, ob ich etwas grundlegendes falschgemacht habe?

[Tobias]

Hi betateilchen,
ich finde die Idee echt super... !!!
ich bin aber auch dafür als Voraussetzung der ConfigDB das Modul DbLog zu machen. Damit kann man alles in diesem Modul kapseln was irgendwie nach Datenbank riecht.
Nicht alle wollen sqlite. Und DbLog ist nunmal DAS fhem-Datenbankmodul

[betateilchen]

Code Auswählen Erweitern

Und DbLog ist nunmal DAS fhem-Datenbankmodul

Nein, ist es nicht. Es ist einfach "nur" ein Modul, das für einen bestimmten Zweck mit einer Datenbank arbeitet.
Das Problem bei 93_DbLog ist zudem, dass dieses Modul viel zu spät ins Spiel kommt, um für die Konfiguration von fhem in Betracht zu kommen.

Ich würde 93_DbLog niemals als Abhängigkeit ansehen - das wäre völlig kontraproduktiv. Es gibt auch noch ein paar ganz andere, technische, Gründe, die dagegensprechen. Für die Konfiguration brauche ich zum Beispiel weder eine gecachte, noch eine permanent bestehende Datenbankverbindung.

Und meine Konfigurationsdatenbank ist - genau wie das DbLog - nicht auf sqlite begrenzt. Es kann die gleichen Datenbanktypen verwenden wie DbLog auch.

Hier kannst Du nachlesen und testen: http://forum.fhem.de/index.php/topic,20194.0.html

[betateilchen]

für FHEMWEb ist nur eine einzige Änderung vorgesehen, das Abschalten der Edit-Möglichkeit für fhem.cfg.

Code Auswählen Erweitern



Index: 01_FHEMWEB.pm
===================================================================
--- 01_FHEMWEB.pm (revision 4920)
+++ 01_FHEMWEB.pm (working copy)
@@ -1507,7 +1507,7 @@

     $attr{global}{configfile} =~ m,([^/]*)$,;
     my $cfgFileName = $1;
-    FW_displayFileList("config file", $cfgFileName);
+    FW_displayFileList("config file", $cfgFileName) unless $attr{global}{configfile} eq 'configDB';
     FW_displayFileList("Own modules and helper files",
         FW_fileList("$MW_dir/^(.*sh|[0-9][0-9].*Util.*pm|.*cfg|.*holiday".
                                   "|.*layout)\$"));



[betateilchen]

Wieso überschreibt eigentlich eine per update erhaltene Datei "fhem.pl" gleichzeitig auch eine vorhandene Date "fhem.dev.pl" im gleichen Verzeichnis?

[betateilchen]

Hallo Rudi,

hast Du schon darüber nachgedacht, die von mir vorgeschlagene "Schnittstelle" in Deine fhem.pl einzubauen? Ich würde gerne die Weiterentwicklung der fhem.pl mit nutzen, ohne jedesmal meine Fallunterscheidungen lokal nachziehen zu müssen.

Mein Vorschlag: Die perl-Erweiterungen in configDB.pm würde ich vorläufig in ./contrib einchecken, falls jemand testen möchte.
Für alle User, die weiter mit der fhem.cfg (oder einer anderen Konfigdatei) arbeiten, sollten sich keinerlei Auswirkungen ergeben.

Die Konfiguration per Datenbank läuft bei mir seit Donnerstag störungsfrei durch

Es sei denn, man modularisiert diese auch. Bin aber z.Zt. eher fuer die if's

Das mit dem modularisieren habe ich mir im Rahmen der Entwicklung auch überlegt. Ansatzweise ist das ja schon in der fhem.pl vorhanden, z.B. in der sub WriteStatefile()

Wenn man mal überlegt, was eigentlich für die Konfiguration überhaupt gebraucht wird, kommt ja an sich nicht viel raus:

• globalDef
• globalAttrBeforeFork (oder so ähnlich)
• cfg lesen
• states lesen
• cfg schreiben
• states schreiben

globalDef ist in beiden Fällen identisch.

Die anderen fünf Funktionen habe ich für die Konfiguration per Datenbank nachprogrammiert und somit schon komplett gekapselt. Aufgrund der derzeitigen Struktur der fhem.pl kam ich nicht umhin, einige dieser Funktionen in Deine subs() zu intergrieren, z.B. in der WriteStatefile und bei den globalen Attributen.

Speziell bei WriteStatefile war das notwendig, weil die an verschiedenen Stellen in der fhem.cfg aufgerufen wird.

Wenn man diese fünf Funktionen auch für die Verwendung mit einer Konfigurationsdatei kapseln würde, wäre man schon ein ganzes Stück weiter - und m.E. auch übersichtlicher.

Viele Grüße
Udo

[rudolfkoenig]

hast Du schon darüber nachgedacht

Sicher, ich wollte nur abwarten, dass deine Baustelle sich beruhigt. Ich kann auch die erwaehnten Funktionen irgendwie Kapseln, dauert aber vermutlich noch ein paar Tage.

Woran merkst du, dass die Config-Daten aus der DB zu holen sind?
Und hat ausser dir sonst jemand diese Erweiterung schon getestet?

[betateilchen]

Hallo Rudi,

Woran merkst du, dass die Config-Daten aus der DB zu holen sind?

Das hatte ich schon irgendwo beschrieben:  fhem wird nicht mit "perl fhem.pl fhem.cfg" gestartet, sondern mit "perl fhem.pl configDB"

configDB ist quasi das festgelegte Schlüsselwort für die Unterscheidung.

Dieses Schlüsselwort wird beim fhem-Start

Code Auswählen Erweitern


###################################################
# Server initialization
doGlobalDef($ARGV[0]);


von der unangetasteten doGlobalDef als Attributwert in das Attribut "configfile" übernommen, und anhand dieses Attributs arbeiten alle Fallunterscheidungen.

Das mit dem Kapseln Deiner Funktionen ist für mich nicht oberste Priorität, das können wir gerne irgendwann gemeinsam angehen, um uns dabei nicht gegenseitig abzuschießen.

Ob es andere Tester gibt? Ja. Zumindest wurde das Variante aus dem Test-Thread schon mehrmals runtergeladen (die letzte Version zwei Mal) und einer der User hat sich auch per email bei mir gemeldet. Allerdings weiß ich von dem User nur seine email-Adresse und nicht seinen Usernamen (die emails aus dem Forum hier enthalten immer noch keinen Hinweis auf den Absender, siehe auch hier: http://forum.fhem.de/index.php/topic,19327.0.html ) somit kann ich Dir nicht sagen, WEM man den "Tester"-Status zuweisen müsste.