Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39

[noansi]

Hallo Frank,

ich habe Deine Änderung mal getestet und wie erwartet, ist es meinen HM-SEC-SC-2 mit Firmware 2.4 völlig schnuppe, ob ein 0101C800 Ack oder der zum Kontakt-Status passende gesendet wird.
Beim vorherigen Auto-Ack werden sie schon aufhören zu lauschen.

Hast Du ein zum Kommentar passendes Problem device oder anderes Logging zur Frage?

Gruß, Ansgar.

Edit: Die Log Zeile würde ich ganz eliminieren.

[noansi]

Hallo Frank,

Martin hat den Code

Code: [Auswählen]

      if ($md =~ m/HM-SEC-SC/){
        push @ack,$shash,$mNo."8002".$dst.$src."0101".((hex($mI[0])&1)?"C8":"00")."00";
      }
      else{
        push @ack,$shash,$mNo."8002$dst$src"."00";
      }
in Revision 5678 manifestiert.
In der Revision 5640 noch angedacht, weil auskommentiert:

Code: [Auswählen]

#      if($mFlgH & 0x02){
        push @ack,$shash,$mNo."8002$dst$src"."00";
#      }
#      else{
#        push @ack,$shash,$mNo."8002".$dst.$src."0101".((hex($mI[0])&1)?"C8":"00")."00";
#      }
Das war gegen Ende April 2014.

Und ist wohl hierraus entstanden, was kurz davor war:

Code: [Auswählen]

  elsif($ioId eq $dst){# if fhem is destination check if we need to react
    if($mTp =~ m/^4./ && $p =~ m/^(..)/ &&  #Push Button event
       (hex($mFlg)&0x20)){  #response required Flag
      my ($recChn) = (hex($1));# button number/event count
                # fhem CUL shall ack a button press
#      push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
      push @ack,$shash,$mNo."8002$dst$src"."00";
      Log3 $name,5,"CUL_HM $name prep ACK for $recChn";
    }
  }
in diesem Zusammenhang https://forum.fhem.de/index.php/topic,22571.0.html oder diesem https://forum.fhem.de/index.php/topic,22337.0.html und bestimmt diesem https://forum.fhem.de/index.php/topic,22688.0.html.

Hier https://forum.fhem.de/index.php/topic,22688.msg163155.html#msg163155 kommt wohl der Kommentar her.
Und hier https://forum.fhem.de/index.php/topic,22688.msg189688.html#msg189688 der ROTO_ZEL-STG-RM-FFK.

Anscheinend ein Überbleibsel aus Stochern im Nebel.

Dein Vorschlag sieht sinnvoller aus, wurde offenbar nicht getestet.
Was sagt Dein Vergleichslogging?

Gruß, Ansgar.

[frank]

hallo ansgar,
ich verspüre tatendrang bei dir. 

nur mal kurz:
- echte probleme hatte ich wohl damit nicht.
- es war eher ein zufallsfund auf der suche nach einer erklärung für den ausfall der verbindung meines cul https://forum.fhem.de/index.php/topic,129073.msg1234142.html#msg1234142

vorher, nachher über cul:

Code: [Auswählen]

