Hallo, ich habe zuhause fast an jedem Fester ein hm-sec-sco montiert und habe ein paar generische doif, die Nachrichten senden oder ein Display aktualisieren, wenn die Fenster geöffnet sind. Leider bekomme ich teilweise zyklisch Nachrichten und auch das Display wird zyklisch aktualisiert. Alles bezüglich Doif habe ich schon in diesem Threat (https://forum.fhem.de/index.php?topic=115805.0) geklärt.
Als Ursache sehe ich die Fenterkontakte, die zyklisch ihren Status an FHEM senden. Genau das sagt auch mein Eventmonitor. Ich habe bei den hm-sec-sco das Register R-cyclicInfoMsg auf on stehen damit ich eine Info bekomme, wenn die Batterien leer sind. Laut Beschreibung sollte nur eine Nachricht alle 24 Stunden kommen. Allerdings haben sich in den letzten zwei Stunden fast alle FKs einmal gemeldet. Habt ihr eine Idee, woran das liegen kann? Hier mal exemplarisch ein List eines Fensterkontakts:
Internals:
DEF 5E0CB8
FUUID 5de5695b-f33f-d318-adfd-6e3baee14125e3e4
IODev gl.gw.Wemos2
LASTInputDev gl.gw.Wemos2
MSGCNT 308
NAME wz.fk.FensterCouch
NR 213
NTFY_ORDER 48-wz.fk.FensterCouch
STATE closed
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
eventCount 277
gl.gw.Wemos1_MSGCNT 32
gl.gw.Wemos1_RAWMSG 0500005C18A6105E0CB830123506010000
gl.gw.Wemos1_RSSI -92
gl.gw.Wemos1_TIME 2024-05-17 03:20:04
gl.gw.Wemos2_MSGCNT 276
gl.gw.Wemos2_RAWMSG 0501004D26A6105E0CB830123506010000
gl.gw.Wemos2_RSSI -77
gl.gw.Wemos2_TIME 2024-05-17 14:29:20
lastMsg No:26 - t:10 s:5E0CB8 d:301235 06010000
protLastRcv 2024-05-17 14:29:20
protRcv 276 last_at:2024-05-17 14:29:20
protSnd 276 last_at:2024-05-17 14:29:20
protState CMDs_done
rssi_at_gl.gw.Wemos1 cnt:32 min:-95 max:-89 avg:-91.46 lst:-92
rssi_at_gl.gw.Wemos2 cnt:276 min:-95 max:-68 avg:-76.66 lst:-77
READINGS:
2024-05-07 08:31:17 Activity alive
2022-06-28 15:48:52 D-firmware 1.0
2022-06-28 15:48:52 D-serialNr OEQ1198546
2024-05-17 14:29:20 IODev gl.gw.Wemos2
2023-11-25 19:21:06 PairedTo 0x301235
2022-06-28 17:46:58 R-cyclicInfoMsg on
2022-06-28 17:46:58 R-eventDlyTime 0 s
2022-06-28 17:46:58 R-pairCentral 0x301235
2022-06-28 17:46:58 R-sabotageMsg on
2022-06-28 17:46:58 R-sign on
2023-11-25 19:21:06 RegL_00. 00:00 02:01 09:01 0A:30 0B:12 0C:35 10:01 14:06
2023-11-25 19:21:06 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2024-05-17 14:29:20 alive yes
2024-05-17 14:29:20 battery ok
2023-11-25 19:22:06 cfgState ok
2024-05-17 14:29:20 commState CMDs_done
2024-05-17 14:29:20 contact closed (to VCCU)
2023-11-25 18:29:20 powerOn 2023-11-25 18:29:20
2024-05-17 14:29:20 recentStateType info
2024-05-17 14:29:20 sabotageError off
2024-05-17 14:29:20 state closed
2024-05-16 11:22:45 trigger_cnt 124
helper:
HM_CMDNR 38
lastMsgTm 1715948960.86301
mId 00C7
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1715062896.3566
TmplTs 1715062896.3566
cmdKey 1:1:0::wz.fk.FensterCouch:00C7:01:
cmdLst:
assignHmKey noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|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 VCCU_Btn1,VCCU_Btn2,az.ht.Heizung_WindowRec,az.ht.Heizung_remote,az.ra.Rollladen,az.wt.Heizung_WindowRec,az.wt.Heizung_remote,ba.ht.Heizung_WindowRec,ba.ht.Heizung_remote,ba.ra.Links,ba.ra.Rechts,fl.ra.RollOben,fl.ra.RollUnten,ga.sa.Blumen,ga.sa.Licht,ga.sa.Pumpe,ga.sa.SprinklerHinten,ga.sa.SprinklerVorne,ga.sa.Unbenutzt6,ga.sa.Unbenutzt7,ga.sa.WasserVorgarten,ga.sa.Wassersteckdose,gh.ht.BadHeizung_WindowRec,gh.ht.BadHeizung_remote,gh.ht.FlurHeizung_WindowRec,gh.ht.FlurHeizung_remote,gh.ht.HeizOben_WindowRec,gh.ht.HeizOben_remote,gh.vi.FensterOffen,gh.wt.HeizOben_WindowRec,gh.wt.HeizOben_remote,gl.vi.WohnFensterOffen,ki.ht.Heizung_WindowRec,ki.ht.Heizung_remote,ki.ra.RollLinks,ki.ra.RollRechts,ki.wt.Heizung_WindowRec,ki.wt.Heizung_remote,ku.ht.Heizung_WindowRec,ku.ht.Heizung_remote,ku.ra.Rollladen,sz.ht.Heizung_WindowRec,sz.ht.Heizung_remote,sz.ra.Rollladen,sz.wt.Heizung_WindowRec,sz.wt.Heizung_remote,wz.ht.Couch_WindowRec,wz.ht.Couch_remote
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 0
raw 1
tpl 0
io:
flgs 0
newChn +5E0CB8,00,00,00
nextSend 1715948961.09714
rxt 2
vccu VCCU
p:
5E0CB8
00
00
00
prefIO:
mRssi:
mNo 26
io:
gl.gw.Wemos1:
gl.gw.Wemos2:
-75
-75
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO gl.gw.Wemos2
flg A
ts 1715948960.86301
ack:
HASH(0x3ca7db0)
2680023012355E0CB800
rssi:
at_gl.gw.Wemos1:
avg -91.46875
cnt 32
lst -92
max -89
min -95
at_gl.gw.Wemos2:
avg -76.6666666666666
cnt 276
lst -77
max -68
min -95
tmpl:
Attributes:
IOgrp VCCU
actCycle 002:50
actStatus alive
alias Couch WZ
autoReadReg 5_readMissing
expert defReg,rawReg
firmware 1.0
model HM-SEC-SCO
peerIDs 00000000
room CUL_HM,GoogleAssistant,Wohnzimmer
serialNr OEQ1198546
subType threeStateSensor
Ich habe auch schon überlegt ob es daran liegt dass ich R-cyclicInfoMsg bei allen FK zur gleichen Zeit eingerichtet habe und die zufälligerweise gerade in den letzten Stunden alle senden. Aber zwischendrin habe ich fast bei jedem FK die Batterien getauscht - der 24h Sendetimer müsste ja dann schon resetted worden sein.
Die Attribute "event-on-cnange-reading" und "timestamp-on-change-reading" kennst du?
Aaah, die kenne ich, hatte sie aber nicht mehr auf dem Schirm *kopfklatsch*
Ich versuche es mal damit...
Zitat von: teichtaucher am 17 Mai 2024, 14:47:27... an jedem Fester ein hm-sec-sco montiert ...
Laut Beschreibung sollte nur eine Nachricht alle 24 Stunden kommen. Allerdings haben sich in den letzten zwei Stunden fast alle FKs einmal gemeldet. Habt ihr eine Idee, woran das liegen kann?
Sorry das kann ich nicht unkommentiert stehen lassen ;D
HM-Sec-SC senden alle 24h, SCo schon immer ca alle Stunde. Es ist also alles in Ordnung mit den Dingern.
Natürlich ist event-on-change-reading die Lösung für eventbasierte Zustandsverarbeitung.