[gelöst] HM-Sec-SC-2 nach (nahezu immer) 60 min dead

Begonnen von DeeSPe, 01 August 2016, 15:37:05

Vorheriges Thema - Nächstes Thema

DeeSPe

Ich habe bei mir nur einen einzigen HM-Sec-SC-2 verbaut und der macht eigentlich immer Probleme im ActionDetector.
Sobald er ausgelöst wird kommt das Event wie gewünscht an, aber nach (nahezu immer) 60 min (manchmal sind es auch 70 min) im ActionDetector ein "dead" des Geräts.
Sobald dann wieder ausgelöst wird kommt das Event wie gewünscht, 2 min später dann ein "alive" um dann 60 min später wieder auf "dead" zu wechseln.
Woran kann das liegen bzw. wie kann ich das Verhalten ändern?

Vielen Dank im Voraus.

Gruß
Dan

P.S. Dieses Verhalten ist mir erst beim Umzug meiner FHEM Installation aufgefallen. Da danach einige HM Geräte auf dead standen, habe ich mir ein entsprechendes Notify für den ActionDetector geschrieben um über tote Geräte informiert zu werden.
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

frank

ich rate mal, weil es keine infos gibt: attr actioncycle falsch 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

Burny4600

Gibt es hierzu passende Vorgaben?
Habe zwar den HM-Sec-SCo in Verwendung, aber diese Sensoren melden sich bei mir auch mit dead, unkn und MISSING ACK.
Standart Vorgabe durch die Installation ist actCycle 000:50.

LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

DeeSPe

Zitat von: frank am 01 August 2016, 16:18:53
ich rate mal, weil es keine infos gibt: attr actioncycle falsch eingestellt.

Ich hatte zwar versucht alle Infos rund um HM zu lesen und zu verstehen, aber actioncycle habe ich bisher nicht gekannt und geprüft.
Werde das nachher zu hause sofort checken, mit meinen anderen HM-Sec-SCo gegenprüfen und Rückmeldung geben.

Danke.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Burny4600

#4
Was mir zudem noch aufgefallen ist, ist das die fhemwiki Beschreibung abweicht von FHEM.
Das sind folgende Parameter.
Auszug aus http://www.fhemwiki.de/wiki/HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch
attr HM_Fensterstatus_BadEG expert 2_full   => diesen gibt es unter FHEM nicht und war standartmässig auf 2_raw
attr HM_Fensterstatus_BadEG peerIDs 00000000  => dieser Parameter wurde bei der Pairinganlage nicht angelegt.
Zudem ist im Wiki ein Fehler: attr HM_Fensterstatus_BadEG peerIDs 00000000,

Welche Einstellungen sollen nun aktuell ausgeführt werden?

LIST
Internals:
   CFGFN      /media/hdd/fhem/mycfg/Ueberwachung/Sensoren.cfg
   DEF        4xxxxx
   IODev      nanoCUL868_HM
   LASTInputDev nanoCUL868_HM
   MSGCNT     1
   NAME       HM_4xxxxx
   NR         926
   NTFY_ORDER 50-HM_4xxxxx
   STATE      OFFEN
   TYPE       CUL_HM
   lastMsg    No:4C - t:41 s:4xxxxx d:000000 011FC8
   nanoCUL868_HM_MSGCNT 1
   nanoCUL868_HM_RAWMSG A0C4C86414C0C76000000011FC8::-79:nanoCUL868_HM
   nanoCUL868_HM_RSSI -79
   nanoCUL868_HM_TIME 2016-08-01 12:16:07
   protCmdPend 3 CMDs pending
   protLastRcv 2016-08-01 12:16:07
   protResnd  1 last_at:2016-08-01 12:16:12
   protSnd    1 last_at:2016-08-01 12:16:07
   protState  CMDs_pending
   rssi_at_nanoCUL868_HM min:-79 cnt:1 max:-79 avg:-79 lst:-79
   Readings:
     2016-08-01 13:12:25   Activity        dead
     2016-07-30 12:51:26   D-firmware      1.0
     2016-07-30 12:51:26   D-serialNr      NEQxxxxxxx
     2016-07-30 12:51:26   R-pairCentral   set_0xF12347
     2016-07-30 12:51:26   aesKeyNbr       00
     2016-08-01 03:40:04   alive           yes
     2016-08-01 12:16:07   battery         ok
     2016-08-01 12:16:07   contact         open (to broadcast)
     2016-08-01 03:40:04   recentStateType info
     2016-08-01 03:40:04   sabotageError   off
     2016-08-01 12:16:07   state           open
     2016-08-01 12:16:07   trigDst_broadcast noConfig
     2016-08-01 12:16:07   trigger_cnt     31
   cmdStack:
     ++A001F123474xxxxxxxxxxxxxxxxxxxxx0
     ++A001F123474xxxxxxxxxxxxxxxxxxxxx1
     ++A001F123474xxxxxxxx3
   Helper:
     HM_CMDNR   76
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4xxxxxx,02,00,00
       nextSend   1470046567.60244
       prefIO
       rxt        2
       vccu
       p:
         4xxxxxx
         00
         00
         00
     Mrssi:
       mNo        4C
       Io:
         nanoCUL868_HM -88
     Prt:
       bErr       0
       sProc      2
       wuReSent   2
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_nanocul868_hm:
         avg        -79
         cnt        1
         lst        -79
         max        -79
         min        -79
