Match List und Client List

[Sidey]

Hallo,


Ich habe mal wieder eine Verständnissfrage zu der Match Liste mit Regex Einträgen und der Client Liste in einem physischen Modul.

In der Client Liste stehen die logischen Module, welche in der dispatch Funktion zuerst geprüft werden. Geprüft wird die Match Regex aus dem logischen  Modul und die Fingerprint Funktion.
Anschließen werden auch die Regex Match Einträge aus der Matchlist (physisches Modul) verifiziert.

Bei letztere kann man ja auch eine Reihenfolge erwirken. Bei der Clientlist geht das nicht, oder ich weiss nicht wie.

Ich frage mich, wie man eigentlich Clientliste und Matchliste einsetzten soll.

Hintergrund meiner ganzen Überlegung kommt aus dem Oregon Modul. Da wird aktuell ein Return wert zurück gegeben, auch wenn der Sensor nicht angelegt wurde. Jetzt wollte ich das Problem etwas entschärfen, in dem ich die Reihenfolge ändere. Dabei kamen dann die Fragen auf.

Ö

Grüße Sidey

[rudolfkoenig]

Die Frage ist mir zu ungenau, deswegen beantworte ich es auch so.

Diese Variablen sind nur bei den Zwei-Modul Systemen relevant, die Dispatch() verwenden.
Eigentlich wuerde MatchList reichen, Clients und Match ist nur aus historischen Gruenden notwendig. Anders gesagt, ich scheue mich vor dem Aufwand, es zu vereinfachen, und die Aenderung auch von jedem Modulautor einzufordern.

Wenn ein IODev was liefert, dann wird zunaechst bei den geladenen(!) Modulen, die laut Clients zu diesem IODev passen (sortierReihenfolge anhand Modulnamen-Prefix) mit dem Match Eintrag geprueft, ob sie dafuer zustaendig sind.
Falls nicht (und das kam spaeter, mit autocreate), dann wird anhand dem IODev-MatchList das passende Modul gesucht, geladen, und dann mit den Daten aufgerufen.

[Sidey]

Hi Rudolf,

Die Frage ist mir zu ungenau, deswegen beantworte ich es auch so.

Kein Problem. Ich kann dank deiner Antwort präziser werden.

Diese Variablen sind nur bei den Zwei-Modul Systemen relevant, die Dispatch() verwenden.
Eigentlich wuerde MatchList reichen, Clients und Match ist nur aus historischen Gruenden notwendig. Anders gesagt, ich scheue mich vor dem Aufwand, es zu vereinfachen, und die Aenderung auch von jedem Modulautor einzufordern.

Das ist ja kein Problem. Stellt sich für mich jetzt die Frage, wenn ich ein neues Modul entwickele? Brauche ich die clientliste?

Wenn ein IODev was liefert, dann wird zunaechst bei den geladenen(!) Modulen, die laut Clients zu diesem IODev passen (sortierReihenfolge anhand Modulnamen-Prefix) mit dem Match Eintrag geprueft, ob sie dafuer zustaendig sind.

Was genau ist der Modulnamen Präfix, wird der in der Matchlist definiert?  Und Geprüft wird anhand des Match Eintrages vom Modul? Richtig?

Falls nicht (und das kam spaeter, mit autocreate), dann wird anhand dem IODev-MatchList das passende Modul gesucht, geladen, und dann mit den Daten aufgerufen.

Verstehe. Die Clientliste wird dabei ja nicht erzeugt oder?

Bitte korrigiere mich, ich habe jetzt folgendes Verstanden:

• Die ClientListe muss nicht im IODev-Modul gesetzt werden, aber sie kann. Hat man keine, so wird auch im laufendem Betrieb keine erzeugt.
  
• Die IODev-MatchList lädt ein logisches Modul,bzw. übergibt Daten dort hin, wenn die Regex in der IODev-MatchList passt.
  Hat man das autoload von unbekannten Modulen verboten, wird es natürlich nicht geladen.
  


• Nachdem das Modul geladen wurde, wird parsefn vom Submodul aufgerufen. Die Match Regex vom logischen Modul spielt hier dann keine Rolle.
  
• Einen Duplikats check via FingerprintFn findet bei der Variante mit der IODev-MatchList keine Anwendung. Wieso eigentlich?
  

Grüße Sidey

[rudolfkoenig]

Brauche ich die clientliste?

Ja, alle 3 Variablen sind notwendig.

Was genau ist der Modulnamen Präfix, wird der in der Matchlist definiert?  Und Geprüft wird anhand des Match Eintrages vom Modul? Richtig?

