Dispatch/Fingerprint: 36_PCA301 mit 00_CUL vs. 36_Jeelink Doublettenfehler

[KölnSolar]

Guten Morgen,
ich bin gestern bald an einem Problem verzweifelt.
Ziel ist es, die Steckdose PCA301 über den CUL(culfw) zu steuern und vorhandene Ressourcen zu nutzen.

Das funktioniert über Dispatch aus dem CUL heraus auch grundsätzlich, sprich, das device wird per autocreate angelegt.

Dann aber bleiben die updates aus. Es gibt keinerlei Logmeldungen. Dadurch fällt auf, dass bei jedem weiteren Datentelegramm vom CUL das 36_PCA301 gar nicht mehr aufgerufen wird. Ich hab dann festgestellt, dass das an der positiven "Doubletten"-Prüfung in der Dispatch-Funktion liegt. Ich gehe jetzt mal davon aus, dass die prinzipiell richtig funktioniert. Sieht man sich die Fingerprintfunktionen an, so fällt auf, dass scheinbar die Fingerprint-Funktion beim Jeelink in dessen logischen Modulen, die des CUL aber im physischen Modul stattfindet. Und das scheint sich jetzt in die Quere zu kommen, wenn ich mit dem CUL ein für den Jeelink entwickeltes logisches Modul nutzen möchte.

