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.
ich rate mal, weil es keine infos gibt: attr actioncycle falsch eingestellt.
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.
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
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.
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)
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".
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
model HM-SEC-SC-2 sendet alle 24 std alive, nicht alle Stunde wie SCo
@ Burny4600
dein SCo ist nicht richtig/fertig gepairt, steht alles in deinem List, daher auch keine Alive Melungen bei dir
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!
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
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
ZitatcmdStack:
++A001F123474xxxxxxxxxxxxxxxxxxxxx0
++A001F123474xxxxxxxxxxxxxxxxxxxxx1
++A001F123474xxxxxxxx3
hier z.B.
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 offalso dies register noch auf on setzen, damit er auch zyklisch sendet.
Zitat von: frank am 01 August 2016, 21:46:10
hallo dan,
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.
Danke für die Info, allerdings wurde bei mir durch autocreate actCycle 001:05 gesetzt. Ist aber schon ein paar Monate her, vielleicht wurde das mittlerweile geändert im Modul. Habe es jetzt wie empfohlen auf 028:00 gesetzt. Mal schauen ob dann bis übermorgen keine dead Meldung kommt. R-cyclicInfoMsg ist nun auch on.
Ich werde berichten ob das Abhilfe geschaffen hat.
Gruß
Dan
Hallo,
normalerweise werden die actCycle von der Software richtig eingestellt - zumindest habe ich da nichts verstellt. Dann muss das Register cyclicInfoMsg auf on gesetzt werden und gut.
Was mir aufgefallen ist, die SC oder SC-2 haben 28:00 als Vorgabe, der SCo hat 00:50 als Vorgabe - der scheint also häufiger zu senden.
Gruß Christoph
Hallo,
ich habe seit einigen Monaten vier SCo und einen SC-2 im Einsatz.
Wie schon an anderen Stellen im Forum beschrieben, ist der Default Wert von 00:50 für die SCo zu kurz. Ich habe den Wert auf 1:05 gesetzt und alles ist gut. (R-cyclicInfoMsg natürlich auf on)
Der SC-2 steht bei mir auf 23:00 und funktioniert zufriedenstellend.
Vielleicht gibt es Unterschiede je nach Firmware-Version. Bei mir: SCo 1.0 und SC-2 2.4.
Gruß
Hermann
Zitat von: Hermann20 am 02 August 2016, 18:22:29
Vielleicht gibt es Unterschiede je nach Firmware-Version. Bei mir: SCo 1.0 und SC-2 2.4.
SCo und SC-2 haben bei mir die identische Firmware wie bei Dir.
Und wie gesagt, meine SCos und der eine SC-2 wurden zusammen am selben Tag angelegt (glaube Anfang Februar) und wurden alle mit 001:05 angelegt.
Hatte übrigens bisher keine dead Meldungen mehr, mal sehen wie es aussieht wenn die eingestellten 28h vorbei sind. Allerdings wird innerhalb von 28h auf jeden Fall der Kontakt ausgelöst, da es meine Eingangstür ist.
Gruß
Dan
Schau doch im Log von deinem SC nach , wann alive: yes als Reading kommt
Zitat von: fhem-hm-knecht am 01 August 2016, 19:37:20
hier z.B.
Die xxxxxx habe ich aufgefüllt anstatt andere Zahlenwerte.
Diese Meldung ist auch bei allen anderen Sensoren diesen Typs nur mit anderen Zahlen befüllt.
der sec-sc-2 hat 28h eingestellt.
der sco müss auf 2:50 korrigiert werden.
@Burny4600
du siehst es auch hier dran, das dein Devicve noch nicht richtig gepaired ist
Zitat2016-07-30 12:51:26 R-pairCentral set_0xF12347
es muss R-pairCentral 0xF12347 dort stehen, also ohne
set
Alles klar.
Bei mir sind nun also die dead Meldungen erfolgreich ausgeblieben, somit ist das Thema für mich gelöst und ich werde es dann schließen wenn keine weiteren Rückmeldungen kommen.
Gruß
Dan