Attributes:
   IODev      nanoCUL868_HM
   actCycle   000:50
   actStatus  dead
   alias      EG Stiegenhaus Haustüre - Öffnungssensor
   autoReadReg 4_reqStatus
   devStateIcon ZU:fts_door OFFEN:fts_door_open@red
   eventMap   closed:ZU open:OFFEN
   expert     2_defReg+raw
   firmware   1.0
   group      Sensoren
   icon       fts_door
   model      HM-SEC-SCo
   peerIDs    00000000
   room       Rolllaeden,Stiegenhaus,_Alarme,_HM,_Kontaktsensoren
   serialNr   NEQ0634518
   subType    threeStateSensor
   userReadings rssi_dB:nanoCUL868_HM_RSSI.* {(ReadingsVal("$name","nanoCUL868_HM_RSSI",0))}


Abhilfe wegen der dead Meldung kann die Einstellung von actCycle auf 001:05 bringen.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

DeeSPe

Der HM-Sec-SC-2 hat actCycle 001:05 gesetzt, genau wie alle meine anderen HM-SEC-SCo's (die keine dead Meldungen verursachen).

Wenn ich das richtig verstehe ist actCycle die Dauer bis ein Device auf dead gesetzt wird wenn in dieser Zeit keine Readings aktualisiert werden, richtig? Somit müssten also auch meine HM-SEC-SCo's bei meiner täglichen Abwesenheit von 10 Stunden dead alarmieren oder? Das tun sie aber nicht.

Gruß
Dan

P.S. Soweit ich das überblicke ist der HM-Sec-SC-2 identisch zu den HM-SEC-SCo's angelegt. Wurden ja auch beide hintereinander am selben Tag angelernt.

Hier noch lists der Devices:

HM-Sec-SC-2
Internals:
   CHANGED
   DEF        XXXXXX
   HMLAN1_MSGCNT 16
   HMLAN1_RAWMSG EXXXXXX,0000,A3XXXXXX,FF,XXXX,XXXXXXXXXXXXXX
   HMLAN1_RSSI -68
   HMLAN1_TIME 2016-08-01 17:41:59
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     16
   NAME       fl_Eingangstuer
   NR         117
   NTFY_ORDER 50-fl_Eingangstuer
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:6F - t:41 s:XXXXXX d:XXXXXX XXXXXX
   protLastRcv 2016-08-01 17:41:59
   protSnd    16 last_at:2016-08-01 17:41:59
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:16 min:-76 lst:-68 max:-64 avg:-67.56
   Readings:
     2016-08-01 17:47:11   Activity        alive
     2016-03-02 12:04:43   CommandAccepted yes
     2016-06-25 13:51:59   D-firmware      2.4
     2016-06-25 13:51:59   D-serialNr      XXXXXXXXX
     2016-06-25 13:51:53   PairedTo        XXXXXXX
     2016-02-25 22:15:35   R-cyclicInfoMsg off
     2016-02-25 22:15:36   R-eventDlyTime  0 s
     2016-03-02 12:05:21   R-pairCentral   XXXXXXX
     2016-02-25 22:15:35   R-sabotageMsg   on
     2016-02-25 22:15:36   R-sign          off
     2016-06-25 13:51:53   RegL_00.        02:01 09:00 0A:2C 0B:D8 0C:91 10:01 14:06 00:00
     2016-06-25 13:51:54   RegL_01.        08:00 20:60 21:00 22:64 30:06 00:00
     2016-06-25 13:52:14   alive           yes
     2016-08-01 17:41:59   battery         ok
     2016-08-01 17:41:59   contact         closed (to HMLAN1)
     2016-06-25 13:51:47   powerOn         2016-06-25 13:51:47
     2016-06-25 13:52:14   recentStateType info
     2016-06-25 13:52:14   sabotageError   off
     2016-08-01 17:41:59   state           closed
     2016-08-01 17:41:59   trigDst_XXXXXX  noConfig
     2016-08-01 17:41:59   trigger_cnt     110
   Helper:
     HM_CMDNR   111
     mId        00B1
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +XXXXXX,00,00,00
       nextSend   1470066119.90236
       prefIO
       rxt        2
       vccu
       p:
         XXXXXX
         00
         00
         00
     Mrssi:
       mNo        6F
       Io:
         HMLAN1     -66
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1470066119.81711
       ack:
         HASH(0x1c2e2b0)
         XXXXXXXXXXXXXXXXX
     Rssi:
       At_hmlan1:
         avg        -67.5625
         cnt        16
         lst        -68
         max        -64
         min        -76
     Tmpl:
