DOIF Batterieüberwachung

weini · 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.

Code Auswählen


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

Damian · 03 Juni 2016, 07:01:27

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.

Code Auswählen Erweitern
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

weini · 03 Juni 2016, 16:33:58

Danke dir für den Hinweis!
Zusätzlich hat auch die Initialisierung der Readings nicht mehr sauber funktioniert. Hier die aktualiseirte Fassung:

Code Auswählen


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);; }

moonsorrox · 25 August 2016, 13:48:50

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

weini · 28 August 2016, 17:02:13

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?

moonsorrox · 28 August 2016, 17:05:55

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

weini · 28 August 2016, 17:09:13

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.

moonsorrox · 28 August 2016, 17:14:30

dies sind die Readings jetzt:

Code Auswählen

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

weini · 28 August 2016, 17:22:17

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

moonsorrox · 28 August 2016, 17:50:19

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

moonsorrox · 06 September 2016, 08:24:27

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

Code Auswählen

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

Code Auswählen

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

Ellert · 06 September 2016, 09:10:27

Zitat[?$SELF:$DEVICE] > "0" and [?$SELF:$DEVICE]

an dieser Stelle wird "low" numerisch mit "0" verglichen, das führt zur Warnung, besser lt.

weini · 06 September 2016, 19:31:42

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?

moonsorrox · 06 September 2016, 23:16:32

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

weini · 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:

Code Auswählen

[?$SELF:$DEVICE] gt "0" and [?$SELF:$DEVICE]

Wie gesagt, ich kann es selbst nicht testen, weil der Fehler bei mir nicht reproduzierbar ist.