2022.09.15 10:19:53.067 4 : CUL_Parse: cul868 A 0C 1F A441 1DE620 1ACE1F 0104C80F -66.5
2022.09.15 10:19:53.070 5 : cul868: dispatch A0C1FA4411DE6201ACE1F0104C8::-66.5:cul868
2022.09.15 10:19:53.109 5 : cul868 sending As0A1F80021ACE1F1DE62000
2022.09.15 10:19:53.110 5 : CUL 1DE620 dly:58ms
2022.09.15 10:19:53.170 5 : DevIo_SimpleWrite cul868: As0A1F80021ACE1F1DE62000
2022.09.15 10:19:53.198 5 : cul868 sending As0D1F80021ACE1F1DE6200101C800
2022.09.15 10:19:53.199 5 : CUL 1DE620 dly:30ms
2022.09.15 10:19:53.230 5 : DevIo_SimpleWrite cul868: As0D1F80021ACE1F1DE6200101C800
2022.09.15 10:19:53.264 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 1F A4 41 1DE620 1ACE1F 0104C8
2022.09.15 10:19:53.267 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 1F 80 02 1ACE1F 1DE620 00
2022.09.15 10:19:53.272 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE4855 d:FF r:FFC3     m:1F A441 1DE620 1ACE1F 0104C8
2022.09.15 10:19:53.275 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FFE48D8 d:FF r:FFD6     m:1F 8002 1ACE1F 1DE620 00
2022.09.15 10:19:53.278 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FFE4916 d:FF r:FFD6     m:1F 8002 1ACE1F 1DE620 0101C800
2022.09.15 10:19:53.284 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 1F 80 02 1ACE1F 1DE620 0101C800
2022.09.15 10:19:53.320 4 : CUL_Parse: cul868 A 0C 20 A041 1DE620 1A164B 0104C812 -65
2022.09.15 10:19:53.321 5 : cul868: dispatch A0C20A0411DE6201A164B0104C8::-65:cul868
2022.09.15 10:19:53.399 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 20 A0 41 1DE620 1A164B 0104C8
2022.09.15 10:19:53.403 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE4950 d:FF r:FFC2     m:20 A041 1DE620 1A164B 0104C8
2022.09.15 10:19:53.445 4 : CUL_Parse: cul868 A 0E 20 8002 1A164B 1DE620 0101C8403208 -70
2022.09.15 10:19:53.446 5 : cul868: dispatch A0E2080021A164B1DE6200101C84032::-70:cul868
2022.09.15 10:19:53.495 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 20 80 02 1A164B 1DE620 0101C84032
2022.09.15 10:19:53.563 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FFE49CE d:FF r:FFBE     m:20 8002 1A164B 1DE620 0101C84032
2022.09.15 10:19:53.645 4 : CUL_Parse: cul868 A 0D 21 A410 1A164B 1ACE1F 0601C84008 -70
2022.09.15 10:19:53.646 5 : cul868: dispatch A0D21A4101A164B1ACE1F0601C840::-70:cul868
2022.09.15 10:19:53.699 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 21 A4 10 1A164B 1ACE1F 0601C840
2022.09.15 10:19:53.703 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FFE4A96 d:FF r:FFBE     m:21 A410 1A164B 1ACE1F 0601C840
2022.09.15 10:19:53.766 4 : CUL_Parse: cul868 A 0A 21 8002 1ACE1F 1A164B 0052 -33
2022.09.15 10:19:53.768 5 : cul868: dispatch A0A2180021ACE1F1A164B00::-33:cul868
2022.09.15 10:19:53.773 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1A msg: 21 80 02 1ACE1F 1A164B 00
2022.09.15 10:19:55.318 4 : CUL_Parse: cul868 A 0C 21 A441 1DE620 1ACE1F 0105000C -68
2022.09.15 10:19:55.321 5 : cul868: dispatch A0C21A4411DE6201ACE1F010500::-68:cul868
2022.09.15 10:19:55.369 5 : cul868 sending As0A2180021ACE1F1DE62000
2022.09.15 10:19:55.370 5 : CUL 1DE620 dly:50ms
2022.09.15 10:19:55.421 5 : DevIo_SimpleWrite cul868: As0A2180021ACE1F1DE62000
2022.09.15 10:19:55.453 5 : cul868 sending As0D2180021ACE1F1DE6200101C800
2022.09.15 10:19:55.454 5 : CUL 1DE620 dly:26ms
2022.09.15 10:19:55.481 5 : DevIo_SimpleWrite cul868: As0D2180021ACE1F1DE6200101C800
2022.09.15 10:19:55.515 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE511F d:FF r:FFC4     m:21 A441 1DE620 1ACE1F 010500
2022.09.15 10:19:55.520 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 30 msg: 21 A4 41 1DE620 1ACE1F 010500
2022.09.15 10:19:55.524 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 21 80 02 1ACE1F 1DE620 00
2022.09.15 10:19:55.528 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 21 80 02 1ACE1F 1DE620 0101C800
2022.09.15 10:19:55.539 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FFE51E2 d:FF r:FFD6     m:21 8002 1ACE1F 1DE620 0101C800
2022.09.15 10:19:55.663 4 : CUL_Parse: cul868 A 0C 22 A041 1DE620 1A164B 01050017 -62.5
2022.09.15 10:19:55.665 5 : cul868: dispatch A0C22A0411DE6201A164B010500::-62.5:cul868
2022.09.15 10:19:55.748 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 22 A0 41 1DE620 1A164B 010500
2022.09.15 10:19:55.751 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 22 80 02 1A164B 1DE620 0101000031
2022.09.15 10:19:55.792 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE521B d:FF r:FFC0     m:22 A041 1DE620 1A164B 010500
2022.09.15 10:19:55.794 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FFE5299 d:FF r:FFBF     m:22 8002 1A164B 1DE620 0101000031
2022.09.15 10:19:55.869 4 : CUL_Parse: cul868 A 0E 22 8002 1A164B 1DE620 01010000310B -68.5
2022.09.15 10:19:55.871 5 : cul868: dispatch A0E2280021A164B1DE6200101000031::-68.5:cul868

######################### repariert

