Hallo,
einer meiner zahlreichen HM-SEC-SCO (TF_Kinderz1) meldete heute Nacht ohne ersichtlichen Grund:
2023-06-23_04:49:31 TF_Kinderz1 contact: (to 216BB1)
2023-06-23_04:49:31 TF_Kinderz1 -
2023-06-23_04:49:31 TF_Kinderz1 contact: closed (to vccu)
2023-06-23_04:49:31 TF_Kinderz1 closed
Wobei die Homematic-Adresse 216BB1 NICHT zu meiner Konfiguration gehört. Ein Gerät oder eine Zentrale mit dieser Nummer habe ich nicht. Muss also eines der Fremdgeräte sein, die es in der Umgebung auch tatsächlich immer mal wieder gibt. Zum Glück hat er nicht "open" gemeldet, dann wäre der Alarm losgegangen. Das ist gar nicht so unwahrscheinlich, denn wir lüften gerade nachts, so dass Fenster offen stehen und wegen event-on-change-reading .* ein Zu- und wieder Aufmachen bemerkt würde. Dieser Sensor ist jedoch seit mehreren Tagen geschlossen.
Mich verwundert, dass dort "to 216BB1" steht, denn Pairing besteht eindeutig nur zu meiner vccu 2247A2. Allerdings ist die Nachricht dorthin leer, was wohl am aktivierten AES liegt. Danach hat er nochmal den richtigen Stand an die richtige Zentrale gemeldet. Durch die vorherige Meldung an Fremd wurde natürlich trotz event-on-change-reading .* ein event generiert. Sonst hätte ich das überhaupt nicht bemerkt und es wäre vermutlich auch egal.
Kann man denn Events durch solche Meldungen an fremde Zentralen ausschließen?
Anbei ein Listing des Sensors. Die vccu besteht aus HMLAN1, HMLAN2 und HMUART1.
Internals:
DEF 616DB1
FUUID 647b847b-f12f-9ab2-0af8-0078e673fffa0a8a
HMLAN1_MSGCNT 516
HMLAN1_RAWMSG D616DB1,0000,0DB82541,FF,FFC1,22A610616DB12247A206010000
HMLAN1_RSSI -63
HMLAN1_TIME 2023-06-23 11:13:10
HMLAN2_MSGCNT 516
HMLAN2_RAWMSG D616DB1,0000,84F9379A,FF,FFC2,22A610616DB12247A206010000
HMLAN2_RSSI -62
HMLAN2_TIME 2023-06-23 11:13:10
HMUART1_MSGCNT 195
HMUART1_RAWMSG 050000521CA610616DB12247A206010000
HMUART1_RSSI -82
HMUART1_TIME 2023-06-23 05:41:24
IODev HMLAN2
LASTInputDev HMLAN2
MSGCNT 1227
NAME TF_Kinderz1
NOTIFYDEV global
NR 2566
NTFY_ORDER 50-TF_Kinderz1
STATE closed
TYPE CUL_HM
chanNo 01
lastMsg No:22 - t:10 s:616DB1 d:2247A2 06010000
protLastRcv 2023-06-23 11:13:10
protRcv 520 last_at:2023-06-23 11:13:10
protSnd 519 last_at:2023-06-23 11:13:10
protState CMDs_done
rssi_at_HMLAN1 cnt:516 min:-72 max:-59 avg:-62.62 lst:-63
rssi_at_HMLAN2 cnt:516 min:-74 max:-50 avg:-61.93 lst:-62
rssi_at_HMUART1 cnt:195 min:-83 max:-76 avg:-79.9 lst:-82
READINGS:
2023-06-03 20:30:56 Activity alive
2022-07-21 08:21:26 CommandAccepted yes
2023-05-07 20:38:23 D-firmware 1.0
2023-05-07 20:38:23 D-serialNr REQ012457
2023-06-03 20:20:57 IODev HMLAN1
2023-05-07 20:38:24 PairedTo 0x2247A2
2020-10-29 10:17:55 R-cyclicInfoMsg on
2022-07-21 08:21:27 R-eventDlyTime 2 s
2020-10-29 10:17:57 R-msgScPosA open
2020-10-29 10:17:57 R-msgScPosB closed
2020-10-29 10:17:55 R-pairCentral 0x2247A2
2020-10-29 10:17:55 R-sabotageMsg on
2020-10-29 10:17:57 R-sign on
2020-10-29 10:17:55 R-transmDevTryMax 6
2020-10-29 10:17:57 R-transmitTryMax 6
2022-07-21 08:21:26 aesCommToDev ok
2022-07-21 08:21:26 aesKeyNbr 00
2023-06-23 11:13:10 alive yes
2023-06-23 11:13:10 battery ok
2023-06-23 09:51:22 cfgState ok
2023-06-23 11:13:10 commState CMDs_done
2023-06-23 11:13:10 contact closed (to vccu)
2023-05-07 20:20:09 powerOn 2023-05-07 20:20:09
2023-06-23 11:13:10 recentStateType info
2020-10-29 10:17:57 sabotageAttack_ErrIoAttack cnt 4
2023-06-23 11:13:10 sabotageError off
2023-06-23 11:13:10 state closed
2023-06-14 08:22:55 trigger_cnt 35
helper:
HM_CMDNR 34
mId 00C7
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1685816467.41859
TmplTs 1685816467.41859
cmdKey 1:1:0::TF_Kinderz1:00C7:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
unpair noArg
lst:
condition closed,open,tilted
peer
peerOpt ganzvielkramundallesvonmmir
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 1
raw 0
tpl 0
io:
flgs 0
newChn +616DB1,00,02,00
nextSend 1687511590.37704
prefIO
rxt 2
vccu vccu
p:
616DB1
00
02
00
mRssi:
mNo 22
io:
HMLAN1:
-63
-63
HMLAN2:
-58
-58
HMUART1:
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMLAN1
flg A
ts 1687511590.28607
ack:
HASH(0x562168657c28)
2280022247A2616DB100
rssi:
at_HMLAN1:
avg -62.6220930232559
cnt 516
lst -63
max -59
min -72
at_HMLAN2:
avg -61.937984496124
cnt 516
lst -62
max -50
min -74
at_HMUART1:
avg -79.9076923076923
cnt 195
lst -82
max -76
min -83
tmpl:
hmccu:
Attributes:
IODev HMLAN2
IOgrp vccu
actCycle 001:05
actStatus alive
autoReadReg 5_readMissing
devStateIcon closed:fts_window_1w@00FF00 open:fts_window_1w_open@yellow
event-on-change-reading .*
expert defReg,allReg
firmware 1.0
model HM-SEC-SCO
peerIDs 00000000
serialNr REQ012457
subType threeStateSensor
Zitat von: topfi am 23 Juni 2023, 12:10:10Mich verwundert, dass dort "to 216BB1" steht, denn Pairing besteht eindeutig nur zu meiner vccu 2247A2.
eventuell eine korrupte message, oder ein fw bug.
meine hm-cc-tc senden auch an beliebige devices, die während einer bereits laufenden kommunikation mit einem anderen device quasi zufällig dazwischen quatschen.
da ist es ein fw bug.
Zitat von: topfi am 23 Juni 2023, 12:10:10Allerdings ist die Nachricht dorthin leer, was wohl am aktivierten AES liegt.
sowas macht aes nicht.
aes ist allerdings auch ziehmlich sinnlos, wenn man nur den default key nutzt, so wie du es tust.
Zitat von: topfi am 23 Juni 2023, 12:10:10Kann man denn Events durch solche Meldungen an fremde Zentralen ausschließen?
umgekehrt.
dein alarm triggerst du nur auf "contact: open (to vccu)"
Danke für die interessanten Antworten.
Ja, stimmt. Die notifys sollte ich darauf ändern, gute Idee. Ist aufwendig, weil sehr viele, aber lohnt sich.
Ich habe von Anfang an einen eigenen AES key vergeben, bevor ich überhaupt was angelernt habe. Den hash sieht man auch in der vccu unter HMkey und HMkey2. Der beim Device angezeigte aesKeyNbr 00 sollte doch hiervon der erste sein.
Mein Verständnis ist, dass erst nach einem Ack (TF sendet, vccu und Tf verständigen sich über den richtigen Key, Ack) ein event generiert wird. Vielleicht verstehe ich das ja falsch?
aesKeyNbr=00 ist der default key.
der erste eigene key hat die nummer 02, bei jedem weteren erhöht sich die zahl jeweils um 2.
nach der definition von keys bei vccu/io müssen diese auch in die devices geschrieben werden, soweit mir bekannt ist => set assignHmKey.
ich habe noch nie einen eigenen key gesetzt.
es entscheidet immer der empfänger eines "befehls", ob er zusätzlich eine aes signierung vordert.
daher empfiehlt sich auch die zentrale (fhem) zu schützen, wenn diese zb auf trigger von sensoren reagieren soll => attr aesCommReq 1