Die Zahl vor dem _ im Modulnamen. Ja. Btw. das ist open Source, und man kann es in den Quellen nachlesen.

Zu deinen Vermutungen:
- Alle Variablen muessen gefuellt sein, auch wenn damit die gleiche Info mehrfach spezifiziert wird.
- Duplikats-Pruefung findet immer statt.

[Sidey]

Hi,

ich hoffe meine Fragerei ist nicht zu lästig. Ich habe den quellcode leider nicht ganz geblickt. Deshalb frage ich halt nach.

Ja, alle 3 Variablen sind notwendig.

Hmm, ich glaube dir gerne. Verstanden habe ich es aber nicht.
Muss ich die clientlist vielleicht nur für Module angeben die auch was senden wollen und für die anderen reicht die Matchlist?
Quellcode habe ich durchgearbeitet, aber scheinbar habe ich den Ablauf nicht so interpretiert wie er ist..
Wenn in der Clientlist nichts steht, dann findet er nichts und sucht anhand der Matchlist.. so zumindest mein Verständnis der Funktion

Code Auswählen Erweitern

dispatch

- Duplikats-Pruefung findet immer statt.

Hmm, vielleicht habe ich Tomaten auf den Augen und Perl ist nicht meine stärke, das gebe ich gerne zu.
In dem Abschnitt in dem die Matchlist durchgearbeitet wird, kommt der ParseFn Aufruf doch ohne fingerprint Aufruf...
Soll der Duplikatscheck vielleicht im Modul selbst gelöst werden?

