fhem Konfiguration aus SQL Datenbank [allgemeines]

[AHA1805]

Hallo betateilchen,

schon beeindruckend was Du hier gemacht hast.

ich überlege gerade worin der Vorteil liegt wenn die Konfiguration in einer Datenbank liegt.

Ich will hiermit nicht deine Arbeit schmälern oder gar kritisieren, sondern nur den Beweggrund verstehen.

-Ist dadurch die Performance besser?
-Verhindert man dadurch ungewolltes editieren der fhem.cfg?
-Hat man sonstige Vorteile bei der Auswertung? 
-Hat man damit noch die Möglichkeit zwei Konfigurationsstände einfach miteinander zu vergleichen?


Im Moment verwende ich einen Cronejob, welcher mir die fhem.cfg bei Veränderung automatisch versioniert.
Dadurch hatte ich schon öfters selbst eingebaute Fehler über einfachen Dateivergleicher gefunden oder auch einfach nachgeschaut wie ich das mal gemacht hatte.

Gruß Hannes


Gesendet von Unterwegs mit Tapatalk 4

[betateilchen]

Hast Du schon die commandref gelesen?

Es hat den Vorteil, dass niemand mehr in die "Versuchung" kommt, seine Konfiguration manuell zu ändern.
Es hat den Vorteil, dass das Rumgehampel mit dem Verteilen auf mehrere Konfigurationsdateien und den includes aufhört.
Es hat den Vorteil, dass die Konfigurationen in der Datenbank versioniert werden. Das heißt, ich kann mir auch die vorletzte Konfiguration einfach wieder zurückholen und produktiv setzen, falls ich mich "beim Basteln" wirklich mal soweit verrannt habe, dass nichts mehr geht.

Komplette Konfigurationsstände direkt vergleichen kannst Du nicht mit fhem Bordmitteln. Aber per SQL Daten zu vergleichen, ist ja jederzeit ausserhalb von fhem möglich, auch das Suchen nach bestimmten Begriffen. Ich hatte z.B. gestern Logmeldungen wegen "uninitialized values in split" (natürlich ohne Angabe, in welchem Device oder File das passiert) und habe mir einfach in der SQL-Datenbank alle Zeilen rausgesucht, in denen überhaupt ein split vorkommt. Damit hatte ich einen sehr guten Ansatzpunkt, dem Problem auf die Schliche zu kommen.

Was aber mit fhem Bordmitteln geht: Du kannst mit cfgDB_List() in alten Versionen in der Datenbank nach devices suchen (einzeln oder mehrere gleichzeitig) und bekommst dann angezeigt, wie ein Gerät "früher" definiert und attributiert war. Das ist also genau das, was Du mit der Versionierung Deiner fhem.cfg auch machst.

Vielleicht erweitere ich die List-Funktion noch um eine Gegenüberstellung der gefunden Altdaten eines Gerätes mit den aktuellen Konfigurationsdaten - das ist eine gute Idee, danke.

Reine Performancevorteile (Geschwindigkeit bei der Ausführung eines "save" oder "rereadcfg") hat das Ganze eigentlich keine.

[Hans Franz]

Mehrzeiligkeit in "defs" perdu? Kein "LF" aber Backslashes.

[betateilchen]

Mehrzeiligkeit bei DEFs kann eigentlich fast nur in notify und at vorkommen. Und da gehört für mich überhaupt keine Mehrzeiligkeit hin, alles was dort im Ausführungsteil mehr als eine Zeile benötigt, sollte in eine Funktion gekapselt und in die 99_myUtils.pm ausgelagert werden. Und die 99_myUtils.pm wiederum kannst Du mit dem neuen enhancedEditor im fhem-Frontend sogar mit Syntaxhighlighting, Auto-Complete und automatischer Klammersetzungskontrolle hervorragend bearbeiten.

[Hans Franz]

Alle Notifys, die mehrzeilig sind, müssen nun von allen Usern umgeschrieben werden?

[ph1959de]

Eine Frage stellt sich mir noch im Bezug auf "Konfiguration aus DB": wie bekomme ich alle Definitionen zu (z.B.) einem Device in einer Art gelistet, wie ich sie dann als Beispiel (z.B. Wiki, Forum, ...) beschreiben kann (also ein define mit allen attr ...)? Also das übliche "zeige mal die komplette Definition für ...". Geht sowas (derzeit schon) oder müssen dazu alle "Zeilen" einzeln zusammengesucht werden?

Gruß, Peter

[betateilchen]

mal eben die VM anwerfen, moment

[Rince]

Mir fiele schon noch ein (potentieller) Vorteil ein:

Eventuell könnte man auf diese Art und Weise fhem eine sichere Multiuserversion beibringen.
Eben auf Datenbankebene.


Und, noch etwas anderes,
vielleicht könnte man die 99myUtils auch überführen in eine Datenbank, und dann die einzelnen Routinen als einzelne Unterprogramme isoliert darstellen lassen.
Vielleicht werden sie ja so mal besser austauschbar. Ich denke an eine große 99myUtils Datenbank, die mit den Routinen der User gefüttert wird, wenn diese es wollen.

[betateilchen]

wie bekomme ich alle Definitionen zu (z.B.) einem Device in einer Art gelistet

Also zum einen kannst Du ja weiterhin den ganz normalen Standardbefehl "list" verwenden, denn der wird ja aus dem fhem-Speicher gelesen und nicht aus irgendeiner Konfigurationsdatei:

Beispiel:

Code Auswählen Erweitern

list configDBdummy

liefert:

Code Auswählen Erweitern



