[Workaround] HM-Sec-SCo dead nach Alarm

Begonnen von kptkip, 06 August 2019, 14:47:15

Vorheriges Thema - Nächstes Thema

kptkip

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

FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

kptkip

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
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

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
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker

frank

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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

kptkip

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
FHEM Revision: 22312 auf RasPI3B+,1xNeumannCUL,HMLAN,1xRasPi3B+,2xRasPI ZERO W
CUL_HM:HM-Sec-SCo, HM-CC-RT-DN
Fritz: Fritz!Box 6590C,DECT301,DECT200
Shelly:Shelly1,Shelly2, ShellyBulb Xiaomi: Schalter, Fensterkontakte HUE: ConbeeII
Tasmota:SonoffBridge, Stecker