Huhu,
ich hab mir aus dem Wiki ein Notify für die Batteriewarnung gemopst.
Funktioniert nach meiner Anpassung auch recht gut, zu gut... alle 5 Minuten :-D
Wie passt man sowas an?
.*:[Bb]attery:.* { if($EVENT !~ m/ok/) { my $aktor = AttrVal($NAME,"alias","Fehler");; fhem( "set Telegram message FHEM Batteriewarnung: *" . $aktor ."*") }; }
Zitat von: accessburn am 16 Februar 2017, 11:10:09
Huhu,
ich hab mir aus dem Wiki ein Notify für die Batteriewarnung gemopst.
Funktioniert nach meiner Anpassung auch recht gut, zu gut... alle 5 Minuten :-D
Wie passt man sowas an?
.*:[Bb]attery:.* { if($EVENT !~ m/ok/) { my $aktor = AttrVal($NAME,"alias","Fehler");; fhem( "set Telegram message FHEM Batteriewarnung: *" . $aktor ."*") }; }
event-on-change-reading wäre das Zauber-Attribut am Aktor!
Gruß
Dan
Muss ich nun auf jedes Device ein "event-on-change-reading battery" setzen?
Zitat von: accessburn am 16 Februar 2017, 11:17:43
Muss ich nun auf jedes Device ein "event-on-change-reading battery" setzen?
Das wäre taktisch unklug, denn dann beraubst Du Dich selbst der anderen Events die Deine Aktoren erzeugen und auf die Du reagieren willst.
Ich setzte meist auf allen Geräten "event-on-change-reading .*" und bei Bedarf "event-on-update-reading" auf nötige Readings, z.B. wakeup bei den batteriebetriebenen Sensoren.
Gruß
Dan
Okay, hab mal einen HT auf change-reading .* gestellt.
Nun kommt aktuell nix mehr. Ich bin etwas unsicher das dass so stimmt :D
Hi,
meiner Meinung nach ist "event-on-change-reading" so erst einmal der falsche Weg. Ich würde das so angehen: Du nimmst Dein notify und änderst es so ab, dass nicht die Message direkt geschickt wird, sondern in einem Dummy irgendwas gesetzt wird. Diesen Dummy gibst Du dann das event-on-change-reading und lässt das notify mit der Message vom Dummy triggern.
Wenn Du die Batterien gewechselt hast, dann setzt Du den Dummy zurück. Alternativ kannst Du das auch von einem at täglich oder so erledigen lassen. Dann bekommst Du einmal am Tag die Nachricht.
Gruß,
Thorsten
Zitat von: accessburn am 16 Februar 2017, 11:32:41
Nun kommt aktuell nix mehr. Ich bin etwas unsicher das dass so stimmt :D
Es werden dann halt von allen Readings nur noch Events erzeugt wenn sich der Wert ändert!
Gruß
Dan
Da wäre dann die at-Methode lieber denn ich habe aktuell 18 Devices, das wird ja eine never ending Stor :-)
DOIF oder at, gibt es da auch etwas wie ein allrounder (.*:[Bb]attery:.*) oder muss ich evenfalls eins für jedes einzelne anlegen?
Ich nutze für alerts, die ich nur alle paar Stunden oder nur täglich haben möchte ganz oldschool E-Mail per notify nach Zeitablauf erneut senden (https://wiki.fhem.de/wiki/E-Mail_per_notify_nach_Zeitablauf_erneut_senden). Funktioniert natürlich auch mit Push-Nachrichten.
Wäre das eine Alternative?
Zitat von: Thorsten Pferdekaemper am 16 Februar 2017, 11:42:06
Hi,
meiner Meinung nach ist "event-on-change-reading" so erst einmal der falsche Weg. Ich würde das so angehen: Du nimmst Dein notify und änderst es so ab, dass nicht die Message direkt geschickt wird, sondern in einem Dummy irgendwas gesetzt wird. Diesen Dummy gibst Du dann das event-on-change-reading und lässt das notify mit der Message vom Dummy triggern.
Wenn Du die Batterien gewechselt hast, dann setzt Du den Dummy zurück. Alternativ kannst Du das auch von einem at täglich oder so erledigen lassen. Dann bekommst Du einmal am Tag die Nachricht.
Gruß,
Thorsten
Verstehe nicht was an der dummy Lösung besser ist!
In meinem System gibt es bis auf das ImportDevice keinen einzigen dummy und trotzdem funktioniert alles wie es soll.
Ihr macht das schon mit Euren dummy(s)......
Viel Spaß weiterhin.
Gruß
Dan
Zitat von: DeeSPe am 16 Februar 2017, 12:05:52
Ihr macht das schon mit Euren dummy(s)......
Da ist aber einer eingeschnappt :-)
Dann hilf mir doch. Ich benötige nur ein Push (wie auch immer) mindestens einmal am Tag das alle Devices auf ein battery:low testet.
Ich möchte keine 18 Notifys, Dummys oder ähnliches anlegen :-)
Bitte nicht streiten, sondern helft mir ;D 8)
Zitat von: DeeSPe am 16 Februar 2017, 11:44:20
Es werden dann halt von allen Readings nur noch Events erzeugt wenn sich der Wert ändert!
Die Frage ist halt, ob man das will. Ich würde das nicht woollen.
Zitat von: DeeSPe am 16 Februar 2017, 12:05:52
Verstehe nicht was an der dummy Lösung besser ist!
Man kann relative einfach steuern, wie oft man die Message haben will.
Zitat von: accessburn am 16 Februar 2017, 11:46:22DOIF oder at, gibt es da auch etwas wie ein allrounder (.*:[Bb]attery:.*) oder muss ich evenfalls eins für jedes einzelne anlegen?
Du lässt das notify so wie es ist, nur dass Du das mit der Message durch das setzen eines geeigneten Readings in einem Dummy ersetzt.
Zitat von: accessburn am 16 Februar 2017, 12:16:21Ich benötige nur ein Push (wie auch immer) mindestens einmal am Tag das alle Devices auf ein battery:low testet.
Ich möchte keine 18 Notifys, Dummys oder ähnliches anlegen :-)
Genau das macht doch meine Lösung. Du musst nur ein Dummy anlegen. Wenn Du willst, dann kannst Du auch ein Reading in irgend einem anderen Device anlagen, muss ja kein neuer Dummy sein.
Gruß,
Thorsten
So, soweit bin ich:
ZitatInternals:
CFGFN
NAME Batterie_dummy
NR 5993
STATE Heizung_WZ_Rechts
TYPE dummy
Readings:
2017-02-16 12:56:33 state Heizung_WZ_Rechts
Attributes:
event-on-change-reading .*
room Wohnzimmer
ZitatInternals:
DEF .*:[Bb]attery:.* { if($EVENT !~ m/ok/) { my $aktor = AttrVal($NAME,"alias","Fehler");; fhem( "set Batterie_dummy " . $aktor) }; }
NAME n_batt_chk
NR 430
NTFY_ORDER 50-n_batt_chk
REGEXP .*:[Bb]attery:.*
STATE 2017-02-16 12:56:33
TYPE notify
Readings:
2017-02-16 12:54:16 state active
Attributes:
Wie stell ich jetzt die Verbindung her?
Na, wie gesagt: Du machst Dir ein notify, das bei Änderung des Dummy triggert und sendest darin Deine Message.
Gruß,
Thorsten
Und da bin ich jetzt am selben Punkt angekommen wie es vorher schon mal war. Ich hab kein Plan wie das gehen soll.
Korrigiere mich, ich versuche es wenigstens zu lernen :-)
Neues, zusätzliches Notify mit:
{
my $Batteriealarm = ReadingsVal("Batterie_dummy", "state", "Fehler");
if ($Batteriealarm !~ m/ok/)
{
fhem("set telegram message blablabla;set Batterie_dummy ok")
}
}
macht das dann so sinn?
Ha!
Ich hab was fast funktionierendes :-)
Jedoch folgende Frage daraus, wieso wird einmal "ok" in den Dummy geschrieben, beim nächsten trigger "alles_gut" dann wieder "ok".
Die Batterie ist doch immer leer :-D
.*:[Bb]attery:.* { if($EVENT !~ m/ok/) { my $aktor = AttrVal($NAME,"alias","Fehler");; fhem( "set battery_dummy $aktor") } else { fhem( "set battery_dummy alles_gut") }; }
Hi,
Du verwirrst mich und Dich selbst wahrscheinlich auch. Das notify, das den Dummy gesetzt hat, war doch schon perfekt. Es schreibt einfach das Device, was als letztes einen Batteriealarm hatte, in den Dummy rein. Ok, wenn es zwei Devices warden, dann bist Du zurück beim ursprünglichen Problem, aber da sehen wir dann weiter.
Bei dem neuen notify must Du doch in den Kommandoteil nur das schreiben:
set telegram message blablabla
Das ist alles.
Gruß,
Thorsten
Verwirrt ist kein ausdruck, nennt mich Alan Touring ;-)
Ich hab es jetzt über ein at gelöst, denn das ursprüngliche kriege ich eh nicht mehr zusammen :-D
das at nervt mich zweimal am Tag so lange der dummy auf irgendwas anderes steht als ok. Jedoch wechselt der dummy andauernd seinen Status hin und her
Zitat von: accessburn am 16 Februar 2017, 16:38:07
Verwirrt ist kein ausdruck, nennt mich Alan Touring ;-)
Der Herr hieß "Alan Turing", ohne "o". :P
Zitat
Ich hab es jetzt über ein at gelöst, denn das ursprüngliche kriege ich eh nicht mehr zusammen :-D
das at nervt mich zweimal am Tag so lange der dummy auf irgendwas anderes steht als ok. Jedoch wechselt der dummy andauernd seinen Status hin und her
Dann lass uns doch nochmal teilhaben an Deinen Verwirrungen. Wie wär's wenn Du mal ein List der beteiligten notifies, des at und des Dummys machst?
Gruß,
Thorsten
notify n_batt_chk
ZitatInternals:
CFGFN
DEF .*:[Bb]attery:.* { if($EVENT !~ m/ok/) { my $aktor = AttrVal($NAME,"alias","Fehler");; fhem( "set battery_dummy $aktor") } else { fhem( "set battery_dummy ok") }; }
NAME n_batt_chk
NR 11028
NTFY_ORDER 50-n_batt_chk
REGEXP .*:[Bb]attery:.*
STATE 2017-02-16 16:52:05
TYPE notify
Readings:
2017-02-16 16:43:23 state active
Attributes:
room Wohnzimmer
dummy battery_dummy
ZitatInternals:
CFGFN
NAME battery_dummy
NR 11072
STATE ok
TYPE dummy
Readings:
2017-02-16 16:52:06 state ok
Attributes:
room Wohnzimmer
at batterie_warnung:
ZitatInternals:
CFGFN
COMMAND { my $aktor = ReadingsVal("battery_dummy","state","Fehler");; if ($aktor !~ m/ok/) { fhem( "set Telegram message FHEM Batteriewarnung: *" . $aktor ."*" ) }; }
DEF +*12:00 { my $aktor = ReadingsVal("battery_dummy","state","Fehler");; if ($aktor !~ m/ok/) { fhem( "set Telegram message FHEM Batteriewarnung: *" . $aktor ."*" ) }; }
NAME batterie_warnung
NR 11200
NTM 04:02:43
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 04:02:43
TIMESPEC 12:00
TRIGGERTIME 1487300563.37993
TRIGGERTIME_FMT 2017-02-17 04:02:43
TYPE at
Readings:
2017-02-16 16:02:43 state Next: 04:02:43
Attributes:
Hi,
also ich würde das in etwa wie folgt ändern:
1. Das erste notify:
.*:[Bb]attery:.* { if($EVENT !~ m/ok/) { my $aktor = AttrVal($NAME,"alias","Fehler");; fhem("setreading battery_dummy lastLowDevice ".$actor);; fhem( "setreading battery_dummy battstate low") } }
2. Im dummy noch zusätzlich:
attr battery_dummy event-on-change-reading battstate
3. Noch ein notify etwa so:
define n_battMsg notify battery_dummy:battstate:.low set Telegram message FHEM Batteriewarnung [battery_dummy:lastLowDevice]
4. Das at so definieren:
define removeBattstate at +*12:00 setreading battery_dummy battstate ok
Du solltest dann zweimal am Tag die Nachricht bekommen, solange Du keine Batterien wechselst. Der Dummy-Status wechselt auch nur zweimal am Tag kurz.
Gruß,
Thorsten
Gruß,
Thorsten
Okay, somit bin ich komplett raus, versteh nicht wieso das so sein muss. Aber ich möchte dich jetzt nicht ärgern, nur es geht nicht :-(
battstate bleibt auf okay stehen. Hab das at mal auf eine minute gedreht und mal bisschen laufen lassen...
Das Log schimpft:
Zitat2017.02.16 17:49:04 1: ERROR evaluating my $EVTPART0='battery:';my $TYPE='MAX';my $SELF='n_batt_chk';my $EVTPART1='ok';my $EVENT='battery: ok';my $NAME='MAX_132a2c';{ if($EVENT !~ m/ok/) { my $aktor = AttrVal($NAME,"alias","Fehler");; fhem("setreading battery_dummy lastLowDevice ".$actor);; fhem( "setreading battery_dummy battstate low") } }: Global symbol "$actor" requires explicit package name at (eval 53169) line 1.
Zitat von: accessburn am 16 Februar 2017, 17:49:38
Okay, somit bin ich komplett raus, versteh nicht wieso das so sein muss.
Muss ja gar nicht, aber ich hatte Dein letztes Posting so verstanden, dass es nocht nicht richtig klappt.
Zitat
battstate bleibt auf okay stehen. Hab das at mal auf eine minute gedreht und mal bisschen laufen lassen...
Das Log schimpft:
Ah, ich habe da in dem ersten notify aus Versehen $actor statt $aktor geschrieben.
Gruß,
Thorsten
Autsch, hab ich auch nicht entdeckt ...
Ich habe den at auf einer Minute laufen. Die Mails kommen wie vorher als normaler notify alle 5-6 Minuten.
Zitat von: accessburn am 16 Februar 2017, 20:00:27
Ich habe den at auf einer Minute laufen. Die Mails kommen wie vorher als normaler notify alle 5-6 Minuten.
Ja, das ist klar. Wenn das at jede Minute läuft, dann setzt es jede Minute das battstate zurück. Dann kann man sich das ganze auch sparen. Du musst das at seltener laufen lassen als die Devices ihre Events produzieren. Dann solltest Du den Effekt sehen. Also z.B. das at alle 15 Minuten, dann müssten die Messages alle 15 bis 21 Minuten kommen, wenn es vorher alle 5 bis 6 Minuten war.
Gruß,
Thorsten
Okay ich teste das mal.
In der Hoffnung es macht irgendwann klick...
Ich weiß schon warum ich PHP gelernt hab und nicht Perl ;-)
Zitat von: accessburn am 16 Februar 2017, 20:08:00
Ich weiß schon warum ich PHP gelernt hab und nicht Perl ;-)
Wieso? Da ist doch jetzt fast kein Perl dabei.