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 (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:
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 msgEventsRatschläge, wie ich der Sache sinnvoll auf den Grund gehen kann, werden sehr gerne genommen ;-)
Gruß,
Tom
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 :D
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
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:
ZitatautoReadReg: 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
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
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.