2022.09.15 12:35:12.467 4 : CUL_Parse: cul868 A 0C 25 A441 1DE620 1ACE1F 0106C821 -57.5
2022.09.15 12:35:12.469 5 : cul868: dispatch A0C25A4411DE6201ACE1F0106C8::-57.5:cul868
2022.09.15 12:35:12.502 5 : cul868 sending As0A2580021ACE1F1DE62000
2022.09.15 12:35:12.504 5 : CUL 1DE620 dly:64ms
2022.09.15 12:35:12.569 5 : DevIo_SimpleWrite cul868: As0A2580021ACE1F1DE62000
2022.09.15 12:35:12.596 5 : cul868 sending As0D2580021ACE1F1DE6200101C800
2022.09.15 12:35:12.597 5 : CUL 1DE620 dly:31ms
2022.09.15 12:35:12.629 5 : DevIo_SimpleWrite cul868: As0D2580021ACE1F1DE6200101C800
2022.09.15 12:35:12.662 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A3259 d:FF r:FFCE     m:25 A441 1DE620 1ACE1F 0106C8
2022.09.15 12:35:12.664 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A32DD d:FF r:FFD6     m:25 8002 1ACE1F 1DE620 00
2022.09.15 12:35:12.670 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 25 A4 41 1DE620 1ACE1F 0106C8
2022.09.15 12:35:12.673 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 25 80 02 1ACE1F 1DE620 00
2022.09.15 12:35:12.676 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 25 80 02 1ACE1F 1DE620 0101C800
2022.09.15 12:35:12.681 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A331B d:FF r:FFD6     m:25 8002 1ACE1F 1DE620 0101C800
2022.09.15 12:35:12.717 4 : CUL_Parse: cul868 A 0C 26 A041 1DE620 1A164B 0106C821 -57.5
2022.09.15 12:35:12.718 5 : cul868: dispatch A0C26A0411DE6201A164B0106C8::-57.5:cul868
2022.09.15 12:35:12.798 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A3354 d:FF r:FFCD     m:26 A041 1DE620 1A164B 0106C8
2022.09.15 12:35:12.801 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 26 A0 41 1DE620 1A164B 0106C8
2022.09.15 12:35:12.843 4 : CUL_Parse: cul868 A 0E 26 8002 1A164B 1DE620 0101C8403705 -71.5
2022.09.15 12:35:12.845 5 : cul868: dispatch A0E2680021A164B1DE6200101C84037::-71.5:cul868
2022.09.15 12:35:12.945 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:307A33D2 d:FF r:FFBD     m:26 8002 1A164B 1DE620 0101C84037
2022.09.15 12:35:12.970 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 26 80 02 1A164B 1DE620 0101C84037
2022.09.15 12:35:13.210 4 : CUL_Parse: cul868 A 0D 27 A410 1A164B 1ACE1F 0601C84004 -72
2022.09.15 12:35:13.211 5 : cul868: dispatch A0D27A4101A164B1ACE1F0601C840::-72:cul868
2022.09.15 12:35:13.268 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:307A3540 d:FF r:FFBD     m:27 A410 1A164B 1ACE1F 0601C840
2022.09.15 12:35:13.288 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 27 A4 10 1A164B 1ACE1F 0601C840
2022.09.15 12:35:13.330 4 : CUL_Parse: cul868 A 0A 27 8002 1ACE1F 1A164B 0051 -33.5
2022.09.15 12:35:13.331 5 : cul868: dispatch A0A2780021ACE1F1A164B00::-33.5:cul868
2022.09.15 12:35:13.337 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1A msg: 27 80 02 1ACE1F 1A164B 00
2022.09.15 12:35:17.716 4 : CUL_Parse: cul868 A 0C 27 A441 1DE620 1ACE1F 01070022 -57
2022.09.15 12:35:17.719 5 : cul868: dispatch A0C27A4411DE6201ACE1F010700::-57:cul868
2022.09.15 12:35:17.755 5 : cul868 sending As0A2780021ACE1F1DE62000
2022.09.15 12:35:17.757 5 : CUL 1DE620 dly:61ms
2022.09.15 12:35:17.819 5 : DevIo_SimpleWrite cul868: As0A2780021ACE1F1DE62000
2022.09.15 12:35:17.845 5 : cul868 sending As0D2780021ACE1F1DE62001010000
2022.09.15 12:35:17.846 5 : CUL 1DE620 dly:31ms
2022.09.15 12:35:17.879 5 : DevIo_SimpleWrite cul868: As0D2780021ACE1F1DE62001010000
2022.09.15 12:35:17.912 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A46DC d:FF r:FFCA     m:27 A441 1DE620 1ACE1F 010700
2022.09.15 12:35:17.915 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A4760 d:FF r:FFD6     m:27 8002 1ACE1F 1DE620 00
2022.09.15 12:35:17.921 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 27 A4 41 1DE620 1ACE1F 010700
2022.09.15 12:35:17.924 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 27 80 02 1ACE1F 1DE620 00
2022.09.15 12:35:17.927 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 27 80 02 1ACE1F 1DE620 01010000
2022.09.15 12:35:17.932 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A479E d:FF r:FFD6     m:27 8002 1ACE1F 1DE620 01010000
2022.09.15 12:35:17.967 4 : CUL_Parse: cul868 A 0C 28 A041 1DE620 1A164B 01070024 -56
2022.09.15 12:35:17.969 5 : cul868: dispatch A0C28A0411DE6201A164B010700::-56:cul868
2022.09.15 12:35:18.046 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A47D8 d:FF r:FFCA     m:28 A041 1DE620 1A164B 010700
2022.09.15 12:35:18.050 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 28 A0 41 1DE620 1A164B 010700
2022.09.15 12:35:18.094 4 : CUL_Parse: cul868 A 0E 28 8002 1A164B 1DE620 010100003907 -70.5
2022.09.15 12:35:18.095 5 : cul868: dispatch A0E2880021A164B1DE6200101000039::-70.5:cul868
2022.09.15 12:35:18.188 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:307A4856 d:FF r:FFBE     m:28 8002 1A164B 1DE620 0101000039
2022.09.15 12:35:18.214 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 28 80 02 1A164B 1DE620 0101000039


jetzt fehlt noch ein ausfiltern anderer io, da diese das zusätzliche ack nicht senden, zb hmuart:

Code: [Auswählen]

