Hallo,
ich bin mir nicht sicher, ob das HM-Forum passend ist oder nicht - falls es wo anders besser hinpasst, gerne verschieben.
Ich beobachte seit einiger Zeit ein sehr seltsames Phänomen:
Ich verliere regelmäßig (alle paar Wochen) den Connect zu meinen HM-Fenstersensoren (HM-Sec-SCo). Um die wieder ins System zu kriegen, habe ich so ziemlich alle Threads zum Thema durchwühlt und bekomme die nach komplettem Entfernen, Reseten und wieder einbinden dann auch irgendwann wieder ans Laufen - wenn auch mühselig, aber es geht.
Nach einiger Zeit sind die Fensterkontakte dann aber wieder auf "dead". Ich habe mich ewig gewundert, woran das liegen könnte und bin einfach nicht schlau daraus geworden.
Nachdem ich das in den letzten Monaten bestimmt 3-4 Mal erleben musste, erkenne ich nun langsam ein Muster:
Die Fensterkontakte verlieren nach kurzer Zeit (2-3 Stunden) den Kontakt (Activity:dead), wenn der Alarm durch einen Fensterkontakt ausgelöst wird.
Kurz das Setting:
- 3 Fenstersensoren in einem Raum,
- angebunden über eine VCCU, die an einer Antenne eines Neuman-CUl (1x400er; 3x 800er CULs) hängt,
- HM Rauchmelder (HM-SEC-SD-2) als Sirene eingebunden,
- Alarm Modul mit den 3 Sensoren als Sensor und dem Rauchmelder (via HM-Team) als Aktor.
Hier mal die Geräte-Definitionen:
VCCU:
[code]defmod VCCU CUL_HM 74826A
attr VCCU .mId FFF0
attr VCCU DbLogExclude .*
attr VCCU IODev CULHat4
attr VCCU IOList CULHat4
attr VCCU IOgrp VCCU
attr VCCU alias Virtuelle VCCU Homematic
attr VCCU expert 2_raw
attr VCCU group Infrastruktur
attr VCCU hmKey XXXXXX
attr VCCU icon cul_868
attr VCCU model CCU-FHEM
attr VCCU room Homematic
attr VCCU subType virtual
attr VCCU webCmd update
setstate VCCU CULHat4:ok
setstate VCCU 2019-08-06 12:29:21 IOopen 1
setstate VCCU 2019-08-06 12:29:21 state CULHat4:ok
setstate VCCU 2019-07-17 05:17:12 unknown_216114 received
setstate VCCU 2019-07-10 12:57:25 unknown_296CAA received
setstate VCCU 2019-08-04 12:23:43 unknown_3CDD6B received
setstate VCCU 2019-07-17 10:34:07 unknown_3FDBE2 received
setstate VCCU 2019-06-18 15:05:50 unknown_589B3A received
setstate VCCU 2019-06-14 19:17:55 unknown_5ECC53 received
setstate VCCU 2019-08-04 15:20:46 unknown_6533D1 received
setstate VCCU 2019-07-28 22:26:31 unknown_663E9A received
setstate VCCU 2019-07-28 22:25:34 unknown_664214 received
setstate VCCU 2019-07-28 22:27:35 unknown_664216 received
setstate VCCU 2019-06-18 15:10:08 unknown_8F65AF received
setstate VCCU 2019-07-13 23:48:27 unknown_AA8551 received[/code]
Einer der Fensterkontakte:
defmod WZ_Fenster_Links CUL_HM 664214
attr WZ_Fenster_Links .mId 00C7
attr WZ_Fenster_Links DbLogExclude .*
attr WZ_Fenster_Links IODev CULHat4
attr WZ_Fenster_Links IOgrp VCCU:CULHat4
attr WZ_Fenster_Links actCycle 002:50
attr WZ_Fenster_Links actStatus dead
attr WZ_Fenster_Links alarmDevice Sensor
attr WZ_Fenster_Links alarmSettings alarm0,|WZ_Fenster_Links:open|Im Wohnzimmer Links|on
attr WZ_Fenster_Links autoReadReg 4_reqStatus
attr WZ_Fenster_Links devStateIcon open:fts_door_open@red closed:fts_door@green
attr WZ_Fenster_Links expert 2_raw
attr WZ_Fenster_Links firmware 1.0
attr WZ_Fenster_Links group Geräte für Alarm
attr WZ_Fenster_Links model HM-SEC-SCO
attr WZ_Fenster_Links peerIDs 00000000,
attr WZ_Fenster_Links room 01_Wohnzimmer,AlarmRoom,Homematic
attr WZ_Fenster_Links serialNr OEQ1983489
attr WZ_Fenster_Links stateFormat state
attr WZ_Fenster_Links subType threeStateSensor
setstate WZ_Fenster_Links closed
setstate WZ_Fenster_Links 2019-07-28 22:29:48 .D-devInfo 810101
setstate WZ_Fenster_Links 2019-07-28 22:29:48 .D-stc 80
setstate WZ_Fenster_Links 2019-07-28 22:27:56 .R-msgScPosA open
setstate WZ_Fenster_Links 2019-07-28 22:27:56 .R-msgScPosB closed
setstate WZ_Fenster_Links 2019-07-28 22:27:56 .R-transmDevTryMax 6
setstate WZ_Fenster_Links 2019-07-28 22:27:56 .R-transmitTryMax 6
setstate WZ_Fenster_Links 2019-07-28 22:29:48 .peerListRDate 2019-07-28 22:29:48
setstate WZ_Fenster_Links 2019-08-04 15:52:39 .protLastRcv 2019-08-04 15:52:39
setstate WZ_Fenster_Links 2019-08-04 18:43:16 Activity dead
setstate WZ_Fenster_Links 2019-07-28 22:29:30 CommandAccepted yes
setstate WZ_Fenster_Links 2019-07-28 22:29:48 D-firmware 1.0
setstate WZ_Fenster_Links 2019-07-28 22:29:48 D-serialNr OEQ1983489
setstate WZ_Fenster_Links 2019-07-28 22:29:48 PairedTo 0x74826A
setstate WZ_Fenster_Links 2019-07-28 22:27:56 R-cyclicInfoMsg on
setstate WZ_Fenster_Links 2019-07-28 22:27:56 R-eventDlyTime 0 s
setstate WZ_Fenster_Links 2019-07-28 22:27:56 R-pairCentral 0x74826A
setstate WZ_Fenster_Links 2019-07-28 22:27:56 R-sabotageMsg on
setstate WZ_Fenster_Links 2019-07-28 22:27:56 R-sign on
setstate WZ_Fenster_Links 2019-07-28 22:29:48 RegL_00. 00:00 02:01 09:01 0A:74 0B:82 0C:6A 10:01 14:06
setstate WZ_Fenster_Links 2019-07-28 22:29:48 RegL_01. 00:00 08:01 20:9C 21:00 30:06
setstate WZ_Fenster_Links 2019-07-28 22:27:56 aesCommToDev ok
setstate WZ_Fenster_Links 2019-07-28 22:27:55 aesKeyNbr 00
setstate WZ_Fenster_Links 2019-08-04 15:52:39 alive yes
setstate WZ_Fenster_Links 2019-08-04 15:52:39 battery ok
setstate WZ_Fenster_Links 2019-08-04 15:52:39 contact closed (to VCCU)
setstate WZ_Fenster_Links 2019-07-28 22:27:00 powerOn 2019-07-28 22:27:00
setstate WZ_Fenster_Links 2019-08-04 15:52:39 recentStateType info
setstate WZ_Fenster_Links 2019-08-04 15:52:39 sabotageError off
setstate WZ_Fenster_Links 2019-08-04 15:52:39 state closed
setstate WZ_Fenster_Links 2019-07-28 22:27:02 trigDst_broadcast noConfig
setstate WZ_Fenster_Links 2019-08-04 10:45:41 trigger_cnt 29
Und noch das Alarm-Device:
defmod Alarmanlage Alarm
attr Alarmanlage armact set teleBot send Alarm ist scharf.
attr Alarmanlage armdelay 00:10
attr Alarmanlage armwait set teleBot send Alarm wird in 10 sek scharf geschaltet.
attr Alarmanlage cancelact set Rauchmelder_Team alarmOff
attr Alarmanlage disarmact set teleBot send Alarm ist wurde entschärft.
attr Alarmanlage level0autocan 0:00
attr Alarmanlage level0cond 1
attr Alarmanlage level0end 23:59
attr Alarmanlage level0msg Einbruch in Abwesenheit
attr Alarmanlage level0offact set teleBot send Alarm abgebrochen.;;set Rauchmelder_Team alarmOff;;
attr Alarmanlage level0onact set teleBot send $SHORT;;set Rauchmelder_Team alarmOn;;
attr Alarmanlage level0start 0:00
attr Alarmanlage level1autocan 0:00
attr Alarmanlage level1cond 1
attr Alarmanlage level1end 23:59
attr Alarmanlage level1msg Zutritt bei Anwesenheit
attr Alarmanlage level1start 0:00
attr Alarmanlage level2autocan 0:00
attr Alarmanlage level2cond 1
attr Alarmanlage level2end 23:59
attr Alarmanlage level2msg --
attr Alarmanlage level2start 0:00
attr Alarmanlage level3autocan 0:00
attr Alarmanlage level3cond 1
attr Alarmanlage level3end 23:59
attr Alarmanlage level3msg --
attr Alarmanlage level3start 0:00
attr Alarmanlage level4autocan 0:00
attr Alarmanlage level4cond 1
attr Alarmanlage level4end 23:59
attr Alarmanlage level4msg --
attr Alarmanlage level4start 0:00
attr Alarmanlage level5autocan 0:00
attr Alarmanlage level5cond 1
attr Alarmanlage level5end 23:59
attr Alarmanlage level5msg --
attr Alarmanlage level5start 0:00
attr Alarmanlage level6autocan 0:00
attr Alarmanlage level6cond 1
attr Alarmanlage level6end 23:59
attr Alarmanlage level6msg Fenster sind offen
attr Alarmanlage level6start 0:00
attr Alarmanlage level7autocan 0:00
attr Alarmanlage level7cond 1
attr Alarmanlage level7end 23:59
attr Alarmanlage level7msg Rauchalarm
attr Alarmanlage level7offact set teleBot send Alarm abgebrochen.;;
attr Alarmanlage level7onact set teleBot send $SHORT;;
attr Alarmanlage level7start 0:00
attr Alarmanlage lockstate unlocked
attr Alarmanlage room AlarmRoom
setstate Alarmanlage \040
setstate Alarmanlage 2019-08-04 16:26:48 level0 disarmed
setstate Alarmanlage 2019-07-28 22:16:09 level1 disarmed
setstate Alarmanlage 2019-07-28 22:16:09 level2 disarmed
setstate Alarmanlage 2019-07-28 22:16:09 level3 disarmed
setstate Alarmanlage 2019-07-28 22:16:09 level4 disarmed
setstate Alarmanlage 2019-07-28 22:16:09 level5 disarmed
setstate Alarmanlage 2019-07-28 22:16:09 level6 disarmed
setstate Alarmanlage 2019-07-28 22:16:09 level7 armed
setstate Alarmanlage 2019-06-17 20:48:23 lockstate unlocked
setstate Alarmanlage 2019-08-04 16:26:48 savedate 2019-08-04 16:26:48
setstate Alarmanlage 2019-08-04 16:26:48 short
setstate Alarmanlage 2019-08-06 14:40:33 state
Den Grund kann ich zwar immer noch nicht finden, sondern nur die o.g. Beobachtung feststellen.
Hat jemand von Euch auch so ein seltsames Phänomen?
Gruß
kptkip
poste mal "list WZ_Fenster_Links".
ständig löschen, resetten, pairen ist übrigens völlig sinnlos eher kontraproduktiv.
dead nach 2std 50min ist doch so eingestellt.
Aloa Frank,
anbei das list-Ergebnis:
CULHat4_MSGCNT 1
CULHat4_RAWMSG A0DD0A61066421474826A06010000::-64:CULHat4
CULHat4_RSSI -64
CULHat4_TIME 2019-08-06 15:02:55
DEF 664214
FUUID 5d3e04d2-f33f-57e4-5554-85c2f8df6c29fc8a
IODev CULHat4
LASTInputDev CULHat4
MSGCNT 1
NAME WZ_Fenster_Links
NOTIFYDEV global
NR 164
NTFY_ORDER 50-WZ_Fenster_Links
STATE closed
TYPE CUL_HM
chanNo 01
lastMsg No:D0 - t:10 s:664214 d:74826A 06010000
protLastRcv 2019-08-06 15:02:55
protRcv 1 last_at:2019-08-06 15:02:55
protSnd 1 last_at:2019-08-06 15:02:55
protState CMDs_done
rssi_at_CULHat4 cnt:1 min:-64 max:-64 avg:-64 lst:-64
READINGS:
2019-08-06 15:10:25 Activity alive
2019-07-28 22:29:30 CommandAccepted yes
2019-07-28 22:29:48 D-firmware 1.0
2019-07-28 22:29:48 D-serialNr OEQ1983489
2019-07-28 22:29:48 PairedTo 0x74826A
2019-07-28 22:27:56 R-cyclicInfoMsg on
2019-07-28 22:27:56 R-eventDlyTime 0 s
2019-07-28 22:27:56 R-pairCentral 0x74826A
2019-07-28 22:27:56 R-sabotageMsg on
2019-07-28 22:27:56 R-sign on
2019-07-28 22:29:48 RegL_00. 00:00 02:01 09:01 0A:74 0B:82 0C:6A 10:01 14:06
2019-07-28 22:29:48 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2019-07-28 22:27:56 aesCommToDev ok
2019-07-28 22:27:55 aesKeyNbr 00
2019-08-06 15:02:55 alive yes
2019-08-06 15:02:55 battery ok
2019-08-06 15:02:55 contact closed (to VCCU)
2019-07-28 22:27:00 powerOn 2019-07-28 22:27:00
2019-08-06 15:02:55 recentStateType info
2019-08-06 15:02:55 sabotageError off
2019-08-06 15:02:55 state closed
2019-07-28 22:27:02 trigDst_broadcast noConfig
2019-08-04 10:45:41 trigger_cnt 29
helper:
HM_CMDNR 208
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +664214,00,01,00
nextSend 1565096575.64711
rxt 2
vccu VCCU
p:
664214
00
01
00
prefIO:
CULHat4
mRssi:
mNo D0
io:
CULHat4:
-60
-60
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO CULHat4
flg A
ts 1565096575.5479
ack:
HASH(0x4932088)
D0800274826A66421400
rssi:
at_CULHat4:
avg -64
cnt 1
lst -64
max -64
min -64
tmpl:
Attributes:
DbLogExclude .*
IODev CULHat4
IOgrp VCCU:CULHat4
actCycle 002:50
actStatus alive
alarmDevice Sensor
alarmSettings alarm0,|WZ_Fenster_Links:open|Im Wohnzimmer Links|on
autoReadReg 4_reqStatus
devStateIcon open:fts_door_open@red closed:fts_door@green
expert 2_raw
firmware 1.0
group Geräte für Alarm
model HM-SEC-SCO
peerIDs 00000000,
room 01_Wohnzimmer,AlarmRoom,Homematic
serialNr OEQ1983489
stateFormat state
subType threeStateSensor
Das mit den 2:50 actCycle stimmt.
Ich frage mich nur, warum das 3-4 Wochen alles super läuft (Fenster auf, zu, auf, zu,...) und dann auf einmal nach dem Alarm anfängt, rum zu zicken. Und gleich alle drei Fenstersensoren auf einmal. :o
Gruß kptkip
Habe gerade etwas weiter am Thema gearbeitet:
Nachdem ich bei den Fensterkontakten die Attribute alarmDevice und alarmSettings gelöscht habe, reagieren sie wieder.
Auch wenn es sich komisch anhört, aber in Kombination mit Alarm und als Sensor, spinnt mein System nach ausgelöstem Alarm.
Folgende Strategie fahre ich jetzt gleich mal:
Ich lege zu jedem physikalischen Fensterkontakt einen Dummy an und einen Notify, der den Status des jeweiligen Fensterkontakts prüft.
Dann werden die Dummies als Sensoren angelegt und dann mal ein Testlauf durchgeführt.
Melde mich wieder.... ;-)
Gruß
kptkip
funk (rssi) ist gut.
mit dem register cyclicInfoMsg=on sendet der fk 1x in der stunde eine statusinfo. zusätzlich kommen noch die messages beim öffnen und schliessen.
wenn diese messages alle empfangen werden, kann das device niemals dead melden. es könnte sogar jede 2. message verloren gehen, ohne dass der actiondetector dead meldet.
ich würde mal beim cul verbose=4 einschalten und schauen, ob alle raw messages im log auftauchen.
Aloa,
hier mal ein kurzer Zwischenbericht meiner oben beschriebenen Strategie.
Ich hab also für jeden Fensterkontakt einen Dummy angelegt und einen Notify, der dem Dummy den gleichen Status gibt, wie der Original-Fensterkontakt. Dann dem Dummy die Zuordnung als Sensor im Alarm-Modul gegeben.
Und schwupps - die Fensterkontakte fliegen nicht mehr raus!
Zugegebenermaßen ist das ein dämlicher und mühseliger Workaround. Aber es klappt.
Wenn ich aus dem Urlaub wieder da bin, dann forsche ich mal weiter nach der Problematik.
Gruß
Kptkip