Hallo zusammen!
Habe jetzt meine DOIF Batterieüberwachung am laufen. Die einfache "Notify"-Variante aus dem Wiki hat mir nicht gereicht, da ich ein paar unzuverlässige Termperaturfühler habe, die manchmal eine Batteriewarnung senden, diese dann aber sofort wieder zurückziehen.
Ich wollte das mit DOIF über die WAIT Funktion abfedern. Das geht so aber leider nicht, weil die Events von verschiedenen Devices auf ein zentrales DOIF treffen.
Letztlich habe ich jetzt eine Counter-basierende Lösung gebaut, bei der die Anzahl Events je Device konfiguriert werden kann, ab denen dann tatsächlich der Alarm ausgelöst wird.
define dif_Batteriewarnung DOIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?dif_Batteriewarnung:$DEVICE] eq "0") ( {SendEMail('postmaster@domain.com', 'FHEM Batteriewarnung', "$DEVICE: $EVENT")}, {Log 3,"$DEVICE: Batteriewarnung $EVENT"}, setreading dif_Batteriewarnung $DEVICE low) \
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?dif_Batteriewarnung:$DEVICE] eq "ok") (setreading dif_Batteriewarnung $DEVICE [dif_Batteriewarnung:delayCounter])\
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?dif_Batteriewarnung:$DEVICE] > "0" and [?dif_Batteriewarnung:$DEVICE] <= [?dif_Batteriewarnung:delayCounter]) (setreading dif_Batteriewarnung $DEVICE {([dif_Batteriewarnung:$DEVICE])-1})\
DOELSEIF ( ([":^battery:.*ok"] or [":^battery:.*1"]) and [?dif_Batteriewarnung:$DEVICE] ne "ok") (setreading dif_Batteriewarnung $DEVICE ok)
attr dif_Batteriewarnung userattr delayCounter
attr dif_Batteriewarnung delayCounter 2
attr dif_Batteriewarnung do always
attr dif_Batteriewarnung notexist "ok"
attr dif_Batteriewarnung userReadings delayCounter { AttrVal($name,"delayCounter",0);; }
Im Attribut "delayCounter" wird die Anzahl konfiguriert, nach der ein Alarm erfolgt. Da DOIF (noch) nicht direkt Attribute abfragen kann habe ich ein einfaches userReading eingefügt. Die Funktion zum Senden der Email ist proprietär, es gibt aber zig Beispiele im Forum.
Hoffentlich nutzt es dem einen oder anderen...
Christian
Zitat von: weini am 02 Juni 2016, 23:35:59
Hallo zusammen!
Habe jetzt meine DOIF Batterieüberwachung am laufen. Die einfache "Notify"-Variante aus dem Wiki hat mir nicht gereicht, da ich ein paar unzuverlässige Termperaturfühler habe, die manchmal eine Batteriewarnung senden, diese dann aber sofort wieder zurückziehen.
Ich wollte das mit DOIF über die WAIT Funktion abfedern. Das geht so aber leider nicht, weil die Events von verschiedenen Devices auf ein zentrales DOIF treffen.
Letztlich habe ich jetzt eine Counter-basierende Lösung gebaut, bei der die Anzahl Events je Device konfiguriert werden kann, ab denen dann tatsächlich der Alarm ausgelöst wird.
define dif_Batteriewarnung DOIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?dif_Batteriewarnung:$DEVICE] eq "0") ( {SendEMail('postmaster@domain.com', 'FHEM Batteriewarnung', "$DEVICE: $EVENT")}, {Log 3,"$DEVICE: Batteriewarnung $EVENT"}, setreading dif_Batteriewarnung $DEVICE low) \
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?dif_Batteriewarnung:$DEVICE] eq "ok") (setreading dif_Batteriewarnung $DEVICE [dif_Batteriewarnung:delayCounter])\
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?dif_Batteriewarnung:$DEVICE] > "0" and [?dif_Batteriewarnung:$DEVICE] <= [?dif_Batteriewarnung:delayCounter]) (setreading dif_Batteriewarnung $DEVICE {([dif_Batteriewarnung:$DEVICE])-1})\
DOELSEIF ( ([":^battery:.*ok"] or [":^battery:.*1"]) and [?dif_Batteriewarnung:$DEVICE] ne "ok") (setreading dif_Batteriewarnung $DEVICE ok)
attr dif_Batteriewarnung userattr delayCounter
attr dif_Batteriewarnung delayCounter 2
attr dif_Batteriewarnung do always
attr dif_Batteriewarnung notexist "ok"
attr dif_Batteriewarnung userReadings delayCounter { AttrVal($name,"delayCounter",0);; }
Im Attribut "delayCounter" wird die Anzahl konfiguriert, nach der ein Alarm erfolgt. Da DOIF (noch) nicht direkt Attribute abfragen kann habe ich ein einfaches userReading eingefügt. Die Funktion zum Senden der Email ist proprietär, es gibt aber zig Beispiele im Forum.
Hoffentlich nutzt es dem einen oder anderen...
Christian
Du kannst es kürzer und allgemeiner halten, wenn du statt
dif_Batteriewarnung $SELF angibst.
Gruß
Damian
Danke dir für den Hinweis!
Zusätzlich hat auch die Initialisierung der Readings nicht mehr sauber funktioniert. Hier die aktualiseirte Fassung:
define dif_Batteriewarnung DOIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] eq "0") ( {SendEMail('postmaster@domain.com', 'FHEM Batteriewarnung', "$DEVICE: $EVENT")}, {Log 3,"$DEVICE: Batteriewarnung $EVENT"}, setreading $SELF $DEVICE low) \
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and ([?$SELF:$DEVICE] eq "ok" or [?$SELF:$DEVICE] eq "novalue")) (setreading $SELF $DEVICE [$SELF:delayCounter])\
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] > "0" and [?$SELF:$DEVICE] <= [?$SELF:delayCounter]) (setreading $SELF $DEVICE {([$SELF:$DEVICE])-1})\
DOELSEIF ( ([":^battery:.*ok"] or [":^battery:.*1"]) and [?$SELF:$DEVICE] ne "ok") (setreading $SELF $DEVICE ok)
attr dif_Batteriewarnung userattr delayCounter
attr dif_Batteriewarnung delayCounter 2
attr dif_Batteriewarnung do always
attr dif_Batteriewarnung notexist "novalue"
attr dif_Batteriewarnung userReadings delayCounter { AttrVal($name,"delayCounter",0);; }
Hallo ich setze dieses DOIF seit einiger Zeit ein und habe heute Nacht seit dem Einsatz das erste mal eine Batteriemeldung bekommen verbunden mit ne Menge Perl Fehler die ganze Nacht hindurch bis ich jetzt die Batterien getauscht habe.
Ist das bei dir auch der Fall..?
Siehe meinen Beitrag von heute (https://forum.fhem.de/index.php/topic,57057.msg484817.html#msg484817)
Mit Perl-Fehlern hatte ich bisher keine Probleme. Ich hatte allerdings auch erst einmal eine "echte" Batteriewarnung und das war vor mehreren Monaten.
Auf was steht denn der "delayCounter" bei dir?
steht bei mir auf "2" vorher hatte ich ihn auf "1"
Aber trotzdem sollten, egal wo der steht keine Perlfehler erzeugt werden oder täusche ich mich da..?
Jetzt ist auch alles wieder ruhig, mal schauen wenn es die nächste Batteriewarnung gibt, denn dadurch hatte ich diese Fehler ja
Völlig richtig, es sollten keine Perl-Fehler auftreten.
Wenn du das Problem nochmal hast, dann wäre einer Liste sämtlicher Readings am DOIF hilfreich.
dies sind die Readings jetzt:
Readings:
2016-06-04 00:52:15 BWM_Terrasse ok
2016-08-28 17:13:24 Device EG_TK_Eingang
2016-06-04 01:20:07 EG_TK_Eingang ok
2016-06-04 06:47:41 FB_RC_8 ok
2016-06-06 13:24:40 FB_RC_8_WZ ok
2016-06-04 06:00:04 Temperatur_Arbeitszimmer ok
2016-07-10 11:57:38 Temperatur_Bad ok
2016-06-04 00:51:07 Temperatur_Kueche ok
2016-06-04 00:51:35 Temperatur_Norden ok
2016-06-04 00:53:41 Temperatur_Terrasse ok
2016-08-25 12:24:04 Temperatur_Wohnzimmer ok
2016-06-04 01:16:50 WZ_TK_Terrasse ok
2016-08-25 12:24:04 cmd 4
2016-08-28 17:13:24 delayCounter 2
2016-08-25 12:22:09 matched_event_c1_1 battery: low
2016-08-25 12:22:09 matched_event_c2_1 battery: low
2016-08-25 12:22:09 matched_event_c3_1 battery: low
2016-08-28 17:13:24 matched_event_c4_1 battery: ok
2016-08-27 14:07:21 state initialize
andere sind das nicht und der Sensor für das Wohnzimmer hatte die Batteriemeldung ;)
Die vom DOIF für die Verwaltung angelegten Readings ("Temperatur...") sehen alle korrekt aus.
Interessant ist der Wert "low" bei den "matched..." Readings, diese legt das DOIF Modul bzw. FHEM an. Wenn es hier beim Vergleich zu einem Perl Fehler kommt, dann wasche ich meine Hände erst mal in Unschuld (lasse mich aber gerene eines besseren belehren).
ich hatte mich damit noch gar nicht beschäftigt, wurde nur durch die 1. Warnmeldung drauf aufmerksam.
Da das Teil sehr kompakt ist habe ich mir die Mühe gespart und das ganze DOIF so wie es hier in Post #2 steht komplett übernommen ohne mir groß Gedanken zu machen. ;)
Na mal schauen was die nächste Fehlermeldung bringt, die kommt ja solange bis die Batterien gewechselt werden, war zumindest bei mir so...!
heute nun wieder eine Batteriewarnung bekommen und leider bin ich nicht zuhause. Er schreibt mir jetzt bis zum Wechsel der Batterie das log wieder voll...
Das muss dann wohl ein Fehler im DOIF sein
2016.09.06 08:15:02 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2235173) line 1.
2016.09.06 08:12:21 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2232111) line 1.
2016.09.06 08:09:26 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2230089) line 1.
2016.09.06 08:07:21 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2228654) line 1.
2016.09.06 08:05:01 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2227101) line 1.
2016.09.06 08:02:26 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2226901) line 1.
2016.09.06 07:59:38 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2226581) line 1.
2016.09.06 07:56:34 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2226230) line 1.
2016.09.06 07:54:21 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2225954) line 1.
2016.09.06 07:51:53 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2225675) line 1.
2016.09.06 07:49:10 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2225380) line 1.
2016.09.06 07:46:13 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2225078) line 1.
2016.09.06 07:44:06 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2224737) line 1.
2016.09.06 07:41:44 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2224430) line 1.
2016.09.06 07:39:08 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2224115) line 1.
2016.09.06 07:36:17 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2223683) line 1.
2016.09.06 07:33:12 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2223358) line 1.
2016.09.06 07:30:57 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2223093) line 1.
2016.09.06 07:28:27 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2222875) line 1.
2016.09.06 07:25:42 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2222494) line 1.
2016.09.06 07:22:44 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2222169) line 1.
2016.09.06 07:20:35 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2221870) line 1.
2016.09.06 07:18:11 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2221559) line 1.
2016.09.06 07:15:33 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2221254) line 1.
2016.09.06 07:12:41 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2220895) line 1.
2016.09.06 07:10:38 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2220668) line 1.
2016.09.06 07:08:21 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2220360) line 1.
2016.09.06 07:05:49 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2220050) line 1.
2016.09.06 07:03:03 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2219738) line 1.
2016.09.06 07:00:02 1: PERL WARNING: Argument "low" isn't numeric in numeric gt (>) at (eval 2219377) line 1.
2016.09.06 06:57:53 3: Temperatur_Bad: Batteriewarnung battery: low
ich habe das DOIF erst einmal deaktiviert
im DOIF ist folgendes zu sehen
matched_event_c1_1 battery: low 2016-09-06 08:15:02
matched_event_c2_1 battery: low 2016-09-06 08:15:02
matched_event_c3_1 battery: low 2016-09-06 08:15:02
Zitat[?$SELF:$DEVICE] > "0" and [?$SELF:$DEVICE]
an dieser Stelle wird "low" numerisch mit "0" verglichen, das führt zur Warnung, besser lt.
Erst mal vielen Dank an Ellert für den Tipp!
Sehr eigenartig finde ich, dass ich das Problem nicht nachgestellt bekomme. Ich ab extra ein Dummy-Device angelegt, damit ich die Readings entsprechend setzen kann. Bei mir löst der Alarm aber nach Ablauf der konfigurierten Iterationen korrekt aus. Eine Warning im Log bekomme ich nicht.
@moonsorrox: Kannst du den Tipp von Ellert bei dir testen, ob das dein Problem löst?
Zitat von: Ellert am 06 September 2016, 09:10:27
an dieser Stelle wird "low" numerisch mit "0" verglichen, das führt zur Warnung, besser lt.
ich glaube ich hab grad nen Brett vorm Kopf, was meinst du mit "besser lt."
Ellert meint vermutlich "lt" als Ersatz für ">". Nach meinem Verständnis müsste das aber "gt" sein, also:
[?$SELF:$DEVICE] gt "0" and [?$SELF:$DEVICE]
Wie gesagt, ich kann es selbst nicht testen, weil der Fehler bei mir nicht reproduzierbar ist.
Zitat von: weini am 06 September 2016, 23:21:22
Ellert meint vermutlich "lt" als Ersatz für ">". Nach meinem Verständnis müsste das aber "gt" sein, also:
[?$SELF:$DEVICE] gt "0" and [?$SELF:$DEVICE]
Wie gesagt, ich kann es selbst nicht testen, weil der Fehler bei mir nicht reproduzierbar ist.
Ja, gt ist natürlich richtig.
OK, dann werde ich das mal testen...
das war es nicht, es geht munter weiter hier die letzten Auszüge
2016.09.07 17:50:44 1: PERL WARNING: Argument "low" isn't numeric in numeric le (<=) at (eval 3494886) line 1.
2016.09.07 17:47:27 1: PERL WARNING: Argument "low" isn't numeric in numeric le (<=) at (eval 3491872) line 1.
2016.09.07 17:45:04 1: PERL WARNING: Argument "low" isn't numeric in numeric le (<=) at (eval 3490462) line 1.
2016.09.07 17:42:26 1: PERL WARNING: Argument "low" isn't numeric in numeric le (<=) at (eval 3488324) line 1.
2016.09.07 17:39:31 1: PERL WARNING: Argument "low" isn't numeric in numeric le (<=) at (eval 3486844) line 1.
2016.09.07 17:36:21 1: PERL WARNING: Argument "low" isn't numeric in numeric le (<=) at (eval 3484626) line 1.
2016.09.07 17:34:05 1: PERL WARNING: Argument "low" isn't numeric in numeric le (<=) at (eval 3482645) line 1.
hier nochmal das DEF:
( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] eq "0") ( {DebianMail('xxxxxxxxxxxx@gmx.de', 'FHEM Batteriewarnung', "$DEVICE: $EVENT")}, {Log 3,"$DEVICE: Batteriewarnung $EVENT"}, setreading $SELF $DEVICE low) DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and ([?$SELF:$DEVICE] eq "ok" or [?$SELF:$DEVICE] eq "novalue")) (setreading $SELF $DEVICE [$SELF:delayCounter]) DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] gt "0" and [?$SELF:$DEVICE] <= [?$SELF:delayCounter]) (setreading $SELF $DEVICE {([$SELF:$DEVICE])-1}) DOELSEIF ( ([":^battery:.*ok"] or [":^battery:.*1"]) and [?$SELF:$DEVICE] ne "ok") (setreading $SELF $DEVICE ok)
Der aufmerksame Leser sieht, das es eine andere Warnung ist und die ist nach dem gleichen Prinzip zu beheben ;)
echt... ;) ich habe jetzt wirklich nicht gesehen das es eine andere Meldung ist (<=)
Da ich aber Perl überhaupt nicht verstehe, fehlt mir da jede Beziehung und kann somit auch nichts dazu beitragen :-\
wäre diese Variante jetzt richtig..?
[?$SELF:$DEVICE] gt "<=" [?$SELF:delayCounter]
nicht ganz... ;)
Versuch bitte:
[?$SELF:$DEVICE] le [?$SELF:delayCounter]
Nur als Zusammenfassung und für den nächsten, der dies implementieren möchte - das DOIF mit einer Pushbullet-Notification und allen Korrekturen:
( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] eq "0")
( set PBNotification message 'Intelligentes Wohnen' | 'Batteriewarnung $DEVICE: $EVENT', setreading $SELF $DEVICE low)
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and ([?$SELF:$DEVICE] eq "ok" or [?$SELF:$DEVICE] eq "novalue"))
(setreading $SELF $DEVICE [$SELF:delayCounter])
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] gt 0 and [?$SELF:$DEVICE] le [?$SELF:delayCounter])
(setreading $SELF $DEVICE {([$SELF:$DEVICE])-1})
DOELSEIF ( ([":^battery:.*ok"] or [":^battery:.*1"]) and [?$SELF:$DEVICE] ne "ok") (setreading $SELF $DEVICE ok)
Die Attribute sind noch zusätzlich zu setzen.
Ciao, -MN
hallo.
Gutes neues Jahr vorerst.
Aber jetzt zur Frage, kann mir jemand die Funktion ausdeutschen?
[?Battery:$DEVICE]
m.f.g.
Das steht aber nirgends im DOIF...
Ciao, -MN
in deinem nicht, aber im DOIF manual bzgl. batterieabfrage
Steht doch alles in der COMMANDREF.
Battery ist ein Dummy. setreading erzeugt künstliche Readings mit dem Namen des $DEVICE.
Dann ist [?Battery:DEVICE] eine nicht-triggerende DOIF-Abfrage, ob dieses Reading bereits existiert.
Das DOIF hier im Thread kommt ohne den Dummy aus, da die künstlichen Readings im DOIF selbst (via $SELF) erzeugt werden.
Ciao, -MN
aha,
dann würde das ja auch genügen ?
define di_battery DOIF ([":battery: low"])
({DebianMail('yourname@gmail.com', 'FHEM - battery warning from device: $DEVICE'})
Ja, das sollte auch passen.
Ich habe die kompliziertere Logik mit den Readings aufgebaut, weil ich bei mir ein paar Batteriegeräte habe, die manchmal einen Fehlalarm bzgl. des Batteriezustands provozieren. Deshalb löst ein DOIF erst aus, wenn der Alarm eine konfigurierbare Anzahl mal wiederholt aufgetreten ist.
Hallo.Ich verzweifle mal wieder mit der fiesen Batterieüberwachung.
habe DOIF
DOIF (["^:battery:low"] or ["^:Battery:low"] ) (set Telegram message @xxxxxxxx send 'Battery warnung $DEVICE' low)
DOELSEIF (["^:batteryLevel"] > 2.2) (set Telegram message @xxxxxxx send 'Batteryspannung $DEVICE' unter 2.2V)
DOELSE
in den Readings steht auch
Device HZ_Schlafzimmer 2017-01-23 06:41:40
cmd 3 2017-01-23 06:48:24
cmd_event HZ_Buero 2017-01-23 06:48:24
cmd_nr 3 2017-01-23 06:48:24
matched_event_c2_1 batteryLevel: 2 2017-01-23 06:41:40
state cmd_3 2017-01-23 06:48:24
Warum wird cmd2 nicht ausgeführt?
Gibts nicht besseres um die Batterien zu checken?
...weil du auf >2.2 V und nicht auf <2.2 V abfrägst?
Batterie hat mittlerweile nur mehr 2v u. Low. Also einmal sollte Meldung schon kommen
send from OP3
Wie denn, wenn du auf größer 2.2 V abfragst?
Dann sollte aber andauernd Meldung kommen das Batterien voll sind,tut es aber auch nicht
send from OP3
(["^:batteryLevel"] > 2.2)
wegen der Anführungszeichen handelt es sich hier um einen Ereignistrigger, der nur wahr oder nicht wahr sein kann. Seit der letzten Version kann man auch Ereignistrigger anders auswerten, indem man ein Defaultwert vorgibt, siehe:
Zitat aus der Commandref:
ZitatAllgemeine Ereignistrigger können ebenfalls so definiert werden, dass sie nicht nur wahr zum Triggerzeitpunkt und sonst nicht wahr sind, sondern Inhalte des Ereignisses zurückliefern. Initiiert wird dieses Verhalten durch die Angabe eines Default-Wertes.
Syntax:
["regex for trigger",<default value>]
Anwendungsbeispiel:
define di_warning DOIF ([":^temperature",0]< 0 and [06:00-09:00] ) (set pushmsg danger of frost)
Damit wird auf alle Devices getriggert, die mit "temperature" im Event beginnen. Zurückgeliefert wird der Wert, der im Event hinter "temperature: " steht. Wenn kein Event stattfindet, wird der Defaultwert, hier 0, zurückgeliefert.
Ebenfalls kann ein Ereignisfilter mit Ausgabeformatierung angegeben werden.
Zitat von: weini am 23 Januar 2017, 08:13:43
...weil du auf >2.2 V und nicht auf <2.2 V abfrägst?
Wenn ich < 2.2 verwende, kommen von allen Aktoren die Messages,obwohl über 2.2v
send from OP3
Zitat von: Damian am 23 Januar 2017, 11:18:34
(["^:batteryLevel"] > 2.2)
wegen der Anführungszeichen handelt es sich hier um einen Ereignistrigger, der nur wahr oder nicht wahr sein kann. Seit der letzten Version kann man auch Ereignistrigger anders auswerten, indem man ein Defaultwert vorgibt, siehe:
Zitat aus der Commandref:
soll es jetzt (["^:xxxx]) oder ([":^xxxx]) lauten?
Zitat von: satprofi am 23 Januar 2017, 17:40:52
soll es jetzt (["^:xxxx]) oder ([":^xxxx]) lauten?
["regex for trigger",<default value>]
Zitat von: Damian am 23 Januar 2017, 17:42:31
["regex for trigger",<default value>]
also ([":^temperature",0]< 0 für mehrere sensoren
Hallo.
Also ich bin am verzweifeln.
DOELSEIF (["HZ:batteryLevel,0"] < 2.7) will einfach nicht arbeiten. Habe 2 Sensoren die 2.5V haben, die sollten doch triggern.
Wenn ich aber das vorzeichen auf > ändere kommen die meldungen der restl. sensoren sofort durch.
besser: ["HZ:batteryLevel",0]
Der Default Value darf nicht in die Anführungszeichen.
Danke, gerade entdeckt, wollts grad melden.
Hallo. Wie schaffe ich die ununterbrochenen Warnungen zu beenden? Kein doalways. Einmal warnen sollte auch genügen
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Halllo satprofi!
Normalerweise dürfen keine Mehrfachalarme ausgelöst werden.
Die Logik funktioniert sinngemäß wie folgt:
- Wenn die Alarmbedingung für ein Device ausgelöst wird, dann reduziere den Zähler für dieses Device (Startwert wird über Attribut "delayCounter" festgelegt).
- Nachfolgende Alarme reduzieren den Counter für das Device. Wenn das Device einmalig wieder "ok" oder "1" sendet, dann wird der Counter gelöscht.
- Wenn der Counter auf 0 reduziert wird, dann wird einmalig der Alarm ausgelöst. Der Counter wird danach auf "low" gesetzt, so dass er nicht weiter heruntergezählt wird.
Ich hatte bei mit niemals Mehrfachalarme. Hast du ggf. "delayCounter" auf einen eigenartigen Wert initialisiert?
VG,
weini
PS: "do always" ist zwingend notwendig, damit die Logik funktioniert
Danke für Antwort. Delaycounter habe ich nicht gesetzt,werde es abends versuchen.
Lg
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Hallo.
Wo finde ich das attr delaycounter? Bei DOIF nicht, oder?
LG
Magst du dir mal den Code im ersten Beitrag ansehen? Daraus wird das ganz schnell klar.
Hast du das bisher nicht genau so übernommen?
schon gefunden, thx.
Habe ein bisschen anderes doif
(([":^battery: low"]) or ([":^Battery: low"])) (set Telegram message @xxxxxxx send 'Battery warnung $DEVICE' low)
DOELSEIF (["HZ:^batteryLevel",0] < 2.2) (set Telegram message @xxxxxxx send 'Batteryspannung $DEVICE' unter 2.2V)
DOELSE
Werds testen, sonst übernehm ich deins 1:1
lg
Ist das dein ganzes DOIF?
Falls ja, dann solltest du es tatsächlich mal ohne "do always" versuchen.
Du nutzt da eine ganz andere Logik: Ich arbeite in meinem DOIF mit einem Zähler, den hast du nicht.
Ja, sollte lt. Commandref genügen.
Habe jetzt deine attribute eingetragen, leider hat sich die eine schwache batterie wieder erfangen und zeigt ok an.
mal abwarten was später passiert
Klappt leider auch nicht, alle 5-10min. alarmmeldung. Habe jetzt counter auf 0 gesetzt, jetzt kommt keine Meldung mehr von diesem Device.
Versteh nicht, warum das Beispiel aus der Commandref nicht funktioniert.
Nochmal: Wenn du oben deinen kompletten DOIF Code gepostet hast, dann bringt dir das Attribut delayCounter nichts, weil du es im DOIF nirgends abfragst.
So wie dein Code aussieht, muss das "do always" erst mal raus. Wenn du dann aber ein "Flattern" beim Batteriestatus bekommst (low & ok im Wechsel), dann löst der Alarm trotzdem mehrfach aus.
Genau um so etwas abzufangen habe ich ja die Logik mit dem Counter entwickelt: Erst wenn der Alarm eine gewisse Anzahl mal hintereinander auftritt, ohne dass es eine Entwarnung gibt, wird die Benachrichtigung ausgelöst (und zwar nur einmal).
hallo.
habe das hier gepostete übernommen
( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] eq "0")
( set PBNotification message 'Intelligentes Wohnen' | 'Batteriewarnung $DEVICE: $EVENT', setreading $SELF $DEVICE low)
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and ([?$SELF:$DEVICE] eq "ok" or [?$SELF:$DEVICE] eq "novalue"))
(setreading $SELF $DEVICE [$SELF:delayCounter])
DOELSEIF ( ([":^battery:.*low"] or [":^battery:.*0"]) and [?$SELF:$DEVICE] gt 0 and [?$SELF:$DEVICE] le [?$SELF:delayCounter])
(setreading $SELF $DEVICE {([$SELF:$DEVICE])-1})
DOELSEIF ( ([":^battery:.*ok"] or [":^battery:.*1"]) and [?$SELF:$DEVICE] ne "ok") (setreading $SELF $DEVICE ok)
samt den Attributen, aber ebenfalls andauernde warnung.
Kannst du mal ein list von deinem DOIF posten?
hallo.
habe wieder den originalzustand hergestellt, wo auch der andauernde alarm kommt
Internals:
DEF (([":^battery: low"]) or ([":^Battery: low"])) (set Telegram message @###### send 'Battery warnung $DEVICE' low)
DOELSEIF (["HZ:^batteryLevel",0] < 2.2) (set Telegram message @###### send 'Batteryspannung $DEVICE' unter 2,2V)
DOELSE
NAME Batt_Check
NR 717
NTFY_ORDER 50-Batt_Check
STATE cmd_3
TYPE DOIF
Readings:
2017-04-11 19:27:11 Device HZ_Vorzimmer
2017-04-11 17:50:48 HZ_Bad ok
2017-04-11 17:50:18 HZ_Buero ok
2017-04-11 17:50:15 HZ_Hobbyraum ok
2017-04-11 17:50:47 HZ_Schlafzimmer ok
2017-04-11 17:51:07 HZ_Vorzimmer ok
2017-04-11 17:50:32 HZ_Wohnzimmer ok
2017-04-11 17:50:36 Hideki_30_1 ok
2017-04-11 17:51:45 Pooltemperatur ok
2017-04-11 19:15:55 SD_WS07_TH_1 low
2017-04-11 17:49:57 TH_Sensor ok
2017-04-11 18:35:05 Wetter_Dach low
2017-04-11 19:27:11 cmd 3
2017-04-11 19:27:11 cmd_event HZ_Vorzimmer
2017-04-11 19:27:11 cmd_nr 3
2017-04-11 19:21:37 delayCounter 0
2017-04-11 19:21:37 matched_event_c1_1 battery: low
2017-04-11 19:27:11 matched_event_c2_1 batteryLevel: 2.6
2017-04-11 19:27:11 state cmd_3
Condition:
0 (EventDoIf('',$hash,'^battery: low',0)) or (EventDoIf('',$hash,'^Battery: low',0))
1 EventDoIf('HZ',$hash,'^batteryLevel',0,'[^\:]*: (.*)','','0') < 2.2
Devices:
Do:
0:
0 set Telegram message @###### send 'Battery warnung $DEVICE' low
1:
0 set Telegram message @###### send 'Batteryspannung $DEVICE' unter 2,2V
2:
0
Helper:
event batteryLevel: 2.6
globalinit 1
last_timer 0
sleeptimer -1
timerdev HZ_Vorzimmer
timerevent batteryLevel: 2.6
triggerDev HZ_Vorzimmer
timerevents:
actuator: 0
battery: ok
batteryLevel: 2.6
desired-temp: 21.0
measured-temp: 22.6
motorErr: ok
timereventsState:
actuator: 0
battery: ok
batteryLevel: 2.6
desired-temp: 21.0
measured-temp: 22.6
motorErr: ok
triggerEvents:
actuator: 0
battery: ok
batteryLevel: 2.6
desired-temp: 21.0
measured-temp: 22.6
motorErr: ok
triggerEventsState:
actuator: 0
battery: ok
batteryLevel: 2.6
desired-temp: 21.0
measured-temp: 22.6
motorErr: ok
Internals:
Itimer:
Readings:
Regexp:
0:
0 :^battery: low
1 :^Battery: low
1:
0 HZ:^batteryLevel
All:
0 :^battery: low
1 :^Battery: low
2 HZ:^batteryLevel
State:
Trigger:
Attributes:
delayCounter 0
do always
notexist "ok"
room DOIF
Du hast "delayCounter" auf 0 gesetzt, das ist in der Tat etwas schräg. Setz das mal auf 2 und versuche meinen Code nochmal.
hatte ich vorher auf 2, keine veränderung.
Mein meinem Code aus dem ersten Post?
Bitte lass es damit nochmal laufen, warte bis wieder andauernd die Alarme kommen und poste dann nochmal ein List.
Das funktioniert? Dachte das dort Fehler drinnen sind. Morgen werde ich testen
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Ja, der Code funktioniert. Nimm besser die Fassung aus dem 3. Post, die ist etwas eleganter, tut aber das selbe.
Ich habe das glaube ich nie mit delayCounter=0 getestet. Der Counter sagt ja, wie oft das Ereignis auftreten soll. Von der Logik her sollte das Minimum 1 sein, ich würde aber 2 empfehlen. Da bekommst du dann keine Fehlalarme, wenn sich ein Aktor einmalig beschwert (meine Temperatursender machen das manchmal).
Ein Nutzer hatte mal Probleme mit der Fassung aus dem 3. Post, die haben sich aber ganz anders geäußert und ich konnte das nie richtig nachstellen. Sonst hatte ich noch keine Beschwerden ;)
Könnte man nicht statt des DelayCounter nicht das eingebaute Attribut repeatsame (https://fhem.de/commandref_DE.html#DOIF_repeatsame) verwenden? Dann vereinfacht sich das DOIF ungemein.
Zitat von: weini am 11 April 2017, 21:31:07
Ja, der Code funktioniert. Nimm besser die Fassung aus dem 3. Post, die ist etwas eleganter, tut aber das selbe.
Ich habe das glaube ich nie mit delayCounter=0 getestet. Der Counter sagt ja, wie oft das Ereignis auftreten soll. Von der Logik her sollte das Minimum 1 sein, ich würde aber 2 empfehlen. Da bekommst du dann keine Fehlalarme, wenn sich ein Aktor einmalig beschwert (meine Temperatursender machen das manchmal).
Ein Nutzer hatte mal Probleme mit der Fassung aus dem 3. Post, die haben sich aber ganz anders geäußert und ich konnte das nie richtig nachstellen. Sonst hatte ich noch keine Beschwerden ;)
OK, danke. Was mich daran stört, ist das meine HComematic Komponenten nicht nach Spannung abgefragt werden.
Muss ich anpassen.
ZitatWas mich daran stört, ist das meine HComematic Komponenten nicht nach Spannung abgefragt werden.
Ja, das habe ich so nicht drin. Mir reicht für meinen Bedarf der Status. Mit der ganzen Counter Logik wird das vermutlich auch etwas trickreich. Ich würde dir eher zu einem zweiten DOIF raten, in dem du dann die Spannung prüfst.
ZitatKönnte man nicht statt des DelayCounter nicht das eingebaute Attribut repeatsame verwenden?
Das geht leider nicht. Die Batterieüberwachung erhält Events von zig verschiedenen Batterieaktoren. Da kann man einige der DOIF Features nicht so einfach nutzen. Letztlich liegt das an der Logik, dass erst nach mehrmaligen Auftreten der Low-Bat Warnung ein Alarm erfolgt. Wenn man darauf verzichten kann, dann wird alles einfacher. Da ich aber ein paar unzuverlässige Aktoren habe, hab ich mich eben für diesen Weg entschieden.
Konkret: Ein Aktor schickt eine Low-Bat Warnung. 2 Sekunden später schickt ein anderer Aktor, dass sein Batteriestand ok ist. Wenn man nur DOIF Features nutzt, dann ist der Alarm jetzt zurückgesetzt. Mit meiner Logik wird aber je Aktor ein Reading angelegt und separat gezählt. So setzte ich die "Fehlertoleranz" um. Der Preis ist eine komplexere Logik im DOIF.
Hallo,
wer kennt die Lösung.
Ich setzte das DoIf Batterieüberwachung ein.
Es werden einige Geräte ausgelesen und in die Readings geschrieben.
Es fehlen noch einige Geräte. Kann mir jemand einen Tipp geben weshalb das so ist und was ich ändern / anpassen muss?
Danke