Batteriestatus überwachen und per Email senden

[Wuppi68]

Hi, was meinst du damit?

@igami, danke für den Tip, kannte ich noch nicht, werde ich mir aber mal ansehen.

der letzte Und Teil sieht mir nach der Bedingung aus, dass kein Event gefeuert wird

[breti]

Vielleicht hilft es jemandem: Ich überwache den Batteriestatus der HomeMatic Komponenten per hmInfo-Device und lasse mich per GCM Nachricht auf's Smartphone informieren. Da sich der hm-Status nur ändert, wenn sich ein Batteriestatus ändert, gibt's auch keine wiederholten identischen Benachrichtigungen.

Das folgende define in der fhem.cfg tut's dafür:

Code Auswählen Erweitern


define gl_nf_battery notify hm:ERR_battery.* {\
  fhem("set gcm send Batterie|Batterie leer|HomeMatic-Komponenten: " . InternalVal('hm', 'ERR_names', ''));;\
}


[CoolTux]

Es ist sehr nett das Du Deine Erkenntnisse teilst.
Bitte achte darauf das auch Anfänger dies gerne in Anspruch nehmen und es generell eine schlechte Idee ist Anfänger das editieren der fhem.cfg zu beschreiben. Besser wäre ein define für die FHEMWEB Kommandozeile

Code Auswählen Erweitern


define gl_nf_battery notify hm:ERR_battery.* set gcm send Batterie|Batterie leer|HomeMatic-Komponenten: $EVENT


Sollte es auch tun. Leider ungetestet.

[breti]

Danke. Wie kommst du darauf, dass $EVENT die Komponentennamen enthält? Das Event im Log sieht wie folgt aus:

Code Auswählen Erweitern


2017-09-08 18:42:28 HMinfo hm ERR_battery: low:2,


[CoolTux]

Ich habe etwas ähnliches mit ERR und dachte man kann es adaptieren.
Wenn nicht empfiehlt sich in Deinem Fall statt ReadingsVal setMagic zu verwenden

Code Auswählen Erweitern


define gl_nf_battery notify hm:ERR_battery.* set gcm send Batterie|Batterie leer|HomeMatic-Komponenten: [hm:ERR_names]


[breti]

Sehr schön, das funktioniert tatsächlich! Vielen Dank, das kannte ich noch nicht.

[CoolTux]

Gern geschehen. Es ist Anfängerfreundlich. Die alten Hasen schreiben natürlich alles in Perl 
Aber FHEM soll ja gerade bei den Beginnern eine höhere Akzeptanz bekommen.


Grüße

[breti]

Hmm - gibt es ERR_names nicht mehr? Meine "Batterie leer"-Meldung sagt nur noch "HomeMatic-Komponenten: [hm:ERR_names]", und während ERR_battery die Device-Namen auch listet, werden mir die Alias-Langnamen offenbar nicht mehr angezeigt?

Code Auswählen Erweitern

fhem> set hm update
fhem> list hm
Internals:
   ERR___rssiCrit sz_fg_fenster
   ERR__protocol sz_sa_bettlicht
   ERR_battery bz_wt_waschbecken,sz_wt_bettlicht
   I_HM_IOdevices ok: HMUSB;
   NAME       hm
   NR         165
   NTFY_ORDER 50-hm
   STATE      updated:2019-01-06 11:50:03
   TYPE       HMinfo
   Version    01
   W__protoNames bz_ht_heizung,sz_sa_bettlicht
   READINGS:
     2018-02-11 15:13:23   CRIT__protocol  -
     2019-01-06 11:50:03   CRI__protocol   -
     2017-10-26 18:22:31   C_sumDefined    entities:150,device:52,channel:131,virtual:3
     2019-01-06 11:19:25   ERR__protocol   CmdDel:1,ResndFail:1
     2019-01-06 11:24:25   ERR__unreachable 0
     2019-01-05 22:03:05   ERR_battery     low:2,
     2019-01-05 15:51:59   I_actTotal      alive:25,dead:0,unkn:1,off:0
     2017-10-23 12:03:19   I_autoReadPend  0
     2019-01-06 11:24:25   I_rssiMinLevel  59<:17 60>:15 80>:5 99>:1
     2019-01-05 22:03:05   I_sum_battery   low:2,ok:38,
     2019-01-06 11:44:27   I_sum_motor     closing:1,stop:6,
     2019-01-06 11:49:27   I_sum_sabotageError off:7,
     2019-01-06 11:19:25   W__protocol     Resnd:2
   helper:
     autoUpdate 300
     cfgChkResult configCheck done:

