Geister-Events HM-SEC-SCO

[juelich]

Hallo,

ich stehe vor einem Rätsel. Da ich eine Frau habe, die gerne mal vergisst, das Fenster nach dem Lüften wieder zu schließen, habe ich als Gedächtnisstütze eine kleine Sirene gebaut, die mittels wachtdog nach 10 Minuten ein Signal absetzt. Das funktioniert im ganzen Haus auch wunderbar. Allerdings häufen sich in letzter Zeit Fehlalarme im Schlafzimmer.
Unter der Vorstellung, dess es sich um einen Sensordefekt handeln könnte habe ich gestern die Batterie entfernt. Trotzdem kam es heute erneut zu Alarmierungen, obwohl das Gerät auch richtig als "dead" im FHEM angezeigt wird. Auffällig ist für mich, dass Alarme häufig zu "runden" Uhrzeiten kommen.
Wie ist so etwas möglich, ein totes Gerät kann doch eigentlich kein Event mehr auslösen, oder?
Hier ist ein List des Gerätes:

Code Auswählen Erweitern


Internals:
   DEF        3634BB
   FUUID      5c47609d-f33f-82e1-eac8-1c4848d4bcd2d680
   FVERSION   10_CUL_HM.pm:0.209540/2020-01-12
   HMLAN_MSGCNT 84
   HMLAN_RAWMSG E3634BB,0000,8929A67D,FF,FFAF,4AA6103634BB1EA0480601008E
   HMLAN_RSSI -81
   HMLAN_TIME 2020-01-21 10:52:40
   IODev      HMLAN
   LASTInputDev HMLAN
   MSGCNT     84
   NAME       fenster.sz
   NOTIFYDEV  global
   NR         117
   NTFY_ORDER 50-fenster.sz
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:4A - t:10 s:3634BB d:1EA048 0601008E
   peerList   hz.sz_Fenster,
   protCmdDel 9
   protIOerr  2 last_at:2020-01-19 21:57:35
   protLastRcv 2020-01-21 10:52:40
   protRcv    84 last_at:2020-01-21 10:52:40
   protRcvB   6 last_at:2020-01-21 07:55:02
   protSnd    71 last_at:2020-01-21 10:52:40
   protState  CMDs_done
   rssi_at_HMLAN cnt:84 min:-98 max:-73 avg:-85.26 lst:-81
   READINGS:
     2020-01-21 13:47:50   Activity        dead
     2019-03-14 21:33:10   CommandAccepted yes
     2018-09-01 21:43:43   D-firmware      1.0
     2018-09-01 21:43:43   D-serialNr      MEXXXX7234
     2019-03-14 21:33:13   PairedTo        0x1EA048
     2017-04-07 20:35:51   R-cyclicInfoMsg on
     2017-04-07 20:35:51   R-eventDlyTime  0 s
     2018-09-01 21:43:22   R-hz.sz_Fenster-expectAES off
     2018-09-01 21:43:22   R-hz.sz_Fenster-peerNeedsBurst on
     2017-04-07 20:35:51   R-pairCentral   0x1EA048
     2017-04-07 20:35:51   R-sabotageMsg   on
     2017-04-07 20:35:51   R-sign          on
     2019-03-14 21:33:13   RegL_00.        00:00 02:01 09:01 0A:1E 0B:A0 0C:48 10:01 14:06
     2019-03-14 21:33:14   RegL_01.        00:00 08:01 20:9C 21:00 30:06
     2019-03-14 21:33:15   RegL_04.hz.sz_Fenster 00:00 01:01
     2019-03-14 21:33:10   aesCommToDev    ok
     2019-03-14 21:33:10   aesKeyNbr       00
     2020-01-21 10:52:40   alive           yes
     2020-01-21 10:52:40   battery         low
     2020-01-21 10:52:40   contact         closed (to VCCU)
     2020-01-19 20:27:48   peerList        hz.sz_Fenster,
     2019-02-12 20:55:02   powerOn         2019-02-12 20:55:01
     2020-01-21 10:52:40   recentStateType info
     2020-01-21 10:52:40   sabotageError   on
     2020-01-21 10:52:40   state           closed
     2019-01-09 08:38:51   trigDst_1EA048  noConfig
     2017-04-07 20:35:22   trigDst_broadcast noConfig
     2018-09-01 21:41:32   trigDst_hz.sz_th noConfig
     2020-01-21 07:55:03   trigger_cnt     116
   helper:
     HM_CMDNR   74
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +3634BB,00,01,00
       nextSend   1579600360.81004
       rxt        2
       vccu       VCCU
       p:
         3634BB
         00
         01
         00
       prefIO:
         HMLAN
     mRssi:
       mNo        4A
       io:
         HMLAN:
           -79
           -79
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         HMLAN
       flg        A
       ts         1579600360.72051
       ack:
         HASH(0x237e110)
         4A80021EA0483634BB00
     rssi:
       at_HMLAN:
         avg        -85.2619047619048
         cnt        84
         lst        -81
         max        -73
         min        -98
     tmpl:
Attributes:
   IODev      HMLAN
   IOgrp      VCCU:HMLAN
   actCycle   002:50
   actStatus  dead
   autoReadReg 4_reqStatus
   devStateIcon open:Wecker.Immer closed:Wecker.Wochentags
   event-on-change-reading state,battery
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCO
   peerIDs    00000000,63XXXX03,
   room       Fenster,Schlafzimmer
   serialNr   MEQ0367234
   subType    threeStateSensor
   userattr   room_map structexclude

