glob/Wildcards in CommandInclude

[jw2013]

Für modulare Setups wäre es hilfreich, wenn der include Befehl Wildcards unterstützen würde, z.B. sollte

Code Auswählen Erweitern

include /etc/fhem/*.cfg
alle Dateien mit .cfg am Ende aus dem Verzeichnis /etc/fhem/ einbinden, in alphabetischer Reihenfolge.
Das ließe sich mit minimalen Änderungen an CommandInclude umsetzen:

Code Auswählen Erweitern

sub
CommandInclude($$)
{
  my ($cl, $arg) = @_;
  my $fh;
  my @ret;
  my $oldcfgfile;
  my @files = ();

  my $type = ($unicodeEncoding ? "< :encoding(UTF-8)" : "<");
  if(!open($fh, $type, $arg)) {
    @files = sort grep $_ ne $arg, glob($arg); # e.g. /etc/fhem/*.cfg
    return "Can't open $arg: $!" unless @files;
  }
 
  Log 1, "Including $arg";
  my @t = localtime(gettimeofday());
  my $gcfg = ResolveDateWildcards(AttrVal("global", "configfile", ""), @t);
  my $stf  = ResolveDateWildcards(AttrVal("global", "statefile",  ""), @t);
  if(!$init_done && $arg ne $stf && $arg ne $gcfg) {
    my $nr =  $devcount++;
    $comments{$nr}{TEXT} = "include $arg";
    $comments{$nr}{CFGFN} = $currcfgfile if($currcfgfile ne $gcfg);
  }
  $oldcfgfile = $currcfgfile;
  do {
    if ( @files ) {
      $arg = shift @files;
      next if ($rcvdquit) or ($arg eq $gcfg) or ($arg eq $stf); # ignore globs matching configfile or statefile
      if(!open($fh, $type, $arg)) {
        push @ret, "Can't open $arg: $!";
        next;
      }
      Log 1, "Including $arg";
    }
    $currcfgfile = $arg;

    my $bigcmd = "";
    my $lineno = 0;
    $rcvdquit = 0;
    while(my $l = <$fh>) {
      $lineno++;
      $l =~ s/[\r\n]//g;

      if($l =~ m/^(.*)\\ *$/) {       # Multiline commands
        $bigcmd .= "$1\n";

      } else {
        my $tret = AnalyzeCommandChain($cl, $bigcmd . $l);
        if(defined($tret)) {
          Log 5, "$arg line $lineno returned >$tret<";
          push @ret, $tret;
        }
        $bigcmd = "";
      }
      last if($rcvdquit);

    }
    close($fh);
  } while @files;
  $currcfgfile = $oldcfgfile;
  return join("\n", @ret) if(@ret);
  return undef;
}

Wenn die angegebene include Datei geöffnet werden kann, verhält sich das Kommando 1:1 wie zuvor.
Ansonsten wird getestet, ob die glob-Funktion (in Perl enthalten) für das Argument Datei-Namen zurückliefert, welche nicht mit dem Argument übereinstimmen.

Die Einbindung der gefundenen Dateien erfolgt so, dass FHEM keine neuen include Statements für diese anlegt (daher hab ich auch auf rekursive Aufrufe verzichtet).

[betateilchen]

Sowas kann zu völlig unvorhergesehenen Effekten führen, wenn sich bei Anwendern in einem Verzeichnis bereits Dateien angesammelt haben, an die der Anwender nicht mehr denkt und er "der Einfachheit halber" ein Wildcard einsetzt.

Außerdem würden wir damit vom in FHEM weitverbreiteten Prinzip abweichen, dass wir bei der Verwendung von Wildcards auf regex setzen und nicht auf die alte DOS Nomenklatur.

Als Hilfeleister halte ich das hier im Forum für nicht mehr handlebar.

Deshalb: dagegen!

[jw2013]

Sowas kann zu völlig unvorhergesehenen Effekten führen, wenn sich bei Anwendern in einem Verzeichnis bereits Dateien angesammelt haben, an die der Anwender nicht mehr denkt und er "der Einfachheit halber" ein Wildcard einsetzt.

Oh je, soweit habe ich gar nicht gedacht, das passiert ja ständig.

https://httpd.apache.org/docs/2.4/mod/core.html#include
https://nginx.org/en/docs/ngx_core_module.html#include
https://man.openbsd.org/sshd_config#Include
https://man.openbsd.org/ssh_config#Include

Nur gut, dass keines dieser Projekte weit verbreitet ist, die wären sonst schon in Support-Anfragen untergegangen.

</sarcasm>
 

Außerdem würden wir damit vom in FHEM weitverbreiteten Prinzip abweichen, dass wir bei der Verwendung von Wildcards auf regex setzen und nicht auf die alte DOS Nomenklatur.

Ich bin selbst ein Freund von regulären Ausdrücken, aber bitte nur dort, wo sie wirklich notwendig sind. Denn leider bringen die auch Probleme mit, wie z.B. ReDoS.
Bei include-Statements in Konfigurationen ist die glob-Syntax üblich, sicherlich nicht ohne Grund...

[betateilchen]

Deine OpenWRT Phantasien in allen Ehren, aber bitte übertreibe es nicht mit Deinen Wünschen/Forderungen zu einem kompletten Umbau von FHEM. Du wirst mit OpenWRT am Ende wahrscheinlich ein Randgebiet abdecken. Ähnlich war es 2014, als ich mich mit der Integration von configDB befasst habe. Genau aus dem Grund hatte ich damals allergrößten Wert darauf gelegt, die Implementierung weitestgehend transparent umzusetzen, damit sowohl andere Entwickler wie auch die Anwender sich möglichst keine Gedanken darüber machen brauchen.

Wenn ich irgendwas zu FHEM suchen muss, dann suche ich das unter /opt/fhem und nicht über das gesamte Dateisystem verteilt. Der Großteil der Anwender kommt mit dem derzeitigen Umfeld gut klar. Die Supporter hier im Forum übrigens eingeschlossen.

Und Deinen Sarkasmus kannst Du Dir gerne auf einen Zettel schreiben und an die Wand hängen. FHEM mit Apache oder den anderen von Dir genannten Projekten vergleichen zu wollen, ist für mich schon ziemlich schräg.

[jw2013]

Abgesehen davon, dass meine Wand schon voll hängt, gehe ich gerne ohne weiteren Sarkasmus auf Deine Punkte ein

Ich mag den Begriff "OpenWrt Phantasien" nicht sonderlich, denn er suggeriert unrealistische Ziele.

Wie Du vielleicht auch bemerkt hast, komme ich nicht mit "Wünschen und Forderungen" zu Euch, in der Hoffnung, jemand möge das in seiner Freizeit für mich implementieren, sondern ich setze mich selbst daran, entwickle und teste. Und wenn ich denke, das macht für alle Sinn, dann melde ich mich. Natürlich in der Hoffnung, Dich und weitere Mitstreiter dafür zu gewinnen.

Und ich denke, dass FHEM auf OpenWrt mehr als eine Randerscheinung werden wird.

Es gibt für mich 2 Arten der Hausautomatisierung: 1. die zum Angeben, und 2. die, die unsichtbar im Hintergrund werkelt.

Die erste Sparte wird meines Erachtens zur Genüge von HomeAssistant abgedeckt. Neuerdings läuft das schon nicht mal mehr auf einem Raspberry 3, schaut dafür aber ganz toll aus. Wurde dennoch (oder gerade deswegen) wieder zum beliebtesten OpenSource Projekt gewählt.

Die zweite Sparte sind die Systeme, die im Hintergrund Aufgaben erledigen, für die man etwas mehr Flexibilität benötigt, als ein typischer Mikrocontroller bietet. Sei es das Einsammeln von Daten von Messstellen, die Verknüpfung von PV, Heizung und Wallboxen, generell die Verknüpfung von an sich inkompatiblen Systemen unterschiedlicher Hersteller. Hier könnte FHEM richtig dominieren.

So wenig, wie ich in FHEM nur einen kleinen HomeAssistant sehe, betrachte ich OpenWrt nur als WLAN Router. Vielmehr ist es das Betriebsystem mit der vielleicht umfangreichsten Liste an unterstützter Hardware, das zufällig für FHEM (und andere IoT Sachen) genau das mitbringt, was zur einfachen Einrichtung fehlt: Eine komfortable Oberfläche für Netzwerkeinstellungen, Firewall und VPN.

Wo ich Dir uneingeschränkt Recht gebe: Die Implementierung ist immer transparent umzusetzen, und in möglichst viele, unabhängige Häppchen aufzuteilen. Die Änderung oben besteht auch nur aus wenigen Zeilen, es schaut nur in einem Diff nach mehr aus, weil ich einen großen Block in eine Schleife genommen hab.

[betateilchen]

Die zweite Sparte sind die Systeme, die im Hintergrund Aufgaben erledigen, für die man etwas mehr Flexibilität benötigt, als ein typischer Mikrocontroller bietet.

Auch ich bevorzuge die "zweite Sparte" mit dem Schwerpunkt, dass man von der Automation möglichst wenig "sieht". Deshalb gibt es hier auch keine Displays an der Wand, mit denen man irgendwas an/in FHEM steuern/regeln/abfragen könnte - es ist schlichtweg hier nicht nötig.

So wenig, ... betrachte ich OpenWrt nur als WLAN Router. Vielmehr ist es das Betriebsystem mit der vielleicht umfangreichsten Liste an unterstützter Hardware, das zufällig für FHEM (und andere IoT Sachen) genau das mitbringt, was zur einfachen Einrichtung fehlt: Eine komfortable Oberfläche für Netzwerkeinstellungen, Firewall und VPN.

Nach gut einem Dutzend Jahren Nutzung von FHEM muss ich sagen, dass ich noch nie ein echtes Problem in FHEM hatte, das auf eine nicht genug einfache Netzwerkkonfigurationen hier vor Ort zurückzuführen gewesen wäre. Und wer mir einreden möchte, dass die Konfiguration von OpenWRT über die Oberfläche intuitiv oder gar "komfortabel" sei, muss sich darauf einstellen, von mir tatsächlich ausgelacht zu werden. Bevor ich in der Oberfläche irgendwas konfiguriere, bearbeite ich die Konfigurationsdateien direkt und bin in 1/3 der Zeit fertig. Und dabei ist es mir völlig egal, ob das Betriebssystem debian oder openwrt heißt.

Insofern sehe ich persönlich keinerlei Vorteile darin, FHEM auf OpenWRT laufen zu lassen.

dann melde ich mich. Natürlich in der Hoffnung, Dich und weitere Mitstreiter dafür zu gewinnen.

Was mich angeht: das wird schwer...

OpenWRT auf WLAN Routern zur Steuerung eines gesamten Netzwerkes ist mir tatsächlich nicht neu. Das Szenario habe ich aber schon vor ca. 15 Jahren aufgegeben. Damals hatte ich das noch auf einem Linksys WRT54GS. Vor einiger Zeit hatte ich das nur deshalb wieder auf eine VM gebracht, weil es tatsächliche die simpelste Variante war, einen "Dumb Access Point" ohne jegliche weitere Funktionalität in Betrieb zu nehmen.