2022.09.15 09:32:29.015 4 : CUL_Parse: cul868 A 0C 1B A441 1DE620 1ACE1F 0102C842 -41
2022.09.15 09:32:29.016 5 : cul868: dispatch A0C1BA4411DE6201ACE1F0102C8::-41:cul868
2022.09.15 09:32:29.076 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FD2E0C8 d:FF r:FFD5     m:1B A441 1DE620 1ACE1F 0102C8
2022.09.15 09:32:29.081 0 : HMUARTLGW hmuart1 recv: 01 05 01 00 27 msg: 1B A4 41 1DE620 1ACE1F 0102C8
2022.09.15 09:32:29.224 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FD2E143 d:FF r:FFCE     m:1B 8002 1ACE1F 1DE620 00
2022.09.15 09:32:29.229 4 : CUL_Parse: cul868 A 0A 1B 8002 1ACE1F 1DE620 0048 -38
2022.09.15 09:32:29.230 5 : cul868: dispatch A0A1B80021ACE1F1DE62000::-38:cul868
2022.09.15 09:32:29.265 4 : CUL_Parse: cul868 A 0C 1C A041 1DE620 1A164B 0102C840 -42
2022.09.15 09:32:29.266 5 : cul868: dispatch A0C1CA0411DE6201A164B0102C8::-42:cul868
2022.09.15 09:32:29.318 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 1B 80 02 1ACE1F 1DE620 0101C800
2022.09.15 09:32:29.321 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FD2E1C3 d:FF r:FFD5     m:1C A041 1DE620 1A164B 0102C8
2022.09.15 09:32:29.324 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 26 msg: 1C A0 41 1DE620 1A164B 0102C8
2022.09.15 09:32:29.391 4 : CUL_Parse: cul868 A 0E 1C 8002 1A164B 1DE620 0101C84030F8 -78
2022.09.15 09:32:29.393 5 : cul868: dispatch A0E1C80021A164B1DE6200101C84030::-78:cul868
2022.09.15 09:32:29.474 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FD2E241 d:FF r:FFBE     m:1C 8002 1A164B 1DE620 0101C84030
2022.09.15 09:32:29.498 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: 1C 80 02 1A164B 1DE620 0101C84030
2022.09.15 09:32:29.522 4 : CUL_Parse: cul868 A 0D 1B 8002 1ACE1F 1DE620 0101C80048 -38
2022.09.15 09:32:29.523 5 : cul868: dispatch A0D1B80021ACE1F1DE6200101C800::-38:cul868
oder weisst du, wie man hmuart, hmlan überreden kann, ein ack zu senden, dass sie von selbst nicht senden?
sowas könnte ich an anderer stelle nämlich gut gebrauchen. 

eigentlich war mir ja dieses zusätzliche ack schon immer ein dorn im auge.
umso mehr, wenn nur der cul es kann und dieser sowieso nur wie ein 5. rad am wagen gemobt wird.

[noansi]

Hallo Frank,

wäre es nicht noch logischer mit

Code: [Auswählen]

          push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'01'$mI[1].$mI[2].'00';zu reparieren? Das würde komplett den Status spiegeln.
Testest Du mit einem SC-2 Fimware 2.2? Sonst ist die Testaussage anscheinend nichtig.

jetzt fehlt noch ein ausfiltern anderer io, da diese das zusätzliche ack nicht senden, zb hmuart:

In sub HMUARTLGW_Write($$$) gibt es

Code: [Auswählen]

if    ($mtype eq "02" && defined($hash->{Peers}{$dst}) &&
   length($msg) == 24 && $src eq $hash->{owner}) {
# Acks are generally send by HMUARTLGW autonomously
# Special
Log3($hash, 5, "HMUARTLGW ${name}: Skip ACK");
return;
}
elsif ($mtype eq "02" && defined($hash->{Peers}{$dst}) &&
   $src ne $hash->{owner}) {
Log3($hash, 0, "HMUARTLGW ${name}: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!");
return;
}

Auch in sub HMLAN_Write($$$)

Code: [Auswählen]

    if (   $mtype eq "02" && $src eq $hash->{owner} && length($msg) == 24
        && defined $hash->{helper}{ids}{$dst}){
      # Acks are generally send by HMLAN autonomously
      # Special
      Log3 $hash, 5, "HMLAN: Skip ACK";
      return;
    }

Damit kannst Du ergebnisoffen experimentieren, wenn Du einfache Acks doppelt senden möchtest. Aber eben nur von der IO eigenen HMID.
Den InfoAck hat der hmuart1 ja anscheinend gesendet, nur eben viel zu spät:

Code: [Auswählen]

2022.09.15 09:32:29.522 4 : CUL_Parse: cul868 A 0D 1B 8002 1ACE1F 1DE620 0101C80048 -38
denn das device hat schon vorher den nächsten gesendet:

Code: [Auswählen]

2022.09.15 09:32:29.324 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 26 msg: 1C A0 41 1DE620 1A164B 0102C8

Gruß, Ansgar.

[noansi]

Hallo Frank,

bei motionDetector und motionAndBtn gibt es auch den merkwürdigen AckInfo im Code.

