[fixed] Dispatch-Funktion bei Signalduino u. IT V3 mit freezes

[Sidey]

Andererseits werden Module nicht so haeufig geladen, und auf meinem Rechner war der Unterschied pro geladenes Modul unter 2ms

Ich kenne die Rechenleistung von deinem Rechner nicht, aber in 2 millisekunden sind für einen Computer einige Rechenoperationen.
Ich habe da allerdings noch eine andere Stelle im Blick, wo der Effekt meines Erachtens in der Summe eher relevant sein könnte.

Ich hoffe das hat sich mit der vorherigen Aenderung erledigt.

Meine Tests sehen bislang gut aus.
Einen Test für Dispatch anzulegen kann aber nicht schaden. Ich bau mal ein Gerüst, wobei ich hier anmerken muss, die "Einheit" Dispatch ist ziemlich umfangreich für einen Test. Ich würd mal schauen, ob ich es zunächst auf den return Wert limiteren kann.

[Beta-User]

Da das geladene Modul nicht im ".clientArray" steht, wird es bei den folgenden dispatch in der .clientArray Schleife nicht aufgerufen und in der matchlist Schleife durch "next if($modules{$mname}{LOADED});" übersprungen.

Das scheint in recht vielen Modulen Probleme zu machen...

Hab's nicht im Detail angesehen, aber neben dem bereits weitgehend geklärten HM485- und LaCrosse-GW-Modulen das hier klingt auch danach:
https://forum.fhem.de/index.php/topic,125614.0/topicseen.html
- Unifi
- Esera-IO

Gibt es evtl. eine Idee, wie man sowas proaktiv auffinden kann, damit man den betr. Maintainern ggf. schon vorab einen Hinweis zukommen lassen könnte...?

[Ralf9]

Gibt es evtl. eine Idee, wie man sowas proaktiv auffinden kann

Dies lässt sich rausfinden durch vergleich der match regex in den Clientmodulen mit der matchliste im IO Modul, diese sollten gleich sein

Esera-IO

Die Clientmodule hab ich gefunden "66_Esera.." ist weiß aber nicht wie das IO Modul heißt

Unifi

da sind die regex gleich, evtl war es das Autocreate problem?

Das 14_Hideki.pm Modul ist auch davon betroffen, da gibts jetzt ein Temperatursensor der nicht mehr funktioniert (Sidey weiß schon davon)

[Beta-User]

Dies lässt sich rausfinden durch vergleich der match regex in den Clientmodulen mit der matchliste im IO Modul, diese sollten gleich sein

...klingt nicht danach, als wäre das per einfachem "grep" über das FHEM-Verzeichnis zu ermitteln...

Die Clientmodule hab ich gefunden "66_Esera.." ist weiß aber nicht wie das IO Modul heißt

Würde auf 66_EseraOneWire.pm tippen:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/66_EseraOneWire.pm#L24

da sind die regex gleich, evtl war es das Autocreate problem?

Wie gesagt: ich habe nur erst mal versucht, die Infos zu verknüpfen, damit ggf. schnell reagiert werden kann, ohne mich mit den Hintergründen zu befassen.

Das 14_Hideki.pm Modul ist auch davon betroffen, da gibts jetzt ein Temperatursensor der nicht mehr funktioniert (Sidey weiß schon davon)

Thx für die Info, mal sehen, wie viele sich dazu melden werden...

[Ralf9]

Würde auf 66_EseraOneWire.pm tippen:

EseraDimmer kann nicht funktionieren, da er in der Clientlist fehlt

Code Auswählen Erweitern

$hash->{Clients} = ":EseraDigitalInOut:EseraTemp:EseraMulti:EseraAnalogInOut:EseraIButton:EseraCount:EseraShutter:";

[Beta-User]

Thx, habe es mal eingekippt, dann sollten die Beteiligten das selbst checken/reparieren (lassen) können.

[Ralf9]

Dies passt auch nicht mit der Matchlist zusammen

Code Auswählen Erweitern

66_EseraDigitalInOut.pm
$hash->{Match}         = "DS2408";

66_EseraMulti.pm
$hash->{Match}         = "DS2438";

Code Auswählen Erweitern

  $hash->{MatchList} = { "1:EseraDigitalInOut" => "^DS2408|^11220|^11233|^11228|^11229|^11216|^SYS1|^SYS2",
                         "2:EseraTemp" => "^DS1820",
                         "3:EseraMulti" => "^DS2438|^11121|^11132|^11133|^11134|^11135",
                         "4:EseraAnalogInOut" => "^SYS3",
                         "5:EseraIButton" => "^DS2401",
                         "6:EseraCount" => "^DS2423",
                         "7:EseraShutter" => "^11231|^11209",
                         "8:EseraDimmer" => "^11221|^11222"};

