Hallo zusammen,
ich bräuchte mal einen Denkanstroß. Ich habe eine generelle Batteriewarnung für meine Sensoren eingerichtet:
define battery_chk notify .*:[Bb]attery:.* {\
if($EVENT !~ m/ok/) {\
FB_mail('name@mail.de', 'FHEM Batteriewarnung', $NAME.': '.$EVENT);;\
Log 3, "$NAME: Batteriewarnung $EVENT";;\
}\
}
Funktioniert für (fast*) alle meine Geräte. Jetzt habe ich aber einen Sensor (TFA Dostmann, TS34C), der zwischen battery ok und battery low im Minutentakt umschaltet.
Dies bedeutet, ich bekomme am Tag knapp 300 Mails mit einer Batteriewarnung.
Jetzt meine Frage:
Wie kann ich das notify so umbauen, dass am Tag max. eine Mail versendet wird? Dem Sensor noch ein Reading mail_sent mit Datum und Uhrzeit spendieren und in Abhängigkeit davon zu triggern? Wenn 24 Stunden um sind, das Reading wieder löschen? Oder habt ihr andere Ansätze?
Danke für Eure Tipps.
Gruß Peter
*Diejenigen, die nicht funktionieren, "sterben" bevor die "Unterspannungsmessung" zuschlagen kann -> Messung unter Last ist vermutlich deutlich besser.
Doif und dann waitsame sowie cmndpause?
defmod Batterie_DOIF DOIF ([":^battery:.*low"]) (set TelegramBot _msg FHEM-Batteriewarnung am Gerät $DEVICE) DOELSEIF ([10:00])
attr Batterie_DOIF do always
attr Batterie_DOIF waitsame 900
Gesendet von iPad mit Tapatalk Pro
Entweder mit watchdog arbeiten, oder ein täglich einmaliges at welche ,,alle leeren Batterie einsammelt" und dann versendet.
Gruß
Dan
Hallo,
bei mir ist das ein Cronjob der einmal am Tag die Werte sammelt. Die Geräte bei mir laufen noch über ein Monat mit der Warnmeldung, das Zeitfenster zum Reagieren ist also größer.
Peter
anhängende raw eines MSwitches sammelt um 18 Uhr alle Werte ein , die nicht 'ok' sind und verschickt diese .
Weiterhin erfolgt entsprechende Anzeige in Device selbst und der Versand kann manuell angestossen werden.
( den Befehl für den Mailversand musst du ggf. Anpassen )
gruss Byte09
defmod Batterie_Msg MSwitch
attr Batterie_Msg MSwitch_Debug 0
attr Batterie_Msg MSwitch_Delete_Delays 1
attr Batterie_Msg MSwitch_Expert 1
attr Batterie_Msg MSwitch_Extensions 0
attr Batterie_Msg MSwitch_Help 1
attr Batterie_Msg MSwitch_Ignore_Types notify allowed at watchdog doif fhem2fhem telnet FileLog readingsGroup FHEMWEB autocreate eventtypes readingsproxy svg cul
attr Batterie_Msg MSwitch_Include_Devicecmds 1
attr Batterie_Msg MSwitch_Include_MSwitchcmds 0
attr Batterie_Msg MSwitch_Include_Webcmds 0
attr Batterie_Msg MSwitch_Inforoom MSwitch
attr Batterie_Msg MSwitch_Lock_Quickedit 1
attr Batterie_Msg MSwitch_Mode Full
attr Batterie_Msg eventMap /exec_cmd_1:send_info/exec_cmd_1 ID 1:clear_readings/
attr Batterie_Msg room 1_test
attr Batterie_Msg stateFormat {my $out = ReadingsVal($name,'Devices_all','no_info');;$out=~ s/\n/<br>/ig;;return $out;;}
attr Batterie_Msg webCmd send_info:clear_readings
setstate Batterie_Msg no_info
setstate Batterie_Msg 2019-04-27 05:50:19 .Device_Affected FreeCmd-AbsCmd1,FreeCmd-AbsCmd2,FreeCmd-AbsCmd3
setstate Batterie_Msg 2019-04-27 05:55:58 .Device_Affected_Details FreeCmd-AbsCmd1#[NF]cmd#[NF]cmd#[NF]{#[nl]my#[sp]@devs#[se]#[nl]@devs=(devspec2array('(.*)#[dp]FILTER=battery=(.*[^ok])'))#[se]#[nl]my#[sp]$alldevices#[se]#[nl]foreach#[sp](@devs)#[nl]{#[nl]my#[sp]$devicename#[sp]=#[sp]"Device_".$_#[se]#[nl]my#[sp]$inhalt#[sp]=#[sp]ReadingsVal($_#[sp]#[ko]'battery'#[ko]'')#[se]#[nl]$alldevices#[sp].=#[sp]$_."#[sp]Status#[dp]#[sp]".$inhalt."#[bs]n"#[se]#[nl]fhem("setreading#[sp]$SELF#[sp]$devicename#[sp]$inhalt")#[se]#[nl]}#[nl]fhem("setreading#[sp]$SELF#[sp]Devices_all#[sp]Flogende#[sp]Batterien#[sp]müssen#[sp]bald#[sp]gewechselt#[sp]werden#[dp]#[bs]n$alldevices")#[se]#[nl]}#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]0#[NF]#[NF]0#[NF]0#[NF]1#[ND]FreeCmd-AbsCmd2#[NF]cmd#[NF]cmd#[NF]{#[nl]fhem("deletereading#[sp]$SELF#[sp]Device_.*")#[se]#[nl]fhem("deletereading#[sp]$SELF#[sp]Devices_.*")#[se]#[nl]}#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]1#[NF]1#[NF]#[NF]0#[NF]0#[NF]1#[ND]FreeCmd-AbsCmd3#[NF]cmd#[NF]cmd#[NF]{#[nl]FB_mail('name@mail.de'#[ko]#[sp]'FHEM#[sp]Batteriewarnung'#[ko]#[sp]'[$SELF#[dp]Devices_all]')#[se]#[nl]}#[nl]#[NF]#[NF]delay1#[NF]delay1#[NF]00#[dp]00#[dp]00#[NF]00#[dp]00#[dp]00#[NF]#[NF]#[NF]0#[NF]0#[NF]2#[NF]0#[NF]#[NF]0#[NF]0#[NF]1
setstate Batterie_Msg 2019-04-27 05:49:30 .Device_Events no_trigger#[tr]state:on
setstate Batterie_Msg 2019-04-27 05:49:30 .First_init done
setstate Batterie_Msg 2019-04-27 05:54:25 .Trigger_Whitelist undef
setstate Batterie_Msg 2019-04-27 05:49:30 .Trigger_cmd_off no_trigger
setstate Batterie_Msg 2019-04-27 05:49:30 .Trigger_cmd_on state:on
setstate Batterie_Msg 2019-04-27 05:54:25 .Trigger_condition
setstate Batterie_Msg 2019-04-27 05:49:30 .Trigger_off no_trigger
setstate Batterie_Msg 2019-04-27 05:49:30 .Trigger_on no_trigger
setstate Batterie_Msg 2019-04-27 05:54:25 .Trigger_time on~off~ononly[18#[dp]00]~offonly~onoffonly
setstate Batterie_Msg 2019-04-27 05:49:30 .V_Check V2.00
setstate Batterie_Msg 2019-04-27 05:54:25 Trigger_device no_trigger
setstate Batterie_Msg 2019-04-27 05:49:30 Trigger_log off
setstate Batterie_Msg 2019-04-27 05:56:06 last_cmd 1
setstate Batterie_Msg 2019-04-27 05:49:30 last_event state:off
setstate Batterie_Msg 2019-04-27 05:56:06 last_exec_cmd {fhem("deletereading Batterie_Msg Device_.*");;fhem("deletereading Batterie_Msg Devices_.*");;}
setstate Batterie_Msg 2019-04-27 05:49:30 state on
Zitat von: Peteruser am 26 April 2019, 22:38:07
Die Geräte bei mir laufen noch über ein Monat mit der Warnmeldung, das Zeitfenster zum Reagieren ist also größer.
Mein Mebus Außen-Temperatursensor lief noch für 3 Monate im Status "Battery low" und sendete regelmäßig seine Daten. Dann waren die Batterien wirklich platt und sogar das kleine Display am Sensor aus. Da wusste ich dann, dass es Zeit ist, die Batterie zu tauschen.
Das Thema ist so alt, wie FHEM selbst :)
Hiermit werden einmal täglich alle Devices gepostet, deren Battery-Reading nicht "ok" ist:
define msgBattery DOIF ([18:00] and [?@"":battery:$_ ne "ok",""]) (msg push Batteriewechsel für folgende Devices: [@"":battery:$_ ne "ok",""])
attr msgBattery do always
Wenn etwas toggelt, dann würde ich es toggeln lassen, bis es auf einen stabilen Zustand fällt (low). Dieser wird dann sicherlich rechtzeitig erkannt und dessen Device per Nachricht verschickt.
Das ist natürlich wieder mal genial, Damian. Kannst Du mal kurz erläutern, was
@"":battery:$_ ne
bedeutet? Ich erkenne "not equal" und den Vergleich mit "ok". Ich sehe @ was "jedes Device" bedeutet, dort dann das Reading battery (nicht besser [bB]attery?). Aber was ist $_ und die beiden Anführungen ""? Gibt es da eine Doku, die jetzt nicht gleich 100 Einträge umfasst?
Zitat von: andies am 27 April 2019, 12:16:36
Das ist natürlich wieder mal genial, Damian. Kannst Du mal kurz erläutern, was
@"":battery:$_ ne
bedeutet? Ich erkenne "not equal" und den Vergleich mit "ok". Ich sehe @ was "jedes Device" bedeutet, dort dann das Reading battery (nicht besser [bB]attery?). Aber was ist $_ und die beiden Anführungen ""? Gibt es da eine Doku, die jetzt nicht gleich 100 Einträge umfasst?
https://fhem.de/commandref_DE.html#DOIF_aggregation
dort ist erklärt, was @ $_ usw. bedeutet. battery ist ein konkretes Reading, inzwischen kann man aber auch Regex für Readings angeben:
z.B. [?@"":"[Bb]attery":$_ ne "ok",""]
Hallo zusammen,
ich muss noch einmal nachfragen, ich habe den Code wie folgt übernommen
define msgBattery DOIF ([18:00] and [?@"":"[Bb]attery":$_ ne "ok",""]) (msg text jemand@mailadresse.info |Batteriewarnung| Batteriewechsel fuer folgende Geraete: [?@"":"[Bb]attery":$_ ne "ok"," "])
bekomme aber bei meinem Homematic Heizköperthermostat und dem Wandthermostat immer die Meldung, dass die Batterie leer ist. Hier ein List eines der beiden Geräte:
Internals:
DEF 6A1E3D
IODev PMCUL01
LASTInputDev PMCUL01
MSGCNT 2
NAME HM_Bad_HKT
NOTIFYDEV global
NR 220
NTFY_ORDER 50-HM_Bad_HKT
PMCUL01_MSGCNT 2
PMCUL01_RAWMSG A0F7886106A1E3D0000000AB0BD0B6400::-53.5:PMCUL01
PMCUL01_RSSI -53.5
PMCUL01_TIME 2020-06-11 11:00:47
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_Bad_HKT_Weather
channel_02 HM_Bad_HKT_Climate
channel_03 HM_Bad_HKT_WindowRec
channel_04 HM_Bad_HKT_Clima
channel_05 HM_Bad_HKT_ClimaTeam
channel_06 HM_Bad_HKT_remote
lastMsg No:78 - t:10 s:6A1E3D d:000000 0AB0BD0B6400
protLastRcv 2020-06-11 11:00:47
rssi_at_PMCUL01 cnt:2 min:-53.5 max:-53.5 avg:-53.5 lst:-53.5
READINGS:
2020-06-11 10:57:59 Activity alive
2020-06-11 10:42:17 CommandAccepted yes
2020-06-11 10:42:29 D-firmware 1.5
2020-06-11 10:42:29 D-serialNr PEQ1192004
2020-06-11 10:42:17 PairedTo 0xF10000
2018-12-30 14:17:44 R-backOnTime 10 s
2020-06-11 10:09:26 R-btnLock off
2018-12-30 14:17:44 R-burstRx on
2018-12-30 14:17:44 R-cyclicInfoMsg on
2018-12-30 14:17:44 R-cyclicInfoMsgDis 0
2018-12-30 14:17:44 R-globalBtnLock off
2018-12-30 14:17:44 R-localResDis off
2020-04-13 19:38:45 R-lowBatLimitRT 2.2 V
2018-12-30 14:17:44 R-modusBtnLock off
2018-12-30 14:17:44 R-pairCentral 0xF10000
2020-06-11 10:42:17 RegL_00. 01:01 02:01 09:01 0A:F1 0B:00 0C:00 0E:0A 0F:00 11:00 12:16 16:01 18:00 19:00 1A:00 00:00
2020-06-11 10:51:08 RegL_07.
2020-06-11 11:00:47 actuator 100
2020-06-11 11:00:47 battery ok
2020-06-11 11:00:47 batteryLevel 2.6
2020-05-21 16:21:00 battery_usr ok
2018-12-31 13:39:19 controlMode manual
2020-06-11 11:00:47 desired-temp 22.0
2020-06-11 11:00:47 measured-temp 18.9
2020-06-11 11:00:47 motorErr ok
2020-06-06 18:13:08 powerOn 2020-06-06 18:13:08
2020-06-06 18:13:08 recentStateType info
2020-06-11 10:42:25 state CMDs_done
2020-06-10 13:14:29 time-request -
helper:
HM_CMDNR 120
mId 0095
regLst ,0
rxType 140
supp_Pair_Rep 0
expert:
def 1
det 1
raw 1
tpl 1
io:
newChn +6A1E3D,00,00,00
nextSend 1591866047.19399
prefIO
rxt 2
vccu
p:
6A1E3D
00
00
00
mRssi:
mNo 78
io:
PMCUL01:
-47.5
-47.5
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_PMCUL01:
avg -53.5
cnt 2
lst -53.5
max -53.5
min -53.5
shRegW:
07 04
tmpl:
Attributes:
IODev PMCUL01
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
event-min-interval (actuator|desired-temp|measured-temp|batteryLevel):600
event-on-change-reading battery
event-on-update-reading actuator,desired-temp,measured-temp,motorErr,controlMode,batteryLevel
expert 251_anything
firmware 1.5
model HM-CC-RT-DN
room 1_Bad
serialNr PEQ1192004
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
M.E. ist das Reading battery vollkommen i.O., ich frage mich, warum dann die Mail abgeschickt wird :o. Für einen Schubs in die richtige Richtung wäre ich echt dankbar ...
Gruß Peter
Ich nutze ja DOIF nicht ;)
aber wenn ich die weiter oben verlinkte cref richtig deute:
Zitat
Liste der Devices, die mit "windows" beginnen und im Status das Wort "open" vorkommt:
[@"^window":state:"open"]
entspricht:
[@"^window":state:$_ =~ "open"] siehe Aggregationsbedingung.
EDIT: wobei müsste es nicht heißen: die mit window statt windows anfangen!?
Da heißt es: die mit ... BEGINNEN...
Die Homematic haben ja das battery-Reading UND das batteryLevel mit Spannungswert, der sicher NICHT "ok" ist ;)
Vielleicht ist es ja das!?
Wie geschrieben: nix DOIF-Einsetzer ;)
Und für Batteriemeldung nutze ich das hier: https://forum.fhem.de/index.php/topic,82637.msg747514.html#msg747514
(gut, gibt den Alarm raus, wenn die Batterie fällig ist aber da sind viele Geräte-Typen "integriert", ist wohl nötig solange es nicht einheitlich ist / bzw. nutze ich immer noch "meinen" Code mit einigen Dingen bzgl. Falschmeldungen etc. / gerade die Homematic Fenstersensoren neigen dazu immer wieder mal zwischen ok und lowBat zu springen, wenn es auf's Ende zu geht [und zwar teilweise "über Monate" ;) ] / fraglich welchen Zustand du erwischst, wenn du nur einmal am Tag "nachschaust" ;) / und es kann dann passieren, dass das Device "plötzlich" dead ist und gar nichts mehr schickt, das Reading aber noch auf ok steht ;) )
Ich merke/protokolliere damit auch autom. wie lange die einzelnen Batterien so gehalten haben und neuerdings (userAttr) auch welche Batterie und wie viele davon denn benötigt wird :)
Gruß, Joachim
Versuche es mal mit:
[?@"":"^[Bb]attery$":$_ ne "ok",""]
Vielen Dank. Heute kam keine Mail, aber es war auch keine Batterie nok ;D
Zitat von: Damian am 11 Juni 2020, 11:27:29
[?@"":"^[Bb]attery$":$_ ne "ok",""]
Ich versuche mal aufzulösen:
[<function>:<format>:"<regex device>:<regex event>":<reading>|"<regex reading>":<condition>,<default>]?@"": ... <regex device> @ ... Liste Devices, beim Fragezeichen bin ich mir nicht sicher, da Doppelpunkt fehlen kann, gilt das für alle Events <regex event>
"^[Bb]attery$": ... <reading> alle Readings mit
Battery oder
Battery, beim ^ bin ich mir nicht sicher
$_ ne "ok", ... <condition> ungleich ok
"" ... <default> kein Defaultwert
Vermutlich sind ? und ^ Platzhalter der
regular expressions, was zugegebenermaßen nicht meine starke Seite ist, bin aber für jeden Hinweis dankbar.
Zitat von: MadMax-FHEM am 11 Juni 2020, 11:23:24
gerade die Homematic Fenstersensoren neigen dazu immer wieder mal zwischen ok und lowBat zu springen, wenn es auf's Ende zu geht [und zwar teilweise "über Monate" ;)
Ja, meine LaCrosse Sensoren toggeln auch noch sehr lange. Daher hatte ich mit der Batteriemeldung aus dem Wiki lange Spaß, vor allem, wenn ich im Ausland war und dann ab früh morgens alle 5 Minuten eine Mail bekommen habe.
Ich schaue mir die andere Lösung mal an, möchte aber jetzt erst eine funktionierende für den statischen Zustand.
Zitat von: MadMax-FHEM am 11 Juni 2020, 11:23:24
Ich merke/protokolliere damit auch autom. wie lange die einzelnen Batterien so gehalten haben und neuerdings (userAttr) auch welche Batterie und wie viele davon denn benötigt wird :)
Geht das automatisch? Ich generiere immer manuell ein Reading Batteriewechsel mit Datum und lasse das dann mitloggen.
Gruß Peter
Zitat von: PeMue am 11 Juni 2020, 21:01:35
Geht das automatisch? Ich generiere immer manuell ein Reading Batteriewechsel mit Datum und lasse das dann mitloggen.
Wie gesagt bzw. dort zu lesen: der Code stammt(e) mal von mir...
...meiner tut das automatisch... :)
Sieht dann aus wie im Anhang...
Die Haltbarkeiten sind Wochen...
...durch Leerzeichen getrennt, wenn schon vorher Haltbarkeiten vorhanden waren...
Gruß, Joachim
Ich habe inzwischen eine andere Lösung für mein Problem am laufen (die Variante https://forum.fhem.de/index.php/topic,82637.0.html (https://forum.fhem.de/index.php/topic,82637.0.html) war mir zu kompliziert und ich habe auch verschiedene Geräte, die sich leider nicht über einen Kamm scheren lassen). Insbesondere gefiel mir nicht, dass mein Bresser_Temeo seit einem halben Jahr eine low-Batterie meldet, es aber immer noch tut. Also habe ich in 99_myUtils nun eine Funktion definiert, die eine Liste mit Gerätennamen und Readings erhält. Geprüft wird nur, ob das Alter des genannten Readings größer als einen halben Tag ist (shellyflood sendet nur zweimal am Tag) und wenn ja, dann wird eine Nachricht versendet.
sub OfflineMelden(){
my %readingliste = (
"BadUntenfenster" => "battery",
# ...
"Wasserzaehler_IEC_01"=> "energyCalc",
"shellyflood" => "battery"
);
foreach my $geraete (keys(%readingliste)){
# durchlaufe alle Geraete
if (ReadingsAge($geraete, $readingliste{$geraete}, "") > 86400) {
fhem("set TelegramBot message Gerät $geraete **offline**.");
}
}
}
Das klappt dann mit
defmod OfflineDOIF DOIF ([07:00] or [19:00]) ({OfflineMelden()})
attr OfflineDOIF do always
sehr gut.