Guten Morgen, seit geraumer Zeit muss ich meine beiden HM-LC-SW1-BA-PCB die am Einfahrtstor und Garage angeschlossen sind nach jedem Neustart von FHEM neu pairen. Das war früher nicht so. Hat jemand eine Idee an was das liegen kann?
List Internals:
DEF 4C3462
FUUID 5c4f4fb4-f33f-6642-1550-1315458a63bea0e9
IODev KG.HmUARTLGW
NAME Garage
NOTIFYDEV global
NR 187
NTFY_ORDER 50-Garage
STATE MISSING ACK
TYPE CUL_HM
chanNo 01
protCmdDel 43
protResnd 43 last_at:2020-04-29 10:34:03
protResndFail 43 last_at:2020-04-29 10:34:08
protSnd 43 last_at:2020-04-29 10:33:57
protSndB 86 last_at:2020-04-29 10:34:03
protState CMDs_done_Errors:1
READINGS:
2020-04-14 06:44:34 CommandAccepted yes
2019-10-13 11:48:13 D-firmware 1.7
2019-10-13 11:48:13 D-serialNr NEQ0603521
2019-11-07 16:26:39 PairedTo 0xF11034
2019-11-07 07:28:27 R-intKeyVisib invisib
2019-11-07 07:28:27 R-ledMode off
2019-11-07 07:28:27 R-lowBatLimitBA 6 V
2019-11-07 07:28:27 R-pairCentral 0xF11034
2019-11-07 07:28:28 R-sign off
2020-04-14 06:44:38 battery ok
2020-04-14 06:44:38 deviceMsg off (to VCCU)
2020-04-14 06:44:38 level 0
2020-04-14 06:44:38 pct 0
2019-11-07 07:28:25 powerOn 2019-11-07 07:28:25
2020-04-14 06:44:38 recentStateType info
2019-10-19 12:38:55 sabotageAttack_ErrIoAttack cnt 2
2020-04-29 10:34:08 state MISSING ACK
2020-04-14 06:44:38 timedOn off
helper:
HM_CMDNR 123
cSnd 01F110344C3462010E,11F110344C34620201C800000280
mId 006C
peerFriend peerSens,peerVirt
peerOpt 3:switch
regLst 0,1,3p
rxType 2
stateUpdatDly 120
expert:
def 1
det 1
raw 0
tpl 0
io:
newChn +4C3462,00,01,00
prefIO
rxt 0
vccu VCCU
p:
4C3462
00
01
00
mRssi:
mNo
io:
CUL_0:
KG.HmUARTLGW:
OG.HmUARTLGW:
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
prs 1
Attributes:
IODev CUL_0
IOgrp VCCU
alexaName Garage
autoReadReg 4_reqStatus
devStateIcon .*:fts_garage
eventMap /on-for-timer 2:on/
expert 1_allReg
firmware 1.7
group Garage
model HM-LC-SW1-BA-PCB
msgRepeat 1
peerIDs 00000000,
room Draußen,Homekit
serialNr NEQ0603521
subType switch
webCmd on:statusRequest
Hi,
was genau meinst Du mit neu pairen?
Der Aktor ist seit November vorigen Jahres gepairt 2019-11-07 16:26:39 PairedTo 0xF11034
Und ist seit dem am Strom 2019-11-07 07:28:25 powerOn 2019-11-07 07:28:25
Warum fehlen die rssi Werte?
Gruß Otto
Oder um es mal anders zu versuchen: MISSING ACK heißt nur, dass FHEM keine Antwort von dem Gerät bekommt. Das kann andere Ursachen haben, deswegen fragte Otto nach den rssi.
Die letzte echte Schaltstatusmeldung war
2020-04-14 06:44:38 deviceMsg off (to VCCU)
Wenn Du eine Chance hast, den Aktor einmal manuell zu betätigen (er hat ja eine Taste onboard), achte auf den gemeldeten Status in FHEM. Dieser ändert sich auch, wenn der Aktor NICHT gepairt ist, etwa nach einen (versehentlichen) Reset oder auch wenn das Gerät zwar in FHEM per autocreate angelegt, aber noch nicht gepairt wurde.
Allerdings richtet der Aktor seine Meldung dann nicht mehr an die ihm bekannte Zentrale VCCU, sondern allgemein:
2020-04-14 06:44:38 deviceMsg off (to broadcast)
So kann man sicher gepairte und ungepairte Aktoren unterscheiden, denn bei einem versehentlichen Reset ändert sich PairedTo nicht von allein und jedes getConfig endet ohnehin im MISSING ACK. Aber wie gesagt: ein MISSING ACK allein bedeutet keinesfalls "nicht gepairt".
Beide HM-LC-SW1-BA-PCB liefen Jahre ohne Probleme. Aktuell ist es so wenn ich ehem update (shutdown restart) reagieren beide Actoren nicht mehr und ich muss in der VCCU hmPairForSec auslösen und an den Actoren den Button drücken. Dann laufen sie wieder bis zum nächsten shutdown restart.
Hatt beide Actoren auch schon aus ehem gelöscht und komplett neu angelegt.Gleiche Situation
zeig mal je ein list der vccu und aller gateways.
Das Verhalten klingt eher nach: Konfiguration nicht gespeichert? Vom Restart bis zum Restart?
Klingt irgendwie komisch. Was macht er denn, wenn er jetzt frisch gepairt ist, nach einem getConfig?
list VCCU Internals:
CUL_0_MSGCNT 1486
CUL_0_RAWMSG A0A7A8002F110345F4A4200::-50:CUL_0
CUL_0_RSSI -50
CUL_0_TIME 2020-04-29 19:11:44
DEF F11034
FUUID 5c4f4fb6-f33f-6642-96f1-04ef910e666c94e5
IODev KG.HmUARTLGW
KG.HmUARTLGW_MSGCNT 482
KG.HmUARTLGW_RAWMSG 050000547A8002F110345F4A4200
KG.HmUARTLGW_RSSI -84
KG.HmUARTLGW_TIME 2020-04-29 19:11:44
LASTInputDev KG.HmUARTLGW
MSGCNT 3097
NAME VCCU
NOTIFYDEV global
NR 220
NTFY_ORDER 50-VCCU
OG.HmUARTLGW_MSGCNT 1129
OG.HmUARTLGW_RAWMSG 0500005878B001F1103466BE6F010E
OG.HmUARTLGW_RSSI -88
OG.HmUARTLGW_TIME 2020-04-29 19:08:41
STATE KG.HmUARTLGW:ok,OG.HmUARTLGW:ok,CUL_0:ok
TYPE CUL_HM
assignedIOs CUL_0,KG.HmUARTLGW,OG.HmUARTLGW
channel_01 VCCU_Btn1_HMremote19_Btn_01
channel_02 VCCU_Btn2_HMremote19_Btn_02
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4_HMremote19_Btn_04
channel_05 VCCU_Btn5_OG.fl.WS_Btn_01
channel_06 VCCU_Btn6_OG.fl.WS_Btn_02
channel_07 VCCU_Btn7_OG.fl.WS_Btn_03
channel_08 VCCU_Btn8_OG.fl.WS_Btn_04
channel_09 VCCU_Btn9_OG.fl.WS_Btn_05
channel_0A VCCU_Btn10_OG.fl.WS_Btn_06
channel_0B VCCU_Btn11_OG.sz.WS_Btn_01
channel_0C VCCU_Btn12_OG.sz.WS_Btn_02
channel_0D VCCU_Btn13_OG.wz.WS_Btn_01
channel_0E VCCU_Btn14_OG.wz.WS_Btn_02
channel_0F VCCU_Btn15_OG.wz.WS_Btn_03
channel_10 VCCU_Btn16_OG.wz.WS_Btn_04
channel_11 VCCU_Btn17_OG.wz.WS_Btn_05
channel_12 VCCU_Btn18_OG.wz.WS_Btn_06
channel_13 VCCU_Btn19
channel_14 VCCU_Btn20
channel_15 VCCU_Btn21
channel_16 VCCU_Btn22
channel_17 VCCU_Btn23
channel_18 VCCU_Btn24
channel_19 VCCU_Btn25
channel_1A VCCU_Btn26
channel_1B VCCU_Btn27
channel_1C VCCU_Btn28
channel_1D VCCU_Btn29
channel_1E VCCU_Btn30
lastMsg No:7A - t:02 s:F11034 d:5F4A42 00
protLastRcv 2020-04-29 19:11:44
protRcv 1245 last_at:2020-04-29 19:11:44
protRcvB 196 last_at:2020-04-29 19:08:34
rssi_at_CUL_0 cnt:1485 min:-102 max:-48 avg:-82.74 lst:-50
rssi_at_KG.HmUARTLGW cnt:482 min:-96 max:-76 avg:-83.43 lst:-84
rssi_at_OG.HmUARTLGW cnt:1129 min:-97 max:-47 avg:-81.55 lst:-88
READINGS:
2020-04-29 19:11:44 CommandAccepted yes
2020-04-28 15:58:12 IOopen 3
2020-03-19 10:49:40 aesReqTo Wohnungstuer
2020-04-28 15:58:12 state KG.HmUARTLGW:ok,OG.HmUARTLGW:ok,CUL_0:ok
2020-04-09 20:38:05 unknown_1992F3 received
2020-04-17 12:32:00 unknown_20045E received
2020-04-15 16:46:52 unknown_28C230 received
2020-04-08 13:58:13 unknown_2CC533 received
2020-04-06 16:16:52 unknown_2DE87D received
2020-04-15 07:57:24 unknown_2FC124 received
2020-03-06 12:55:09 unknown_45E28A received
2020-03-30 08:40:43 unknown_46CF00 received
2020-04-06 20:31:18 unknown_46F611 received
2019-11-08 12:56:39 unknown_493765 received
2020-02-12 00:31:29 unknown_49DD42 received
2020-04-17 07:35:54 unknown_4EC68E received
2020-04-04 13:37:29 unknown_4F104C received
2020-04-16 09:39:42 unknown_4F7F9B received
2020-04-16 05:28:07 unknown_52A798 received
2020-04-19 12:46:19 unknown_52A79B received
2020-04-15 21:55:14 unknown_65820A received
2019-12-25 11:36:19 unknown_661604 received
2020-04-08 10:15:30 unknown_6CEE2D received
2020-03-31 18:33:56 unknown_706B2A received
2020-04-28 23:36:19 unknown_7FB1D2 received
2020-04-17 17:09:21 unknown_9C5A56 received
helper:
HM_CMDNR 122
PONtest 1
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
nextSend 1588180304.30361
prefIO
vccu VCCU
ioList:
KG.HmUARTLGW
OG.HmUARTLGW
CUL_0
mRssi:
mNo 7A
io:
CUL_0:
-50
-50
KG.HmUARTLGW:
-82
-82
OG.HmUARTLGW:
-88
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_CUL_0:
avg -82.7474747474746
cnt 1485
lst -50
max -48
min -102
at_KG.HmUARTLGW:
avg -83.4336099585062
cnt 482
lst -84
max -76
min -96
at_OG.HmUARTLGW:
avg -81.555358724535
cnt 1129
lst -88
max -47
min -97
Attributes:
IODev KG.HmUARTLGW
IOList KG.HmUARTLGW,OG.HmUARTLGW,CUL_0
IOgrp VCCU
expert 2_raw
group Gateway
hmKey 01:1b501a7a0f1eedee97e52e0a84ac8e4f
model CCU-FHEM
room System->Gateways
subType virtual
webCmd update
List Cul Internals:
CMDS BCFiAZEGMKURTVWXefmltux
CUL_0_MSGCNT 17153
CUL_0_TIME 2020-04-29 19:13:41
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/ttyACM0@9600 1034
DeviceName /dev/ttyACM0@9600
FD 16
FHTID 1034
FUUID 5db598ee-f33f-6642-7416-5b7bf54987cc55f9
NAME CUL_0
NR 402
NR_CMD_LAST_H 18
PARTIAL
RAWMSG A13B486704DC27D0000000088500019C00044E165CD
RSSI -99.5
STATE Initialized
TYPE CUL
VERSION V 1.58 CUL868
initString X21
Ar
owner_CCU VCCU
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-04-28 14:45:51 cmds B C F i A Z E G M K U R T V W X e f m l t u x
2020-04-29 19:13:41 state Initialized
XMIT_TIME:
1588177821.80592
1588178012.33457
1588178075.08917
1588178177.59142
1588178327.61527
1588178653.59033
1588178713.00869
1588178818.06221
1588178952.03874
1588179181.62318
1588179881.00892
1588179881.52621
1588179881.78308
1588179881.87963
1588179882.05922
1588179882.31529
1588179882.41343
1588179882.5958
helper:
235B06:
QUEUE:
24DA3C:
QUEUE:
257EEE:
QUEUE:
27D8C1:
QUEUE:
28C0BE:
QUEUE:
28C1E5:
QUEUE:
2BDA12:
QUEUE:
3372E0:
QUEUE:
337F3B:
QUEUE:
337F6B:
QUEUE:
33F709:
QUEUE:
38A437:
QUEUE:
3B266F:
QUEUE:
3BA55D:
QUEUE:
3FB9C6:
QUEUE:
404A80:
QUEUE:
47BA08:
QUEUE:
4A1CE2:
QUEUE:
4C3462:
QUEUE:
4D2854:
QUEUE:
51AFFE:
QUEUE:
51B020:
QUEUE:
531B56:
QUEUE:
5321C4:
QUEUE:
536DB6:
QUEUE:
5E89ED:
QUEUE:
5EC6F5:
QUEUE:
5EC7E1:
QUEUE:
5EC838:
QUEUE:
5F4A42:
QUEUE:
623D37:
QUEUE:
6CEE2D:
QUEUE:
706B2A:
QUEUE:
Attributes:
devStateIcon Initialized:general_ok@green
group Gateway
hmId F11034
rfmode HomeMatic
room System->Gateways
verbose 2
List KG.HmUARTLGW Internals:
AssignedPeerCnt 5
CNT 105
Clients :CUL_HM:
DEF uart://192.168.143.12:23
DEVCNT 105
DevState 99
DevType UART
DeviceName 192.168.143.12:23
FD 25
FUUID 5c4f4fb5-f33f-6642-9610-66aad17d4af49245
LastOpen 1588078083.7489
NAME KG.HmUARTLGW
NOTIFYDEV global
NR 196
NTFY_ORDER 50-KG.HmUARTLGW
PARTIAL
RAWMSG 040219
RSSI -89
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 13
msgLoadHistory 7/-7/0/0/0/0/0/0/0/0/0/0
msgLoadHistoryAbs 13/6/13/13/13/13/13/13/13/13/13/13/13
owner F11034
owner_CCU VCCU
Helper:
CreditTimer 6777
FW 66561
Initialized 1
SendCnt 236
AckPending:
LastSendLen:
3
3
Log:
IDs:
PendingCMD:
RoundTrip:
Delay 0.00443100929260254
loadLvl:
lastHistory 1588180387.43014
MatchList:
1:CUL_HM ^A......................
Peers:
24E85D +24E85D,00,01,00
3B1776 +3B1776,00,01,00
3B2666 +3B2666,00,01,00
5E89ED +5E89ED,00,01,00
66BE6F +66BE6F,00,01,00
READINGS:
2020-04-28 14:48:07 D-HMIdAssigned F11034
2020-04-28 14:48:07 D-HMIdOriginal 59D9FE
2020-04-28 14:48:07 D-firmware 1.4.1
2020-04-28 14:48:07 D-serialNr OEQ0607458
2020-04-28 14:45:50 D-type HM-MOD-UART
2020-04-28 14:48:07 cond ok
2020-04-29 19:08:52 load 13
2020-04-28 15:58:12 loadLvl low
2020-04-28 14:48:03 state opened
helper:
Attributes:
devStateIcon opened:general_ok@green
group Gateway
hmId F11034
room Keller->Appartement,System->Gateways
List OG.HmUARTLGW Internals:
AssignedPeerCnt 30
CNT 27
Clients :CUL_HM:
DEF uart://192.168.143.14:23
DEVCNT 195
DevState 99
DevType UART
DeviceName 192.168.143.14:23
FD 27
FUUID 5da49bb7-f33f-6642-9d5f-6220929e5011d8f7
LastOpen 1588078083.76551
NAME OG.HmUARTLGW
NOTIFYDEV global
NR 399
NTFY_ORDER 50-OG.HmUARTLGW
PARTIAL
RAWMSG 0500002B99861038A4370000000A28D00B0040
RSSI -43
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 1
msgLoadHistory 0/0/0/0/0/0/0/-2/1/0/0/0
msgLoadHistoryAbs 1/1/1/1/1/1/1/1/3/2/2/2/2
owner F11034
owner_CCU VCCU
Helper:
CreditTimer 6798
FW 66561
Initialized 1
SendCnt 171
AckPending:
175:
cmd 02000000788002F110345F4A420101C800
dst 1
frame FD001301AF02000000788002F110345F4A420101C800102A
time 1588178987.73451
193:
cmd 02000000798002F110345F4A420101C800
dst 1
frame FD001301C102000000798002F110345F4A420101C800B0E3
time 1588179180.26826
83:
cmd 02000000BB8002F110344A1CE201017000
dst 1
frame FD0013015302000000BB8002F110344A1CE201017000AB78
time 1588177696.10762
89:
cmd 02000000BC8002F110344A1CE201017000
dst 1
frame FD0013015902000000BC8002F110344A1CE2010170005D76
time 1588177756.96516
LastSendLen:
3
3
Log:
IDs:
PendingCMD:
RoundTrip:
Delay 0.00493907928466797
loadLvl:
lastHistory 1588180387.49561
MatchList:
1:CUL_HM ^A......................
Peers:
1DAD8E +1DAD8E,00,01,00
224208 +224208,00,01,00
235CDE +235CDE,00,01,00
23A106 +23A106,00,01,00
2BDA12 +2BDA12,00,01,00
2D9B03 +2D9B03,00,01,00
306A91 +306A91,00,01,00
322E15 +322E15,00,01,00
335E73 +335E73,00,01,00
335EFB +335EFB,00,01,00
3360FC +3360FC,00,01,00
336AFC +336AFC,00,01,00
3376D3 +3376D3,00,01,00
347C9F +347C9F,00,01,00
34B28A +34B28A,00,01,00
36A04A +36A04A,00,01,00
37511A +37511A,00,01,00
3B2660 +3B2660,00,01,00
3B2DC7 +3B2DC7,00,01,00
404A80 +404A80,00,01,00
4EA08B +4EA08B,00,01,00
516CDA +516CDA,00,01,00
51B010 +51B010,00,01,00
5218CD +5218CD,00,01,00
531B56 +531B56,00,01,00
5E89ED +5E89ED,00,01,00
5EC6F5 +5EC6F5,00,01,00
5F4A42 +5F4A42,00,01,00
616DB3 +616DB3,00,01,00
623D37 +623D37,00,01,00
READINGS:
2020-04-28 14:48:07 D-HMIdAssigned F11034
2020-04-28 14:48:07 D-HMIdOriginal 59DA31
2020-04-28 14:48:07 D-firmware 1.4.1
2020-04-28 14:48:07 D-serialNr OEQ0607503
2020-04-28 14:45:51 D-type HM-MOD-UART
2020-04-28 14:48:07 cond ok
2020-04-29 18:34:26 load 1
2020-04-28 14:48:07 loadLvl low
2020-04-28 14:48:03 state opened
helper:
Attributes:
devStateIcon opened:general_ok@green
group Gateway
hmId F11034
room System->Gateways
@Otto natürlich haben ich die Konfiguration gespeichert ;-)
setze mal in den devices je ein prefered io, das jeweils den besten empfang haben sollte.
prefered io sind grundsätzlich für stationäre devices ratsam.
es hat mal jemand gesagt, dass beim start immer zuerst das erste oder letzte device im attr IOList der vccu assigned werden würde. eventuell hilft zusätzlich ein änderung der reihenfolge.
eventuell wird nach restart ein io gewählt, das gar nicht in reichweite ist, oder ein io das beim start überlastet (overload) wird. zb wenn erst alle das selbe io erhalten.
deshalb immer mit prefered ios arbeiten uns schön die load verteilen.
zudem sind die aktoren burst devices, was bei nichterreichbarkeit schnell zum problem werden kann.
pairen ist grundsätzlich nicht notwendig.
es könnte höchstens durch das pairen ein besseres io gewählt werden.
mit welchem befehl hast du immer gepairt?
Eventuell auch mal
autoReadReg 4_reqStatus
auf
autoReadReg 5_readMissing
umstellen.
Dann wird nur das abgerufen was nötig ist und nicht (immer) alles...
War mal ein Tipp von Martin an mich...
Gruß, Joachim
ergänzend: reqStatus erfolgt m.W. immer wenn Grund zur Annahme besteht dass der Aktorstatus nicht stimmt, also insbesondere wenn fhem down war. Das Problem entsteht dann quasi durch den Neustart.
Allerdings sollte dann eine Steuerbarkeit dennoch gegeben sein.
Weiterer Diagnosetipp: nach dem Neustart für den Aktor ein clear msgEvents senden (löscht im Cache unabgearbeitete Befehle) und danach eine Schaltung versuchen.
Wenn das klappt, ist der Tipp mit autoReadReg auf readMissing umso wertvoller.
Zitat von: frank am 29 April 2020, 20:46:00
setze mal in den devices je ein prefered io, das jeweils den besten empfang haben sollte.
prefered io sind grundsätzlich für stationäre devices ratsam.
Das hat geholfen. Vielen Dank für eure Tipps.