Hier ist ein Auszug aus dem Log seit Ausbau der Batterie:

Code Auswählen Erweitern


2020-01-21_10:52:40 fenster.sz battery: low
2020-01-21_18:00:00 fenster.sz open
2020-01-21_18:00:00 fenster.sz open
2020-01-21_18:00:00 fenster.sz open
2020-01-21_18:00:17 fenster.sz open
2020-01-21_18:00:17 fenster.sz open
2020-01-21_18:00:38 fenster.sz open
2020-01-21_18:00:39 fenster.sz open
2020-01-22_10:00:00 fenster.sz open
2020-01-22_10:00:00 fenster.sz open
2020-01-22_10:00:00 fenster.sz open
2020-01-22_10:10:07 fenster.sz open
2020-01-22_10:10:07 fenster.sz open
2020-01-22_10:10:20 fenster.sz open
2020-01-22_10:10:20 fenster.sz open


[frank]

das reale device sendet natürlich nicht mehr ohne batterie.
im state könnte grundsätzlich aber eventuell noch etwas passieren, wie zb missing ack.

da aber im list der aktuellste timestamp mit dem ältesten eintrag deines logauszugs korreliert, müssten die anderen einträge durch andere "aktionen/events" in fhem getriggert werden.

ausserdem würde das event-on-change im device nicht immer das selbe event generieren.

ich würde mal den eventmonitor laufen lassen und mit zeitgleichen einträgen im filelog vergleichen.

[Pfriemler]

mystischST. Lese mal mit.
Könnten wir bitte noch das DEF des FileLogs sehen?

Vielleicht gibt es von außen generierte Events durch andere Routinen, indem readings in fenster.sz manipuliert werden?

[juelich]

Hallo, das Log wurde automatisch mit dem Device angelegt. Ich kann beim DEF nichts Besonderes entdecken:

Code Auswählen Erweitern

Internals:
   DEF        ./log/fenster.sz-%Y.log fenster.sz
   FD         31
   FUUID      5c47609d-f33f-82e1-ccd0-5648708ac2540085
   FVERSION   92_FileLog.pm:0.208260/2019-12-25
   NAME       FileLog_fenster.sz
   NOTIFYDEV  fenster.sz
   NR         118
   NTFY_ORDER 50-FileLog_fenster.sz
   REGEXP     fenster.sz
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/fenster.sz-2020.log
   logfile    ./log/fenster.sz-%Y.log
   READINGS:
     2020-01-22 10:10:20   linesInTheFile  154
Attributes:
   logtype    text
   room       CUL_HM

Was wäre in der Lage, von außen ein Event in einem Fenstersensor zu triggern?

Dafür würde ja sprechen, dass es genau zu vollen Uhrzeiten triggert. Aber es betrifft nur einen einzigen Sensor von fast 10, die ich habe. Was soll da von Außen das Reading manipulieren?

Ich bin echt überfragt.

Viele Grüße

Markus

[LuckyDay]

userattr   room_map structexclude

was ist das?

[juelich]

Heureka - danke für Eure Hinweise.
Es wurde tatsächlich von außen manipuliert - von mir selber 🙈.
Ich habe ein kleines Display, welches mir den Status der Fenster anzeigt. Dieses nutze ich auch als Anzeige, wenn die Mülltonne geleert werden muss.
Da ich leider zu blöd war, es hinzubekommen nur die unterste Zeile zu beschreiben lasse ich eine Doppelzeile beschreiben und Trigger über Fenster:Open ein Neuschreiben des Displays. Genau das hat dann offensichtlich den Fenster-offen-Alarm ausgelöst.

Also noch einmal vielen Dank

Markus

[Pfriemler]

userattr   room_map structexclude

was ist das?

wird von einer structure namens "room_map" automatisch angelegt, nehme ich mal an. Ist zumindest bei mir so.

... lasse ich eine Doppelzeile beschreiben und Trigger über Fenster:Open ein Neuschreiben des Displays. Genau das hat dann offensichtlich den Fenster-offen-Alarm ausgelöst.

Na, ne. Nicht wirklich. Deine Displayroutine erzeugt offenbar Events, auf die zumindest das recht einfache Regex in der FileLog-Definition anspricht. Ob Dein Alarm darauf reagiert, hängt davon ab, mit welchem Regex er triggert. Ein Regex namens "fenster.sz" triggert dabei (wegen des Joker-Zeichens .) auch auf "fenster sz" oder "fenster:sz". Deswegen sind Punkte in Device-Namen ja an sich keine besonders schlaue Idee...

[juelich]

Da ich das Neuschreiben des Displays Mangels guter Programmierkenntnisse mittels trigger fenster.sz:open ausgelöst habe geht es meines Erachtens völlig in Ordnung, dass dadurch ein Event und ein Logeintrag ausgelöst wird.
Über das Problem eines Punktes im Devicenamens habe ich mir ehrlich gesagt noch nie Gedanken gemacht - aber es gab ja auch noch nie Probleme...
Aber ich glaube, dieses Problem hier war ja auch hausgemacht.

[frank]

wenn wirklich mal ein vorhandener punkt im namen probleme in einer regex machen sollte, kann man ja den punkt mit einem backslash "maskieren".

also so: "\."