panStamp support

rudolfkoenig · 25 Mai 2013, 18:57:21

> jeder panstamp wie in einem mesh network nachrichten erneut senden kann

Dann muss mAn das Firmware solche Duplikate filtern, bei FS20 werden ja auch nicht 3 Nachrichten zu fhem weitergereicht, weder vom FHZ noch vom culfw.

> das dimup/dimdown beispiel ist mir nicht ganz klar

Ich druecke die FS20 Fernbedienung etwas laenger, dann faengt dieser an dimup mit Abstand von etwa 0.3 Sekunden zu senden. Da das nicht mehr als FS20-Wiederholung von culfw erkannt wird, werden diese Befehle an fhem weitergegeben.
Falls die gleichen Daten von einem weiterem Empfaenger (CUL/FHZ) innerhalb von 0.5 Sekunden gemeldet werden, dann werden diese von fhem unterdrueckt im CheckDuplicate()

Wenn wir nach deinem Vorschlag die Geraete-Unterscheidung in CheckDuplicate() entfernen, dann kommt beim Benutzer nur ein einziges dimup an, und man kriegt nicht mal mit, wann man mit dimup aufgehoert hat.

Wg. FS20-KnowHow in CheckDuplikate:
- Korrekterweise muessten _alle_ Module, die Daten per Dispatch liefern, auch noch mitteilen, welcher Teil dieser Daten fuer ein Duplikatspruefung relevant ist. D.h. alle Module die Dispatch verwenden (17 Stueck) anpassen.
- Das schlimme daran: das ist nicht mal das Problem, da man eigentlich die komplette Nachricht pruefen koennte. Bloss war ich im 00_CUL.pm zu faul, und habe beim Nachstellen des FHZ Formats fuer FS20 und FHT die FHZ Checksumme nicht gefaelscht, weil FS20.pm und FHT.pm es nicht braucht. Deswegen habe ich es in CheckDuplikate gefiltert (war einfacher). D.h. wenn ich die FHZ-Checksumme in 00_CUL.pm berechne, kann man die "FS20"-Zeile in CheckDuplikate entfernen.

justme1968 · 25 Mai 2013, 21:11:32

Zitat von: rudolfkoenig schrieb am Sa, 25 Mai 2013 18:57> jeder panstamp wie in einem mesh network nachrichten erneut senden kann

Dann muss mAn das Firmware solche Duplikate filtern, bei FS20 werden ja auch nicht 3 Nachrichten zu fhem weitergereicht, weder vom FHZ noch vom culfw.

jein. vom konzept her sind die panstamps etwas dümmer als ein cul. d.h. der host macht etwas mehr. für das 'native' protokoll sollte es aber schon so sein. zur zeit tun sie das aber leider nicht.

Zitat von: rudolfkoenig schrieb am Sa, 25 Mai 2013 18:57> das dimup/dimdown beispiel ist mir nicht ganz klar

Ich druecke die FS20 Fernbedienung etwas laenger, dann faengt dieser an dimup mit Abstand von etwa 0.3 Sekunden zu senden. Da das nicht mehr als FS20-Wiederholung von culfw erkannt wird, werden diese Befehle an fhem weitergegeben.
Falls die gleichen Daten von einem weiterem Empfaenger (CUL/FHZ) innerhalb von 0.5 Sekunden gemeldet werden, dann werden diese von fhem unterdrueckt im CheckDuplicate()

Wenn wir nach deinem Vorschlag die Geraete-Unterscheidung in CheckDuplicate() entfernen, dann kommt beim benutzer nur ein einziges dimup an, und man kriegt nicht mal mit, wann man mit dimup aufgehoert hat.

verstanden. aber einfach lösbar in dem die fingerprint funktion mit angibt ob das das IODev relevant ist oder nicht.

Zitat von: rudolfkoenig schrieb am Sa, 25 Mai 2013 18:57Wg. FS20-KnowHow in CheckDuplikate:
- Korrekterweise muessten _alle_ Module, die Daten per Dispatch liefern, auch noch mitteilen, welcher Teil dieser Daten fuer ein Duplikatspruefung relevant ist. D.h. alle Module die Dispatch verwenden (17 Stueck) anpassen.
- Das schlimme daran: das ist nicht mal das Problem, da man eigentlich die komplette Nachricht pruefen koennte. Bloss war ich im 00_CUL.pm zu faul, und habe beim Nachstellen des FHZ Formats fuer FS20 und FHT die FHZ Checksumme nicht gefaelscht, weil FS20.pm und FHT.pm es nicht braucht. Deswegen habe ich es in CheckDuplikate gefiltert (war einfacher). D.h. wenn ich die FHZ-Checksumme in 00_CUL.pm berechne, kann man die "FS20"-Zeile in CheckDuplikate entfernen.

