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

[Ralf9]

@KölnSolar
ich hab erstmal bei mir auf dem github beim IT Modul die "return undef" durch return '' ersetzt
https://github.com/Ralf9/10_IT/blob/master/FHEM/10_IT.pm
https://github.com/Ralf9/10_IT/commit/2b42dc60bfb573397c4738dfa197cb8da0439ea4#diff-31ce4f5175b925aa615d7dd8138f71f31c7cabd3e4f352a8386b91af91ae809b

Außerdem habe ich noch bei meiner Variante der 00_SIGNALduino.pm
- Das ClientsKeepOrder gesetzt
- Die Sortierung der Clientlist optimiert, die Module für Temperatursenoren und Wetterstationen stehen nun am Anfang, da bei denen regelmässig ca jede Minute was empfangen wird
- Bei aktiver Whitelist, werden nun nur noch die Clientmodule der IDs die in der Whitelist stehen in die $hash->{Clients} kopiert

Wenn z.B. in der whitelist die folgenden IDs stehen:

Code Auswählen Erweitern

0 - CUL_TCM97001
3 - IT
9 - SD_WS09  Weatherstation WH1080, WH3080 ...
12 - Hideki
18 - Oregon
61 - FS10

Dann steht im Internal Clients nur noch:

Code Auswählen Erweitern

:CUL_TCM97001:SD_WS09:Hideki:OREGON:IT:FS10:

https://github.com/Ralf9/RFFHEM/blob/dev_clientlist/FHEM/00_SIGNALduino.pm
https://github.com/Ralf9/RFFHEM/blob/dev_clientlist/FHEM/lib/signalduino_protocols.pm

Gruß Ralf

[Sidey]

Das ist nicht sinnvoll, da die Liste nur nach Laden neuer Module berechnet wird. Aus dem Gleichen Grund ist eine Optimierung nur begrenzt wichtig. Aber wenn es nich wesentlich länger oder unleserlich wird: warum nicht.

Verstehe. Ich habe ein wenig getestet. Ab drei geladenen Modulen ist die Variante mit den Vorberechnung der Regex schon schneller. Mit mehr Modulen oder einer größeren Clientliste wird der Effekt stärker, das dürfte also in den allermeisten Fällen immer etwas bringen und somit CPU Ressourcen zum 0-Tarif schenken.

Die Lesbarkeit ist für denjenigen, der es geschrieben hat ja meist kein Problem, aber es ist nur ein map hinzugekommen.
Noch effizienter wäre es natürlich, wenn man die Regex der Clientliste vorcompiliert speichert, aber das erschien mir zunächst komplexer zu werden.

Grüße Sidey

[KölnSolar]

Erst einmal mein Dank an Euch.

@Ralf hab alle 3 Module eingespielt,keine whitelist und shutdown/restart. In freezemon bin ich runter auf threshold=0.5 und alles bleibt friedlich. 
Grüße Markus

[Ralf9]

#2 Bei der erneuten Suche nach verfuegbaren Modulen werden auch bereits geladene (und damit schon befragte) Module erneut gefragt (d.h. ParseFn wird aufgerufen), und clientArray wird sinnlos geloescht.
#2. Habe ich gerade gefixt. Das sollte computeClientArray in diesen Faellen vermeiden,

Das passt noch nicht ganz.

Siehe hier im Kommentar:

https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L4106

