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:
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:
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
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.
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?
Hallo, das Log wurde automatisch mit dem Device angelegt. Ich kann beim DEF nichts Besonderes entdecken:
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
Zitatuserattr room_map structexclude
was ist das?
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
Zitat von: fhem-hm-knecht am 22 Januar 2020, 22:12:38
Zitatuserattr room_map structexclude
was ist das?
wird von einer structure namens "room_map" automatisch angelegt, nehme ich mal an. Ist zumindest bei mir so.
Zitat von: juelich am 22 Januar 2020, 22:15:35
... 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...
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.
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: "\."