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

[exocet01]

Hi Ansgar,

die Dose und Handsender sind immer auf den gleichen Code eingestellt. Da habe ich nichts verstellt. Mit dem Handsender kann ich die Dose immer zuverlässig ein- und ausschalten.

Hier mal die Logs:
Handsender Taste ON:

Code: [Auswählen]

2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /P03 376 984 272 1008 920 376 240 5 2 2 -45 414540

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 P03 376 984 272 1008 920 376 240 5 2 2 -45 414540
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /i0505153B

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 i0505153B -44.5
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /p04 240 9936 280 1008 912 368 288 0 3 0 -45 050515

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 p04 240 9936 280 1008 912 368 288 0 3 0 -45 050515
2022.10.06 19:35:10 5: CUL_0: dispatch i050515
2022.10.06 19:35:10 4: CUL_0 IT: message "i050515" (7)
2022.10.06 19:35:10 4: CUL_0 IT: msgcode "00FF00FF0FFF" (12) bin = 000001010000010100010101
2022.10.06 19:35:10 5: CUL_0 IT: V1 housecode = 00FF00FF0F  onoffcode = FF
2022.10.06 19:35:10 4: CUL_0 IT: 00FF00FF0F not defined (Switch code: FF), msg:i050515
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /i0575D53C

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 i0575D53C -44
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /p04 248 9928 280 1000 904 376 272 0 3 0 -44 0575D5

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 p04 248 9928 280 1000 904 376 272 0 3 0 -44 0575D5
2022.10.06 19:35:10 5: CUL_0: dispatch i0575d5
2022.10.06 19:35:10 4: CUL_0 IT: message "i0575d5" (7)
2022.10.06 19:35:10 4: CUL_0 IT: msgcode "00FFF1FF1FFF" (12) bin = 000001010111010111010101
2022.10.06 19:35:10 5: CUL_0 IT: V1 housecode = 00FFF1FF1F  onoffcode = FF
2022.10.06 19:35:10 4: CUL_0 IT: 00FFF1FF1F not defined (Switch code: FF), msg:i0575d5
Handsender Taste OFF:

Code: [Auswählen]

2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /P03 296 1024 288 992 888 400 272 5 2 2 -47 414500

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 P03 296 1024 288 992 888 400 272 5 2 2 -47 414500
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /i05051436

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 i05051436 -47
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /p04 272 9904 272 1008 920 360 320 0 3 0 -47 050514

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 p04 272 9904 272 1008 920 360 320 0 3 0 -47 050514
2022.10.06 19:36:39 5: CUL_0: dispatch i050514
2022.10.06 19:36:39 4: CUL_0 IT: message "i050514" (7)
2022.10.06 19:36:39 4: CUL_0 IT: msgcode "00FF00FF0FF0" (12) bin = 000001010000010100010100
2022.10.06 19:36:39 5: CUL_0 IT: V1 housecode = 00FF00FF0F  onoffcode = F0
2022.10.06 19:36:39 4: CUL_0 IT: 00FF00FF0F not defined (Switch code: F0), msg:i050514
2022.10.06 19:36:39 3: CUL_0 IT: For autocreate please use the on button.
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /i0575D539

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 i0575D539 -45.5
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /p04 272 9888 264 1008 920 376 256 0 3 0 -46 0575D5

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 p04 272 9888 264 1008 920 376 256 0 3 0 -46 0575D5
2022.10.06 19:36:39 5: CUL_0: dispatch i0575d5
2022.10.06 19:36:39 4: CUL_0 IT: message "i0575d5" (7)
2022.10.06 19:36:39 4: CUL_0 IT: msgcode "00FFF1FF1FFF" (12) bin = 000001010111010111010101
2022.10.06 19:36:39 5: CUL_0 IT: V1 housecode = 00FFF1FF1F  onoffcode = FF
2022.10.06 19:36:39 4: CUL_0 IT: 00FFF1FF1F not defined (Switch code: FF), msg:i0575d5
Jetzt klappt es!!! Ich denke der Fehler lag bei mir. Die Logs haben mir dabei geholfen :-). Der Handsender hat 2 An- und Aus-Schalter und die "Kanalwahl A,B,C,D". Wenn ich auf dem Handsender auch nur eine Dose an- oder ausschalten will, sendet er aber trotzdem auch für die zweite Dose. Nur so kann ich mir erklären das 2 Geräte angelegt werden. Außerdem habe ich die Dose direkt neben dem Raspi eingesteckt, wodurch anscheinend das Signal zu stark war und manchmal der Schaltwunsch vermutlich durch Übersteuerung nicht erkannt wurde.