Konkrete Ausprägung der Fingerprint-Funktionen:
00_CUL      -  $msg = substr($msg, if($msg =~ m/^81/ && length($msg) > ;
IT, FS20     -  keine Fingerprintfunktionen
00_Jeelink  -  leere Fingerprintfunktion
PCA301      -  return ( "", $msg )
TRX            - Fingerprint weder in physikalischem, noch in logischen Modulen
Signalduino - Fingerprint in physikalischem Modul
Wenn ich in meinem Fall die Funktionalität aus der Fingerprint-Funktion des CUL ODER PCA301 entferne, funktioniert alles wie es soll(abgesehen natürlich von einer korrekten sinnvollen Doubletten-Prüfung.  )

Ich spekuliere daher mal, dass die Fingerprint-Funktionalität falsch angewandt wird oder es noch an einer Vorschrift/Standard fehlt, dass die Fingerprint-Funktion entweder nur in den physischen Modulen oder eben nur in den logischen Modulen vorhanden sein darf.

Wer kann helfen ? Müssen Module angepasst werden ?

Danke&Grüße
Markus

[rudolfkoenig]

- fingerprintFn gehoert ins Modul, der Dispatch aufruft.
- fingerprintFn liefert (evtl. modifiziert) die Input-Parameter zurueck: $ioname und $msg.
- $ioname eq "" bedeutet, dass $ioname bei der Duplikatpruefung irrelevant ist.
- Sonst werden nur solche als Duplikat markiert, die nicht vom aktuell meldenden Geraet kommen: z.Bsp. CUL/FS20/dim: vom gleichen IODev ist dim kein Duplikat

[KölnSolar]

Hallo Rudi,
danke Dir.

- fingerprintFn gehoert ins Modul, der Dispatch aufruft.

heißt dann aber doch, dass Andre das falsch in 36_Jeelink/36_PCA301 implementiert hat und ändern müsste, oder ?

Grüße Markus

[Markus Bloch]

Die FingerprintFn wird sowohl vom physischen, als auch vom logischen Modul aufgerufen, sofern entsprechend implementiert.

[rudolfkoenig]

...sofern entsprechend implementiert.

Danke fuer den Hinweis, das habe ich uebersehen.

[KölnSolar]

Hmmm, dann sind wir jetzt wieder bei meiner Fragestellung aus Post #1. 

Wo liegt der Fehler ?

[KölnSolar]

Hm, niemand eine Meinung 
ich könnt mir ja mit einer angepassten Kopie(36_PCA301_CUL) der 36_PCA301 behelfen. Finde das aber gelinde gesagt Irrsinn.
Grüße Markus

[justme1968]

das problem scheint in der tat die doppelte prüfung zu sein. die beiden durchläufte 'wissen' nicht das es in diesem fall keine doppelt empfange nachricht ist, sondern eine einzige nachricht die zwei mal geprüft wird.

ich habe gerade keine idee ob es hier überhaupt eine lösung gibt. stell dir vor du hast 2 cul und zwei jeelink im system. wie stellen wir sicher das keine nachricht mehrfach verarbeitet wird?

[KölnSolar]

Hallo Andre,
schön, dass Du Dich meldest.

stell dir vor du hast 2 cul und zwei jeelink im system. wie stellen wir sicher das keine nachricht mehrfach verarbeitet wird?

Ich dachte das wäre genau der Sinn des Fingerprint. 1st come, 1st serve. Die anderen 3 werden verworfen. Nur dadurch, dass es beim CUL im physischen Modul und beim Jeelink in den logischen Modulen steckt, gibt es Probleme. Bei Realisierung im physischen Jeelink-Modul  würde ich die gewünschte Funktionsweise erwarten.
Ich kenne nur die 4 im 1. Post genannten 2-stufigen Module. Gibt es andere mit Fingerprintfunktion ? Wie ist es dort umgesetzt ?
Grüße Markus

[justme1968]

ja. das ist der sinn. aber als es eingebaut wurde hat niemand den fall bedacht das es unterschiedliche ios gibt die das gleiche protokoll verstehen aber die routine auf unterschiedlichen ebenen aufrufen.

zur geschichte: ursprünglich gab es die fingerprint funktion nicht. der cul hat alle dubletten selber verworfen.

dann habe ich dir panstamps und das swap protokoll in fhem implementiert. bei swap ist es so das man das protokoll verstehen muss um dubletten zu erkennen. deshalb war es unbedingt nötig die erkennung in der zweiten stufe zu machen. in dem zuge ist dann die fingerprint funktion entstanden.

bei allen tests gab es aber immer nur mehrer ios vom gleichen typ. an einen misch betrieb hat niemand gedacht.

das führt jetzt dazu das die gleiche nachricht die ein einziges mal empfangen ist direkt hintereinander zwei mal durch die erkennung geschickt wird. beim zweiten mal schlägt die erkennung dann zu.

von der logik her bin ich auch der meinung es gehört in die zweite stufe.

vielleicht könnte man dispatch so ändern das das ergebnis der ersten stufe nur ausgewertet wird wenn es in der zweiten keine fingerprintFn gibt. 

das ist aber nicht ganz so einfach da es ja mehrere clients geben kann von denen nur manche eine fingerprintFn haben. und ich befürchte das geht wieder schief wenn man tatsächlich mehrere ios im mischbetrieb hat.

magst du mal testen ob es funktioniert wenn man die fingerprintFn der zweiten stufe mit einem zusätzlichen optionalen parameter aufruft der angibt ob es in der ersten stufe schon eine prüfung gab. dann kann man im pca modul nur prüfen wenn es vorher noch keine prüfung gab.

[KölnSolar]

Ich versteh natürlich wie immer nicht viel mehr als die Hälfte 

von der logik her bin ich auch der meinung es gehört in die zweite stufe.

Ich hätt jetzt gesagt in die 1., damit so früh wie möglich eine Doppelverarbeitung ausgeschlossen wird. 

magst du mal testen ob es funktioniert wenn man die fingerprintFn der zweiten stufe mit einem zusätzlichen optionalen parameter aufruft der angibt ob es in der ersten stufe schon eine prüfung gab. dann kann man im pca modul nur prüfen wenn es vorher noch keine prüfung gab.

Du überschätzt meine Fähigkeiten. Ich hab noch nicht einmal Testhardware dazu. Das ließe sich aber noch lösen. Ich hab aber die Dispatch-Funktion noch nicht wirklich durchschaut, dass ich mir zutrauen würde dort eine Veränderung vorzunehmen. Ich gucke....

[KölnSolar]

Hallo Andre,
das war vielleicht ein Kampf. Eine gedachte Lösung hatte ich recht schnell, nur, ich bekam den case nicht mehr nachgestellt. Und weißt Du woran es gelegen hatte: Ich hatte vergessen das PCA301 in die clients-list der 00_CUL aufzunehmen. Trotzdem hat alles perfekt funktioniert. Dann auch ohne das Doublettenproblem. Da ist doch dann noch etwas ganz anderes bei der 2-Stufigkeit im argen. Wieso hat das Dispatchen dann überhaupt funktioniert ?  Wozu gibt es denn sonst die clients-Liste, wenn nicht zum Dispatch bei der 2-Stufigkeit ? 

Ich hab die Dispatch-Funktion mit dem zusätzlichen Code in rot umgebaut, also nur dann die Fingerprintprüfung des logischen Moduls, wenn keine Fingerprintfunktion im physischen Modul vorhanden ist:

Code: [Auswählen]

Dispatch($$;$$)
{
  my ($hash, $dmsg, $addvals, $nounknown) = @_;
  my $module = $modules{$hash->{TYPE}};
  my $name = $hash->{NAME};

  if(GetVerbose($name) == 5) {
    Log3 $hash, 5, escapeLogLine("$name: dispatch $dmsg");
  }

  my ($isdup, $idx) = CheckDuplicate($name, $dmsg, $module->{FingerprintFn});
  return rejectDuplicate($name,$idx,$addvals) if($isdup);

  my @found;
  my $parserMod="";
  my $clientArray = $hash->{".clientArray"};
  $clientArray = computeClientArray($hash, $module) if(!$clientArray);

  foreach my $m (@{$clientArray}) {
    # Module is not loaded or the message is not for this module
    next if(!$modules{$m} || $dmsg !~ m/$modules{$m}{Match}/i);

    if( my $ffn = $modules{$m}{FingerprintFn} &&
   !$module->{FingerprintFn} ) {

Code: [Auswählen]

      ($isdup, $idx) = CheckDuplicate($name, $dmsg, $ffn);
      return rejectDuplicate($name,$idx,$addvals) if($isdup);
    }

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

  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}) {
        if($dmsg =~ m/$h->{$m}/) {
          my ($order, $mname) = split(":", $m);

          if(AttrVal("global", "autoload_undefined_devices", 1)) {
            my $newm = LoadModule($mname);
            $mname = $newm if($newm ne "UNDEFINED");
            if($modules{$mname} && $modules{$mname}{ParseFn}) {
              no strict "refs"; $readingsUpdateDelayTrigger = 1;
              @found = &{$modules{$mname}{ParseFn}}($hash,$dmsg);
              use strict "refs"; $readingsUpdateDelayTrigger = 0;
              $parserMod = $mname;
              last if(defined($found[0]));
            } else {
              Log 0, "ERROR: Cannot autoload $mname";
            }

          } else {
            Log3 $name, 3, "$name: Unknown $mname device detected, " .
                        "define one to get detailed information.";
            return undef;

          }
        }
      }
    }
    if((!int(@found) || !defined($found[0])) && !$nounknown) {
      DoTrigger($name, "UNKNOWNCODE $dmsg");
      Log3 $name, 3, "$name: Unknown code $dmsg, help me!";
      return undef;
    }
  }

  ################
  # Inform raw
  if(!$module->{noRawInform}) {
    foreach my $c (keys %inform) {
      if(!$defs{$c} || $defs{$c}{NR} != $inform{$c}{NR}) {
        delete($inform{$c});
        next;
      }
      next if($inform{$c}{type} ne "raw");
      syswrite($defs{$c}{CD}, "$hash->{TYPE} $name $dmsg\n");
    }
  }

  # Special return: Do not notify
  return undef if(!defined($found[0]) || $found[0] eq "");

  foreach my $found (@found) {

    if($found =~ m/^(UNDEFINED.*)/) {
      DoTrigger("global", $1);
      return undef;

    } else {
      if($defs{$found}) {
        if(!$defs{$found}{".noDispatchVars"}) { # CUL_HM special
          $defs{$found}{MSGCNT}++;
          my $avtrigger = ($attr{$name} && $attr{$name}{addvaltrigger});
          if($addvals) {
            foreach my $av (keys %{$addvals}) {
              $defs{$found}{"${name}_$av"} = $addvals->{$av};
              push(@{$defs{$found}{CHANGED}}, "$av: $addvals->{$av}")
                if($avtrigger);
            }
          }
          $defs{$found}{"${name}_MSGCNT"}++;
          $defs{$found}{"${name}_TIME"} = TimeNow();
          $defs{$found}{LASTInputDev} = $name;
        }
        delete($defs{$found}{".noDispatchVars"});
        DoTrigger($found, undef);
      } else {
        Log 1, "ERROR: >$found< returned by the $parserMod ParseFn is invalid,".
               " notify the module maintainer";
        return undef;
      }
    }
  }

  $duplicate{$idx}{FND} = \@found
        if(defined($idx) && defined($duplicate{$idx}));

  return \@found;
}


