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:
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
#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
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
Zitat von: justme1968 am 09 Oktober 2015, 22:39:45
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
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
Zitat von: justme1968 am 09 Oktober 2015, 23:43:36
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.
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
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
Zitat von: justme1968 am 10 Oktober 2015, 19:14:22
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
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
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
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.
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
Hi Ralf,
Zitat von: Ralf9 am 10 Oktober 2015, 22:58:34
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.
Zitat von: Ralf9 am 10 Oktober 2015, 22:58:34
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:
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.
if(!int(@found) || !defined($found[0])) {.
@found wird durch folgendes Statement gesetzt
@found = &{$modules{$m}{ParseFn}}($hash,$dmsg);Das ganze ist in eine Schleife gekapselt
foreach my $m (@{$clientArray}) { Zitat von: Ralf9 am 10 Oktober 2015, 22:58:34
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
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:
ZitatHmm, also die Prüfung der Regex aus den logischen Modulen erfolgt so:
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.
Hi,
Zitat von: justme1968 am 11 Oktober 2015, 00:06:21
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. :(
Zitat von: justme1968 am 11 Oktober 2015, 00:06:21
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.
Zitat von: justme1968 am 11 Oktober 2015, 00:06:21
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
$modules{$m}{LOADED} und in der Funktion
CommandReload auf 1 gesetzt, wird das Modul meiner Meinung nach nicht wieder geladen.
if($modules{$m} && !$modules{$m}{LOADED}) { # autoloadZitatnoch 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.
Zitat von: justme1968 am 11 Oktober 2015, 00:06:21
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:
Zitat
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
Zitat von: Sidey am 11 Oktober 2015, 00:35:44
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
$hash->{Match} = "^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*", #38-78Müsste da nicht am Ende anstatt einem Komma ein ";" stehen?
Gruß Ralf
die module aus Clients werden nicht (automatisch) geladen. in computeClientArray wird Clients mit Match der zur zeit geladenen module zusammengeführt. die geladenen module sind die für die es zum jeweils aktuellen zeitpunkt ein definiertes device gibt. hier wird als reihenfolge dir nummer am anfang des modul file namen verwendet. d.h. du hast auch hier einfluss auf die reihenfolge. wobei ich mir nicht sicher bin ob es geschickt ist etwas von der reihenfolge abhängig zu machen (siehe unten).
du hast recht. das laden passiert nur ein mal.
das dies der vorgesehene weg ist heisst ja nicht das das andere unter bestimmten randbedingungen (nur empfangen, nicht senden, FingerprintFn nur im physikalischen modul, nicht im logischen) auch funktionieren kann. es heisst aber das es vermutlich der effizienteste weg ist da z.b. normalerweise nur auf die beim anwender auch tatsächlich vorhanden und definierten devices gematched wird und auf die 10 anderen die das modul zwar kann aber für die noch nichts empfangen wurde. du weisst ja nicht ob ein anwender das erste oder das 10. aus der liste einsetzt.
gruss
andre
Hi Andre,
Jetzt ist der Groschen bei mir gefallen. Ich denke jetzt habe ich es verstanden.
Die MatchList hat den Zweck ein Modul bei Bedarf laden zu können.
Damit nicht wahllos irgendwas geladen wird, gibt es eine Regex die verständlicher Weise im IO Dev Modul definiert wird.
Damit die ankommende Nachricht nicht verloren geht, wird parsefn aufgerufen.
Die Clientliste enthält die bereits geladenen und vom Autor des IO Dev Modules vorgesehenen Module. In einem versteckten Imternal stehen die geladenen Module, welche nur auch in Clientlist spezifizierte sein können.
Ab dem Zeitpunkt, wo ein Modul geladen ist, gilt die Match Regex aus dem logischen Modul.
Man könnte den clientArray demnach auch durch ein paar split und concat Befehle aus der MatchList erzeugen.
Nur mit der MatchList zu arbeiten geht, dafür ist diese aber nicht gedacht.
Ich werde mal versuchen das ins Wiki einzubauen.
Sidey
wiki klingt gut :)
gruss
andre
Hi,
erlaube mir mich einzuklinken, hänge da auch gerade:
Aufgabe:
ich möchte testweise ein modul für spezielle WMBUS Nachrichten erstellen die vom 36_WMBUS nicht dekodiert werden.
Idealerweise möchte ich nicht 01_CUL oder 36_WMBUS patchen.
Ziel: ich erstelle das Modul (testlevel), definiere die Instanzen von Hand (auf autocreate verzichte ich vorerst)
Danach soll "dispatch" CUL Nachrichten mit
"^b.+{24}A0.*" an den (meinen) Prototypen leiten und
"^b.*" weiterhin an 36_WMBUS
Reicht es das modul 35_whatever zu nennen (also kleinerer prefix) und im intitialize $hash->{Match} = "^b.+{24}A0.*" zu setzen ?
Danke und vg
joerg
joerg
Nein. Wenn du sicherstellst, dass 35_whatever geladen ist (z.Bsp. via define), dann musst du noch $clientsWMBus mit whatever erweitern. Sonst musst du zusaetzlich zu Match und clientsWMBus auch noch matchListWMBus erweitern.
Btw: ich glaube dein regexp ist fehlerhaft, + und {24} vertragen sich mWn nicht.
du musst in die Clients liste von 00_CUL. sonst wird deine Match garnicht erst ausgewertet.
wen du ohne autocreate arbeitest und du dein modul von hand lädst müsste es eigentlich gehen wenn du im der DefFn deines moduls vor dem AssignIoPort aufruf die Clients liste der cul instanz die du verwenden willst patchst. das sollte zum testen gehen. sauber ist aber anders :)
autoload geht aber nicht ohne das dein modul in der MatchList steht.
eine andere möglichkeit die mir einfällt die eventuell geht ist wenn du zur laufzeit $modules{WMBUS}{ParseFn} durch deine ersetzt bei nicht passenden nachrichten wieder das original aufrufst. nicht wirklich sauberer aber das hätte den vorteil das die ein rfmode umschalten oder reconnect beim cul nicht Clients wieder zurück setzt.
gruss
andre
Iss ja erstmal "nur" POC.
Also, $hash->{MatchList} vom CUL zur Laufzeit "patchen"
Der erste char ("J:WMBUS" => "^b.*" / hier das "J") gibt die Reihenfolge an ?
Danke.
vg
joerg
MatchList musst du anpassen wenn autload funktionieren soll. Clients musst du anpassen damit Dispatch funktioniert.
gruss
andre
oh. sorry. ok dann hab ichs (glaub ich) verstanden
danke und Grüße
Jörg
hat prima funktioniert. Danke.
vg
joerg