Optimierung 2. stufiges Modulkonzept

Begonnen von M.Schulze, 10 April 2020, 10:59:08

Vorheriges Thema - Nächstes Thema

M.Schulze

Hallo,


beim 2. stufigen Modulkonzept benötigt man ja eine Matchlist.

Die von meinem Modul:

  $hash->{MatchList} =
{ "1:HATP_SCDE" => "^scde\$",
  "2:HATP_SwITCH" => "^switch\$",
  "3:HATP_ADC" => "^adc\$",
  "4:HATP_ClIMA" => "^clima\$",
  "5:HATP_S0" => "^s0\$",
  "6:HATP_LiGHT" => "^light\$"
};

Das hat in diesem Fall die Nachteile das diese Liste ziemlich unnötig aber dennoch gepflegt werden muss (nicht wirklich das Problem).

Wunsch wäre aber das weitere 2. Stufe Module OHNE Erweitern dieser Liste funktionieren.  Also dann auch ohne Abstimmung mit dem Modul-Author 1. Stufe und updaten dieses Moduls.

Was haltet ihr davon für so ein Szenario eine Überholspur einzubauen?

Vorschlag: Eine neue Alternative. Statt einer MatchList kann einfach ein Prefix-Ausdruck angeben werden. Dann auf gut Glück testen ob das Modul vorhanden ist, oder Fehler. In der Dispatch Funktion.
  $hash->{Prefix} = "HATP_" + Message(an Displatch geht nur das Scheme der Message) = zu ladendes Modul 2. Stufe


MfG
Muss ich hier das Licht aus machen?

rudolfkoenig

ZitatAlso dann auch ohne Abstimmung mit dem Modul-Author 1. Stufe und updaten dieses Moduls.
Der Autor des physischen Moduls muss doch die zum virtuellen Modul passende Nachricht generieren, d.h. er muss das Modul sowieso anfassen.
Oder will damit der Firmware-Autor den Autor des physischen Moduls schonen?
Dann muesste das physische Modul erst das Weitergeben beliebiger Nachrichten implementieren.
Alternativ koennte die MatchList des physischen Moduls dynamisch erweitert werden.
=> dieses Problem kann auch mit den verfuegbaren Mitteln geloest werden

M.Schulze

Zitat von: rudolfkoenig am 10 April 2020, 11:27:18
Dann muesste das physische Modul erst das Weitergeben beliebiger Nachrichten implementieren.

Hmm, ja ich denke das ist so.
Request vom Gerät (im vereinbarten Protokoll) -> physische Modul bereitet Daten auf -> Dispatch mit identifizierter Scheme (aufbereitete Daten verbleiben aber im physische Modul hash, der ja an 2. Stufe geht -> 2. Stufe tut ihren Job und bereitet Response vor ->physische Modul finalisiert Response und sendet.
Muss ich hier das Licht aus machen?

RichardCZ

#3
Zitat von: M.Schulze am 10 April 2020, 10:59:08
Die von meinem Modul:

  $hash->{MatchList} =
{ "1:HATP_SCDE" => "^scde\$",
  "2:HATP_SwITCH" => "^switch\$",
  "3:HATP_ADC" => "^adc\$",
  "4:HATP_ClIMA' => "^clima\$",
  "5:HATP_S0" => "^s0\$",
  "6:HATP_LiGHT" => "^light\$"
};

Das hat in diesem Fall die Nachteile das diese Liste ziemlich unnötig aber dennoch gepflegt werden muss (nicht wirklich das Problem).

Das hat insbesondere den Nachteil, dass man hier eine falsche Datenstruktur verwendet. Man redet zwar von MatchListe (= geordnet),  verwendet dann aber schlussendlich ein Hash (= ungeordnet). Also klatscht man vor die Keys einen numerischen Präfix um das wieder geordnet zu bekommen.

Das ist so, als würde jemand mit der Kneifzange Laub kehren wollen.
Also wenn schon Update, dann weniger Müll und schneller und richtiger wäre natürlich

$hash->{MatchList} = [
    'HATP_SCDE'   => qr{^scde$},
    'HATP_SwITCH' => qr{^switch$},
    'HATP_ADC'    => qr{^adc$},
    'HATP_ClIMA'  => qr{^clima$},
    'HATP_S0'     => qr{^s0$},
    'HATP_LiGHT'  => qr{^light$},
];


Dann hätte man erstmal einen Rechen statt einer Kneifzange. Man könnte sogar die alte Show lassen, da man ja locker MatchList zwischen ref ARRAY und HASH diskriminieren könnte.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

M.Schulze

So dachte ich mir das ...

Ich werde das mal testen.


    # last try, load module by adding prefix
    my $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"});
    }

Muss ich hier das Licht aus machen?