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

[rudolfkoenig]

Das ist schon mal begrenzter in der Wirkung, also gut

Kannst Du statt . und X was laengeres (.configDB o.ae.) als Suffix/Markierung waehlen, damit man die Links auch nach einem Jahr zuordnen kann?

[betateilchen]

Klar, kann ich machen, bin halt nur kein großer Freund von langen Strings in Quelltexten.

Ich baue heute abend nochmal patches, dann auch schon für/mit 98_SVG.pm

[betateilchen]

Ich baue heute abend nochmal patches, dann auch schon für/mit 98_SVG.pm

wie versprochen: geändert, getestet, gedifft

Falls Du Dich mit dem Vertauschen der Listenblöcke styles und gplot anfreunden kannst, diese Änderung ist mir versehentlich auch mit reingerutscht.

[rudolfkoenig]

Habs an wenigen Stellen leicht umformatiert, getestet und eingecheckt.

[betateilchen]

Danke schön

[betateilchen]

Ich bin grade noch auf ein Problem gestoßen - die Neuanlage über den Link "Create SVG plot" in der Detailansicht eine Logfiles funktioniert noch nicht richtig, das template File wird offenbar nicht gelesen. Grundsätzlich funktioniert das Anlegen des Plots trotzdem, die angezeigte Fehlermeldung ist eben nur erstmal verwirrend.

Muss ich mir genauer anschauen.

[betateilchen]

Gelöst - "set <name> copyGplotFile" hatte ich überhaupt nicht auf dem Schirm.

So klappts auch mit dem Create-Link:

Code Auswählen Erweitern


Index: 98_SVG.pm
===================================================================
--- 98_SVG.pm (revision 5603)
+++ 98_SVG.pm (working copy)
@@ -99,13 +99,16 @@
                  $hash->{GPLOTFILE} . ":".
                  $hash->{LOGFILE};

-  open(SFH, $srcName) || return "Can't open $srcName: $!";
-  open(DFH, ">$dstName") || return "Can't open $dstName: $!";
-  while(my $l = <SFH>) {
-    print DFH $l;
+  if(configDBUsed()) { # copy template.gplot inside configDB
+    _cfgDB_Writefile($dstName,_cfgDB_Readfile($srcName));
+  } else {
+    open(SFH, $srcName) || return "Can't open $srcName: $!";
+    open(DFH, ">$dstName") || return "Can't open $dstName: $!";
+    while(my $l = <SFH>) {
+      print DFH $l;
+    }
+    close(SFH); close(DFH);
   }
-  close(SFH); close(DFH);
-
   return undef;
}


[rudolfkoenig]

Eingecheckt.

Ich finde es wird Zeit fuer ein readCfgFile/writeCfgFile in fhem.pl
Es aergert mich nur, dass ich nicht vorher auf die Idee gekommen bin.

[betateilchen]

Eingecheckt.

Danke.

Ich finde es wird Zeit fuer ein readCfgFile/writeCfgFile in fhem.pl

Es aergert mich nur, dass ich nicht vorher auf die Idee gekommen bin.

Rudi, nicht ärgern, ein lebendes Produkt wie fhem entwickelt sich einfach weiter und dann kommen solche "Leichen" eben irgendwann aus dem Keller wieder ans Tageslicht. Bisher kam ja auch niemand auf die Idee, alles was mit Konfiguration zu tun hat, in eine Datenbank zu schreiben.

Ich hätte das mit den Konfigurationsfiles ja auch gerne anders gelöst, aber aus Kompatibilitätsgründen heißen die Konfigurationsfiles in der Datenbank nun eben auch genau so wie im Dateisystem - inkl. Pfadangabe. Dafür ist es auf diese Weise für die User in der Anwendung aber völlig transparent geblieben.

[betateilchen]

Ich finde es wird Zeit fuer ein readCfgFile/writeCfgFile in fhem.pl
Es aergert mich nur, dass ich nicht vorher auf die Idee gekommen bin.

Das kannst Du doch jederzeit noch nachholen. Die meisten Stellen, an denen sowas gebraucht würde, haben wir doch inzwischen identifiziert und entsprechend vorbereitet
Falls Du das aber angehst, lass uns das bitte abstimmen, damit wir vereinheitlichen können, ob das Lesen einer Konfigurationsdatei einen String (mit \n getrennte Textzeilen) oder ein ein Array (mit den Konfigurationszeilen) zurückliefern soll.



Eine Baustelle habe ich noch, die ich im Zusammenhang mit configDB jetzt noch angehen muss: 98_update.pm
Wenn eine Datei per Update kommt, muss geprüft werden, ob die Datei "configDB-relevant" ist und entsprechend reagiert werden.
Wobei dabei auch noch Fallunterscheidungen zu treffen sind.

Beispiele:

• geänderte 99_myUtils.pm : diese Datei kann, darf, muss aber nicht in der configDB liegen, um zu funktionieren
• neue oder geänderte XYZ.gplot : diese Datei muss in der configDB liegen, um benutzt werden zu können.

Dazu werde ich eine entsprechend Funktion bauen, mit der das update-Modul einfach Dateinamen an configDB übergibt, und configDB wird entsprechend handeln und an update zurückmelden.
Wobei ich noch nicht sicher bin, ob ich das einzeln nach jedem get(file) machen soll oder ob update am Ende eine Namensliste übergibt - das wäre sicher perfomanter.

[betateilchen]

Ich hätte da noch eine klitzekleine Korrektur für die fhem.pl damit CommandVersion auch svnIds aus Moduldateien in der configDB finden kann.

Code Auswählen Erweitern


Index: fhem.pl
===================================================================
--- fhem.pl (Revision 5640)
+++ fhem.pl (Arbeitskopie)
@@ -2435,7 +2435,12 @@
     Log 4, "Looking for SVN Id in module $m";
     my $fn = "$attr{global}{modpath}/FHEM/".$modules{$m}{ORDER}."_$m.pm";
     if(!open(FH, $fn)) {
-      push @ret, "$fn: $!";
+      my $ret = "$fn: $!";
+      if(configDBUsed()){
+        Log 4, "Looking for module $m in configDB to find SVN Id";
+        $ret = cfgDB_Fileversion($fn,$ret);
+      }
+      push @ret, $ret;
     } else {
       push @ret, map { chomp; $_ } grep(/# \$Id:/, <FH>);
     }


[rudolfkoenig]

eingecheckt

[betateilchen]

danke!