- ja aber eigentlich nicht (nur) die module die die daten für das dispatch liefern sondern (auch) die module die die daten per dispatch empfangen weil es vom protokoll abhängt und das IODev eigentlich nichts vom protokoll wissen sollte und auch gleichzeig mehrere protokolle (transparent) bedienen kann.

- das mit dem anpassen ist kein problem und einfach rückwärts kompatibel lösbar: wenn ein modul nichts angibt bleibt das verhalten so wie es ist und die ganze nachricht wird verwendet. man kann das sogar zweistufig machen. die fingerprint funktion kann entweder im IODev sein oder im parsenden modul.

- es ist noch nicht mal nötig die checksumme zu berechnen. es reicht wie bisher das fälschen. nur eben nicht in CheckDuplikate sondern in der fingerprint funktion im 00_CUL.

ich habe das gerade eben mal probehalber umgesetzt:

jedes modul das dispatch aufruft und jedes modul das parse anbietet kann optional eine fingerprint funktion haben:
für SWAP (protokoll ebene):

Code Auswählen

sub                           
SWAP_Initialize($)            
{
...
  $hash->{FingerprintFn}   = "SWAP_Fingerprint";
...
}

sub
SWAP_Fingerprint($$$)
{
  my ($hash, $name, $msg) = @_; 
 
  substr( $msg, 2, 2, "--" ); # ignore sender
  substr( $msg, 4, 1, "-" ); # ignore hop count

   # IODev is not relevant
   return ("",$msg);
}[/pre]

für CUL (IODev ebene):

Code Auswählen


CUL_Initialize($)            
{
...
  $hash->{FingerprintFn}   = "CUL_Fingerprint";
...
}

sub
CUL_Fingerprint($$$)
{
  my ($hash, $name, $msg) = @_; 

  # Store only the "relevant" part, as the CUL won't compute the checksum
  $msg = substr($msg, 8) if($msg =~ m/^81/ && length($msg) > 8);

  # IODev is relevant
  return ($name,$msg);
}

][/code]beide identisch.

der fs20 teil aus CheckDuplicate wird nicht mehr benötigt

CheckDuplicate ignoriert das IODev wenn es leer ist

Code Auswählen

  foreach my $oidx (keys %duplicate) {
    if($duplicate{$oidx}{TIM} < $lim) {
      delete($duplicate{$oidx});
 
    } elsif($duplicate{$oidx}{MSG} eq $msg &&
            $duplicate{$oidx}{ION} eq "") {
      return (1, $oidx);
 
    } elsif($duplicate{$oidx}{MSG} eq $msg &&
            $duplicate{$oidx}{ION} ne $ioname) {
      return (1, $oidx);
 
    }[/pre]

in Dispatch wird für das IODev die fingerprint funktion aufgerufen:

Code Auswählen

($ioname,$fingerprint) = &{$ffn}($hash,$name,$dmsg);

wenn es keine gibt -> CheckDuplicate wie bisher mit $name und $dmesg aufrufen
wenn es eine gibt die etwas zurück liefert -> CheckDuplicate wie bisher mit $ioname und $fingerprint aufrufen
wenn sie nichts zurüchliefert (ebenso wenn definiert aber leer)-> CheckDuplicate nicht jetzt am anfang aufrufen sondern später mit dem ergebniss der fingerprint funktion des devices an das die nachricht dispatched wird.

damit sind alle drei fälle abgedeckt. alle devices die nicht modifiziert werden verhalten sich wie bisher, alle devices die den fingerprint auf IODev ebene haben brauchen keine sonderbehandlung mehr in CheckDuplicate (das ist nur 00_CUL) und SWAP kann teile der nachricht auf protokoll ebene ausblenden.[/list]damit ist alles rückwärtskompatibel, es sind nur kleine änderungen an fhem.pl und einem modul (00_CUL) nötig und das SWAP modul kann die komplette CheckDuplicate infrastruktur mit verwenden ohne das code dupliziert wird.