Bei meinem HM-SEN-MDIR-SM FW V1.6 ist AckInfo überflüssig, bzw. das device ist nach LED grün Status mit einfachem Ack glücklich. Und wiederholt auch nicht.
Er ist mit einem VCCU Button gepeert. Das Verhalten ist auch unabhängig von aesCommReq.
Mehr Testkandidaten habe ich jedoch nicht.

Wie ist Deine Erfahrungslage bei motionDetector und motionAndBtn devices?

Gruß, Ansgar.

[exocet01]

Hallo exocet01,

in Deinem Log Auszug ist außer der Initialisierung des CUL kein Sendebefehl zu sehen.
Ein Y Kommando sollte auftauchen, ohne wird auf jeden Fall nichts gesendet.

Gruß, Ansgar.

Hallo Ansgar,

habe jetzt nochmal getestet:
Einmal habe ich versucht das Rollo über das Somfy Gerät zu steuern und einmal direkt über RAW Message. Geht beides nicht. Woraufhin ich mal eine Gegenüberstellun der TSCUL FW (funktioniert nicht) und CUL FW (funktioniert) erstellt habe:

Somfy Log (TS_CULV3):

Code: [Auswählen]

2022.09.18 11:09:13 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :on:  arg1 ::  pos :0:
2022.09.18 11:09:13 4: SOMFY_set: handled command on --> move :on:  newState :0:
2022.09.18 11:09:13 5: SOMFY_set: handled for drive/udpate:  updateState :200:  drivet :0: updatet :27:
2022.09.18 11:09:13 4: SOMFY_UpdateState: Rollo_1 enter with  newState:0:   updatestate:200:   move:on:
2022.09.18 11:09:13 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:0:  rounded:0:  stateTrans:open:
2022.09.18 11:09:13 4: SOMFY_sendCommand: Rollo_1 -> cmd :on:
2022.09.18 11:09:13 4: SOMFY_send Rollo_1 on: sAB4008C8000001
2022.09.18 11:09:13 5: SOMFY_send Rollo_1 enc key : AB  rolling code : 08C8
2022.09.18 11:09:13 4: SOMFY_set: Rollo_1 -> update state in 27 sec
2022.09.18 11:09:16 4: SOMFY_TimedUpdate
Somfy Log (CULV3):

Code: [Auswählen]

2022.09.18 01:39:29 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :on:  arg1 :200:  pos :0:
2022.09.18 01:39:29 4: SOMFY_set: handled command on --> move :on:  newState :0:
2022.09.18 01:39:29 5: SOMFY_set: handled for drive/udpate:  updateState :200:  drivet :0: updatet :27:
2022.09.18 01:39:29 4: SOMFY_UpdateState: Rollo_1 enter with  newState:0:   updatestate:200:   move:on:
2022.09.18 01:39:29 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:0:  rounded:0:  stateTrans:open:
2022.09.18 01:39:29 4: SOMFY_sendCommand: Rollo_1 -> cmd :on:
2022.09.18 01:39:29 4: SOMFY_send Rollo_1 on 200: sA74008C4000001
2022.09.18 01:39:29 5: SOMFY_send Rollo_1 enc key : A7  rolling code : 08C4
2022.09.18 01:39:29 4: SOMFY_set: Rollo_1 -> update state in 27 sec
2022.09.18 01:39:30 4: SOMFY Parse: Rollo_1 msg: YsA74808C4010000  --> 40-on   --> io is CUL
2022.09.18 01:39:32 4: SOMFY_TimedUpdate
RAW Message:
Der Befehl funktionierte nicht mit TSCUL FW. Nachdem ich aber auf CUL FW zurück flashte funktionierte er:

TSCUL Log:

TSCUL Log:
2022-09-18_11:16:04 CUL_0 raw YsAB4008C8000001
2022-09-18_11:31:48 CUL_0 Ints_per_sec: SI: 267.36030  TI: 30.12951  S: 81.89291  L: 11.94423  F: 17.18771  M: 2.77147

Global Log:
2022.09.18 11:16:05 4: SOMFY Parse: Rollo_1 msg: YsAB4808C8010000  --> 40-on   --> io is TSCUL

Ich hänge auch nochmal ein Bild von der Device Konfiguration an.

[noansi]

Hallo exocet01,

wenn Du loggst, dann bitte auch mit dem CUL auf verbose 5. Sonst kann ich nicht sehen, was an den CUL raus gegangen ist und was von ihm kommt.

Dann fällt mir noch auf, dass Du relativ viele Interrupts/s hast und damit relativ viel Störfeuer oder Rauschen empfängst.
Versuch mal, beim TSCUL CCAmode auf 0 zu setzen, nicht, dass es an Kanalbelegungserkennung scheitert.
Dafür würde auch sprechen, dass in Deinem SOMFY Log keine Rückmeldung zur Sendenachricht zu sehen ist.

Gruß, Ansgar.

[noansi]

Hallo exocet01,

versuch es bitte mal mit der 00_TSCUL.pm aus dem Anhang.
Das Y "verschwindet" bereits in der alten, so dass der CUL schon nur s... statt Ys... zu sehen bekommt.

Gruß, Ansgar.

[exocet01]

jetzt sieht das Log so aus (das Y kommt jetzt) und CCAmode ist auf 0:
Global Log:

Code: [Auswählen]