[noansi]

Hallo Eckart,

schön, dass es jetzt besser ausschaut. 

Wenn Du noch das Attribut ITclock für die zu diesem Handsender gehörenden Dosen auf 312 oder 320 einstellst, dann sollte es vom CUL aus noch etwas besser klappen. Denn derzeit sendest Du mit dem Default von 416.

Der i0575d5 ist bei on und off gleich. Möglicherweise eine Art Abschlusscode für das oder ein transienter Code bei dem Taste Loslassen.

Mit set raw X27 beim CUL werden auch Wiederholungen des Handsenders geliefert. So lange Du eine Taste drückst, sollte der Code dazu kommen und wenn Du loslässt der i0575d5 Code, wenn die Vermutung zutrifft.

Gruß, Ansgar.

[yersinia]

Hallo noansi,

ich les' immer, dass die V0.39 sowas von völlig veraltet zu sein scheint, ua hier:

im Anhang noch eine neue als V0.40 "getarnte" Version der Firmware, damit auch der IT Empfang wieder klappt.

Habe ich irgendwas verpasst? Zumindest für meine nanoCULs finde ich nur die V0.39, und nichts neueres - mein letzter Stand ist immer noch der Anhang von #1264. Was hab ich übersehen?

Danke vorab.

[Bastel-Frank]

Hallo Ansgar,
Ich setze deine Firmware seit Jahren erfolgreich mit mehreren Cul's ein. Bisher habe ich diese per Raspi und Ser2net angebunden.
Da der Raspi immer schlechter verfügbar ist und mir schon mehrere ausgefallen sind, suche ich nach einer Lösung, deinen Cul direkt ins WLAN zu bringen, z.B. als Idee mit einem ESP. Hast du dazu eine Lösungsidee oder einen Vorschlag für mich?

Viele Grüße
Frank

[noansi]

Hallo yersinia,

nein, Du hast nichts verpasst.
Meine Zählung unveröffentlicher Zwischenstände ist nur weiter fortgeschritten.

Gruß, Ansgar.

[noansi]

Hallo Frank,

meine Meinung zu WLAN Anbindung habe ich hier https://forum.fhem.de/index.php/topic,24436.msg1234919.html#msg1234919 und hier https://forum.fhem.de/index.php/topic,24436.msg1235192.html#msg1235192 bereits kund getan.

Ist Ser2net auf den RasPi begrenzt? Ist doch eine Linux Lösung.

Gruß, Ansgar.

[frank]

hallo ansgar,
soweit ich sehe, hast du in deiner cul_hm auch folgendes problem, siehe https://forum.fhem.de/index.php/topic,129777.0.html

du hast doch sicher eine idee. 

gruss frank

[noansi]

Hallo Frank,

prep, ein Feature, dass ich noch nie benutzt habe. 

soweit ich sehe, hast du in deiner cul_hm auch folgendes problem

Ja, kann ich nachvollziehen.

du hast doch sicher eine idee.

Ja, nicht neu berechnen, sondern merken in einem Zusatzhelper in CUL_HM_pushConfig(), genau wie die shadowRegs.

Code: [Auswählen]

  $sdH->{helper}{shadowReg}{$regLNp} = $regs; # update shadow
  $sdH->{helper}{shadowRegChn}{$regLNp} = $chn; #noansi: save chn for later use, even with prep
