Hallo Martin, (oder andere Kompetenzen)
ich habe die E-Mailbenachrichtigung bei niedriger Batterie Meldung umgesetzt:
####################################################
##Batterieüberwachung Anfang
####################################################
define n_batt_chk notify .*:[Bb]attery.* { if("%" !~ m/ok/) { \
{DebianMail('any@@one.org', 'FHEM Batteriewarnung', '@ %')};; \
Log 3, "@: Batteriewarnung %";; \
}\
}
attr n_batt_chk room 99.System
####################################################
##Batterieüberwachung Ende
####################################################
Jetzt ist mir das Batteriesymbol an einem HM-TC im Bad aufgefallen aber in FHEM unter dem Gerät:
readings
.
.
.
battery ok
Was ist da los?
ist das resding aktuell (timestamp)?
bei meinen tc muss dass batterie symbol lange aufleuchten bis irgendwann der status gesendet wird. einfach mal warten.
gruss frank
Und ausserdem macht die regexp in der notify Definition nicht wirklich sehr viel Sinn. Ich tippe mal auf "einfach aus fhemwiki kopiert" ;)
der TC ist ein cleverer Bursche. Der zeigt auch an, wenn einer seiner Freunde (Ventil/Fensterkontakt) kaum noch Saft hat. Das meldet er aber nicht der Zentrale.
Prinzip: Ein TC als semi-zentrale zeigt Infos über andere an. Eine wirkliche Zentrale muss nicht informiert werden, die bekommt die Daten direkt.
a) wo ist die batterie "low"? TC oder VD? oder am Ende Fensterkontakt?
b) wird das entsprechende Device gemeldet?
=Hatte gerade einen batteriealarm vom VD. War im TC zu sehen. In FHEM gemeldet am VD. Nach batterietausch sind alle Alarme weg.
Dann noch ein Hinweis auf vorbereits vorhandenen Alarmierungen: HMInfo
HMInfo sammelt einige generell kritischen Alarme. Eine Auswertung von HMInfo zu diesem Punkt sollte das notify "kanalisieren". Es soll vermeiden, dass User sich kritische Alarme selbst "suchen" müssen. Batterie wird her gesammelt und kann direkt genutzt werden
Gruss Martin
Hallo Martin,
kannst Du einen Beispiel HMinfo Notity hier reinstellen?
Gruß und Dank aus Barcelona
der Ralf
define hmERRnf notify hm:ERR_.* {send email %EVENT}
Beinhaltet ERR__protocol und alle, deren Zustand im Attribut sumERROR definiert ist.
in sumERROR steht beispielsweise battery:ok,...
=> wenn das Reading battery vorhanden ist, aber nicht "ok" wir dies als Fehelr gewertet.
Dann erscheint ein Reading mit der Aussage wie viele battery-fehlzustände vorhanden sind.
"ERR_batterie:..."
in Internals siehst du dieNamen aller fehlerhaften Komponenten
InternalVal("hm","ERR_names","")
was du in deinem Notify verarbeiten kannst
Teste es indem du
attr hm sumERROR batterie:xx
setzt. Dann werden alle "batterie ok" als fehler gemeldet.
merke dir den Inhalt von sumERROR - da sind wichtige Fehler abgebildet - erweitern kannst du natürlich.
wenn du nur Batterie willst kannst du
define hmERRnf notify hm:ERR_bat.* {send email %EVENT}
nehmen
ein ganz grosses
D a n k e
Zitat von: martinp876 am 11 April 2014, 15:24:00
Teste es indem du
attr hm sumERROR batterie:xx
setzt. Dann werden alle "batterie ok" als fehler gemeldet.
Das funktioniert bei mir nicht.grrr... es funktioniert, aber nur, wenn ich manuell ein set hm update mache. Aber von events, auf die ich triggern könnte, keine Spur.
du solltest das attribut autoUpdate setzen
attr hm autoUpdate 0:3
=> alle 3 min ein Update automatisch.
Ja wirklich warten!
Es war der TC und heute (über 2-3 Wochen seit erstem anzeigen) wurde eine E-Mail an mich gesendet!
Was ist denn mit meinem notify? Bitte um Verbesserungsvorschläge...
Bei mir gibt es von hminfo keine events, die irgendwas triggern könnten - weder ein FileLog noch ein notify.
@betateilchen
habe gerade noch einmal getestet. Wenn dich battery:xx einbaue kommt nach 3 min (mein update timer) ein "inform", also ein trigger
2014-04-12 10:53:48.789 HMinfo hm ERR_battery: ok:11;low:1;
der steht auch im logfile - und im Reading.
=> wird dein Reading gesetzt, aber es kommt kein Trigger? Oder kommt das Reading erst garnicht?
@AbeamStart
ZitatEs war der TC und heute (über 2-3 Wochen seit erstem anzeigen) wurde eine E-Mail an mich gesendet!
anzeigen wo? Am TC oder in FHEM? Für TC oder VD?
Hast du das ganze in einem event-log?
Da es i.a. funktioniert bitte sehr detailierte Beschreibung, prüfen der Readings aller Komponenten.... inc. deren Zeitstempel, logfile lesen...