2022.09.19 21:02:23 4: WEB_192.168.178.33_55697 POST /fhem?cmd.Rollo_1=set%20Rollo_1%20auf&XHR=1&fwcsrf=csrf_164952049103182&fw_id=99; BUFLEN:0
2022.09.19 21:02:23 5: Cmd: >set Rollo_1 auf<
2022.09.19 21:02:23 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :off:  arg1 ::  pos :200:
2022.09.19 21:02:23 4: SOMFY_set: handled command off --> move :off:  newState :200:
2022.09.19 21:02:23 5: SOMFY_set: handled for drive/udpate:  updateState :0:  drivet :0: updatet :29:
2022.09.19 21:02:23 4: SOMFY_UpdateState: Rollo_1 enter with  newState:200:   updatestate:0:   move:off:
2022.09.19 21:02:23 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:200:  rounded:200:  stateTrans:closed:
2022.09.19 21:02:23 5: Starting notify loop for Rollo_1, 4 event(s), first is closed
2022.09.19 21:02:23 5: createNotifyHash
2022.09.19 21:02:23 5: Starting notify loop for Rolladenautomatik, 1 event(s), first is Rollo_1_PosValue: 200
2022.09.19 21:02:23 5: End notify loop for Rolladenautomatik
2022.09.19 21:02:23 5: Starting notify loop for Rolladenautomatik, 1 event(s), first is manual
2022.09.19 21:02:23 5: End notify loop for Rolladenautomatik
2022.09.19 21:02:23 5: Compute sunrise/sunset for latitude 48.30725403298442 , longitude 11.935535784027014
2022.09.19 21:02:23 5: Compute sunrise/sunset for latitude 48.30725403298442 , longitude 11.935535784027014
2022.09.19 21:02:23 5: End notify loop for Rollo_1
2022.09.19 21:02:23 4: SOMFY_sendCommand: Rollo_1 -> cmd :off:
2022.09.19 21:02:23 4: SOMFY_send Rollo_1 off: sA62008D3000001
2022.09.19 21:02:23 5: SOMFY_send Rollo_1 enc key : A6  rolling code : 08D3
2022.09.19 21:02:23 4: TSCUL_Write: CUL_0 sending YsA62008D3000001
2022.09.19 21:02:23 4: SOMFY_set: Rollo_1 -> update state in 29 sec
2022.09.19 21:02:23 4: WEB: /fhem?cmd.Rollo_1=set%20Rollo_1%20auf&XHR=1&fwcsrf=csrf_164952049103182&fw_id=99 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 / Cache-Control: no-cache, no-store, must-revalidate
2022.09.19 21:02:23 5: Starting notify loop for Rollo_1, 2 event(s), first is ASC_ShuttersLastDrive: manual
2022.09.19 21:02:23 5: End notify loop for Rollo_1
2022.09.19 21:02:24 5: Starting notify loop for myReadings, 3 event(s), first is kernel: 5.10.103-v7+
2022.09.19 21:02:24 5: End notify loop for myReadings
2022.09.19 21:02:24 5: TSCUL_Read CUL_0: /YsA62908D3010000
2022.09.19 21:02:24 4: TSCUL_Parse: CUL_0 YsA62908D3010000
2022.09.19 21:02:24 5: CUL_0: dispatch YsA62908D3010000
2022.09.19 21:02:24 4: SOMFY Parse: Rollo_1 msg: YsA62908D3010000  --> 20-off   --> io is TSCUL
2022.09.19 21:02:24 5: Starting notify loop for Rollo_1, 4 event(s), first is received: 20
2022.09.19 21:02:24 5: End notify loop for Rollo_1
2022.09.19 21:02:26 4: SOMFY_TimedUpdate
Aber trotz Verbose auf 5 wird im CUL Log kaum etwas geschrieben:

Code: [Auswählen]

2022-09-19_20:57:46 CUL_0 Xmit-Events: disconnected:1
2022-09-19_20:57:46 CUL_0 prot_disconnected: last
2022-09-19_20:57:48 CUL_0 cond: non-HM
2022-09-19_20:57:48 CUL_0 Xmit-Events: non-HM:1 disconnected:1
2022-09-19_20:57:48 CUL_0 prot_non-HM: last
2022-09-19_20:57:48 CUL_0 Initialized
2022-09-19_20:57:48 CUL_0 CONNECTED
2022-09-19_20:57:58 CUL_0 cond: non-HM
2022-09-19_20:57:58 CUL_0 Xmit-Events: non-HM:2 disconnected:1
2022-09-19_20:57:58 CUL_0 prot_non-HM: last
2022-09-19_20:59:05 CUL_0 CONNECTED

[frank]

hallo ansgar,

wäre es nicht noch logischer mit

Code: [Auswählen]

          push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'01'$mI[1].$mI[2].'00';zu reparieren? Das würde komplett den Status spiegeln.

im ackinfo ist das 2. byte aber hauptsächlich der channel => cul_hm_parsecommon/ackinfo.
ist meinem sc-1/fw2.0 aber auch egal, was da kommt.

Damit kannst Du ergebnisoffen experimentieren, wenn Du einfache Acks doppelt senden möchtest. Aber eben nur von der IO eigenen HMID.

