Bedeutung von "recentStateType" und "ack" beim HM-LC-SW1PBU-FM?

[t1me2die]

Moin liebes Forum,

ich habe seit ca. 2 Jahren einen HM-LC-SW1PBU-FM Taster im Einsatz.
Dieser wird über einen Bewegungsmelder gesteuert, der seit Beginn an hervorragende Dienste geleistet hat.
Seit geraumer Zeit kommt es zu Verzögerungen / Schaltaussetzer.

Erst dachte ich, es wäre die Schuld des Bewegungsmelder, Fehlanzeige.
Habe nun aktiv die Schaltvorgänge verfolgt und mir fiel dabei auf, dass verdammt häufig das Reading "recentStateType" geupdatet wird mit "ack".

Erst einmal ein List:

Code Auswählen Erweitern


Internals:
   DEF        47EF2D
   FUUID      5ca49ed4-f33f-5a17-fe69-da76c2f27bbdc65b
   IODev      myHmUARTUSB
   LASTInputDev myHmUARTLGW
   MSGCNT     3777
   NAME       az_Deckenbeleuchtung
   NOTIFYDEV  global
   NR         357
   NTFY_ORDER 50-az_Deckenbeleuchtung
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:3D - t:02 s:47EF2D d:115200 010100002B
   myHmUARTLGW_MSGCNT 1893
   myHmUARTLGW_RAWMSG 050000213D800247EF2D115200010100002B
   myHmUARTLGW_RSSI -33
   myHmUARTLGW_TIME 2019-07-22 19:23:16
   myHmUARTUSB_MSGCNT 1884
   myHmUARTUSB_RAWMSG 040300243D800247EF2D115200010100002B
   myHmUARTUSB_RSSI -36
   myHmUARTUSB_TIME 2019-07-22 19:23:16
   protLastRcv 2019-07-22 19:23:16
   protRcv    1892 last_at:2019-07-22 19:23:16
   protSnd    1886 last_at:2019-07-22 19:23:15
   protState  CMDs_done
   rssi_at_myHmUARTLGW cnt:1893 min:-54 max:-30 avg:-37.49 lst:-33
   rssi_at_myHmUARTUSB cnt:1884 min:-39 max:-32 avg:-35.2 lst:-36
   rssi_myHmUARTLGW cnt:29 min:-45 max:-36 avg:-40.89 lst:-41
   rssi_myHmUARTUSB cnt:1559 min:-44 max:-38 avg:-40.93 lst:-43
   READINGS:
     2019-07-22 19:23:16   CommandAccepted yes
     2018-02-15 20:03:03   D-firmware      2.8
     2018-02-15 20:03:03   D-serialNr      NEQ0276096
     2019-02-02 16:52:54   PairedTo        0x115200
     2018-02-15 20:03:08   R-pairCentral   0x115200
     2018-02-15 20:03:09   R-powerUpAction off
     2018-02-15 20:03:09   R-sign          off
     2019-02-02 16:52:54   RegL_00.        02:01 0A:11 0B:52 0C:00 15:FF 18:00 00:00
     2019-02-02 16:52:55   RegL_01.        08:00  30:06 57:24 56:00 00:00
     2019-07-22 19:23:16   deviceMsg       off (to VCCU)
     2019-07-22 19:23:16   level           0
     2018-12-24 22:46:38   levelMissed     desired:100
     2019-07-22 19:23:16   pct             0
     2019-02-02 16:52:50   powerOn         2019-02-02 16:52:50
     2019-07-22 19:23:16   recentStateType ack
     2018-08-28 18:30:10   sabotageAttack_ErrIoAttack cnt 8
     2019-07-22 19:23:16   state           off
     2019-07-22 19:23:16   timedOn         off
   helper:
     HM_CMDNR   61
     cSnd       1111520047EF2D0201C80000,1111520047EF2D0201000000
     dlvlCmd    ++A01111520047EF2D0201000000
     mId        0069
     peerFriend peerSens,peerVirt
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +47EF2D,00,00,00
       nextSend   1563816196.21527
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         47EF2D
         00
         00
         00
     mRssi:
       mNo        3D
       io:
         myHmUARTLGW:
           -33
           -33
         myHmUARTUSB:
           -28
           -28
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       at_myHmUARTLGW:
         avg        -37.4944532488115
         cnt        1893
         lst        -33
         max        -30
         min        -54
       at_myHmUARTUSB:
         avg        -35.2064755838641
         cnt        1884
         lst        -36
         max        -32
         min        -39
       myHmUARTLGW:
         avg        -40.8965517241379
         cnt        29
         lst        -41
         max        -36
         min        -45
       myHmUARTUSB:
         avg        -40.9345734445157
         cnt        1559
         lst        -43
         max        -38
         min        -44
Attributes:
   DbLogExclude .*
   IOgrp      VCCU
   alias      az_Deckenbeleuchtung
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   genericDeviceType light
   icon       light_pendant_light
   model      HM-LC-SW1PBU-FM
   peerIDs    00000000,
   room       Arbeitszimmer,Homekit
   serialNr   NEQ0276096
   subType    switch
   verbose    2
   webCmd     on:off