Code Auswählen Erweitern


            if($modules{$mname} && $modules{$mname}{ParseFn}) {
              no strict "refs"; $readingsUpdateDelayTrigger = 1;
              @found = &{$modules{$mname}{ParseFn}}($hash,$dmsg);
              use strict "refs"; $readingsUpdateDelayTrigger = 0;
            } else {



Grüße Sidey

[justme1968]

schau mal hier: http://forum.fhem.de/index.php/topic,42018.msg342378.html#msg342378

da gibt es noch eine diskussion zum gleichen thema. vielleicht hilft dir das weiter.

gruss
  andre

[Sidey]

Danke,  für mich ist jetzt klar, was geht und was wofür gedacht ist..

[Sidey]

Hallo,

ich habe nun einige Tage über die Funktion MatchList und Clientlist nachgedacht.
Ich weiss, ich habe vor einigen Tagen noch geschrieben, dass ich nichts ändern will, sondern es nur verstehen möchte.


Einen Beitrag im Wiki werde ich noch verfassen, alledings würde ich dennoch erst eine Änderung vorschlagen, bevor ich es im Wiki dokumentiere wie es funktioniert.
Grund der Änderung ist, dass ich es doch komplex finde, wie die Client und auch die Matchlist wirken. Es könnte aus meiner Sicht etwas klarer sein.

Die Funktion ist heute in etwa so:


1. Durchsuche die Clientlist in der nur geladene Module enthalten sind, ob eine Regex passt.
2a. Wurde eine passende Regex gefunden, wird an das zutreffende Modul übergeben.
2b. Wurde nichts passendes gefunden, durchsuche die Matchlist ob eine Regex passt.
3a. Wenn ja, versuche das Modul zu laden und übergib immer an das zutreffende Modul in der Matchlist.


Dabei verwischt aus meiner Sicht etwas der Sinn und Zweck der Clientliste.
Ich würde daher folgenden Ablauf als verständlicher und einfacher empfinden:

1. Durchsuche die Clientlist in der nur geladene Module enthalten sind, ob eine Regex passt.
2a. Wurde eine passende Regex gefunden, wird an das zutreffende Modul übergeben.
2b. Wurde nichts passendes gefunden, durchsuche bisher nicht geladene Module der Matchlist ob eine Regex passt.
3a. Wenn ja, versuche das Modul zu laden und übergib immer an das zutreffende Modul in der Matchlist.

Die Änderung ist relativ gering. Dadurch würde die Matchlist klar zum Zweck des Laden eines Modules begrenzt und nicht mehr so wie heute, auch bei geladenen Modulen ein erfolgreiches Dispatch verursachen, sofern die Regex passt.
Obwohl ich mich intensiv mit dem Thema beschäftigt habe, bin ich nun doch schon mehrfach darüber gestolpert und habe mich immer wieder gewundert, weshalb dies und jenes passier.

Den Patch dazu würde ich erstellen, sofern das auf Zustimmung trifft.

Eines vorweg:
In FHEM 5.7 würde ich das jetzt nicht mehr einbauen, da ich nicht einschätzen kann ob alle Entwickler die Client und die Matchlist so verwendet haben, wie diese verwendet werden sollten. Bisher war es ja möglich sowohl über die Clientlist als auch über die Matchlist ein erfolgreiches Dispatch zu veranlassen.

Grüße Sidey

[rudolfkoenig]

Da im Punkt 1 die bisher geladenen Module geprueft wurden, wuerde die Aenderung nur eine Geschwindigkeitsoptimierung aber keine Funktionale Aenderung bewirken. Da diese Stelle nur beim Anlegen eines neuen Geraetes via autocreate eine Rolle spielt, ist der Fall, wo wir die (geschaetzt) <1ms einsparen, relativ selten.

Auch wenn die Aenderung klein ist, sehe ich den Vorteil im zusaetzlichen Code nicht.
Ich lasse mich aber gerne aufklaeren.

[Sidey]

Hallo Rudolf,

um den Geschwindigkeitsgewinn ging es mir dabei nicht, auch wenn Ressourcen schonendes Programmieren auch ein Motiv wäre.

Eine funktionale Änderung würde es aus meiner Sicht durchaus bringen.
Nach unzähligen Beiträgen habe ich verstanden, dass die MatchList gedacht ist um festzustellen, welches Modul geladen werden muss.
Das es dann noch den Dispatch ausführt, liegt halt an der Reihenfolge, dass erst die Clientlist durchgearbeitet wird.

Ich bin jetzt schon mehrfach darüber gestolpert, dass es eine Abweichung zwischen soll und ist gibt.

Soll: Die Matchlist soll nur für das Nachladen der Module verwendet werden.
Ist: Sie kann auch für eine Verteilung auf bereits geladene Module genutzt werden.


Ein Beispiel aus dem Wahren Leben nur etwas vereinfacht:

Nehmen wir an, wir haben folgenden Wert, der an ein logisches Modul übergeben werden soll:
AAF3B


Im Match des Empfänger Moduls steht folgendes:

Code Auswählen Erweitern

  $hash->{Match}     = "^[A-F0-9]{2}F[A-F0-9]{2}"; 

In der Match List des IO Modules steht folgendes:

Code Auswählen Erweitern


my %matchListIO = (
    "10:Logisches_Modul" => "^[A-F0-9]{5},
)


Verhalten funktioniert so wie gedacht, wenn das Modul nicht geladen wurde, dann wird es geladen und anschließend wird dispatcht.
Kommt dann noch eine Nachricht die auf die Regex passt, geht es direkt über die Clientlist an das Modul.

Was passiert, wenn Folgende Nachricht kommt?

Code Auswählen Erweitern

AA03B

Sie wird nicht über die Clientliste verteilt, sondern über die Matchlist. Das Match Statement im Modul passt hier nicht.
Dabei wird das Modul nicht noch mal geladen, da es ja schon geladen ist, aber die MatchList übernimmt jetzt schön das Verteilen von Nachrichten, auch wenn das Modul die "eigentlich" nicht haben möchte.


Einzige Chance das derzeit zu umgehen ist, die Regex Einträge in der MatchList und in logischen Modulen das Match Statement identisch zu halten.
Nebenbei, wenn ein Fehler in dem Match Statement im Modul ist, kann ganz leicht vom IO Modul über die Matchlist ein Workaround geschaffen werden. Ob da jedem Autor klar ist,  wieso und was da nun passiert bezweifle ich leider.

Ich denke, es ist weniger komplex für einen Modul Autor, wenn die MatchList nur zum Laden des Modules verwendet und das Dispatch nur über die Clientlist und das Match im Logischen Modul regelt. So hätten beide Listen ihren Zweck und würden sich nicht überschneiden.


Grüße Sidey

[rudolfkoenig]

Dein Beispiel demonstriert, dass bei einer falscher Programmierung ein unerwartetes Verhalten auftreten kann. Nach der vorgeschlagenen Aenderung wuerde das Verhalten seltener auftreten: nur dann, wenn das "kaputte" Modul noch nicht geladen ist. Das alles ist mir zu theoretisch, und werde deswegen noch nichts aendern.

[Sidey]

Nunja, wenn wenn Du meinst, dass es eine falsche Programmierung ist, lasse ich das mit dem Patch.

Ich hätte ihn wenn, dann vermutlich so realisiert, dass kein dispatch mehr aufgeführt wird, wenn die Match Regex vom Clientmodul nicht passt.

Also Modul laden über die matchlist und dann die Match Regex aus dem Modul geprüft.