HM-SEC-SC-2 und aesCommReq Protokollabweichung mit CUL

[noansi]

Hallo Martin, hallo Michael,

beim HM-SEC-SC-2 gibt es ein Problem mit CUL_HM bei aktivem aesCommReq, Bytechanger hat das Problem.

Hier das, was mit CUL gesendet wird und womit der Fensterkontakt bezüglich der Antwort nicht glücklich ist, trotz wunderbarem Timing und aesCommToDev ok.
https://forum.fhem.de/index.php/topic,24436.msg674031.html#msg674031

Hier mal mitgelauscht, was HMLAN macht:
https://forum.fhem.de/index.php/topic,24436.msg674048.html#msg674048
EDIT:
und hier noch eine Variante mit AES doch für beide Vorgänge!
https://forum.fhem.de/index.php/topic,24436.msg674064.html#msg674064

Das ist definitv anders mit HMLAN.

Beim Öffnen kommt nur ein Kontakt ACK ohne Signierungsanforderung von HMLAN.

HMLAN macht AES-Signierungsanforderung nur beim Schliessen. beim Öffnen und beim Schließen.
Und die Signierung enthält nicht die Kontaktquittierung, sondern wohl nur ein mit authbytes ergänztes ACK gefolgt von einem Kontakt ACK.

Da kann ich mit Firmware und TSCUL nichts dran machen, sondern das muss in CUL_HM korrigiert werden.

Ich denke Bytechanger wird gerne testen, wenn Ihr keine Testkandidaten habt.

Danke,

Ansgar.

[noansi]

Hallo Martin,

damit Verbunden noch ein Änderungswunsch für CUL_HM_Parse:

am Ende des Abschnitts

Code Auswählen Erweitern

  elsif($mh{st} =~ m /^(motionDetector|motionAndBtn)$/) { ######################
in CUL_HM_Parse:

Code Auswählen Erweitern

    if($ioId eq $mh{dst} && $mh{mFlgH}&0x20 && $state){
      push @ack,$mh{shash},$mh{mNo}."8002".$ioId.$mh{src}."0101".$state."00";
      $mh{AckDone} = 1;  #noansi: mark allready done device specific
    }


fast am Ende von CUL_HM_Parse:

Code Auswählen Erweitern

  elsif($ioId eq $mh{dst}){# if fhem is destination check if we need to react
    if(!$mh{AckDone} &&       #noansi: allready done device specific
       $mh{mTp} =~ m/^4./ &&  #Push Button event
       ($mh{mFlgH} & 0x20)){  #response required Flag
                # fhem CUL shall ack a button press
      if ($mh{md} =~ m/^(HM-SEC-SC.*|Roto_ZEL-STG-RM-FFK)$/){# SCs - depending on FW version - do not accept ACK only. Especially if peered
        push @ack,$mh{shash},$mh{mNo}."8002".$mh{dst}.$mh{src}."0101".((hex($mI[0])&1)?"C8":"00")."00";
      }
      else{
        push @ack,$mh{shash},$mh{mNo}."8002$mh{dst}$mh{src}"."00";
      }
      Log3 $mh{devN},5,"CUL_HM $mh{devN} prep ACK for $mI[0]";
    }
  }


Mit dem zusätzlichen $mh{AckDone} läßt sich ein selektives ACK für Kontakttrigger (oder andere) effizient umsetzen.

Die Änderung habe ich für meinen HM-SEN-MDIR-SM Firmware 1.6 eingebaut, weil der das sonst erzeugte zusätzlich ACK nicht benötigt um glücklich zu sein und es nur gestört hat. Mit aesCommReq=1 erfolgreich getestet.

Ähnlich könnte man es für das Fensterkontaktproblem lösen. Vielleicht reicht es, erst ein ACK und dann ein ACK mit Kontakt zu senden, falls ergänzte authbytes nicht stören?

Gruß, Ansgar.

[noansi]

Hallo Martin,

der angedachte Trick mit dem zusätzlich ACK beim "threeStateSensor" scheint erfolgversprechend.

In dem Abschnitt habe ich mal

Code Auswählen Erweitern

  elsif($mh{st} eq "threeStateSensor") { ######################################
    #Event:      mTp=0x41 p(..)(..)(..)     channel   , unknown, state
    #Info Level: mTp=0x10 p(..)(..)(..)(..) subty=06, chn, state,err (3bit)
    #AckStatus:  mTp=0x02 p(..)(..)(..)(..) subty=01, chn, state,err (3bit)
    my ($chn,$state,$err,$cnt); #define locals
    if(($mh{mTyp} eq "0201") ||
       ($mh{mTyp} eq "1006")) {
      ($chn,$state,$err) = (hex($mI[1]), $mI[2], hex($mI[3]));
      $chn = sprintf("%02X",$chn&0x3f);
      $mh{shash} = $modules{CUL_HM}{defptr}{"$mh{src}$chn"}
                             if($modules{CUL_HM}{defptr}{"$mh{src}$chn"});
      push @evtEt,[$mh{devH},1,"alive:yes"];
      push @evtEt,[$mh{devH},1,"battery:". (($err&0x80)?"low"  :"ok"  )];
      if (  $mh{md} =~ m/^(HM-SEC-SC.*|HM-SEC-RHS|Roto_ZEL-STG-RM-F.K)$/){
                                 push @evtEt,[$mh{devH},1,"sabotageError:".(($err&0x0E)?"on"   :"off")];}
      elsif($mh{md} ne "HM-SEC-WDS"){push @evtEt,[$mh{devH},1,"cover:"        .(($err&0x0E)?"open" :"closed")];}
    }
    elsif($mh{mTp} eq "41"){
      ($chn,$cnt,$state)=(hex($1),$2,$3) if($mh{p} =~ m/^(..)(..)(..)/);
      my $err = $chn & 0x80;
      $chn = sprintf("%02X",$chn & 0x3f);
      $mh{shash} = $modules{CUL_HM}{defptr}{"$mh{src}$chn"}
                             if($modules{CUL_HM}{defptr}{"$mh{src}$chn"});
      push @evtEt,[$mh{devH},1,"battery:". ($err?"low"  :"ok"  )];

      push @ack,$mh{shash},$mh{mNo}."8002".$mh{dst}.$mh{src}."00"; #noansi: test for Bytechanger
    }
    if (defined($state)){# if state was detected post events

um den push @ack ergänzt.

Hier https://forum.fhem.de/index.php/topic,24436.msg674254.html#msg674254 der Hinweis auf
einen "glücklichen" Fensterkontakt.

Hier https://forum.fhem.de/index.php/topic,24436.msg674105.html#msg674105 ist die CUL_HM mit den Änderungen zu finden.

Es bleibt also die Frage, ob andere Firmwarestände damit auch leben können.

Und es bleibt das leidige Thema Timing und FHEM Geschwindigkeit...

Gruß, Ansgar.