danke fürs aufspüren der code abschnitte. die io eigene hmid ist an der stelle, die mich interessiert, leider nicht immer angesagt. deshalb mache ich es zur zeit nur mit cul.

Den InfoAck hat der hmuart1 ja anscheinend gesendet, nur eben viel zu spät:

oh ja, habe ich überssehen. der ack kommt wirklich spät, auch über hmlan.

wenn ich die timestamps vom hmlan nehme (t: ...), kommt das 1.ack 123ms nach dem trigger und das ackinfo weitere 278ms nach dem 1. ack, total 401ms nach dem trigger.
auch den send eintrag vom hmuart finde ich schon zu spät. bei "normalen" cmds kommt das "sofort" nach dem auslöser und hmlan/hmuart verzögern dann das senden bis die autonomen acks beendet sind.
ist diese verzögerung auch bei deinem hmuart zu sehen? diese verzögerung muss doch durch fhem kommen, oder?

Code: [Auswählen]

2022.09.19 11:06:53.856 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:44C3B420 d:FF r:FFD2     m:38 A441 1DE620 1ACE1F 010EC8
2022.09.19 11:06:53.859 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:44C3B49B d:FF r:FFD0     m:38 8002 1ACE1F 1DE620 00
2022.09.19 11:06:54.011 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 38 80 02 1ACE1F 1DE620 010EC800
2022.09.19 11:06:54.157 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:44C3B5B1 d:FF r:FFD0     m:38 8002 1ACE1F 1DE620 010EC800

Wie ist Deine Erfahrungslage bei motionDetector und motionAndBtn devices?

motion devices habe ich leider nicht.

[noansi]

Hallo exocet01,

ok, Ys... wird jetzt an den CUL geschickt, wie in Deinem oberen Log zu sehen ist.

Code: [Auswählen]

2022.09.19 21:02:23 4: TSCUL_Write: CUL_0 sending YsA62008D3000001Und auch die Antwort kommt, vom CUL.

Code: [Auswählen]

2022.09.19 21:02:24 5: TSCUL_Read CUL_0: /YsA62908D3010000
2022.09.19 21:02:24 4: TSCUL_Parse: CUL_0 YsA62908D3010000Demnach hat er auch was gesendet.

Aber das Rollo reagiert nicht, weil mir noch ein Fehler beim Senden des letzten Bytes aufgefallen ist.

Im Anhang eine neue Firmwaredatei und die geänderten FHEM Module, damit Du für den SlowRf Test auf Stand kommst.

Versuch es damit bitte nochmal.

Gruß, Ansgar.

[noansi]

Hallo Frank,

danke fürs aufspüren der code abschnitte. die io eigene hmid ist an der stelle, die mich interessiert, leider nicht immer angesagt. deshalb mache ich es zur zeit nur mit cul.

An Einschränkungen in der HMUARTLGW kann ich leider nichts ändern. HMID ständig anpassen? Ob das gut geht?

diese verzögerung muss doch durch fhem kommen, oder?

In 00_HMUARTLGW.pm gibt es in HMUARTLGW_Parse($$$$)

Code: [Auswählen]

if ($modules{CUL_HM}{defptr}{$src}) {
my $flgh = hex($flags);
my $wait = 0.100;
$wait += 0.200 if ($flgh & (1 << 5) && # BIDI
   $modules{CUL_HM}{defptr}{$src}->{IODev}->{TYPE} =~ m/^(?:TSCUL|HMUARTLGW)$/s);
$wait -= 0.044 if ($flgh & (1 << 6)); # received from Repeater

$wait -= $hash->{Helper}{RoundTrip}{Delay}
if (defined($hash->{Helper}{RoundTrip}{Delay}));

if ($wait > 0) {
my $nextSend = $recvtime + $wait;
$modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend} = $nextSend
if (!defined($modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend})   ||
$nextSend < $modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend} ||
($recvtime - $modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend}) > 0.09); # not allready set by previous IO
}
}
Was ich als Verzögerungsquelle verstanden habe. Also 300ms + sonstiger Verzögerungen bis dahin vom Trigger Empfang + weitere Verarbetung des {nextSend} bis Senden nach dem Auto-Ack..

ist diese verzögerung auch bei deinem hmuart zu sehen?

Mein Pi ist derzeit und normalerweise mit SCC bestückt. Ich teste/nutze lieber meine Firmware. Daran kann ich was ändern.

im ackinfo ist das 2. byte aber hauptsächlich der channel => cul_hm_parsecommon/ackinfo.

Stimmt auffallend. Aber der AckInfo müsste sich ja eigentlich auf einen ggf. gepeerten Channel der VCCU beziehen. Warum soll konstant 1 richtig sein?
Lässt sich nur mit einer der Problem FW Versionen genauer experimentell bestimmen, womit sie zufrieden wäre.

ist meinem sc-1/fw2.0 aber auch egal, was da kommt.

Ich hatte V2.2 als die problematischste aus der Historie verstanden.

Gruß, Ansgar.

[exocet01]

Hallo exocet01,

ok, Ys... wird jetzt an den CUL geschickt, wie in Deinem oberen Log zu sehen ist.

Code: [Auswählen]

2022.09.19 21:02:23 4: TSCUL_Write: CUL_0 sending YsA62008D3000001Und auch die Antwort kommt, vom CUL.