#  Log 0,"CUL_HM_pushConfig $regs";
  my @changeList;
  if ($prep eq "exec"){#update complete registerset
    @changeList = keys%{$sdH->{helper}{shadowReg}};
  }
  elsif ($prep eq "prep"){
    return; #prepare shadowReg only. More data expected.
  }
  else{
    push @changeList,$regLNp;
  }
  my $changed = 0;# did we write
  foreach my $nrn(@changeList){
    my $change;
    my $nrRd = ReadingsVal($chnhash->{NAME},$regPre.$nrn,"");
    foreach (sort split " ",$sdH->{helper}{shadowReg}{$nrn}){
      $change .= $_." " if ($nrRd !~ m/$_/);# filter only changes
    }
    next if (!$change);#no changes
    $change =~ s/00:00//;
    $change =~ s/(\ |:)//g;
    if ($nrRd){
      $chnhash->{READINGS}{$regPre.$nrn}{VAL} =~ s/00:00//; #mark incomplete as we go for a change;
    }
    my $pN;
    $changed = 1;# yes, we did
    ($list,$pN) = ($1,$2) if($nrn =~ m/RegL_(..)\.(.*)/);
    if ($pN){($peerAddr,$peerChn) = unpack('A6A2', CUL_HM_name2Id($pN,$hash));}
    else       {($peerAddr,$peerChn) = ('000000','00');}

    if (AttrVal($chnhash->{NAME},"peerIDs","") =~ m/${peerAddr}00/){$peerChn = "00"}# if device we are not sure about device or channel. Check peers

    CUL_HM_updtRegDisp($hash,$list,$peerAddr.$peerChn);
    ############partition
#   my @chSplit = unpack('(A28)*',$change);
    $chn = $sdH->{helper}{shadowRegChn}{$nrn}; #noansi: use correct chn
    my @chSplit = unpack('(A1120)*',$change);# makes max 40 lines, 280 byte
Ob es sich lohnt, die helper dann auch wieder zu löschen, wenn die shadow Regs gelöscht werden...?

Gruß und Danke für den Hinweis, Ansgar.

[frank]

moin ansgar,

einfach, elegant und funktioniert.
endlich laufen die templates (wieder?) durch, danke.

prep, ein Feature, dass ich noch nie benutzt habe. 

das glaube ich nicht. 
bei HMdeviceTools.js nutzt du es im hintergrund automatisch beim zusammenklicken von registeränderungen (ist anschliessend auch in fhem.log zu sehen).
bei templates kommt es auch zum einsatz.

Ob es sich lohnt, die helper dann auch wieder zu löschen, wenn die shadow Regs gelöscht werden...?

zumindest sollten verbleibende helper keinen ärger machen, da die gespeicherten werte konstant bleiben.


hast du rt oder tc-it?
mich verwundert nämlich, dass die drei cmds so absurd unterschiedlich behandelt werden.

    foreach my $chSpl(@chSplit){
      my $mch = CUL_HM_lstCh($chnhash,$list,$chn);
      CUL_HM_PushCmdStack($hash, "++".$flag.'01'.$src.$dst.$mch.'05'.
                                          $peerAddr.$peerChn.$list);
      $tl = length($chSpl);
      for(my $l = 0; $l < $tl; $l+=28) {
        my $ml = $tl-$l < 28 ? $tl-$l : 28;
        CUL_HM_PushCmdStack($hash, "++A001".$src.$dst.$chn."08".
                                       substr($chSpl,$l,$ml));
      }
      CUL_HM_PushCmdStack($hash,"++A001".$src.$dst.$mch."06");
    }

[noansi]

Hallo Frank,

das glaube ich nicht. 

OK, nur Templisten für 2 RTs habe ich damit tatsächlich mal gesetzt. Bin aber dem Code nicht nachgekrochen, in welchen Funktionen das umgesetzt wird, da es geklappt hatte.

mich verwundert nämlich, dass die drei cmds so absurd unterschiedlich behandelt werden.

In CUL_HM_updateConfig($) gibt es die Vorbereitung für CUL_HM_lstCh als

Code: [Auswählen]

    if    ($md =~ m/^HM-CC-RT-DN/s){
      $hash->{helper}{shRegR}{'07'} = '00' if ($chn eq '04');# Reg List 7 read/write from/to device CH 0
      $hash->{helper}{shRegW}{'07'} = '04' if ($chn eq '00');# Reg List 7 write to CH 4 for display and use in fhem
    }
    elsif ($md =~ m/^HM-TC-IT-WM-W-EU/s){
      $hash->{helper}{shRegR}{'07'} = '00' if ($chn eq '02');# Reg List 7 read/write from/to device CH 0
      $hash->{helper}{shRegW}{'07'} = '02' if ($chn eq '00');# Reg List 7 write to CH 2 for display and use in fhem
    }
Hast Du da Protokollprobleme entdeckt?

Gruß, Ansgar.

Edit: Komentare korrigiert

[frank]

Hast Du da Protokollprobleme entdeckt?

nein, habe keine rt/tc.
ich hatte nur das gefühl, dass beim 08'er cmd eventuell auch $mch genutzt werden müsste.

[presskopf]

Hallo Frank,

meine Meinung zu WLAN Anbindung habe ich hier https://forum.fhem.de/index.php/topic,24436.msg1234919.html#msg1234919 und hier https://forum.fhem.de/index.php/topic,24436.msg1235192.html#msg1235192 bereits kund getan.

Ist Ser2net auf den RasPi begrenzt? Ist doch eine Linux Lösung.

Gruß, Ansgar.

Hi Ansgar,

ich komme nochmal auf das Thema LAN / WLAN-Anbindung des TSCUL zurück.
Probleme hatte ich ja mit der WLAN-Anbindung über einen Raspi, der über ser2net den TSCUL bereitstellt. Warum auch immer. Vielleicht ist der Wlan-Dongle einfach nur schrottig, I dont know.

Jedenfalls versuchte ich es nun über einen esp32 mittels Tasmota und TCPBridge, welcher über LAN- und WLAN-Funktionalität verfügt (Olimex esp32-poe-iso), um beides zu testen.
Heute, nach knappen zwei Wochen, kann ich -> für mein Setup <- sagen, dass es über beide Kanäle stabil läuft. Über LAN hatte ich es quasi erwartet. Der Ort des Geschehens ist über WLAN gar nicht so schlecht versorgt (40%, -80 dBm); der Ping ist natürlich mit einem avg von 86 ms deutlich höher als im LAN. Aber alle zugewiesenen HM-Geräte (drei Rolladen, ein Rauchmelder, zwei Bewegungsmelder, zwei Fensterkontakte) laufen anstandslos (kein Ausfall, keine Fehler im genannten Zeitraum).

Ich danke Dir für Deine Entwicklungsarbeit und Deine Meinung zur WLAN-Anbindung. Anscheinend ist mein Setup im "stabilen Timing-Bereich" der recht robusten TS-Firmware. Wie es bei schlechterem WLAN-Empfang aussieht, muss dann jeder für sich testen.

Dennoch werde ich den Anschluss über LAN vornehmen, was aber eher daran liegt, dass ich den Olimex über POE galant versorgen kann - da ich mittlerweile eine Strippe gezogen habe.

Viele Grüße
Matthias

[noansi]

Hallo Frank,

ich hatte nur das gefühl, dass beim 08'er cmd eventuell auch $mch genutzt werden müsste.

Kommt mir auch komisch vor, zumal es mit RT und IT ohnehin immer auf ch 00 beim templisten Setzen rausläuft.
Habe ich mal mit geändert.

Gruß, Ansgar.

[noansi]

Hallo Matthias,

danke für Dein Feedback, insbesondere im Namen derer, die es doch mal mit WLAN ausprobieren wollen.
Freut mich, wenn es bei Dir mit Deinem Setup zufriedenstellen funktioniert hat.

Ich hoffe, Du berätst auch, wenn hier Probleme mit WLAN Anbindung auf den Tisch kommen.

Gruß, Ansgar.

[yersinia]

Hallo noansi,
in den letzten Tagen hatte ich mehrfach Probleme mit meinen tsculfw nanoCULs, vermute als Grund eher ein Kernelupgrade bzw den USB-Port des RasPis (andere USB Devices sind ebenso betroffen). Ich hab' nur eine Bitte: ist es möglich, dass wenn der nanoCUL nicht erreichbar ist oder unplausible Daten ausgibt wie zB

Code: [Auswählen]

2022.11.11 07:34:45 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 07:43:04 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 07:48:08 1: TSCUL_RecoverHMQlen: nanoCUL_868_1 recovered from Qlen lock
2022.11.11 07:48:39 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 07:58:44 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 08:00:43 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:02:56 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 08:15:47 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:30:51 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:45:55 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:47:15 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 09:00:59 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 09:02:41 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 09:16:03 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDles ein reading in dem TSCUL-Device gibt, welches auch das reading cond (oder irgendein anderes) auf was anderes als ok setzt?

Hintergrund: ich prüfe periodisch verschiedene Devices und ua auch diesen nanoCUL und kann bei Bedarf ein set reset automatisch ausführen. (ist noch ein Überbleibsel vom alten Bootloader...)

TSCUL Version 0.39

Code: [Auswählen]

VERSION_TS, VTS 0.39 CSM868, nanoCUL_V1.x_0014FHEM-Module sind auf dem mir aktuellen Stand von 0.97.

Anbei noch ein list vom nanoCUL (hmId duch ###### ersetzt und ausgabe gekürzt):

Code: [Auswählen]

Internals:
   CMDS       ABCFGJKRUVWXYeiltx
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:TSHMS
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A94H5T9K-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A94H5T9K-if00-port0@38400
   FD         10
   FHTID      0000
   FUUID      5c443cea-f33f-3151-cc84-d7ba10e1ebdcec87
   NAME       nanoCUL_868_1
   NR         22
   PARTIAL   
   RAWMSG     A144F845E2D478700000080E3F300000000000951FF::-76:nanoCUL_868_1:
   RSSI       -76
   STATE      2022-11-11 09:25:19 Initialized
   TYPE       TSCUL
   VERSION    VTS 0.39 CSM868
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 55
   assignedIDsCnt 26
   devioNoSTATE 1
   eventCount 12
   initString XP0C
X21
Ar
AM5
AH######
   msgLoadCurrent 0
   nanoCUL_868_1_MSGCNT 17008
   nanoCUL_868_1_TIME 2022-11-11 16:25:42
   owner_CCU  VCCU
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     CUL_HM
   MatchList:
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:TSHMS    ^810e04......a001
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2022-09-09 08:23:43   Initialized     
     2022-11-11 09:25:23   Xmit-Events     ok:6 non-HM:1 disconnected:2
     2022-11-11 09:25:17   cmds             A B C F G J K R U V W X Y e i l t x
     2022-11-11 09:25:23   cond            ok
     2022-11-09 10:11:35   disconnected   
     2022-11-11 09:25:12   prot_disconnected last
     2021-04-30 09:06:45   prot_init       last
     2022-11-09 10:11:51   prot_non-HM     last
     2022-11-11 09:25:23   prot_ok         last
     2022-11-10 01:16:50   scF             0.999673925227026
     2022-11-11 09:25:19   state           Initialized
     2022-11-11 09:33:10   uptime          0 00:07:57
     2022-11-11 09:33:06   version         VTS 0.39 CSM868
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   26
     assIdRep   26
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         1B39F300   00
         3C775B00   00
         3C95EB00   00
         3E804200   00
         3F464200   00
         40AA4F00   00
         4930EC00   00
         4ADAF500   00
         4B3FE700   00
         50CDF000   00
         5389B700   00
         538A7800   00
         564A8300   00
         567A3600   00
         567A3800   00
         5683FF00   00
         56840900   00
         56842200   00
         58ADFB00   00
         59795B00   00
         59F7C500   00
         5C179800   00
         5C1CA000   00
         5C912900   00
         5ED64C00   00
         5ED76B00   00
       msgCNT:
         0x01       17008
         0x02       461
         0x03       643
       unknwn:
         3B5ADA:
           nextSend   1668076043.77502
           lRcTm:
             mcnt       02
             nanoCUL_868_1 16015948
             tnms       554991003
             type       11
         40D9AF:
           nextSend   1668177201.6565
           lRcTm:
             mcnt       10
             nanoCUL_868_1 22095532
             tnms       656148885
             type       8E
         451818:
           nextSend   1668171353.90928
           lRcTm:
             mcnt       10
             nanoCUL_868_1 16245880
             tnms       650301137
             type       8E
         4BEEC8:
           nextSend   1668179701.18435
           lRcTm:
             mcnt       9C
             nanoCUL_868_1 24595860
             tnms       658648412
             type       10
         4BEEC9:
           nextSend   1668120414.70759
           lRcTm:
             mcnt       97
             nanoCUL_868_1 60401528
             tnms       599361936
             type       10
         677759:
           nextSend   1668179836.39099
           lRcTm:
             mcnt       10
             nanoCUL_868_1 24731116
             tnms       658783619
             type       8E
         AF761B:
           nextSend   1668180161.12973
           lRcTm:
             mcnt       12
             nanoCUL_868_1 25055960
             tnms       659108358
             type       83
         B56FD3:
           nextSend   1668174399.34079
           lRcTm:
             mcnt       10
             nanoCUL_868_1 19292296
             tnms       653346569
             type       8E
     cnd:
       0          6
       250        1
       253        2
     hmLog:
       IDs:
     hmLogHist:
        146370                 As 0D 7F 8002 ###### 59F7C5 0101C800
        04865060 A F103 08346868 01 0A 7F 8002 ###### 59F7C5 00 _CCAdly:4 _dhmSt:96
        04865155 A F103 08346964 01 0D 7F 8002 ###### 59F7C5 0101C800 _CCAdly:4 _dhmSt:192
        04866834 A F101 08348672 00 0F E7 8610 5683FF 000000 0A80BBC70000 -53.5dB
        04875842 A F001 08357684 00 0F 5E 8610 567A36 000000 0A98CA090000 -38.5dB
        04896600 A F001 08378436 00 0F CE 8610 567A38 000000 0A98CAC80500 -57dB
        04906230 A F001 08388084 00 0F 86 8610 568422 000000 0A98C70E0200 -52.5dB
        04914424 A F001 08396272 00 0F A7 8610 568414 000000 0A98CF090000 -70.5dB
        04926889 A F001 08408748 00 0F 55 8610 568409 000000 0AA0E00C0000 -57dB
        04948558 A F001 08430416 00 0C D8 865A 3C95EB 000000 98C43D -61.5dB
        04962159 A F001 08444032 00 0C A0 865A 3C775B 000000 98C844 -61dB
        04968560 A F001 08450424 00 0C D8 8470 3C95EB 000000 00C43D -59.5dB
        04975554 A F001 08457420 00 0C 2A 865A 40AA4F 000000 A0DE3F -72dB
        04978350 A F001 08460216 00 14 4F 845E 2D4787 000000 80E3F300000000000951FF -76dB
     hmQ:
       000000:
       3C775B:
       3C95EB:
       3F4642:
       40AA4F:
       4930EC:
       5389B7:
       538A78:
       567A36:
       567A38:
       5683FF:
       568409:
       568422:
       58ADFB:
       59795B:
       59F7C5:
       5C1798:
       5C9129:
       5ED64C:
       5ED76B:
     ids:
       [...]
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1668153701.7581
       answerPend 0
       hmLanQlen  1
     ref:
       Sdly       12
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3780.95735595249
       ioBRMean   3352.48190506548
       lHMt       25221248
       lSys       659273583
       pTTu       16
       pndAs      0
       pndCUAp    1
       pndTuP     1
       pngFrc     1
       pngLm      70
       pngRef     -100000000
       scErr      0
       scF        0.999673925227026
       scFN       1
       scHT       88221780
       scST       627172874
       scpTm      1668040433.88637