HM-SEC-SCO Sabotage Kontakt meldet nicht immer

Begonnen von DerBodo, 24 Oktober 2015, 14:43:02

Vorheriges Thema - Nächstes Thema

DerBodo

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


DerBodo

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

chunter1

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.

frank

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.
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

knxhm

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
KNX, HM, HMLAN, RPi 2 mit Raspbian Jessie, knxd und FHEM, 1w Temperaturmessung mit gpio4, Dämmerungssensor, autom. Rolladensteuerung

DerBodo

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

chunter1

Mein Sensor scheint wirklich nicht in Ordnung zu sein.
Hab den gleichen Test mit einem zweiten durchgeführt und keine Probleme feststellen können.

chunter1

Kurzes Update...
Hab den "defekten" Sensor mal komplett resetet.
Und siehe da, jetzt funktioniert er wieder normal!

DerBodo

Ich hatte bisher noch nicht die Zeit gefunden mal einen aus dem Fensterrahmen auszubauen.
Konnte daher leider noch nicht mit einem anderen testen.