templist mismatch
    bz_ht_heizung_Climate: failed Entries:
     bz_ht_heizung_Climate :R_2_tempListMon mismatch 05:45 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ne 05:40 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ##
     bz_ht_heizung_Climate :R_3_tempListTue mismatch 05:45 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ne 05:40 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ##
     bz_ht_heizung_Climate :R_4_tempListWed mismatch 05:45 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ne 05:40 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ##
     bz_ht_heizung_Climate :R_5_tempListThu mismatch 05:45 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ne 05:40 17.0 10:00 21.5 21:30 18.5 24:00 17.0 ##
     bz_ht_heizung_Climate :R_6_tempListFri mismatch 05:45 17.0 10:00 21.5 22:00 18.5 24:00 17.0 ne 05:40 17.0 10:00 21.5 22:00 18.5 24:00 17.0 ##
     weekplanListDef ./tempList-home.cfg
     weekplanListDir ./
     weekplanList:
       az_ht_heizung_Climate
       wz_ht_heizung_Climate
       bz_ht_heizung_Climate
       wf_ht_heizung_Climate
       sz_ht_heizung_Climate
       ku_ht_heizung_Climate
   nb:
     cnt        1
Attributes:
   autoUpdate 00:05
   configTempFile tempList-home.cfg
   room       Global
   sumERROR   battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
   sumStatus  battery,sabotageError,powerError,motor
   webCmd     update:protoEvents short:rssi:peerXref:configCheck:models

fhem>

[breti]

Hmm - weiß hier wirklich niemand etwas drüber?  Ist ERR_names einfach so verschwunden?

[Tommy82]

Hi,
ich muss das nochmal hoch holen,
das notify sieht aktuell so aus, der Dummy wird auch korrekt geschaltet

Code Auswählen Erweitern

defmod Batterie_Status_nt notify .*[Bb]attery:.(?!ok).* { \
if (($NAME ne "rd_Batterie") && ($NAME ne "rd_Batterie_Level") && ($NAME ne "rd_Rauchmelder") && ($NAME ne "rd_Rauchmelder_Erdgeschoss") && (Value("BATT_Status") ne "LOW" )) {\
Log(3,"$NAME : Batteriewarnung $EVENT");;\
{ fhem ("set BATT_Status LOW") } ;;\
DebianMail('Batteriewarnung',$NAME.': '.$EVENT);; \
    } \
}
attr Batterie_Status_nt group Info
attr Batterie_Status_nt room Zentral

setstate Batterie_Status_nt 2019-12-10 19:51:28
setstate Batterie_Status_nt 2019-12-10 19:48:05 state active


allerdings löst das notify auch aus wenn ich z.b. ein Fenster öffne/schließe und einer meiner HM Fensterkontakte auslöst

Code Auswählen Erweitern

defmod Gaeste_WC_Fenster CUL_HM 589CE2
attr Gaeste_WC_Fenster .mId 00C7
attr Gaeste_WC_Fenster IODev hmusb
attr Gaeste_WC_Fenster IOgrp vccu:hmusb
attr Gaeste_WC_Fenster actCycle 002:50
attr Gaeste_WC_Fenster actStatus alive
attr Gaeste_WC_Fenster alarmDevice Sensor
attr Gaeste_WC_Fenster alarmSettings alarm0,|Gaeste_WC_Fenster:open|Einbruch Fenster Gäste WC|on
attr Gaeste_WC_Fenster autoReadReg 4_reqStatus
attr Gaeste_WC_Fenster burstAccess 1_auto
attr Gaeste_WC_Fenster expert 2_raw
attr Gaeste_WC_Fenster firmware 1.0
attr Gaeste_WC_Fenster group Fensterkontakte
attr Gaeste_WC_Fenster model HM-SEC-SCO
attr Gaeste_WC_Fenster peerIDs 00000000,2237FB03,
attr Gaeste_WC_Fenster room Gäste_WC
attr Gaeste_WC_Fenster serialNr OEQ0439191
attr Gaeste_WC_Fenster subType threeStateSensor

setstate Gaeste_WC_Fenster closed
setstate Gaeste_WC_Fenster 2018-10-12 20:15:06 .D-devInfo 810101
setstate Gaeste_WC_Fenster 2018-10-12 20:15:06 .D-stc 80
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 .R-msgScPosA open
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 .R-msgScPosB closed
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 .R-transmDevTryMax 6
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 .R-transmitTryMax 6
setstate Gaeste_WC_Fenster 2018-10-12 20:15:07 .peerListRDate 2018-10-12 20:15:07
setstate Gaeste_WC_Fenster 2019-12-10 19:25:26 .protLastRcv 2019-12-10 19:25:26
setstate Gaeste_WC_Fenster 2019-12-10 19:48:21 Activity alive
setstate Gaeste_WC_Fenster 2018-09-24 19:39:13 CommandAccepted yes
setstate Gaeste_WC_Fenster 2018-10-12 20:15:06 D-firmware 1.0
setstate Gaeste_WC_Fenster 2018-10-12 20:15:06 D-serialNr OEQ0439191
setstate Gaeste_WC_Fenster 2018-10-12 20:15:06 PairedTo 0x000041
setstate Gaeste_WC_Fenster 2018-10-12 20:19:10 R-Gaeste_WC_WindowRec-expectAES off
setstate Gaeste_WC_Fenster 2018-10-12 20:19:10 R-Gaeste_WC_WindowRec-peerNeedsBurst on
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 R-cyclicInfoMsg on
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 R-eventDlyTime 0 s
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 R-pairCentral 0x000041
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 R-sabotageMsg on
setstate Gaeste_WC_Fenster 2018-10-12 20:19:11 R-sign on
setstate Gaeste_WC_Fenster 2018-10-12 20:15:06 RegL_00. 02:01 09:01 0A:00 0B:00 0C:41 10:01 14:06 00:00
setstate Gaeste_WC_Fenster 2018-10-12 20:15:07 RegL_01. 08:01 20:9C 21:00 30:06 00:00
setstate Gaeste_WC_Fenster 2018-10-12 20:15:08 RegL_04.Gaeste_WC_WindowRec 01:01 00:00
setstate Gaeste_WC_Fenster 2018-09-24 19:39:13 aesCommToDev ok
setstate Gaeste_WC_Fenster 2018-09-24 19:39:13 aesKeyNbr 00
setstate Gaeste_WC_Fenster 2019-12-10 19:25:26 alive yes
setstate Gaeste_WC_Fenster 2019-12-10 19:25:26 battery ok
setstate Gaeste_WC_Fenster 2019-12-10 19:25:26 contact closed (to vccu)
setstate Gaeste_WC_Fenster 2019-12-10 19:48:23 peerList Gaeste_WC_WindowRec,
setstate Gaeste_WC_Fenster 2019-12-10 19:25:26 recentStateType info
setstate Gaeste_WC_Fenster 2019-12-10 19:25:26 sabotageError off
setstate Gaeste_WC_Fenster 2019-12-10 19:25:26 state closed
setstate Gaeste_WC_Fenster 2019-12-09 21:23:45 trigger_cnt 86



