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 (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 (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 (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.
Hallo Martin,
damit Verbunden noch ein Änderungswunsch für CUL_HM_Parse:
am Ende des Abschnitts
elsif($mh{st} =~ m /^(motionDetector|motionAndBtn)$/) { ######################
in CUL_HM_Parse:
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:
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.
Hallo Martin,
der angedachte Trick mit dem zusätzlich ACK beim "threeStateSensor" scheint erfolgversprechend.
In dem Abschnitt habe ich mal
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 (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 (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.