Hallo,
ich habe das Wiki-Beispiel zur Batterie-Warnung etwas adaptiert:
defmod di_BatterieCheck DOIF ([":[Bb]attery: low"])\
(setreading $SELF B_$DEVICE low,\
(msg mail meine@email.de 2 |FHEM: Batteriewarnung| Hallo,\n\n $DEVICE meldet niedrigen Batteriestand!\n\nGruss\nEuer HausAutomat))\
DOELSEIF ([":[Bb]attery: ok"])\
(setreading $SELF B_$DEVICE ok)
attr di_BatterieCheck do always
Das funktioniert soweit gut, nur kommen die Warnungen natürlich nervtötend oft.
Nach den Infos der commandref hatte ich angenommen, mit
Zitatattr di_BatterieCheck cmdpause 21600
würde frühestens nach 21.600 Sekunden eine erneute Warnung geschickt werden - tatsächlich bekomme ich aber GAR KEINE.
"matched_event_c1_1" zeigt korrekt an, dass das Event erkannt wurde, aber es erfolgt keine Ausführung, weder beim 1. Mal noch irgendwann später.
Warum? Oder auch anders gefragt, wie sollte ich das zweckmäßigerweise lösen?
Hättest du das Bespiel komplett aus der Commandref https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events
übernommen, hättest du das Problem nicht.
Hallo Damian,
damit wird nach meinem Verständnis die Meldung genau EIN Mal ausgelöst.
Das will ich aber nicht: wenn man sich nicht kümmert, soll weiterhin erinnert werden (nur halt nicht im 5-Minuten-Takt)!
Nein, jedes Mal, dass ein Event in der Form ":[Bb]attery: low" ausgelöst wird.
EDIT: Sorry, hatte das Thread zu schnell gelesen...
Warum setzt Du nicht event-min-interval [Bb]attery:21600 auf jeweiligen Devices?
Zitat von: amenomade am 20 Dezember 2017, 22:49:19
Warum setzt Du nicht event-min-interval [Bb]attery:21600 auf jeweiligen Devices?
Weil ich gern eine elegante Lösung hätte, die jegliche Art von Batteriewarnungen von beliebigen Devices überwacht, ohne dass ich die alle explizit kennen und setzen muss. ;)
Dann füge mal noch in der ersten Befehlsfolge des ursprünglichen DOIF (von CommandRef) sowas hinzu:
defmod at_battery_$DEVICE at +06:00 setreading $SELF B_$DEVICE ok
Vielleicht würde es auch somit gehen (wäre zu testen):
([":battery: low"] and [?$SELF:B_$DEVICE] ne "low")
((msg mail meine@email.de 2 |FHEM: Batteriewarnung| Hallo,\n\n $DEVICE meldet niedrigen Batteriestand!\n\nGruss\nEuer HausAutomat))
(setreading $SELF B_$DEVICE low)
(setreading $SELF B_$DEVICE ok)
DOELSEIF ([":battery: ok"] and [?$SELF:B_$DEVICE] ne "ok")
(setreading $SELF B_$DEVICE ok)
attr di_BatterieCheck wait 0,0,21600
attr di_BatterieCheck do always
Zitat von: borsti67 am 20 Dezember 2017, 22:19:37
Hallo Damian,
damit wird nach meinem Verständnis die Meldung genau EIN Mal ausgelöst.
Das will ich aber nicht: wenn man sich nicht kümmert, soll weiterhin erinnert werden (nur halt nicht im 5-Minuten-Takt)!
Bei cmdpause wird nur dann ein Befehl ausgeführt, wenn die letzte Änderung des Zustand des DOIF-Moduls alt genug ist (hier 6 Stunden). Das ist hier keine gute Idee, da ok-Meldungen den Zustand alle paar Minuten aktualisieren. Abgesehen davon würde man ggf. wichtige Meldung von anderen Devices verpassen.
Da die Warnmeldung nicht so zeitkritisch ist, kann man z. B. alle paar Stunden einen Check machen:
DOIF ([+[6]:00] and [?#"":battery:$_ ne "ok"]) ((msg mail meine@email.de 2 |FHEM: Batteriewarnung| Hallo,\n\n [@"":battery:$_ ne "ok"] meldet niedrigen Batteriestand!\n\nGruss\nEuer HausAutomat))
attr do always Mit der Aggreationsfunktion werden auch mehrere Devices gemeldet, wenn sie nicht ok sind
@amenomade:
geht so leider nicht, denn das würde in beiden Fällen nur nach 6 Stunden den Status zurücksetzen, aber nicht verhindern, dass zwischenzeitlich die ganzen neuen Events triggern (wobei im 2. Beispiel auch noch der Test "ne low" raus müsste, denn der verhindert, dass überhaupt eine 2. Meldung kommt ;))
@Damian:
Das ist eine super Idee, die vermutlich sogar die Last etwas reduziert, da fhem so nicht bei jeder Batterie-Meldung das DOIF abarbeiten muss!
Die Aggregatsfunktionen habe ich noch nie benutzt; teils weil ich noch keinen Anwendungsfall gefunden hatte, den ich nicht auch "klassisch" hätte lösen können, und zum anderen, weil ich die Syntax und deren (mögliche) Auswirkungen nicht durchschaut habe... Auch Deinen Vorschlag hier habe ich erst im 3. Anlauf verstanden (jedenfalls hoffe ich das). :( Nur noch eine Frage: Wird das im Ausführungsteil durch eine (kommagetrennte?) Liste ersetzt, oder werden "n" Mails mit je einem Device versandt, wenn mehr als 1 Batterie-Status nicht ok ist?
Ich werde das jedenfalls mal so einbauen und beobachten. Vielen Dank!
Zitat von: borsti67 am 21 Dezember 2017, 07:53:35
@amenomade:
geht so leider nicht, denn das würde in beiden Fällen nur nach 6 Stunden den Status zurücksetzen, aber nicht verhindern, dass zwischenzeitlich die ganzen neuen Events triggern (wobei im 2. Beispiel auch noch der Test "ne low" raus müsste, denn der verhindert, dass überhaupt eine 2. Meldung kommt ;))
Eben nicht.
Wenn Du das (vollständige - mit "ne low") DOIF von CommandRef wie geschrieben nimmst, würden die Events zwar triggern, aber die "ne low" Bedingung würde verhindern, dass eine Nachricht wieder geschickt wird. Bis das "at" das Reading zurück auf ok setzt, dann wird "ne low" wieder wahr.
Und im 2. Beispiel genauso. "ne low" muss
nicht raus. Die 2. Meldung kommt erst dann wenn "setreading $SELF B_$DEVICE ok" nach dem 21600 wait Timer das Reading zurücksetzt. Dann ist "ne low" wieder wahr.
Zitat von: borsti67 am 21 Dezember 2017, 07:53:35
( Nur noch eine Frage: Wird das im Ausführungsteil durch eine (kommagetrennte?) Liste ersetzt, oder werden "n" Mails mit je einem Device versandt, wenn mehr als 1 Batterie-Status nicht ok ist?
Es ist eine kommagetrennte Liste, man kann das Trennzeichen definieren, so z. B. mit Leerzeichen:
[@s( ):"":battery:$_ ne "ok"]
Zitat von: borsti67 am 20 Dezember 2017, 22:53:06ohne dass ich die alle explizit kennen und setzen muss. ;)
Musst du ja nicht. Macht doch das DOIF automatisch. Selbst wenn du mittendrin neue Devices (mit Batterie-Reading) anlegst, werden die bei der ersten Statusmeldung der Batterie angelegt.
Zitat von: Per am 21 Dezember 2017, 11:28:57
Musst du ja nicht. Macht doch das DOIF automatisch.
Ich hatte amenomade so verstanden, dass das Attribut bei jedem Device angelegt werden muss, welches potenziell mal ein Battery-Reading auswirft... Könnte man vermutlich im DOIF unterbringen, wenn's sein muss, das stimmt, aber macht dann auch wieder extra-Last...
@amenomade: Hast natürlich recht! Aber mir widerstrebt trotzdem ein wenig die Idee, ein Reading "fälschlich" auf OK zu setzen, wenn es das nicht ist. Zwar mache ich derzeit sonst nichts mit diesem Wert, aber - hm. Trotzdem danke für die Idee!
@Damian: Alles klar, danke!
ZitatAber mir widerstrebt trotzdem ein wenig die Idee, ein Reading "fälschlich" auf OK zu setzen, wenn es das nicht ist.
Dann setze es auf "diese_Batterie_ist_leer_aber_ich_habe_schon_eine_Nachricht_gesendet_und_warte_deswegen_5_mn_bevor_ich_eine_neue_Nachricht_schicke"
Es ist auch "ne low"
Zitat von: borsti67 am 21 Dezember 2017, 20:27:52
Ich hatte amenomade so verstanden, dass das Attribut bei jedem Device angelegt werden muss, welches potenziell mal ein Battery-Reading auswirft... Könnte man vermutlich im DOIF unterbringen, wenn's sein muss, das stimmt, aber macht dann auch wieder extra-Last...
Nein. Das DOIF erstellt für jedes Device innerhalb des DOIF (daher
$SELF) ein Reading. Und irgendeinen Merker brauchst du ohnehin, die "zusätzliche Last" lässt sich nicht umgehen, selbst wenn du die Merker manuell anlegst, gefüllt werden müssen sie automatisch. Sonst bringt es nix.