Ich könnt aber jetzt auch einfach das PCA301 in der clients-Liste weglassen... 

Was meinst Du ?
Grüße Markus

[justme1968]

schau dir im wiki noch mal an wie clients liste und MatchList funktionieren. rudi hat auch hier im forum noch mal den 'historischen' grund beschrieben warum es beides gibt und einen fallback wenn clients nicht reicht.

die idee war eher so:

Code: [Auswählen]

3800     if( my $ffn = $modules{$m}{FingerprintFn} ) {
3801       ($isdup, $idx) = CheckDuplicate($name, $dmsg, $ffn, $module->{FingerprintFn});
3802       return rejectDuplicate($name,$idx,$addvals) if($isdup);
3803     }
und in den zusätzlichen parameter dann an die client FingerprintFn durchreichen. und in pca301 dann etwas in der art:

Code: [Auswählen]

156 sub     
157 PCA301_Fingerprint($$$)
158 {       
159   my ($name, $msg, $done) = @_;
160         
161   return ( "", $name.':'.$msg ) if( $done );
162
163   return ( "", $msg );
164 }       

d.h. in pca301 wird ein anderer fingerprint zurück gegeben als in cul. damit wäre der fall abgedeckt das ein anwender mehrere gleiche io im einsatz hat.

für den tatsächlichen mischbetrieb habe ich leider noch keine idee.

