Hallo zusammen,
ich würde gerne prüfen ob die Haustüre abgeschlossen ist.
Daher habe ich bei einem HM-SEC-SCO den Schalter für den Sabotagekontakt entfernt und durch einen ReedKontakt ersetzt.
Leider meldet dieser nur eine Beschränkte Zahl von Zustandsänderungen bevor dies verweigert.
Der Optische Sensor meldet weiterhin jeden Wechsel seines Zustandes.
Der Kontakt meldet sabotageError on -> off -> on -> evtl nochmal ein off und dann ist Schluss.....
Wenn ich die Batterie entferne oder den Config Button drücke gehen wieder 3-4 Statuswechsel.
Anbei noch ein List des Devices:
Internals:
CFGFN
DEF 3C8989
HMLAN1_MSGCNT 225
HMLAN1_RAWMSG E3C8989,0000,0066A0F7,FF,FFC5,12A6103C8989XXXXX06010000
HMLAN1_RSSI -59
HMLAN1_TIME 2015-10-24 14:38:09
HMUSB_MSGCNT 207
HMUSB_RAWMSG E3C8989,0000,2DC88F0D,FF,FFA4,11A6103C8989XXXXXX0601000E
HMUSB_RSSI -92
HMUSB_TIME 2015-10-24 14:38:03
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 432
NAME HM_3C8989
NR 107988
STATE closed
TYPE CUL_HM
lastMsg No:12 - t:10 s:3C8989 d:25756B 06010000
protCmdDel 10
protEvt_AESCom-ok 5 last_at:2015-10-23 19:36:21
protEvt_AESerrReject 1 last_at:2015-10-23 19:35:08
protLastRcv 2015-10-24 14:38:09
protNack 3 last_at:2015-10-23 21:26:48
protResnd 5 last_at:2015-10-24 14:33:40
protSnd 197 last_at:2015-10-24 14:38:09
protState CMDs_done
rssi_at_HMLAN1 min:-84 lst:-59 avg:-64.62 cnt:219 max:-56
rssi_at_HMUSB min:-103 lst:-92 cnt:195 avg:-85.44 max:-77
CHANGETIME:
Helper:
Dblog:
Poweron:
Mydblog:
TIME 1445690014.52457
VALUE 2015-10-24 14:33:34
Readings:
2015-10-24 14:37:38 Activity alive
2015-10-23 21:26:48 CommandAccepted no
2015-10-24 14:37:38 D-firmware 1.0
2015-10-24 14:37:38 D-serialNr MEQ0752362
2015-10-24 14:33:45 PairedTo 0xXXXXXX
2015-10-23 19:36:46 R-cyclicInfoMsg on
2015-10-23 19:36:47 R-eventDlyTime 0 s
2015-10-23 19:36:47 R-msgScPosA open
2015-10-23 19:36:47 R-msgScPosB closed
2015-10-23 19:36:46 R-pairCentral 0x25756B
2015-10-23 19:36:46 R-sabotageMsg on
2015-10-23 19:36:47 R-sign on
2015-10-23 19:36:46 R-transmDevTryMax 6
2015-10-23 19:36:47 R-transmitTryMax 6
2015-10-24 14:33:45 RegL_00: 02:01 09:01 0A:25 0B:75 0C:6B 10:01 14:06 00:00
2015-10-24 14:33:45 RegL_01: 08:01 20:9C 21:00 30:06 00:00
2015-10-23 19:36:21 aesCommToDev ok
2015-10-23 19:36:21 aesKeyNbr 00
2015-10-24 14:38:09 alive yes
2015-10-24 14:38:09 battery ok
2015-10-24 14:38:09 contact closed (to vccu)
2015-10-24 14:33:34 powerOn 2015-10-24 14:33:34
2015-10-24 14:38:09 recentStateType info
2015-10-24 14:38:09 sabotageError off
2015-10-24 14:38:09 state closed
2015-10-24 14:33:44 trigDst_vccu noConfig
2015-10-24 14:33:44 trigger_cnt 2
Helper:
HM_CMDNR 18
PONtest 0
cSnd 0125756B3C898901040000000001,01XXXXX3C89890103
mId 00C7
peerIDsRaw ,00000000
rxType 28
Io:
newCh 1
newChn +3C8989,00,00,00
nextSend 1445690289.49871
prefIO
rxt 2
vccu
p:
3C8989
00
00
00
Mrssi:
mNo 12
Io:
HMLAN1 -57
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1445690289.41421
ack:
HASH(0x21763b8)
12800225756B3C898900
Rssi:
At_hmlan1:
avg -64.6210045662101
cnt 219
lst -59
max -56
min -84
At_hmusb:
avg -85.4461538461538
cnt 195
lst -92
max -77
min -103
Shadowreg:
Attributes:
IODev HMLAN1
IOgrp vccu:HMLAN1
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,
room CUL_HM
serialNr MEQXXXXXX
subType threeStateSensor
Für Hinweise was ich noch ändern oder Probieren könnte wäre ich euch sehr Dankbar !
Gruß
Bodo
Ich habe nun noch etwas weiter getestet.
Offensichtlich führt eine Aktion am Sabotagetaster nicht zum Aufwecken des Devices.
Es wird also solange gewartet bis der Status (vom optischen Sensor) sich ändert oder ich den Config Button drücke um das Device aufzuwecken.
Kann ich das irgendwie beeinflussen, dass das Device beim Sabotagecontact aufwacht und mir den Stauts mitgibt ?
Gruß
Bodo
Würde mich auch interessieren.
Hatte schon Drähte drangelötet um ihn als Wassersensor zu verwenden.
Verhält sich aber leider so wie beschrieben.
bei einem sec-sc scheint es diese "begrenzung" nicht zu geben.
also entweder ein neues feature oder ein bug. ich vermute ein bug, da ich keinen sinn darin erkennen kann, dass man unbedingt bei sabotage batterien sparen will. da die anzahl leicht variiert, könnte es mit dem laden/entladen eines kondensators zu tun haben oder ein eingang ist unbeschaltet und driftet langsam.
Hallo,
ich hatte die gleiche Idee und habe an den Sabotagekontakt eines HM-Sec-SCo einen Mikroschalter angeschlossen der den Schlosstatus abfragt.
Wie ich diesen Beitrag gelesen habe dachte ich - ups.
Ich habe gerade 10x hintereinader auf und zugesperrt aber konnte kein Problem entdecken - es ging immer und geht noch immer.
Gottseidank.
Die FW meines Kontakts ist auch die 1.0.
Den Mikroschalter habe ich über die Kontaktflächen MP1 und MP2 angeschlossen. Der Sabotageschalter ist noch dran, hab nur die Betätigungsnase von Kontaktgehäuse innen entfernt.
Vielleicht hast du doch ein HW Problem ?
lg
Hi knxhm,
danke für den Hinweis. Ich hatte gleich den Schalter entfernt......
Habe das Schloss der Haustüre nun über einen HM-SEC-SC2 angebunden, hier habe ich mich einfach an den normalen Reedkontakt mit den Drähten drangehängt.
Funktioniert soweit erstmal einwandfrei.
Testen werde ich es dennoch, dann kann ich ggf die Fenster mit Glasbruchsensoren erweitern oder einem 2ten Reedkontakt um zwischen offen/gekippt unterscheiden zu können.
Gruß
Bodo
Mein Sensor scheint wirklich nicht in Ordnung zu sein.
Hab den gleichen Test mit einem zweiten durchgeführt und keine Probleme feststellen können.
Kurzes Update...
Hab den "defekten" Sensor mal komplett resetet.
Und siehe da, jetzt funktioniert er wieder normal!
Ich hatte bisher noch nicht die Zeit gefunden mal einen aus dem Fensterrahmen auszubauen.
Konnte daher leider noch nicht mit einem anderen testen.