Code Auswählen Erweitern


  if((!int(@found) || !defined($found[0])) && !$nounknown) {
    my $h = $hash->{MatchList};
    $h = $module->{MatchList} if(!$h);
    if(defined($h)) {
      foreach my $m (sort keys %{$h}) {  ## <- in $m steht der Modulname mit der Nummer am Anfang z.B. "07:Hideki"
        next if($modules{$m}{LOADED});   ## <- hier wird aber nur der Modulname benötigt
        if($dmsg =~ m/$h->{$m}/s) {
          my ($order, $mname) = split(":", $m);

So funktionierts:

Code Auswählen Erweitern


  if((!int(@found) || !defined($found[0])) && !$nounknown) {
    my $h = $hash->{MatchList};
    $h = $module->{MatchList} if(!$h);
    if(defined($h)) {
      foreach my $m (sort keys %{$h}) {
        my (undef, $mname) = split(":", $m);      ## neu
        next if($modules{$mname}{LOADED}); # checked in the loop above, #125292
        if($dmsg =~ m/$h->{$m}/s) {
          #my ($order, $mname) = split(":", $m);  ## alt

Aufgefallen ist's mir am 14_Hideki.pm Modul, da ist die match regex fehlerhaft

Code Auswählen Erweitern

$hash->{Match}     = "^P12#75[A-F0-9]{17,30}
Diese regex ist genauer als die regex in der Matchlist:

Code Auswählen Erweitern

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

Z.B. diese dmsg "P12#75E80635C7405C63" ist für die Match regex im Hideki Modul zu kurz, deshalb gibt's kein match im clientarray

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

Gruß Ralf

[rudolfkoenig]

Das passt noch nicht ganz.

Wo Du Recht hast...
Habs gesendert und eingecheckt.

[Sidey]

Die Lesbarkeit ist für denjenigen, der es geschrieben hat ja meist kein Problem, aber es ist nur ein map hinzugekommen.
Noch effizienter wäre es natürlich, wenn man die Regex der Clientliste vorcompiliert speichert, aber das erschien mir zunächst komplexer zu werden.

Offenbar war der Anhang nicht dabei. Jetzt sollte er dabei sein.

[Ralf9]

Wo Du Recht hast...
Habs gesendert und eingecheckt.

Beim Autocreate passt's noch nicht ganz.

Ein Autocreate von einem Device funktioniert nur, wenn sich das Clientmodul im ".clientArray" befindet.
Wenn man das erste Device von einem Modul per Autocreate erzeugen will, wird das Modul zwar geladen, es wird aber das ".clientArray" nicht gelöscht.
Ich habs mal mit einem FS10 Device getestet. Nachdem nach dem ersten Dispatch Aufruf per Matchlist das FS10 Modul geladen wurde, habe ich das ".clientArray" gelöscht damit das ".clientArray" neu erzeugt wurde.
Danach war das FS10 Modul im ".clientArray" und das autocreate hat funktioniert.

[Sidey]

Wo Du Recht hast...
Habs gesendert und eingecheckt.

Seit dieser Änderung laufen einige meiner Test nicht mehr durch.
Z.B. autocreate geht nicht mehr.

Ob meine Module jetzt fehlerhaft sind, oder die Anpassung, das habe ich nicht durchleuchtet.

[Sidey]

@rudi

Ich habe den Fehler in fhem.pl gefunden. Folgender Patch beseitigt ihn aus meiner Perspektive.
Erste tests haben dies bestätigt.

Edit:
Ich habe eine Nacht darüber geschlafen und glaube der Patch ist noch nicht fertig. Da fehlt eine explizite Bedingung, ob ein neues Modul nachgeladen wurde.
So wird computeClientArray auch ausgeführt wenn das Modul über die Clientliste geladen wurde. 

[buennerbernd]

Irgendwas endscheidendes scheint sich geändert zu haben. Das KLF200 Modul, das jahrelang ohne Probleme lief, hat nun Probleme (evtl. mit autoCreate und/oder Netzwerkverbindungen)
Siehe https://forum.fhem.de/index.php/topic,92907.msg1201966.html#msg1201966
Leider habe ich momentan null Kapazität, den Ursachen nachzugehen.

[rudolfkoenig]

Offenbar war der Anhang nicht dabei. Jetzt sollte er dabei sein.

Danke, habs eingecheckt. Bei CUL ist der Zeitersprarnis 80% wenn ein Modul neu geladen wurde.

Seit dieser Änderung laufen einige meiner Test nicht mehr durch.
Z.B. autocreate geht nicht mehr.

Zur Klarstellung: autocreate funktioniert allgemein, jedenfalls habe ich gerade bei MQTT2_SERVER und CUL kein autocreate Problem feststellen koennen.

Statt patch zu bauen waere viel sinnvoller einen Testfall zu konstruiren, womit ich das Problem nachstellen kann.

[Ralf9]

Das Autocreate funktioniert nicht, wenn man das erste Device von einem Modul per Autocreate erzeugen will. Das Modul wird dann zwar geladen, aber das ".clientArray" wird nicht gelöscht.
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.

Ich habs mit 2 log Ausgaben in der fhem.pl getestet

Code Auswählen Erweitern

  foreach my $m (@{$clientArray}) {
    # The message is not for this module
    Log3 $hash, 2, "SYSTEM $name: clientloop0 m=$m";   ## <--
    next if($dmsg !~ m/$modules{$m}{Match}/s);

    if( my $ffn = $modules{$m}{FingerprintFn} ) {
      ($isdup, $idx) = CheckDuplicate($name, $dmsg, $ffn);
      return rejectDuplicate($name,$idx,$addvals) if($isdup);
    }

    no strict "refs"; $readingsUpdateDelayTrigger = 1;
    my @tfound = &{$modules{$m}{ParseFn}}($hash,$dmsg);
    Log3 $hash, 2, "SYSTEM $name: clientloop1 m=$m tfound=@tfound";  ## <--
    use strict "refs"; $readingsUpdateDelayTrigger = 0;
    $parserMod = $m;
    if(int(@tfound) && defined($tfound[0])) {
      if($tfound[0] && $tfound[0] eq "[NEXT]") { # not a goodDeviceName, #95446
        shift(@tfound);
        push @found, @tfound;                   # continue feeding other modules
      } else {
        push @found, @tfound;
        last;
      }
    }
  }

Ich habs mit dem CUL_WS Modul und der folgenden dmsg = K11130200 getestet:

- dispatch 1:
  das CUL_WS Modul wird in der matchlist Schleife geladen
  in der events und fhemlog Ausgabe steht nun

Code Auswählen Erweitern

CUL_WS UNDEFINED temp/hum sensor detected, code 2
Global global UNDEFINED CUL_WS_2 CUL_WS 2

Da das ".clientArray" nicht gelöscht wurde, steht das CUL_WS Modul nicht im ".clientArray"

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

- löschen des  ".clientArray"

- dispatch
  es wird computeClientArray aufgerufen und das CUL_WS Modul steht im  ".clientArray"
  im log steht nun

Code Auswählen Erweitern

2022.01.20 18:03:36.507 2 : SYSTEM sduinoD: clientloop0 m=CUL_WS
2022.01.20 18:03:36.507 1 : CUL_WS UNDEFINED temp/hum sensor detected, code 2
2022.01.20 18:03:36.507 2 : SYSTEM sduinoD: clientloop1 m=CUL_WS tfound=UNDEFINED CUL_WS_2 CUL_WS 2
2022-01-20 18:03:36.509 Global global UNDEFINED CUL_WS_2 CUL_WS 2

Bei den folgenden dispatch erfolgt nun das Autocreate

[rudolfkoenig]

Ich habs mit dem CUL_WS Modul und der folgenden dmsg = K11130200 getestet:

Danke, das reicht mir.

Ich habe mit FHT und MQTT2_DEVICE getestet, hier wird IODev gesetzt, was clientArray auch zuruecksetzt, deswegen habe ich keine Probleme gesehen.

Ich habe das jetzt durch verschieben der delete Zeile auch fuer "IODev-lose" Geraete gefixt.

[Sidey]

Danke, habs eingecheckt. Bei CUL ist der Zeitersprarnis 80% wenn ein Modul neu geladen wurde.

Top. Ich hätte da noch die ein oder andere ähnliche gelagerte Idee

Statt patch zu bauen waere viel sinnvoller einen Testfall zu konstruiren, womit ich das Problem nachstellen kann.

Ja das stimmt. Ich hatte einen meiner Autocreate Tests um ein Print vom Clientarray ergänzt, ich kann aber durchaus mal ein Test erstellen.

[rudolfkoenig]

Bei CUL ist der Zeitersprarnis 80% wenn ein Modul neu geladen wurde.

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

ich kann aber durchaus mal ein Test erstellen.

Ich hoffe das hat sich mit der vorherigen Aenderung erledigt.