Code: [Auswählen]

2022.09.19 21:02:24 5: TSCUL_Read CUL_0: /YsA62908D3010000
2022.09.19 21:02:24 4: TSCUL_Parse: CUL_0 YsA62908D3010000Demnach hat er auch was gesendet.

Aber das Rollo reagiert nicht, weil mir noch ein Fehler beim Senden des letzten Bytes aufgefallen ist.

Im Anhang eine neue Firmwaredatei und die geänderten FHEM Module, damit Du für den SlowRf Test auf Stand kommst.

Versuch es damit bitte nochmal.

Gruß, Ansgar.

Funktioniert leider nicht. Rollos reagieren nicht
Aus dem CUL log kommt immer noch nichts und das ander log zeigt:

Code: [Auswählen]

2022.09.23 19:45:59 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :on:  arg1 ::  pos :200:
2022.09.23 19:45:59 4: SOMFY_set: handled command on --> move :on:  newState :200:
2022.09.23 19:45:59 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2022.09.23 19:45:59 4: SOMFY_UpdateState: Rollo_1 enter with  newState:200:   updatestate:<undef>:   move:on:
2022.09.23 19:45:59 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:200:  rounded:200:  stateTrans:closed:
2022.09.23 19:45:59 4: SOMFY_sendCommand: Rollo_1 -> cmd :on:
2022.09.23 19:45:59 4: SOMFY_send Rollo_1 on: sA04008DD000001
2022.09.23 19:45:59 5: SOMFY_send Rollo_1 enc key : A0  rolling code : 08DD
2022.09.23 19:45:59 4: TSCUL_Write: CUL_0 sending YsA04008DD000001
2022.09.23 19:46:00 5: TSCUL_Read CUL_0: /YsA04708DD010000

2022.09.23 19:46:00 4: TSCUL_Parse: CUL_0 YsA04708DD010000
2022.09.23 19:46:00 5: CUL_0: dispatch YsA04708DD010000
2022.09.23 19:46:00 4: SOMFY Parse: Rollo_1 msg: YsA04708DD010000  --> 40-on   --> io is TSCUL
2022.09.23 19:48:19 5: TSCUL_Read CUL_0: /CiE717221A56B3039B09C5024D391304FF

2022.09.23 19:51:42 3: set CUL_0 raw YsA04008DD000001
2022.09.23 19:51:43 5: TSCUL_Read CUL_0: /YsA04708DD010000

2022.09.23 19:51:43 4: TSCUL_Parse: CUL_0 YsA04708DD010000
2022.09.23 19:51:43 5: CUL_0: dispatch YsA04708DD010000
2022.09.23 19:51:43 4: SOMFY Parse: Rollo_1 msg: YsA04708DD010000  --> 40-on   --> io is TSCUL

Auffällig ist das mein 868 MHz CUL (TSCUL) FWV0.39 jetzt disconnected anzeigt

Gruß
Eckart

[noansi]

Hallo Eckart,

ok, danke für den Test. Da muss ich wohl nochmal über SOMFY intensiver drüber schauen. Vermutlich liegts noch am letzten Bit, mal sehen.

Aus dem CUL log kommt immer noch nichts und das ander log zeigt:

Dein CUL Log zeigt auch nur Events von Readings (für das aktuelle Problem derzeit nicht von Bedeutung). Nicht aber Log Einträge, die im Code erzeugt werden. Die landen im fhem log.
Ich sehe in Deinen "anderen" Log Daten, was ich zur CUL Kommunikation sehen will, das ist ok.

Auffällig ist das mein 868 MHz CUL (TSCUL) FWV0.39 jetzt disconnected anzeigt

Das ist korrekt. Die TSCUL aus der zip mag V0.40 bis V0.42. Jedoch nicht mehr die V0.39. Leider hast Du zu spät Feedback gegeben, als dass ich das noch mit meinen alten Ständen hätte in Einklang bringen können. War mir nich klar, dass Du auch einen 868 MHz CUL parallel hast.

Geh erst mal wieder auf die vorherigen Dateien und Standard culfw für den 433 Testkandidaten zurück.

Gruß, Ansgar.

[noansi]

Hallo Eckart,

im Anhang eine neue Testfirmware. Ich habe ihr eine VTS 0.40 verpasst, obwohl sie eigentlich eine VTS 0.41 ist, damit Du mit den älteren FHEM Modulen Somfy testen kannst. Also bitte auch nur dafür verwenden und nicht etwa für Deinen 868er.

Ich bin diesmal optimistischer, dass es besser klappt. Die Manchesterumsetzung hatte ihre Tücken.

Nebenbei habe ich noch bemerkt, dass sowohl in der Standard culfw, als auch in der a-culfw die frame-Pause zwischen den Wiederholungen viel zu kurz ausfällt, wegen fehlender Klammern in der betreffenden Sourcecode Zeile.

Code: [Auswählen]

my_delay_us(30415 + ((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half);Macht nicht in somfy_rts.c das von

Code: [Auswählen]

my_delay_us(30415 + (((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half));erwartete (falls Rudolf und Björn hier mal rein schauen).
Scheint, Deine Rollos aber anscheinend wenig zu stören.

Gruß, Ansgar.