Physische Module / logische Module / Zuordnung flexibler

[herrmannj]

Hallo Rudi,

von hier: https://forum.fhem.de/index.php/topic,125887.0.html

bei zweistufigen Modulen ist mAn aktuell die Relation physisches Modul zu logischen Modulen hardkodiert.

Anders gesprochen: ein physisches Modul spricht nur mit logischen Modulen welche in $hash->{Clients} bekannt sind. Falls weiter logische Module angesprochen werden sollen, muss das physische Modul vom Autor modifiziert werden.

Wunsch: (neue) logische Module sollen sagen dürfen welche physischen Module sie verstehen (CUL, MQTT, etc) und das physische Modul sendet diesen dann ebenfalls die Nachrichten. (dispatch)

Falls das schon geht, bin ich für einen Hinweis dankbar. Andernfalls: würdest Du einen patch akzeptieren oder möchtest Du da selber aktiv werden (weil zentral)?

Danke, vg
joerg

[rudolfkoenig]

Wunsch: (neue) logische Module sollen sagen dürfen welche physischen Module sie verstehen (CUL, MQTT, etc) und das physische Modul sendet diesen dann ebenfalls die Nachrichten. (dispatch)

Das geht jetzt schon, wenn das logische Modul das bereits geladene physische Modul selbst "patcht".
Ich kann eine Funktion dafuer bereitstellen, wenn das gewuenscht ist.
Der Haken: solche logische Module koennen nicht per autocreate angelegt werden.

[herrmannj]

exakt, mit dem patchen arbeite ich schon, fühlt sich ein wenig nach hack an. Wenn Du, bei Gelegenheit, eine Funktion bereitstellen könntest, wäre das schön. Bonuspunkt: wenn das Modul sich auch wieder austragen kann. Speziell, das gebe ich zu, aber ich hätte Bedarf. Danke.

Autocreate bleibt solange auf der Strecke bis dass die erste logische Instanz definiert ist. Für Module, die diesen Weg wählen, ist das sicher akzeptabel.

[herrmannj]

keine weiteren Aktionen notwendig hier, Danke für die Bereitschaft. Für MQTT2_(SERVER|CLIENT) habe ich passenden code und plane ihn zur Verfügung zu stellen

[M.Schulze]

bei zweistufigen Modulen ist aktuell die Relation physisches Modul zu logischen Modulen hardkodiert.

Anders gesprochen: ein physisches Modul spricht nur mit logischen Modulen welche in $hash->{Clients} bekannt sind. Falls weiter logische Module angesprochen werden sollen, muss das physische Modul vom Autor modifiziert werden.

Hallo, das ist nur teilweise richtig, da $hash->{Clients} ja wildcard characters enthalten kann.

Dennoch wäre es wünschenswert das die Relation physisches Modul zu logischen Modulen NICHT hardkodiert ist. Also als Option.


Das nächste Problem ergibt sich beim Autoload über die Matchlist.

Ich würde eine neue Option einführen: Laden der Module über ->{MatchList} , wie bisher, dann NEU 2. Versuch wenn NICHT gefunden (auch weil keine Match liste da) laden der Module über ->{Prefix}

Im physisches Modul (Beispiel Dateiname z.B.: Meinprotokoll_HATP.pm)
  $hash->{Clients} =      "HATP_.*";
  $hash->{Prefix} =      "HATP_";
  keine MatchListe

Im logischen Modul (Beispiel Dateiname z.B.: HATP_myscheme.pm)
  $hash->{Match} =   "^myscheme\$";        # matcht dann später $dmsg

Ergänzung in FHEM hinter dem 1. Ladeversuch über MatchListe:

Code Auswählen Erweitern


    # option 2, load module by Prefix
    $h = $hash->{Prefix};
    $h = $module->{Prefix} if(!$h);
    if(defined($h)) {
      my $mname = $h.$dmsg;

      if(AttrVal("global", "autoload_undefined_devices", 1)) {
        my $newm = LoadModule($mname);
        $mname = $newm if($newm ne "UNDEFINED");
        if($modules{$mname} && $modules{$mname}{ParseFn}) {
          no strict "refs"; $readingsUpdateDelayTrigger = 1;
          @found = &{$modules{$mname}{ParseFn}}($hash,$dmsg);
          use strict "refs"; $readingsUpdateDelayTrigger = 0;
          $parserMod = $mname;
        } else {
          Log 0, "ERROR: Cannot autoload $mname";
        }

      } else {
        Log3 $name, 3, "$name: Unknown $mname device detected, " .
                    "define one to get detailed information.";
        return undef;

      }
#?      delete($hash->{".clientArray"});
    }

    # no module found




So können beliebig viele neu logische Module ergänzt werden, ohne das das Physische Modul angepasst werden muss.

Anmerkung: Wobei in $dmsg nur der "Message Scheme" übergeben wird. Das logische Modul bekommt ja den Hash vom Physischen Modul, mit den geparsten Daten der Message.

MfG

[rudolfkoenig]

Anmerkung: Wobei in $dmsg nur der "Message Scheme" übergeben wird. Das logische Modul bekommt ja den Hash vom Physischen Modul, mit den geparsten Daten der Message.

Ich sehe grundsaetzliche Probleme:
- das physische Modul muss wissen, dass das richtige logische Modul noch nicht geladen ist, damit es statt den eigentlichen Daten das "Message Scheme" uebergibt.
- weiterhin muss es aus der Nachricht das richtige Scheme ableiten. Wieso das nicht direkt in die MatchList eintragen?
Wenn ich den Vorschlag nicht verstanden habe (was ich z.Zt. annehme), dann bitte den Ablauf mit einem konkreten Message demonstrieren.

Fuer diese Aufgabe preferiere ich z.Zt. den manuellen Weg, wie das in MQTT2_SERVER und MQTT2_CLIENT mit dem clientOrder Attribut praktiziert wird. Das erlaubt nicht nur die Reihenfolge der Abnehmer zu steuern, sondern auch beliebige logische Module hinzuzufuegen, oder Standard-Abnehmer gegen Alternativen auszutauschen. Weiterhin ist das Instanz- und nicht Modulspezifisch. Vorsicht ist beim Setzen des Attributes bei Modulen wie CUL oder SIGNALduino geboten, das koennte nicht jeder Benutzer auf Anhieb.

Falls gewuenscht, kann ich fhem.pl / CommandAttr() soweit erweitern, dass dieser Mechanismus jedem Modul zur Verfuegung steht, wo clientOrder in der AttrList eingetragen ist.