AssignIoPort bei Zwei-Modul Systemen mit Dispatch()

[Ralf9]

Hallo,

ich bin gerade am SIGNALduino am Basteln. Dort wird Dispatch() mit Clients und MatchList verwendet.
Da mich interessiert hat ob der Dispatch auch ohne Clientliste funktioniert, habe ich mal den Eintrag "Hideki:" für das Modul "14_Hideki.pm" aus der Clientliste entfernt.
Nun bekomme ich beim fhemstart im log die folgenden Fehlermeldungen:

Code Auswählen Erweitern

Including ./log/fhem.save
2015.10.09 19:00:20 3: No I/O device found for Hideki_30_4
2015.10.09 19:00:20 3: No I/O device found for Hideki_30_1
2015.10.09 19:00:20 3: No I/O device found for Hideki_30_2
2015.10.09 19:00:20 0: Featurelevel: 5.6
2015.10.09 19:00:20 0: Server started with 24 defined entities (version $Id: fhem.pl 9091 2015-08-18

Wenn ich im logischem Modul 14_Hideki.pm in der "sub Hideki_Define($$)" das

Code Auswählen Erweitern

#AssignIoPort($hash);
auskommentiere, sind die Fehlermeldungen weg.

Mir ist nicht klar zu was das AssignIoPort() im define benötigt wird. Es funktioniert auch ohne das AssignIoPort().
Es gibt einige logische Module wie z.B. das "14_CUL_TCM97001.pm" wo das AssignIoPort() fehlt und es trotzdem funktioniert.

Gibt es eigentlich auch eine Möglichkeit mit dem Dispatch() auch ohne Clients oder MatchList direkt ein Modul aufzurufen?

Gruß Ralf

[justme1968]

AssignIoPort nur beim senden relevant und nur wenn die Kommunikation von logischen zu physikalischem modul über IOWrite passiert.

ohne Clients (und MatchList) funktioniert Dispatch nicht weil es nicht weiss wohin die nachrichten sollen.

was hast du denn für ein problem mit den beiden?

gruss
  andre

[Ralf9]

was hast du denn für ein problem mit den beiden?

Laut
http://forum.fhem.de/index.php/topic,41994.msg342175.html#msg342175
müsste die MatchList reichen, aber anscheinend wird bei Modulen die das AssignIoPort($hash) verwenden doch noch ein Eintrag in der Clientliste benötigt.

Gruß Ralf

[justme1968]

AssignIoPort geht die Clients liste durch um um ein passendes IODev zu finden wenn kein device vorgeschlagen wird. woher sollte AssignIoPort sonst wissen welche IODevs überhaupt infrage kommen.

wenn du AssignIoPort verwendest musst du dafür sorgen das du das IODev kennst und es mit angeben oder du brauchst die Clients liste.

bei dem von dir verlinkten thread war bist jetzt nur von der empfangs richtungt die rede. für die senderichtung kommt Clients über AssignIoPort wieder ins spiel.

wo ist denn das problem einfach beides zu setzen?

gruss
  andre

[Ralf9]

bei dem von dir verlinkten thread war bist jetzt nur von der empfangs richtungt die rede. für die senderichtung kommt Clients über AssignIoPort wieder ins spiel.
wo ist denn das problem einfach beides zu setzen?

D.h. dann, daß in die clientlist nur die logischen Module eingetragen werden müssen, bei denen im define ein AssignIoPort steht.
Oder wird die clientlist auch noch für was anderes benötigt, wenn es eine matchlist gibt.

Ich habe das mit dem client- und matchlist und dem Dispatch so verstanden:
Wenn es z.B. 10 logische Module gibt die in der client- und matchlist eingetragen sind,
und wenn dann in der parse Routine dem dispatcher eine fehlerhaft empfangene Nachricht übergeben wurde,
dann geht der dispatcher zuerst die clientlist durch und prüft die match regex in den Modulen
dann prüft er auch noch die regex in der matchlist.
Nachdem er festgestellt hat, daß keine der 20 regex paßt, erzeugt er einen "unknown code" event.

Damit der dispatcher nicht mit fehlerhaften Nachrichten "belästigt" wird und im log keine unötigen unknown Meldungen auftauchen, müsste es doch sinn machen, wenn in der parse Routine schon vor dem dispatch aufruf ein regex auf die Nachricht durchgeführt wird.
Ich denke dies dürfte vorallem bei recht genauen regex wie z.B. "^u7[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}" Sinn machen.

Da es beim SIGNALDuino einen ProtocolListSIGNALduino hash gibt, ist die regex schon vor dem dispatch Aufruf bekannt.

Code Auswählen Erweitern

my %ProtocolListSIGNALduino  = (
    "0"    =>
        {
            name => 'weather1', # Logilink, NC, WS, TCM97001 etc.
id          => '0',
one => [1,-8],
zero => [1,-4],
sync => [1,-18],
clockabs    => '500', # not used now
format      => 'twostate',  # not used now
preamble => 's', # prepend to converted message
postamble => '00', # Append to converted message
clientmodule    => 'CUL_TCM97001',   # not used now
modulematch     => '^s[A-Fa-f0-9]+', # not used now
length_min      => '24',
length_max      => '40',
paddingbits     => '8', # pad up to 8 bits, default is 4
        },
    "1"    =>

Obwohl beim dispatch Aufruf der Name des clientmodul schon bekannt ist, muß der dispatcher die client und matchlist durchsuchen,
oder gibt es eine einfache Möglichkeit das clientmodul direkt aufzurufen?

Gruß Ralf

[justme1968]

Clients ist dazu da um festzustellen an welches modul eine nachricht verteilt werden soll. intern wird aus Clients nur die einträge genommen zu denen es auch ein geladenes modul (d.h. definiertes device) gibt.

wenn keines der geladenen module past dann wird die MatchList durchgegangen (so fern global autoload_undefined_devices nicht auf 0 gesetzt ist) und versucht die nachricht an jedes modul aus der liste loszuwerden.


es zwingt dich doch niemand dispatch zu verwenden wenn du schon weisst welches modul dafür zuständig ist. du kannst die parseFn oder jede andere auch direkt aufrufen.

aber du verlierst dadurch die vorteile die dir fhem mit dem dispatch framework liefert: duplikat erkennung, fhem2fhem fähigkeit, die möglichkeit das ein protokoll auch von anderen physikalischen modulen verstanden wird und dann über dispatch deine logisches modul aufruft, die möglichkeit das ein anderes physikalisches modul daten empfängt die zu einem deiner logischen module passen, du fängst vermutlich sehr bald an die anderen features aus Dispatch nachzimplementieren, ...

sollten nicht 'falsche' nachrichten so früh erkannt und ausgeschlossen werden das sie garnicht erst durch dispatch laufen? wenn du eine regex hast die das schafft schmeiss die nachrichten in der parseFn deines physikalischen moduls weg und dann ruf dispatch wie gedacht mit der übrig geblieben nachrichten auf.

gruss
  andre

[Ralf9]

Clients ist dazu da um festzustellen an welches modul eine nachricht verteil werden soll. intern wird aus Clients nur die einträge genommen zu denen es auch ein geladenes modul (d.h. definiertes device) gibt.

wenn keines der geladenen module past dann wird die MatchList durchgegangen (so fern global autoload_undefined_devices nicht gesetzt ist) und versucht die nachricht an jedes modul aus der liste loszuwerden.

Danke, nun ist mir vieles klar geworden.

Mir ist noch nicht klar zu was clientmodule, die kein AssignIoPort enthalten, in die clientliste eingetragen werden müssen?
Ich habe bei mir in der 00_SIGNALduino.pm drei Temperatursensor Clientmodule aus der clientliste entfernt.
Es funktioniert trotzem noch alles. Es werden readings geschrieben und events erzeugt. Das autocreate neuer Sensoren funktioniert auch.
Damit müsste bei diesen 3 Modulen nur die matchlist verwendet werden.
Werden bei der matchlist auch nur die einträge genommen zu denen es auch ein geladenes modul gibt?

Ich habe es mir folgendermaßen gedacht.
Wenn vor dem dispatch eine genaue regex wie z.B. "^u7[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}" geprüft wird, dann reicht in der matchlist eine einfache ("^u7.*").
Im clientmodul kann dann für andere physikalische module eine genaue regex stehen.

Gruß Ralf

[justme1968]

wenn du Clients nicht verwendest dann wird die regex die in $hash->{Match} der logischen module angegeben ist niemals ausgewertet was vermutlich nicht sehr effizient ist weil bei der anschließenden auswertung der MatchList das modul jedes mal neu geladen wird.

bei der MatchList werden alle durchgegangen bei denen die regex passt und das modul automatisch geladen und dann die parseFn aufgerufen.

warum trägst du nicht einfach Clients und MatchList ein wie es vorgesehen ist?

gruss
  andre

[Ralf9]

Bei der Matchlist sind normalerweise die regex eindeutig, so daß nur eine regex passt. Den Nachrichten werden dafür je nach Protokoll eindeutige Zeichen vorangestellt.
D.h. bei Nachrichten von bereits definierten devices müsste das Modul bereits geladen sein, oder müssen bei der Matchlist auch module von bereits definierten devices neu geladen werden?

Ich hatte gedacht es müsste effizienter sein, wenn nach der prüfung der genauen regex in der parse routine nur noch einfache regex in der Matchlist geprüft werden müssen.
Wahrscheinlich mache ich mir dazu zu viele Gedanken und es macht gar keinen so großen Unterschied ob in der Matchlist einfache regex oder bei der clientlist in den logischen module längere genauere regex überprüft werden müssen.

Gruß Ralf

[justme1968]

bei der prüfung über Clients und Match der bereits geladen module werden diese nicht neu geladen.

das ist nur dann effizienter wenn sich die regex sehr weit hinten unterscheiden. wenn der anfang sowieso unterschiedlich ist und nicht matched wird ja sofort abgebrochen.

gruss
  andre

ps: achtung: es gibt drei dinge zu beachten. zum einen Clients im physikalischen modul das mit Match im logischen modul zusammen arbeitet und MatchList wenn Clients nicht gegriffen hat. das Match im logischen modul steht ist auch der grund das es erst nach dem laden ausgewertet werden kann. deshalb die verdoppelung in MatchList.

[Ralf9]

Danke, daß Du so viel Geduld mit mir hattest.
Nun ist es mir klar geworden, daß es keinen Sinn macht nicht alle verwendeten logischen Module in die clientlist einzutragen.
Die matchlist wird demnach nur verwendet wenn bei einem logischem Modul die match regex fehlt oder fehlerhaft ist,
oder wenn dem dispatcher eine Nachricht übergeben wird zu dem es noch kein device gibt und die Nachricht an ein noch nicht geladenes Modul übergeben werden muß.

Gruß Ralf

[Sidey]

Hi Ralf,

Nun ist es mir klar geworden, daß es keinen Sinn macht nicht alle verwendeten logischen Module in die clientlist einzutragen.

Das denke ich nicht. Alle die Senden sollten da rein, aber reine Empfänger müssen da doch nicht stehen.

Die matchlist wird demnach nur verwendet wenn bei einem logischem Modul die match regex fehlt oder fehlerhaft ist,

Hmm, also die Prüfung der Regex aus den logischen Modulen erfolgt so:

Code Auswählen Erweitern


next if($dmsg !~ m/$modules{$m}{Match}/i);

Wenn Match nun leer ist wäre die Bedingung ja erfüllt. Wenn Match nun nicht definiert ist, vermute ich mal ebenso.
Die Match list wird durchgearbeitet wenn folgende Bedingung erfüllt wird.

Code Auswählen Erweitern

  if(!int(@found) || !defined($found[0])) {.
@found wird durch folgendes Statement gesetzt

Code Auswählen Erweitern

@found = &{$modules{$m}{ParseFn}}($hash,$dmsg);
Das ganze ist in eine Schleife gekapselt 

Code Auswählen Erweitern

  foreach my $m (@{$clientArray}) {

oder wenn dem dispatcher eine Nachricht übergeben wird zu dem es noch kein device gibt und die Nachricht an ein noch nicht geladenes Modul übergeben werden muß.

Hmm, ob ein device definiert ist oder nicht spielt für dispatch keine Rolle denke ich.
Wann die Module, welche in der ClientList definiert sind geladen werden habe ich noch nicht gefunden. Aber ganz sicher irgendwo beim Initialisieren. Andernfalls würde die Clientlist nicht ohne Matchlist funktionieren.

Grüße Sidey

[justme1968]

doch. so wie Ralf9 es verstanden hat ist es gedacht.

der normalfall für bereits geladene module (das sind alle für die schon ein device definiert ist) ist der weg über Clients aus dem physikalischen und Match aus dem logischen modul.

erst wenn hier niemand gefunden wird der zuständig ist wird die MatchList ausgewertet die die information aus Clients und Match noch mal in etwas anderer form enthält. aber eben nur im physikalischen modul da das logische modul ja noch nicht geladen ist.

MatchList ist nur für noch nicht geladene logische module gedacht. wenn man Clients nicht verwendet wird bei jedem durchlaufen der MatchList jedes potentiell passende modul immer wieder neu geladen.

noch mal der hinweis: Match und MatchList sind zwei verschiedene dinge.

und ja: das ist zum teil redundant da sich die information überlappen. aber wie rudi im anderen thread geschrieben hat hat das historische gründe und ist nur mit aufwand umzustellen. es ist doch nicht wirklich schlimm einfach alle drei auszufüllen.

gruss
  andre

ps:

Hmm, also die Prüfung der Regex aus den logischen Modulen erfolgt so:

Code Auswählen Erweitern

next if($dmsg !~ m/$modules{$m}{Match}/i);
Wenn Match nun leer ist wäre die Bedingung ja erfüllt. Wenn Match nun nicht definiert ist, vermute ich mal ebenso.

nein. und es gibt einen meldung weil $modules{$m}{Match} dann eben nicht definiert ist.

[Sidey]

Hi,

doch. so wie Ralf9 es verstanden hat ist es gedacht.

Jetzt bin ich baff. Weisst Du, wo die Module, welche in Clientlist stehen geladen werden? Ich habe das nicht gefunden.

der normalfall für bereits geladene module (das sind alle für die schon ein device definiert ist) ist der weg über Clients aus dem physikalischen und Match aus dem logischen modul.

erst wenn hier niemand gefunden wird der zuständig ist wird die MatchList ausgewertet die die information aus Clients und Match noch mal in etwas anderer form enthält. aber eben nur im physikalischen modul da das logische modul ja noch nicht geladen ist.

Also die geladenen Module und das darin verwendete Match wird doch nur angewandt, wenn in der Clientliste des physisches Modules diese Module auch aufgeführt sind. Werden sie darin nicht spezifiziert, dann wird auch Match nicht in einer regex angewendet. Ebenso dann natürlich auch nicht parsefn.

MatchList ist nur für noch nicht geladene logische module gedacht. wenn man Clients nicht verwendet wird bei jedem durchlaufen der MatchList jedes potentiell passende modul immer wieder neu geladen.

Da in LoadModule geprüft wird, ob ein Modul geladen ist, bevor es geladen wird

Code Auswählen Erweitern

$modules{$m}{LOADED} und in der Funktion

Code Auswählen Erweitern

CommandReload auf 1 gesetzt, wird das Modul meiner Meinung nach nicht wieder geladen.

Code Auswählen Erweitern

if($modules{$m} && !$modules{$m}{LOADED}) {   # autoload

noch mal der hinweis: Match und MatchList sind zwei verschiedene dinge.

Das habe ich verstanden.
Die ganze Aktion kommt ja nur daher, da man in MatchList eine Reihenfolge angeben kann und bei Verwendung der Clientlist diese vom Modulautor mit bestimmt wird.

und ja: das ist zum teil redundant da sich die information überlappen. aber wie rudi im anderen thread geschrieben hat hat das historische gründe und ist nur mit aufwand umzustellen. es ist doch nicht wirklich schlimm einfach alle drei auszufüllen.

Wegen mir muss nichts umgestellt werden. Ich versuche nur zu verstehen, ob es nicht ohne Clientliste auch sehr gut funktionieren würde, da wenn ich sowohl Matchlist als auch Clientlist ausfülle ich zwangsläufig die Reihenfolge nicht so hin bekomme, wie ich die gerne hätte.

Abschließend ist aber folgender Satz:

der normalfall für bereits geladene module ist der weg über Clients aus dem physikalischen und Match aus dem logischen modul.

Wenn das der vorgesehene Weg ist und der andere nicht, dann ist das ja auch eine Aussage. Der vorgesehen Weg war mir bislang halt noch nicht klar.

Grüße Sidey

[Ralf9]

Wegen mir muss nichts umgestellt werden. Ich versuche nur zu verstehen, ob es nicht ohne Clientliste auch sehr gut funktionieren würde, da wenn ich sowohl Matchlist als auch Clientlist ausfülle ich zwangsläufig die Reihenfolge nicht so hin bekomme, wie ich die gerne hätte.

Für die in der Clientlist nicht festlegbare Reihenfolge gibt es eine einfache Lösung. Es muß nur dafür gesorgt werden, daß in der clientliste nur bei einem Modul die regex passt. Ich denke dies ist machbar.

Mir ist beim 41_OREGON.pm Modul aufgefallen, daß dort die Zeile mit dem match regex fehlerhaft ist.
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/41_OREGON.pm#l67

Code Auswählen Erweitern

$hash->{Match}     = "^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*", #38-78

Müsste da nicht am Ende anstatt einem Komma ein ";" stehen?

Gruß Ralf