Hallo,
Ich habe seit Jahren einen HM-SEC-SCO (threeStateSensor) im Einsatz, der über VCCU meldet, ob eine Tür zu oder auf ist.
Nun ist die Batterie anscheinend aus und der Sensor meldet natürlich nix mehr.
Aber mir kommt komisch vor, dass die folgenden Readings unterschiedliches anzeigen:
Activity dead
state closed
alive yes
Vor allem "Activity" und "alive" sollten sich doch nicht widersprechen. Oder ist das so gedacht?
Alle Geräte sind versionsmäßig auf dem letzten Stand.
Hier ein list des HM-SEC-SCO:
Internals:
DEF 41ABAE
FUUID 5c43b90a-f33f-0b7a-ae9e-f7f3d6f922c5d627
FVERSION 10_CUL_HM.pm:0.252980/2021-12-05
IODev HmUART
NAME WZ.HeizungKontakt
NR 328
NTFY_ORDER 48-WZ.HeizungKontakt
STATE closed
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
READINGS:
2021-12-24 09:29:25 Activity dead
2021-07-30 14:09:33 CommandAccepted no
2019-08-05 18:27:38 D-firmware 1.0
2019-08-05 18:27:38 D-serialNr MEQ1406449
2021-12-24 06:29:27 IODev HmUART
2021-07-30 14:08:23 PairedTo 0x000000
2021-04-26 13:30:55 R-cyclicInfoMsg on
2021-04-26 13:30:55 R-eventDlyTime 0 s
2021-04-26 13:30:55 R-pairCentral 0x000000
2021-04-26 13:30:55 R-sabotageMsg on
2021-04-26 13:30:55 R-sign on
2021-07-30 14:08:23 RegL_00. 00:00 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06
2021-07-30 14:08:24 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2021-12-12 20:47:45 alive yes
2021-12-12 20:47:45 battery low
2021-11-02 22:03:44 cfgState PairMism
2021-07-30 14:09:33 commState CMDs_done
2021-12-12 20:47:45 contact closed (to broadcast)
2021-06-30 15:54:08 powerOn 2021-06-30 15:54:08
2021-12-12 20:47:45 recentStateType info
2021-07-30 14:09:33 sabotageAttack_ErrIoAttack_cnt 1
2021-12-12 20:47:45 sabotageError off
2021-12-12 20:47:45 state closed
2020-02-24 16:22:57 trigDst_broadcast noConfig
2021-12-11 08:18:06 trigger_cnt 4
helper:
HM_CMDNR 33
mId 00C7
peerFriend peerAct,peerVirt
peerIDsState complete
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
bm:
CUL_HM_Get:
cnt 13
dmx -1000
dtot 0
dtotcnt 0
mTS 25.12. 10:56:26
max 0.0010221004486084
tot 0.00729703903198242
mAr:
HASH(0x4ef9030)
WZ.HeizungKontakt
?
CUL_HM_Set:
cnt 41
dmx -1000
dtot 0
dtotcnt 0
mTS 24.12. 06:39:24
max 0.0329458713531494
tot 0.059135913848877
mAr:
HASH(0x4ef9030)
WZ.HeizungKontakt
?
cfgChk:
cmds:
TmplKey :no:1640323768.34111
TmplTs 1640323768.34111
cmdKey 1:1:0::WZ.HeizungKontakt: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 BZ.Fussboden_Sw,HM_61725F_Sw_01,HM_61725F_Sw_02,TO.DimmerGelaender,TO.Stimmungslicht_Sw_01,TO.Stimmungslicht_Sw_02,TO.Stimmungslicht_Sw_03,TO.Stimmungslicht_Sw_04,TO.Ventil_Ahorn,TO.Ventil_Blumen,TO.Ventil_Gelaender,TO.Ventil_Hecke,TO.Ventil_Sw_02,TO.Ventil_Sw_03_kaputt,TO.Ventil_Tomaten,TO.Ventil_Zitrone,TO.Wand,TU.Ventil_Gemuese,TU.Ventil_Gross,TU.Ventil_Tomaten,TU.Ventil_klein,TW.DimmerGelaender,TW.Podest_Sw_01,TW.Podest_Sw_02,TW.Podest_Sw_03,TW.Podest_Sw_04,TW.Stimmungslicht2_Sw_01,TW.Stimmungslicht2_Sw_02,TW.Stimmungslicht2_Sw_03,TW.Stimmungslicht2_Sw_04,TW.Stimmungslicht_Segel_links,TW.Stimmungslicht_Segel_rechts,TW.Stimmungslicht_Sw_01,TW.Stimmungslicht_Sw_02,TW.Stimmungslicht_Sw_03,TW.Stimmungslicht_Sw_04,TW.Ventil_Ahorn,TW.Ventil_Bank,TW.Ventil_Erdbeeren,TW.Ventil_Gelaender,TW.Ventil_GelaenderH,TW.Ventil_Kraeuter,TW.Ventil_Lavendel,TW.Ventil_Obst,TW.Ventil_Olive,TW.Ventil_Podest,TW.Ventil_Podest_klein,TW.Ventil_Zypresse,VCCU_Btn1,WZ.Aufgang
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 +41ABAE,00,00,00
rxt 2
vccu VCCU
p:
41ABAE
00
00
00
prefIO:
mRssi:
mNo
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
tmpl:
Attributes:
IOgrp VCCU
actCycle 002:50
actStatus dead
alias WZ.HeizungKontakt
autoReadReg 4_reqStatus
commStInCh off
devStateIcon open:tuer_fenster_kontakt closed:tuer_fenster_kontakt_closed
expert defReg,rawReg
firmware 1.0
forceEvents 1
model HM-SEC-SCO
peerIDs 00000000
room CUL_HM,Wohnzimmer
serialNr MEQ1406449
subType threeStateSensor
Vielen Dank im Voraus
Frohe Weihnachten noch, lg, Gerhard
ZitatAber mir kommt komisch vor, dass die folgenden Readings unterschiedliches anzeigen:
warum sollen verschiedene readings alle das selbe anzeigen?
ausserdem ist immer der timestamp entscheidend, denn genau genommen, ist der wert nur zu dem zeitpunkt gültig.
die letzte message vom device kam scheinbar am 2021-12-12 20:47:45.
Activity wird vom actiondetector "berechnet", je nach konfiguration diverser attribute.
theoretisch wurde Activity=dead für diesen sensor ca 3 std nach der letzten message zum ersten mal gemeldet.
und anschliessend von hminfo/hminfotools entsprechend gemeldet.
was alive genau bedeutet und welche werte hier erscheinen können, keine ahnung. eventuell ist alive immer "yes" und ändert nur den timestamp. ebenfalls abhängig von attributen.
"attr forceEvents 1"
warum hast du nicht wie ausdrücklich von mir hingewiesen die events reduziert?
ausserdem ist der sensor nicht mal gepairt. warum?
Moin,
blöde Frage: Was passiert, wenn du die Batterie wechselst?
Gruß,
MDietrich
Hallo,
Zitat von: frank am 27 Dezember 2021, 11:57:36
warum sollen verschiedene readings alle das selbe anzeigen?
ausserdem ist immer der timestamp entscheidend, denn genau genommen, ist der wert nur zu dem zeitpunkt gültig.
Mir ist das nur aufgefallen, weil sich "Activity=dead" und "alive=yes" halt offensichtlich widersprochen haben.
Zum Auswerten von Zuständen ist es dann wohl besser nur Activity zu prüfen.
Zitat von: frank am 27 Dezember 2021, 11:57:36
"attr forceEvents 1"
warum hast du nicht wie ausdrücklich von mir hingewiesen die events reduziert?
Da bin ich nach der Anleitung vorgegangen und habe es damals wohl blöderweise als nicht so wichtig erachtet.
Ist nun geändert. Danke!
Zitat von: frank am 27 Dezember 2021, 11:57:36
ausserdem ist der sensor nicht mal gepairt. warum?
Ehrlich gesagt: keine Ahnung.
Jetzt wo wieder eine Batterie drinnen ist, steht da auch die richtige PairedTo-ID.
Zitat von: MDietrich am 28 Dezember 2021, 08:40:18
blöde Frage: Was passiert, wenn du die Batterie wechselst?
Jetzt scheint alles wieder zu passen, der Sensor ist gepairt und funktioniert.
lg, Gerhard