Überwachung Ausfall HM Fenster Kontakte

[ChrisW]

Hallo,
ich musste mit erschrecken feststellen das es keine wirkliche 24 Stunden Meldung gibt .. 
Geplant war unteranderen die Sensorgen mit einem Wassermelder zu versehen. Auch ist jetzt ein Fensterkontakt ausgefallen wohl Batterie Leer. Dieser wird sehr selten benutzt und der letzte Status liegt 3 Wochen zurück da war die Batterie noch Okay. Nun keine Reaktionen mehr .. Batterie Rein/Raus nun Sendet er wieder aber Batterie LOW.

Was ich funden habe ist R-cyclicInfoMsg = on zu setzen dies habe ich auch gemacht. Trotzdem keine 24 Stunden meldung !!


Jemand eine Lösung ?

[CBSnake]

Hi,
was verstehst du unter einer 24h Meldung? Meine senden einmal die Stunde, und das wird vom ActionDector überwacht.

Grüße
Achim

[frank]

nur der optische sco meldet sich stündlich. alle anderen einmal am tag.
mit leerer batterie natürlich gar nicht. 

zeig ein aktuelles list.

[CBSnake]

ah ok, ich hab nur optische

[ChrisW]

Meine melden sich auch nicht alle 24 Stunden .. habe 6 Stück

[CBSnake]

Hast du mal ein List von einem der seit 24h keinen Mucks von sich gab?

Grüße
Achim

[ChrisW]

hier :

Code Auswählen Erweitern

Internals:
   DEF        558FE1
   HMLAN_MSGCNT 2
   HMLAN_RAWMSG E558FE1,0000,62D380C3,FF,FFAF,048441558FE1000000010400
   HMLAN_RSSI -81
   HMLAN_TIME 2018-01-20 14:32:47
   IODev      HMLAN
   LASTInputDev HMLAN
   MSGCNT     2
   NAME       hm.fenster.esszimmer
   NOTIFYDEV  global
   NR         619
   NTFY_ORDER 50-hm.fenster.esszimmer
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:04 - t:41 s:558FE1 d:000000 010400
   peerList   heizung_esszimmer_WindowRec,
   protLastRcv 2018-01-20 14:32:47
   rssi_at_HMLAN lst:-81 min:-87 avg:-84 max:-81 cnt:2
   READINGS:
     2018-01-03 21:15:08   .D-devInfo      810101
     2018-01-03 21:15:08   .D-stc          80
     2017-11-22 07:29:27   .R-ledOnTime    0.5 s
     2017-11-22 07:29:27   .R-msgScPosA    closed
     2017-11-22 07:29:27   .R-msgScPosB    open
     2017-11-22 07:29:26   .R-transmDevTryMax 6
     2017-11-22 07:29:27   .R-transmitTryMax 6
     2018-01-03 21:15:18   .peerListRDate  2018-01-03 21:15:18
     2018-01-20 14:32:47   .protLastRcv    2018-01-20 14:32:47
     2018-01-21 18:34:00   Activity        dead
     2018-01-03 21:15:10   CommandAccepted yes
     2018-01-03 21:15:08   D-firmware      2.4
     2018-01-03 21:15:08   D-serialNr      NEQ1834903
     2018-01-03 21:15:17   PairedTo        0x006633
     2018-01-03 21:15:08   R-cyclicInfoMsg on
     2017-11-22 07:29:27   R-eventDlyTime  0 s
     2017-11-22 07:48:40   R-heizung_esszimmer_WindowRec-expectAES off
     2017-11-22 07:48:40   R-heizung_esszimmer_WindowRec-peerNeedsBurst on
     2018-01-03 21:15:17   R-pairCentral   0x006633
     2017-11-22 07:29:26   R-sabotageMsg   on
     2017-11-22 07:29:27   R-sign          off
     2018-01-14 15:26:08   alive           yes
     2018-01-20 14:32:47   battery         ok
     2018-01-20 14:32:47   contact         closed (to broadcast)
     2018-01-19 10:13:36   peerList        heizung_esszimmer_WindowRec,
     2018-01-14 15:26:08   powerOn         2018-01-14 15:26:08
     2018-01-14 15:26:08   recentStateType info
     2018-01-14 15:26:08   sabotageError   off
     2018-01-20 14:32:47   state           closed
     2018-01-20 14:32:47   trigger_cnt     4
   helper:
     HM_CMDNR   4
     mId        00B1
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +558FE1,00,00,00
       nextSend   1516455167.51139
       rxt        2
       vccu       VCCU
       p:
         558FE1
         00
         00
         00
       prefIO:
         HMLAN
     mRssi:
       mNo        04
       io:
         HMLAN      -79
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HMLAN:
         avg        -84
         cnt        2
         lst        -81
         max        -81
         min        -87
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN
   IOgrp      VCCU:HMLAN
   actCycle   028:00
   actStatus  dead
   alarmDevice Sensor
   alarmSettings alarm5,|hm.fenster.esszimmer:open|Alarm Fenster Esszimmer AUF|on
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.4
   model      HM-SEC-SC-2
   peerIDs    00000000,23C77603,
   room       Türen-Fenster
   serialNr   NEQ1834903
   subType    threeStateSensor
   userattr   winOpenMaxTrigger winOpenTimer winOpenTimer2 winOpenType:Fenster,Türe winOpenName
   winOpenMaxTrigger 2
   winOpenName Esszimmer-Fenster
   winOpenTimer 00:30:00
   winOpenTimer2 00:45:00
   winOpenType Fenster

