Frage zu fhem.pl und Laden von 99_.* Modulen

[betateilchen]

Hallo Rudi,

verstehe ich das richtig, dass der "Lademechanismus" für 99er-Module einzig und allein in der sub GlobalAttr() steckt und genau dann ausgeführt wird, wenn der modpath gesetzt wird?

Ich arbeite gerade an einer Möglichkeit, eigene 99_.*.pm Dateien in die configDB zu importieren und von dort zu laden. Grundsätzlich funktioniert das bei mir jetzt schon völlig problemlos. Ich wundere mich nur darüber, dass es so erstaunlich einfach zu implementieren sein könnte, wie ich das jetzt in der fhem.pl eingebaut habe:

Code Auswählen Erweitern


  elsif($name eq "modpath") {
    return "modpath must point to a directory where the FHEM subdir is"
        if(! -d "$val/FHEM");
    my $modpath = "$val/FHEM";

    opendir(DH, $modpath) || return "Can't read $modpath: $!";
    push @INC, $modpath if(!grep(/\Q$modpath\E/, @INC));
    $attr{global}{version} = $cvsid;
    my $counter = 0;

+    if($attr{global}{configfile} eq 'configDB') {
+      Log 4, "loading 99ers from configDB";
+      $counter += cfgDB_Read99(undef);
+    }



Nach  meinem Veständnis müsste ich allerdings auch noch eine Anpassung in CommandReload machen.

[rudolfkoenig]

verstehe ich das richtig, dass der "Lademechanismus" für 99er-Module einzig und allein in der sub GlobalAttr() steckt und genau dann ausgeführt wird, wenn der modpath gesetzt wird?

Scheint mir auch so. Hab die Stelle seit Jahren nicht angefasst.

Nach  meinem Veständnis müsste ich allerdings auch noch eine Anpassung in CommandReload machen.

Das wird aber erst dann interessant, wenn man die Dateien auch "online" editieren kann.

[betateilchen]

Funktioniert über den Umweg Export -> Editieren -> Import jetzt schon. Aber für einen Automatismus, das in der FHEMWEB einfacher zu machen, fehlt mir momentan noch ein Plan, weil ich erst genau rausfinden muss, wie Du das mit dem "Save" beim "edit files" machst.  Es ist halt - historisch bedingt - einfach nicht gekapselt genug, um sich da einfach reinzuhängen (das ist jetzt überhaupt kein Vorwurf!)

FW_fileList($) dazu zu bringen, in configDB gespeicherte Dateien mit anzuzeigen, ist jedenfalls kein Problem 

[rudolfkoenig]

Das Speichern passiert in der FW_style,  elsif($a[1] eq "save") Abschnitt, anpassen muesste einfach sein.

[betateilchen]

Ja, dazu fehlt mir noch das Gegenstück für die configDB, ausserdem brauch ich noch den Mechanismus, den Inhalt einer gewählten Datei aus der Datenbank zu lesen. (wobei ich die Stelle schon kenne, das ist ungefähr da, wo wir den codemirror ansetzen)

Eins nach dem anderen, ich komme da sicher nochmal mit ganz konkreten Fragen auf Dich zu.

Ich bin ja schon froh, dass ich meine RSS und holiday Dateien jetzt schonmal gesammelt in der Datenbank führen kann. Und dass das initiale Lesen der 99ers so problemlos funktionieren kann

[betateilchen]

Könnte man bei Gelegenheit sowas in die fhem.pl einbauen?

Code Auswählen Erweitern



sub configDBUsed()
{ return ($attr{global}{configfile} eq 'configDB'); }



Das würde die Lesbarkeit mancher Codingstellen erhöhen und im Sourcecode übersichtlicher aussehen.

Code Auswählen Erweitern

if (configDBUsed)

sieht irgendwie "schöner" aus als

Code Auswählen Erweitern

if($attr{global}{configfile} eq 'configDB')

[rudolfkoenig]

Vor allem es kapselt den String configDB.
Habs eingebaut in fhem.pl und in etwa 5 FHEM/*.pm Dateien.

[betateilchen]

wie? was? neue Funktion schon eingebaut? Super, danke


Mal eben aus den Tiefen der FHEMWEB wieder auftauchen, um Luft zu holen...

• FW_fileList = funktioniert
• FW_style list = funktioniert
• automatisches Lesen aus configDB in "Edit files" - funktioniert
• FW_style edit = funktioniert
• FW_style save = funktioniert theoretisch (d.h. ich weiss, wie ich es umsetze, aber ich hab heute keine Lust mehr)
• reload/rereadcfg = muss ich als nächstes drüber nachdenken, nicht nur für FHEMWEB sondern auch für fhem.pl

Alles in allem war es gar nicht so kompliziert wie befürchtet, man muss nur erstmal die Logik durchschauen. Das am meisten Verwirrende ist der Mischmasch aus den ganzen html-Texten die in FHEMWEB "geschrieben" werden und dem Coding dazwischen *lach*

[betateilchen]

• FW_style save = funktioniert (für save und save as)
• Das Reload muss ich in der fhem.pl einbauen, denn die FHEMWEB ruft ja auch nur die Funktion in der fhem.pl auf.

Falls von Interesse, habe ich hier die bei mir durchgeführten Änderungen in der FHEMWEB angehängt.
Das Einzige was noch fehlt (auskommentiert), ist der Aufruf des reload bei Datenbanknutzung. (gestrichen da obsolet)

Verbesserungsvorschläge gerne jederzeit hier.

[betateilchen]

Fertsch

Das Laden der 99_.*.pm-Dateien aus der configDB ist nun komplett in CommandReload enthalten. Wird der übergebene Dateiname nicht gefunden und die configDB ist aktiv, wird versucht, die Datei in der Datenbank zu finden. Im Erfolgsfall wird die Datei ins Dateisystem exportiert, und dem bewährten Evaluierungs- und Ladeprozess von fhem übergeben. Nach der Evaluierung wird die Datei im Dateisystem wieder gelöscht. Das war die einfachste Lösung, um nicht den ganzen Lademechanismus neu schreiben (und testen und bugfixen) zu müssen.

Beim Starten von fhem werden die 99_.*.pm Dateien wie bisher in der Funktion GlobalAttr() erstmalig geladen, indem zusätzlich zur Dateiliste der Module aus dem Dateisystem noch eine Dateiliste der in configDB vorhandenen 99_ Dateien auf identische Art und Weise (Aufruf von CommandReload) verarbeitet wird.

Beim Ändern einer Datei im Frontend, die aus der Datenbank gelesen wird, erfolgt das Speichern auch wieder in die Datenbank. Falls es sich bei der geänderten Datei um eine Moduldatei handelt, wird diese anschließend ebenfalls über "reload" neu geladen - identisch zur bisherigen Vorgehensweise.


Irgendwelche Einwände gegen dieses generische Vorgehen? Im Anhang befinden sich zwei diff files für fhem.pl und 01_FHEMWEB.pm

[betateilchen]

Nach umfangreichen Tests habe ich die Änderungen jetzt auch auf meinem produktiven fhem im Einsatz - bisher absolut problemlos.


Nächste Baustelle: Das gleiche für die gplot Files. Wobei das Lesen in 98_SVG.pm relativ simpel ist (vergleichbare Änderung wie in 95_holiday) aber für den gplot-Editor muss ich wohl wieder tief in die FHEMWEB hinabtauchen 

[betateilchen]

Nächste Baustelle: Das gleiche für die gplot Files. Wobei das Lesen in 98_SVG.pm relativ simpel ist (vergleichbare Änderung wie in 95_holiday) aber für den gplot-Editor muss ich wohl wieder tief in die FHEMWEB hinabtauchen

Erledigt und im Testbetrieb erfolgreich im Einsatz. Das war doch einfacher als ich dachte und die FHEMWEB war erfreulicherweise (fast) nicht involviert

[rudolfkoenig]

Aenderung in fhem.pl koennte ich uebernehmen, die Aenderung in 01_FHEMWEB.pm auch, bis auf das Loeschen eines Punktes in FW_pH. FW_pH ist viel zu generische, ich will da sowas nicht haben. Kannst Du das bitte anders loesen?

[betateilchen]

Hallo Rudi,

danke für Deine Bewertung.  Ich habs geahnt... der Punkt war die Sache, die mir bei der Umsetzung am meisten Kopfzerbrechen gemacht hat.
Ok, ich werde über den Punkt heute abend nochmal intensiv nachdenken, vielleicht fällt mir etwas konformeres ein.

[betateilchen]

Hättest Du etwas dagegen, wenn ich den Punkt in FW_displayFileList entferne und dann so arbeite?

Code Auswählen Erweitern


sub
FW_displayFileList($@)
{
  my ($heading,@files)= @_;
  my $hid = lc($heading);
  $hid =~ s/[^A-Za-z]/_/g;
  FW_pO "<div class=\"fileList $hid\">$heading</div>";
  FW_pO "<table class=\"block fileList\">";
  my $cfgDB = "";
  my $row = 0;
  foreach my $f (@files) {
    $cfgDB = $f =~ s,\.$,,; # remove dot as last character (used to indicate configDB content)
    $cfgDB = ($cfgDB) ? "X" : "-";
    FW_pO "<tr class=\"" . ($row?"odd":"even") . "\">";
    FW_pH "cmd=style edit $f $cfgDB", $f, 1;
    FW_pO "</tr>";
    $row = ($row+1)%2;
  }
  FW_pO "</table>";
  FW_pO "<br>";
}



In FW_style() hätte ich damit in @a ein neues Element, das ich sowohl in "edit" als auch in "save" auswerten kann und die FW_pH() bliebe unangetastet.