Internals:
   CFGFN     
   NAME       configDBdummy
   NR         19
   STATE      ???
   TYPE       dummy
   Readings:
     2014-03-06 11:09:45   reading1        25
Attributes:
   group      dummyGruppe
   room       configGruppe




Darüberhinaus hast Du nun die Möglichkeit, die in der Konfiguration gespeicherten Einträge zu lesen, und das sogar aus verschiedenen gespeicherten Versionen. Standardmäßig wird immer die aktuelle Version (0) gelesen:

Code Auswählen Erweitern

{cfgDB_List 'configDBdummy'}

liefert als Ergebnis:

Code Auswählen Erweitern



search result for device: configDBdummy in version: 0
--------------------------------------------------------------------------------
define configDBdummy dummy
attr configDBdummy group dummyGruppe
attr configDBdummy room configGruppe



Hier kommen also exakt die Zeilen, wie man sie eingeben müsste, und nicht die einzelnen internen Werte wie beim "list"
Dafür kommen aber bei dieser Ausgabe  keine Readings mit, weil die nichts mit der Konfiguration selbst zu tun haben und auch nicht in der Konfigurationsdatenbank stehen.

[betateilchen]

vielleicht könnte man die 99myUtils auch überführen in eine Datenbank, und dann die einzelnen Routinen als einzelne Unterprogramme isoliert darstellen lassen.

das hat dir doch die NSA verraten, oder?

Wobei ja das Syntaxhighlighting in der 99_myUtils inzwischen schon sehr viel weiterhilft, was die Darstellung angeht.

Man kann sogar (fast) die gesamte fhem.pl in eine Datenbank legen, (das hab ich hier auch schon fertig) aber dann erschlägt mich wahrscheinlich seine Majestät. *duck-und-weg*

[betateilchen]

-Hat man damit noch die Möglichkeit zwei Konfigurationsstände einfach miteinander zu vergleichen?

Du meinst, sowas?

(http://up.picr.de/17564372cw.jpg)

Jetzt ja mittels

Code Auswählen Erweitern

{cfgDB_Diff 'global',3}

[Rince]

Code Auswählen Erweitern

das hat dir doch die NSA verraten, oder?

fhem User erfindet das Rad neu. Ingenieure sind verblüfft

Ich meine das durchaus ernst.
attr blblablub share 1
Und schon wird bei einem Update oder so der Code in eine große Datenbank hochgeladen.
Vielleicht noch 2 oder 3 Attribute zur Verschlagwortung der Geschichte.

Am besten dann noch ne Funktion, um aus der großen Datenbank Codeschnippsel zu integrieren.

Wieso das ganze?
Weil nicht jeder das Rad neu erfinden muss. Das ist schon da und funktioniert soweit gut. Der eine nimmt ein Rad, der nächste zwei Räder, auch Konstrukte mit 3 oder 4 Rädern sind gebräuchlich.

Bei fhem ist es nicht unähnlich. Betrachte Module als Räder. Die sind da, getestet und funktionsfähig.

Wie du jetzt aber die Achse und die Lenkung konstruierst, ist deine Sache. Damit stehst du alleine auf weiter Flur.

Eigentlich schade. Vermutlich hat jemand genau deine Idee schon mal umgesetzt. Aber davon provitierst du nur dann, wenn du einen entsprechenden sinnvollen Forumsbeitrag schreibst und, hier wirds spannend, derjenige mit deiner Wunschachse auch tatsächlich deinen Beitrag entdeckt.

Deshalb fände ich eine Art Repository für fhem Lösungen eine gute Idee. Sobald es aber viel Manpower braucht, wird es tricky. Deshalb sollte dies automatisiert werden.

Ein attr, welches man extra freigeben muss, um das Codeschnippselchen frei zu geben, erschiene mir eine nicht dumme Idee zu sein.

[betateilchen]

Mit "NSA verraten" meinte ich, dass ich meine 99_myUtils inzwischen bereits komplett in der Datenbank liegen habe - nicht erst seit Deinem Vorschlag, den ich durchaus ernstnehme.

Aber das wird in fhem nicht generell umsetzbar sein. Schau Dir einfach mal die bestehenden Module an und zähle mal durch, alleine wieviele Funktionen es darin bereits gibt, um aus einem Timestamp etwas für den Menschen sinnvoll lesbares zu machen.

Und wer Funktionen in die 99_myUtils auslagert, muss die zumindest auch so dokumentieren, dass daraus bereits für jeden Interessenten klar wird, wozu die Funktion gut ist. Und dieser Grundsatz ist bis heute noch nicht einmal in der "offiziellen" 99_Utils.pm umgesetzt.

Ausserdem werden hier im Entwicklungsbereich einfach zu oft zu viele Pfründe vehement verteidigt, die es eigentlich längst nicht mehr wert sind.

[justme1968]

jetzt mal ganz abgesehen ob und wie das technisch geht sehr ich zwei probleme: zum einen bestehen solche 'lösungen' meist aus mehr als einem device sondern selber wieder aus komponenten dir zusammenspielen. d.h. man bräuchte hier noch irgend eine art schema um das zu kennzeichnen und zum anderen gibt es keys, accounts, passwôrter & co die auf keinen fall aus versehen gegeilt werden sollten.

[betateilchen]

Genau. Deshalb macht es - obwohl prinzipiell ein nachvollziehbarer Vorschlag - nicht sehr viel Sinn, dafür sonderlich viel Zeit aufzuwenden.

Ich wäre ja schonmal froh, wenn man endlich diese vermaledeiten Konfigdateien generell loswerden könnte.

aus versehen gegeilt 

Da hat Dir jetzt aber Deine Rechtschreibprüfung in die Suppe gespuckt