Bei den anderen ist R-cyclicInfoMsg = off.
Der von oben ist relativ weit weg, Vielleicht kommt die Funkmeldung auch nicht an ? Ich werde mal R-cyclicInfoMsg = on  bei einem Gerät testen was näher dran ist wo es 100% Funkverlust gibt.

[Wernieman]

was näher dran ist wo es 100% Funkverlust gibt.

Du meinst bestimmt: wo es zu 100% KEINEN  Funkverlust gibt.

Oder??

[frank]

fhem und hmlan müssen natürlich auch permanent empfangsbereit sein. stichworte: disconnect, freezes, reboot, ...

[ChrisW]

ja 100% kein Funkverlust natürlich
HMLAN udn FHEM ist immer an

[Pfriemler]

Nur nebenbei (weil es offensichtlich nicht ursprünglich um diesen geht):

Warum sendet der an Broadcast, wenn er doch mit dem Thermostaten im Esszimmer gepeert ist? Könnte es sein dass er zurückgesetzt wurde und daher das cyclicInfoMsg wieder auf (default) off steht? Ist er denn auch wirklich tot?

[MadMax-FHEM]

Es melden sich sowohl die magnetischen Fenstersensoren als auch die optischen (zumindest bei mir).

Die magnetischen wohl mind. 1x am Tag und die optischen auch mal öfter (so alle 2h)...

"Überwachung" übernimmt der ActionDetector (bei autocreate norm. "automatisch"), Stichwort: Attribut actCycle (in welchem Zyklus soll "geprüft" werden / muss nat. größer sein als das Mindestmeldezeitfenster)...

Voraussetzung: msgCycligInfo ist auf on (und event-on-change-reading NICHT .* außer event-on-update-reading battery...)

Die Batterieüberwachung mache ich wie folgt: https://forum.fhem.de/index.php/topic,82637.0.html
(da aber eher die Warnung, dass ich mal Batterien kaufen gehen sollte / die Fensterkontakte halten durchaus [bei mir] noch Wochen nach einem "low")

Zusätzlich eben noch ActionDetector: wenn dead (und vorher "low") dann muss ich wechseln...

(Bei dead ohne erkennbaren [Batterie]Grund drehe ich immer mal am actCycle bzw. versuche zu ergründen warum sich der Sensor nicht wie erwartet gemeldet hat)

Gruß, Joachim

[martinp876]

Dazu gibt es ja den Actiondetecor. Barlow sendet das Device. Ist das zuverlässig? Nun ja. Glauben manche, die gegen die Einführung des actdet waren.
M.e ist batlow hilfreich. Aber der actdetector ist ultimativ und zuverlässig. Ausser man ignoriert ihn.

[ChrisW]

also msgCycligInfo ist bei mir bei jedem Sensor aus ..

Kann gut sein für msgCycligInfo on zu schalten musste ich den Knopf drücken .. daher hat er sicher die Verbindung verloren zum Thermostat.

Wie kann ich die Zeiten bis ein Gerät als weg erkannt wird anpassen ?

Auch für meine Teamvirtuell für die Rauchmelder müsste ich diese Prüfung Deaktivieren.

Bin noch nicht dazu gekommen zu checken ob der Sensor näher am Gerät sich alle 24 Stunden meldet. Hoffe ich komme am Wochenende dazu.

[martinp876]

Sollte alles in Action detector beschrieben sein, der macht die Überwachung.