HM-MOD-Re-8: Regelmäßig MISSING ACK / Device hängt bis Tastendruck

[sledge]

Hi,

seit einigen Monaten habe ich mehrere HM-MOD-Re-8 im Einsatz - soweit klappt das auch ganz gut.

Hin und wieder jedoch beobachte ich zwei Phänomene:

• Das Device zeigt im Status "MISSING ACK" - und den Status der einzelnen Channels bleibt auf set-on oder set-off. Hier hilft dann oft ein "status-request" - so wie auch in diesem Thread beschrieben: https://forum.fhem.de/index.php/topic,58082.msg495093.html#msg495093.
• Die "verschärfte" Variante ist das MISSING ACK, welches ich remote nicht mehr beseitigen kann - da hilft dann idR nichts, außer in den Keller zu gehen und eine Taste zu drücken - irgendeine. Dann ist wieder alles fein.

Besonders der letzte Umstand ist ein bisschen nervig - denn eigentlich sollte das ganze System ja auch unbetreut laufen.

Wie empfohlen läuft mein Setup über eine VCCU, auch die RSSI-Werte liegen mE im grünen Bereich - ein Empfangsproblem sollte also nicht zugrunde liegen.

Hier mal die Definitionen:

Code Auswählen Erweitern

CFGFN
   DEF        35FDAC
   DI.EG.CUL_MSGCNT 4
   DI.EG.CUL_RAWMSG A1107A00235FDAC37A0E204359EF39A0FD6865E3DFA9C000000CBD3830103C4::-95:DI.EG.CUL
   DI.EG.CUL_RSSI -95
   DI.EG.CUL_TIME 2016-12-23 10:53:58
   IODev      DI.EG.CUL
   LASTInputDev DI.EG.CUL
   MSGCNT     16
   NAME       HZ.KG.HM
   NOTIFYDEV  global
   NR         110
   NTFY_ORDER 50-HZ.KG.HM
   STATE      MISSING ACK
   TK.KG.CUL_MSGCNT 12
   TK.KG.CUL_RAWMSG A1207800235FDAC37A0E2010500000057E2C66A::-64.5:TK.KG.CUL
   TK.KG.CUL_RSSI -64.5
   TK.KG.CUL_TIME 2016-12-23 10:46:31
   TYPE       CUL_HM
   channel_01 WZ.EG.FBH
   channel_02 WZ2.EG.FBH
   channel_03 EZ.EG.FBH
   channel_04 DI2.EG.FBH
   channel_05 KU.EG.FBH
   channel_06 HZ.KG.HM_Sw_06
   channel_07 HZ.KG.HM_Sw_07
   channel_08 HZ.KG.HM_Sw_08
   protCmdDel 2
   protResnd  1 last_at:2016-12-23 12:48:36
   protResndFail 1 last_at:2016-12-23 12:48:40
   protSnd    1 last_at:2016-12-23 12:48:34
   protState  CMDs_done_Errors:1
   rssi_at_DI.EG.CUL min:-96.5 lst:-95 cnt:4 avg:-89.12 max:-70
   rssi_at_TK.KG.CUL cnt:12 avg:-61.41 max:-54.5 min:-66.5 lst:-64.5
   Readings:
     2016-12-23 12:43:20   Activity        alive
     2016-12-08 22:06:44   CommandAccepted yes
     2016-10-29 16:27:48   D-firmware      1.2
     2016-10-29 16:27:48   D-serialNr      MEQ0649827
     2016-11-18 17:15:34   PairedTo        0x37A0E2
     2016-09-10 16:41:52   R-pairCentral   0x37A0E2
     2016-10-24 23:06:45   R-sign          off
     2016-10-24 23:06:45   RegL_01.        08:00 00:00
     2016-12-23 10:46:31   aesCommToDev    ok
     2016-12-23 10:53:58   aesKeyNbr       86
     2016-12-08 22:06:44   deviceMsg       22 (to vccu)
     2016-12-08 22:06:44   level           22
     2016-12-08 22:06:44   pct             22
     2016-12-08 22:06:44   recentStateType ack
     2016-12-16 06:44:26   sabotageAttack_ErrIoAttack cnt 21
     2016-12-23 12:48:40   state           MISSING ACK
     2016-12-08 22:06:44   timedOn         running
     Regl_00.:
       VAL
   Helper:
     HM_CMDNR   33
     cSnd       0137A0E235FDAC00040000000000,1137A0E235FDAC0201C80000
     mId        00BE
     rxType     2
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +35FDAC,00,01,00
       nextSend   1482486838.29111
       rxt        0
       vccu       vccu
       p:
         35FDAC
         00
         01
         00
     Mrssi:
       mNo        07
       Io:
         DI.EG.CUL  -93
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       prs        1
     Rpt:
       IO         DI.EG.CUL
       flg        A
       ts         1482486838.1958
       ack:
         HASH(0x6588438)
         07800237A0E235FDAC00
     Rssi:
       At_di.eg.cul:
         avg        -89.125
         cnt        4
         lst        -95
         max        -70
         min        -96.5
       At_tk.kg.cul:
         avg        -61.4166666666667
         cnt        12
         lst        -64.5
         max        -54.5
         min        -66.5
     Tmpl:
Attributes:
   IODev      TK.KG.CUL
   IOgrp      vccu
   actCycle   000:30
   actStatus  alive
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.2
   model      HM-MOD-Re-8
   msgRepeat  1
   room       CUL_HM,homematic
   serialNr   MEQ0649827
   subType    switch
   verbose    1
   webCmd     getConfig:clear msgEvents

Ratschläge, wie ich der Sache sinnvoll auf den Grund gehen kann, werden sehr gerne genommen

Gruß,
Tom

[Otto123]

Hallo Tom,

mir fallen mehrere Sachen auf:
autoReadReg 5_readMissing -> steht bei mir auf 4_reqStatus habe ich nie geändert, ich weiß nicht was dies wirklich bewirkt 
2016-12-16 06:44:26   sabotageAttack_ErrIoAttack cnt 21 -> Ein fremder IO redet mit ihm, nicht schön. Ich weiß nicht ob das stört.
IODev      DI.EG.CUL + rssi_at_DI.EG.CUL min:-96.5 lst:-95 cnt:4 avg:-89.12 max:-70 -> weit weg von guten RSSI geht eher in Richtung unterirdisch 

CUL mit welcher Firmware? -> für HM ist die Standard Firmware nicht so gut geeignet!

Du solltest attr IOgrp      vccu:<preferred IO > setzen.

Gruß Otto

[sledge]

Hi Otto,

bin davon ausgegangen, dass bei der Config via vccu der zweite CUL einspringt - der wiederum hat ja RSII-Werte um die 60. Aber preferredIO setze ich gleich mal, wenn das Linderung verschaffen sollte...

Bzgl. des autoRedReg steht im Wiki:

autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen

Daher habe ich das so eingestellt. Ansonsten sollte das Wiki hier angepasst werden, wenn es eine "bessere" Empfehlung gibt.

Der unbekannte Gesprächspartner ist mir auch bereits aufgefallen - Hinweise, wie ich den identifizieren kann sind gerne genommen - ist aber mE nicht in meinem Haus...

Gruß,

Tom

[martinp876]

Autoreadreg 5 ist meine Empfehlung. Es wird auf fehlende configdir geprüft und Register werden gelesen.
Ist der kompletteste Versuch, registercopien in fhem synchron zu halten.
Es gibt für mich nichts anderes. Dennoch, man kann es abschalten.

Bei attack gibt es mehr readings. Es wird u.a geprüft, ob Kommandos von der zentrale gelesen werden an welche diese sich nicht erinnern kann. Sollten Kommandos von einem anderen hmid Einstellungen schicken wird diese ID angezeigt.

Wenn du mehrere IOs hast koennte es sein, dass es durch Verzögerungen dazu kommen kann, dass eine Attacke erkannt wird. Sollte das der Fall sein kannst du einmal sniffen

[sledge]

Hi Martin,

in der Tat habe ich mehrere IOs - und hatte gehofft, dass durch "vccu" die meisten Probleme aus der Welt geschafft würden.

Ich habe jetzt mal den zentralen CUL neu positioniert und allen HomeMatic-Devices einen "preferred-IO" zugewiesen - bisher sieht es ganz gut aus...

Wenn es jetzt "passt" - fein - ansonsten fange ich mal mit sniffen an.

Merci.