Manchmal meine ich zu hören, dass der Taster versucht das Relais zu schalten, der Status geht in FHEM dann auf "on" obwohl das Relais noch nicht geschaltet werden konnte. Nun dauert es ca. 5-8Sekunden (Bauchgefühl) bis evtl. das Licht angeht.
Ich vermute, dass der Taster mittlerweile Müdigkeitserscheinungen hat, daher wollte ich gerne wissen, was in diesem Zusammenhang das Reading "recentStateType" bedeutet.

Laut Device specific help bedeutet "ack" sinnlich übersetzt, dass einige Statusinformationen nicht bestätigt werden konnten.

Gruß
Mathze

[Otto123]

Hi,

ich habe mal probiert. Ich denke recentStateType wird mit ack gesetzt wenn FHEM einen Schaltvorgang ausführt.
Die meisten Geräte haben dort info stehen.

Ich habe eine Schalter (HM-LC-SW2-PB-FM) der zeigt seit ein paar Wochen ein ähnliches Verhalten wie Du es beschreibst.
Mir technisch unerklärlich ist das Verhalten: Ich schalte einen Kanal (egal welchen), es passiert nichts. Wenn ich lange genug warte geht das Licht nach 5-20 sec an. Schalte ich den zweiten Kanal gehen beide Lampen sofort an!

Gruß Otto

[t1me2die]

Moin Otto,

danke für deine Erfahrung.
Wie alt ist dein 2fach Taster? Hörst du beim schalten des ersten Kanals auch ein leichtes Knacken, deutlich leiser als das typische Relais "knacken".
All meine anderen 1fach Taster (wz,sz,bad,ku) haben bei recentStateType nur "info" stehen.

Dieser Taster, der bei mir betroffen ist, ist auch der Taster, der definitiv mit Abstand die meisten Schaltvorgänge bisher bewältigt hat.
Irgendwie sagt mir mein Bauchgefühl, dass hier irgendein Defekt vorliegt oder erste Ausfallerscheinungen langsam auftreten.

Es ist nicht so, dass diese Verzögerung jedesmal beim Schaltvorgang auftritt sondern sporadisch und nicht unbedingt rekonstruierbar ist.

Einen Reset / Werkseinstellungen habe ich erst einmal noch nicht probiert, da ich erstmal nachfragen wollte, bevor ich anfange hier wieder wild herum zu fummeln.

Gruß
Mathze

[Otto123]

ehrlich gesagt kann ich ein Relaisklacken nicht hören. Dieser Schalter Typ ist ein relativ alter, anders als die heutigen. Da klacken die Tasten schon deutlich ich müsste mich daneben stellen und mit FHEM schalten. Habe ich noch nicht gemacht.

Wenn Du über FHEM schaltest geht der recentStateType  nicht auf ack?

[t1me2die]

Auch wenn ich über FHEM direkt schalte kommt ,,ack".
Wobei mir ist gerade aufgefallen, dass andere HM Taster auch bei Schaltvorgängen auf ,,ack" springen.

Dementsprechend verstehe ich nun weniger die Bedeutung von ,,ack".

Gruß
Mathze

[Otto123]

ack -> acknowledged -> bestätigt

FHEM gibt einen Befehl und das Gerät bestätigt die Ausführung. Alles ok.

[frank]

und "freiwillig" gesendete statusmessages sind typ info, zb die regelmässigen beim fensterkontakt.

schon mal nach freezes in fhem geschaut?

[t1me2die]

Gut, nun bin bzgl. der Begrifflichkeiten ein wenig schlauer, danke 

Ich werde den Taster einfach mal austauschen und schauen, ob danach das Problem behoben ist / wurde.

@frank: Freezes sind auf jeden Fall laut Freezemon keine vorhanden. Auch sonst habe ich keinerlei Probleme, alles läuft Butterzart.
Ich habe FHEM bzw. die virtuelle Maschine schon mind. 45Tage durchgehend am laufen, daran sollte es aber nicht liegen. Es betrifft ja tatsächlich nur diesen einen Taster und diesen halt auch nur sehr sporadisch. Die Entfernung von dem Taster zum CUL sind auch nur 1m Luftlinie, also direkt unter der Antenne ist tatsächlich der Taster 

Ich habe mir einfach mal ganz unverbindlich nen neuen Taster besorgt, werde den heute Abend mal fix einbauen und einfach mal beobachten, falls es der Taster nicht gewesen sein sollte, melde ich mich noch einmal 

Gruß
Mathze

[t1me2die]

Also ich habe nun den Taster ausgetauscht und so wie es scheint hatte der Taster tatsächlich einen leichten Ditscher gehabt, denn der neue Taster hat bisher noch keinerlei Ausfallerscheinungen / Verzögerungen gezeigt. Ich werde das mal die nächsten Tage weiter beobachten und das Thema hier ggf. auf "gelöst" setzen.

Dennoch danke für eure Hilfe.

Gruß
Mathze