Woran kann das liegen?

Danke

[amenomade]

Schau mal die Events im Eventmonitor. Vermutlich wird beim öffnen/schliessen auch ein Event mit battery geschickt, der zu deiner Regex passt

[Tommy82]

Schau mal die Events im Eventmonitor. Vermutlich wird beim öffnen/schliessen auch ein Event mit battery geschickt, der zu deiner Regex passt

Hi,
im Eventmonitor steht (manchmal) das beim öffnen/schließen des Fensters

Code Auswählen Erweitern

2019-12-14 11:19:00.344 monitoring Batterie_monitoring warning remove: Gaeste_WC_Fenster
2019-12-14 11:19:00.344 monitoring Batterie_monitoring warning:
2019-12-14 11:19:00.344 monitoring Batterie_monitoring warningCount: 0
2019-12-14 11:19:00.344 monitoring Batterie_monitoring allCount: 0
2019-12-14 11:19:00.367 CUL_HM Gaeste_WC_Fenster battery: ok
2019-12-14 11:19:00.367 CUL_HM Gaeste_WC_Fenster contact: open (to Gaeste_WC)
2019-12-14 11:19:00.367 CUL_HM Gaeste_WC_Fenster open
2019-12-14 11:19:00.367 CUL_HM Gaeste_WC_Fenster trigger_cnt: 99
2019-12-14 11:19:00.480 CUL_HM Gaeste_WC_WindowRec trigLast: Gaeste_WC_Fenster:open
2019-12-14 11:19:00.480 CUL_HM Gaeste_WC_WindowRec trig_Gaeste_WC_Fenster: Open_99
2019.12.14 11:19:00.710 3 : Gaeste_WC_Fenster : Batteriewarnung battery: low
2019.12.14 11:19:00.744 1 : sendEmail RCP: Th.Halberstadt@googlemail.com
2019.12.14 11:19:00.745 1 : sendEmail Subject: Batteriewarnung
2019.12.14 11:19:00.745 1 : sendEmail Text: Gaeste_WC_Fenster: battery: low
2019.12.14 11:19:03.031 1 : sendEmail returned: Dec 14 11:19:03 localhost sendEmail[15555]: Email was sent successfully!
2019.12.14 11:19:03.198 1 : [Freezemon] myFreezemon: possible freeze starting at 11:19:01, delay is 2.195 possibly caused by: no bad guy found :-(
2019-12-14 11:19:00.724 dummy BATT_Status LOW
2019-12-14 11:19:03.065 monitoring Batterie_monitoring warning add: Gaeste_WC_Fenster
2019-12-14 11:19:03.065 monitoring Batterie_monitoring warning: Gaeste_WC_Fenster
2019-12-14 11:19:03.065 monitoring Batterie_monitoring warningCount: 1
2019-12-14 11:19:03.065 monitoring Batterie_monitoring allCount: 1
2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster battery: low
2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster contact: open (to vccu)
2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster open
2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster trigger_cnt: 99

[amenomade]

Code Auswählen Erweitern

2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster battery: low
2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster contact: open (to vccu)
2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster open
2019-12-14 11:19:03.091 CUL_HM Gaeste_WC_Fenster trigger_cnt: 99
Anscheinend sendet dein FK beim Öffnen das Reading battery mit. Oder zyklisch wenn das Fenster offen bleibt.

Aber statt in der Log zu schauen, guck lieber im Eventmonitor

[Tommy82]

Das ist aus dem Eventmonitor

[amenomade]

Ne im Eventmonitor kommen nw. keine Meldungen mit Loglevel 3 oder 1, sondern nur die Events, es sei denn, Du hast "FHEM log" angehackt