Attributes:
   IODev      HMLAN1
   actCycle   001:05
   actStatus  alive
   alias      Eingangstür
   autoReadReg 4_reqStatus
   devStateIcon open:fts_door_open@red closed:fts_door@green
   event-on-change-reading battery,contact,sabotageError,state
   expert     2_raw
   firmware   2.4
   group      Fenster und Türen
   homebridgeMapping StatusTampered=sabotageError,values=/^off/:NOT_TAMPERED;/^on/:TAMPERED
   icon       fts_door_right_open
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       Flur,HomeKit
   serialNr   XXXXXXXXXX
   subType    threeStateSensor


HM-SEC-SCo
Internals:
   CHANGED
   DEF        XXXXXX
   HMLAN1_MSGCNT 47
   HMLAN1_RAWMSG EXXXXXX,0000,A3XXXXXX,FF,FFC1,04A610XXXXXXXXXXXXXXXXXX
   HMLAN1_RSSI -63
   HMLAN1_TIME 2016-08-01 18:00:50
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     47
   NAME       wz_Balkontuer
   NR         121
   NTFY_ORDER 50-wz_Balkontuer
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:04 - t:10 s:XXXXXX d:XXXXXX XXXXXX
   peerList   wz_Heizung_WindowRec,
   protLastRcv 2016-08-01 18:00:50
   protSnd    37 last_at:2016-08-01 18:00:50
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-59.34 max:-56 lst:-63 min:-71 cnt:47
   Readings:
     2016-07-31 17:47:08   Activity        alive
     2016-05-21 01:04:12   CommandAccepted no
     2016-05-20 19:56:18   D-firmware      1.0
     2016-05-20 19:56:18   D-serialNr      XXXXXXXXXXX
     2016-05-21 16:37:21   PairedTo        0xXXXXXX
     2016-02-26 20:15:22   R-cyclicInfoMsg on
     2016-02-26 20:15:23   R-eventDlyTime  0 s
     2016-02-26 20:15:22   R-pairCentral   0xXXXXXX
     2016-02-26 20:15:22   R-sabotageMsg   on
     2016-02-26 20:15:23   R-sign          on
     2016-02-28 00:12:51   R-wz_Heizung_WindowRec-expectAES off
     2016-02-28 00:12:51   R-wz_Heizung_WindowRec-peerNeedsBurst on
     2016-05-21 16:37:21   RegL_00.        02:01 09:01 0A:2C 0B:D8 0C:91 10:01 14:06 00:00
     2016-05-21 16:37:22   RegL_01.        08:01 20:9C 21:00 30:06 00:00
     2016-05-21 16:37:23   RegL_04.wz_Heizung_WindowRec 01:01 00:00
     2016-02-28 00:12:49   aesCommToDev    ok
     2016-02-28 00:12:48   aesKeyNbr       00
     2016-08-01 18:00:50   alive           yes
     2016-08-01 18:00:50   battery         ok
     2016-08-01 18:00:50   contact         open (to HMLAN1)
     2016-07-31 17:47:08   peerList        wz_Heizung_WindowRec,
     2016-05-20 19:53:29   powerOn         2016-05-20 19:53:29
     2016-08-01 18:00:50   recentStateType info
     2016-08-01 18:00:50   sabotageError   off
     2016-08-01 18:00:50   state           open
     2016-08-01 17:42:46   trigDst_XXXXXX  noConfig
     2016-02-26 17:59:45   trigDst_wz_Heizung noConfig
     2016-08-01 17:42:46   trigger_cnt     78
   Helper:
     HM_CMDNR   4
     mId        00C7
     rxType     28
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +XXXXXX,00,00,00
       nextSend   1470067250.93635
       prefIO
       rxt        2
       vccu
       p:
         XXXXXX
         00
         00
         00
     Mrssi:
       mNo        04
       Io:
         HMLAN1     -61
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1470067250.84929
       ack:
         HASH(0x1c2e508)
         048002XXXXXXXXXXXX00
     Rssi:
       At_hmlan1:
         avg        -59.3404255319149
         cnt        47
         lst        -63
         max        -56
         min        -71
     Tmpl:
Attributes:
   IODev      HMLAN1
   actCycle   001:05
   actStatus  alive
   alias      Balkontür
   autoReadReg 4_reqStatus
   devStateIcon open:fts_door_open@red closed:fts_door@green
   event-on-change-reading battery,contact,sabotageError,state
   expert     2_raw
   firmware   1.0
   group      Fenster und Türen
   homebridgeMapping StatusTampered=sabotageError,values=/^off/:NOT_TAMPERED;/^on/:TAMPERED
   icon       fts_door_right_open
   model      HM-SEC-SCo
   peerIDs    00000000,XXXXXX,
   room       HomeKit,Wohnzimmer
   serialNr   XXXXXXXXXXX
   subType    threeStateSensor


(IDs sind unkenntlich gemacht)
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Brockmann

Zitat von: DeeSPe am 01 August 2016, 18:10:22
Somit müssten also auch meine HM-SEC-SCo's bei meiner täglichen Abwesenheit von 10 Stunden dead alarmieren oder? Das tun sie aber nicht.
Die melden sich einmal pro Stunde von alleine mit einer Statusmeldung bei der Zentrale. Deshalb soll man den Intervall auf etwas mehr als eine Stunde stellen, damit der ActionDetector spätestens durch die stündliche Statusmeldung getriggert wird. Dann gibt es auch kein "dead".

DeeSPe

Zitat von: Brockmann am 01 August 2016, 18:19:11
Die melden sich einmal pro Stunde von alleine mit einer Statusmeldung bei der Zentrale. Deshalb soll man den Intervall auf etwas mehr als eine Stunde stellen, damit der ActionDetector spätestens durch die stündliche Statusmeldung getriggert wird. Dann gibt es auch kein "dead".

Das bringt mich leider nicht weiter denn 001:05 ist "etwas mehr als eine Stunde".

Vielleicht verstehe ich hier auch was noch nicht richtig?

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

LuckyDay

model      HM-SEC-SC-2  sendet alle 24 std alive, nicht alle Stunde wie SCo

LuckyDay

@   Burny4600

dein SCo ist nicht richtig/fertig gepairt, steht alles in deinem List, daher auch keine Alive Melungen bei dir

Brockmann

Zitat von: DeeSPe am 01 August 2016, 18:31:46
Das bringt mich leider nicht weiter denn 001:05 ist "etwas mehr als eine Stunde".
Mit dem 01:05 sagst Du dem ActionDetector "Wenn Du eine Stunde und 5 Minuten lang nichts hörst, melde das Gerät als dead."
Wenn das Gerät nun alle 60 Minuten einen Status sendet, tritt dieser Fall aber nie ein, es sei denn, das Gerät ist wirklich defekt/Batterie leer/was auch immer.
Aber bitte auch den Hinweis von fhem-hm-knecht beachten!

DeeSPe

Zitat von: fhem-hm-knecht am 01 August 2016, 18:54:35
model      HM-SEC-SC-2  sendet alle 24 std alive, nicht alle Stunde wie SCo

Dann sollte eventuell actCycle 025:00 eine Lösung meines Problems sein?
Werde es mal testen.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Burny4600

Zitat von: fhem-hm-knecht am 01 August 2016, 18:58:39
@   Burny4600

dein SCo ist nicht richtig/fertig gepairt, steht alles in deinem List, daher auch keine Alive Melungen bei dir
Woran erkennt man das im LIST
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

LuckyDay

ZitatcmdStack:
     ++A001F123474xxxxxxxxxxxxxxxxxxxxx0
     ++A001F123474xxxxxxxxxxxxxxxxxxxxx1
     ++A001F123474xxxxxxxx3

hier z.B.

frank

hallo dan,

ZitatDann sollte eventuell actCycle 025:00 eine Lösung meines Problems sein?
autocreate setzt default 028:00 std. das hilft aber nur, wenn der sc auch entsprechend konfiguriert ist.

     2016-02-25 22:15:35   R-cyclicInfoMsg off
also dies register noch auf on setzen, damit er auch zyklisch sendet.
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