Batterieüberwachung HM-Devices

Begonnen von AbeamStart, 10 April 2014, 12:02:53

Vorheriges Thema - Nächstes Thema

AbeamStart

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?
FHEM auf Debian (VM)

frank

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
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

betateilchen

Und ausserdem macht die regexp in der notify Definition nicht wirklich sehr viel Sinn. Ich tippe mal auf "einfach aus fhemwiki kopiert" ;)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

martinp876

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

Wuppi68

Hallo Martin,

kannst Du einen Beispiel HMinfo Notity hier reinstellen?

Gruß und Dank aus Barcelona

der Ralf
FHEM unter Proxmox als VM

martinp876

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

Wuppi68

FHEM unter Proxmox als VM

betateilchen

#7
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

martinp876

du solltest das attribut autoUpdate setzen

attr hm autoUpdate 0:3
=> alle 3  min ein Update automatisch.

AbeamStart

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...
FHEM auf Debian (VM)

betateilchen

Bei mir gibt es von hminfo keine events, die irgendwas triggern könnten - weder ein FileLog noch ein notify.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

martinp876

@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...