Ellert · 07 September 2016, 00:03:38

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:
Code Auswählen Erweitern
[?$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.

moonsorrox · 07 September 2016, 08:28:39

OK, dann werde ich das mal testen...

moonsorrox · 07 September 2016, 17:54:09

das war es nicht, es geht munter weiter hier die letzten Auszüge

Code Auswählen

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:

Code Auswählen

( ([":^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)

Ellert · 07 September 2016, 20:03:50

Der aufmerksame Leser sieht, das es eine andere Warnung ist und die ist nach dem gleichen Prinzip zu beheben

moonsorrox · 08 September 2016, 00:15:08

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

Code Auswählen

[?$SELF:$DEVICE] gt "<=" [?$SELF:delayCounter]

weini · 08 September 2016, 06:46:39

nicht ganz...

Versuch bitte:

Code Auswählen

[?$SELF:$DEVICE] le [?$SELF:delayCounter]

Morgennebel · 30 Dezember 2016, 17:27:35

Nur als Zusammenfassung und für den nächsten, der dies implementieren möchte - das DOIF mit einer Pushbullet-Notification und allen Korrekturen:

Code Auswählen


( ([":^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

satprofi · 01 Januar 2017, 13:13:27

hallo.
Gutes neues Jahr vorerst.
Aber jetzt zur Frage, kann mir jemand die Funktion ausdeutschen?
[?Battery:$DEVICE]

m.f.g.

Morgennebel · 01 Januar 2017, 13:42:46

Das steht aber nirgends im DOIF...

Ciao, -MN

satprofi · 01 Januar 2017, 14:05:23

in deinem nicht, aber im DOIF manual bzgl. batterieabfrage

Morgennebel · 01 Januar 2017, 14:25:57

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

satprofi · 01 Januar 2017, 14:35:13

aha,
dann würde das ja auch genügen ?

Code Auswählen


define di_battery DOIF ([":battery: low"])

    ({DebianMail('yourname@gmail.com', 'FHEM - battery warning from device: $DEVICE'})

weini · 01 Januar 2017, 15:07:21

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.

satprofi · 23 Januar 2017, 06:50:12

Hallo.Ich verzweifle mal wieder mit der fiesen Batterieüberwachung.
habe DOIF

Code Auswählen


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

Code Auswählen


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?

weini · 23 Januar 2017, 08:13:43

...weil du auf >2.2 V und nicht auf <2.2 V abfrägst?

satprofi · 23 Januar 2017, 08:28:14

Batterie hat mittlerweile nur mehr 2v u. Low. Also einmal sollte Meldung schon kommen

send from OP3

weini · 23 Januar 2017, 08:35:07

Wie denn, wenn du auf größer 2.2 V abfragst?

satprofi · 23 Januar 2017, 11:14:15

Dann sollte aber andauernd Meldung kommen das Batterien voll sind,tut es aber auch nicht

send from OP3

Damian · 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:

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.

satprofi · 23 Januar 2017, 11:52:42

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

satprofi · 23 Januar 2017, 17:40:52

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?

Damian · 23 Januar 2017, 17:42:31

Zitat von: satprofi am 23 Januar 2017, 17:40:52
soll es jetzt (["^:xxxx]) oder ([":^xxxx]) lauten?

["regex for trigger",<default value>]

satprofi · 23 Januar 2017, 17:51:22

Zitat von: Damian am 23 Januar 2017, 17:42:31
["regex for trigger",<default value>]

also ([":^temperature",0]< 0 für mehrere sensoren

satprofi · 23 Januar 2017, 18:42:16

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.

weini · 23 Januar 2017, 18:45:05

besser: ["HZ:batteryLevel",0]

Der Default Value darf nicht in die Anführungszeichen.

satprofi · 23 Januar 2017, 18:48:25

Danke, gerade entdeckt, wollts grad melden.

satprofi · 10 April 2017, 21:42:17

Hallo. Wie schaffe ich die ununterbrochenen Warnungen zu beenden? Kein doalways. Einmal warnen sollte auch genügen

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

weini · 10 April 2017, 22:46:31

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

weini · 10 April 2017, 22:47:22

PS: "do always" ist zwingend notwendig, damit die Logik funktioniert

satprofi · 11 April 2017, 13:06:57

Danke für Antwort. Delaycounter habe ich nicht gesetzt,werde es abends versuchen.
Lg

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

satprofi · 11 April 2017, 15:39:12

Hallo.
Wo finde ich das attr delaycounter? Bei DOIF nicht, oder?

LG

weini · 11 April 2017, 15:43:35

Magst du dir mal den Code im ersten Beitrag ansehen? Daraus wird das ganz schnell klar.

Hast du das bisher nicht genau so übernommen?

satprofi · 11 April 2017, 15:49:03

schon gefunden, thx.
Habe ein bisschen anderes doif

Code Auswählen


(([":^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

weini · 11 April 2017, 16:00:06

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.

satprofi · 11 April 2017, 16:17:08

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

satprofi · 11 April 2017, 18:45:44

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.

weini · 11 April 2017, 19:02:00

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

satprofi · 11 April 2017, 19:22:08

hallo.
habe das hier gepostete übernommen

Code Auswählen


( ([":^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.

weini · 11 April 2017, 19:23:36

Kannst du mal ein list von deinem DOIF posten?

satprofi · 11 April 2017, 19:30:27

hallo.
habe wieder den originalzustand hergestellt, wo auch der andauernde alarm kommt

Code Auswählen


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

weini · 11 April 2017, 19:32:55

Du hast "delayCounter" auf 0 gesetzt, das ist in der Tat etwas schräg. Setz das mal auf 2 und versuche meinen Code nochmal.

satprofi · 11 April 2017, 19:36:02

hatte ich vorher auf 2, keine veränderung.

weini · 11 April 2017, 19:38:35

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.

satprofi · 11 April 2017, 21:22:54

Das funktioniert? Dachte das dort Fehler drinnen sind. Morgen werde ich testen

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

weini · 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

Per · 12 April 2017, 10:33:52

Könnte man nicht statt des DelayCounter nicht das eingebaute Attribut repeatsame verwenden? Dann vereinfacht sich das DOIF ungemein.

satprofi · 12 April 2017, 18:43:25

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.

weini · 12 April 2017, 19:11:47

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.

Beetle2003 · 07 November 2017, 22:24:28

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