[rudolfkoenig]

Gibt es evtl. eine Idee, wie man sowas proaktiv auffinden kann, damit man den betr. Maintainern ggf. schon vorab einen Hinweis zukommen lassen könnte...?

Todo:
- IO-Modul laden. Problem: Perl-Module muessen installiert sein.
- MatchList abfragen. Problem: Manche Module setzen je nach Attribut einen unterschiedlichen MatchList.
- aus Matchlist die logischen Module laden, und deren Match mit dem MatchList Eintrag vergleichen. Problem: Regex vs. Regex Vergleich.

Perfekt zu loesen ist mW nicht moeglich, insb. wegen dem letzten Punkt.
Ob das, was machbar ist, praktisch einen Nutzen hat, weiss ich nicht.

[Beta-User]

Nun ja, wie wir erleben, taucht das meiste dann doch eher schneller, von daher ist es halt lästig, aber meistens dann auch recht schnell zu fixen...

[Sidey]

@Sidey, es wäre schön, wenn Du die regex im Hideki Modul fixen könnstet

Hast Du auch eine passende RawMsg?

Grüße Sidey

[Ralf9]

Hast Du auch eine passende RawMsg?

Hatte ich hier bereits gepostet:
https://forum.fhem.de/index.php/topic,58397.msg1200961.html#msg1200961

Gruß Ralf

[Ralf9]

Revision 25560: 14_Hideki.pm: fix match regex
- avoid "Unknown code ...

14_Hideki.pm: fix match regex
- avoid "Unknown code P12#751CBA4A31BFC751F4, help me!" errors in logfile
- forum:#125679

Source: Revision 25560: 14_Hideki.pm: fix match regex
- avoid "Unknown code ...
http://svn.fhem.de/trac/changeset/25560/trunk

Hallo Sidey,

damit wird der Fehler mit den "Unknown code P12#xxx, help me!" errors in logfile" nicht zu 100% behoben.

Ich hätte es besser gefunden, wenn Du so wie auch bei allen anderen Clientmodulen, die match regex gleich gemacht hättest, wie in der Matchliste: 

Code Auswählen Erweitern

'7:Hideki'            => '^P12#75[A-F0-9]+',

Gruß Ralf

[Sidey]

Ich hätte es besser gefunden, wenn Du so wie auch bei allen anderen Clientmodulen, die match regex gleich gemacht hättest, wie in der Matchliste: 

Um welche Nachrichten exakt geht es? Ich kenne aktuell keine, welche eine derartige Meldung erzeugen.

Die Regex dient als Filter und Nachrichten beliebiger Lange können vom Modul doch nicht verarbeitet werden.

[Ralf9]

Es geht um fehlerhafte MC Nachrichten die evtl eine dmsg von weniger als 14 Zeichen nach der "75" ergeben.

[KölnSolar]

Hi Rudi,

(oder vielleicht auch Ralf oder Sidey) ich bin ja begeistert, dass Ihr das freeze-Problem beim Signalduino gelöst habt.

Leider hab ich nun ein Problem mit der fhem.pl, dass das Dispatch nicht mehr mein logisches Modul oder Matchbegriff findet. Ich hab es soweit analysieren können, dass der Fehler behoben ist, wenn ich die Zeile

Code Auswählen Erweitern

    next if($modules{$mname}{LOADED}); # checked in the loop above, #125292auskommentiere.

Ich hab ja eher an einen Fehler in meinen Modulen geglaubt, aber nun bin ich mir sicher, dass es das nicht ist.

Vielleicht fällt Euch ja was auf.

Physisches Modul

Code Auswählen Erweitern

  $hash->{Clients}   = "DLNAController";
  $hash->{MatchList} = { "1:DLNAController"      => "^(RenderingControl|AVT|Speak|Sess)" ,
};

Logisches Modul

Code Auswählen Erweitern

  $hash->{Match} = { "1:DLNAController"      => "^(RenderingControl|AVT|Speak|Sess)",
};

Im Ursprung hatte ich 4 einzelne Einträge im Hash, aber die Änderung brachte es nicht. Ebensowenig, dass ich den zu matchenden Begriff komplett(RenderingControl anstatt nur Ren) aufgenommen habe. Jetzt hätte ich nur noch die Idee, dass das Problem bei mir auftritt, weil es nur 1 logisches Modul gibt ? 

Grüße
Markus