[KölnSolar]

So meintest Du das mit dem Parameter  Dann müssten aber alle Module mit Fingerprint-Funktion angefasst werden.

Und so würde aber doch dann ein Jeelink ebenfalls die Daten neben dem CUL verarbeiten(was Du vermutlich mit

für den tatsächlichen mischbetrieb habe ich leider noch keine idee.

meintest) Dann lassen wir das noch reifen....

schau dir im wiki noch mal an wie clients liste und MatchList funktionieren.

Hab ich gemacht. Dann ist

Anhand einer bereitgestellten Client-Liste (Auflistung von logischen Modulen) kann FHEM feststellen, welche logischen Module mit dem physischen Modul kommunizieren können. Nur die hier aufgelisteten, logischen Module werden beim Aufruf von Dispatch() angesprochen.

der 1. Satz, naja, unglücklich. Was heißt schon konkret kann.  Aber das nur im 2. Satz ist doch dann falsch.

Viel wichtiger: Ich scheine da eine "allgemeine Lücke" in der Dispatchfunktion aufgedeckt zu haben, die ich sicherlich nicht im Stande bin zu lösen bzw. Änderungen in ihrer Auswirkung beurteilen zu können. Denke oder helfe aber gerne bei der Lösungsfindung.

Zurück zu meinem case: Es wird doch kaum jemand einen Jeelink UND einen CUL in einer Installation einsetzen, die beide nur für PCA301-Handling eingesetzt sind. Da es ja offensichtlich funktioniert, wäre doch die einfachste Lösung(zumindest vorerst), dass ich im CUL-Modul das PCA301 aus der Client-Liste raus lasse. Oder siehst Du da etwas, was dagegen spricht ?