Moin zusammen,
Der Watchdog soll jede Minute (1 Minute hier beim Testen) auslösen und eine Mail senden.
Definition:
HM_6674CF_Btn_01:closed 00:01 SAME {DebianMail} ; ; trigger HM_6674CF_Btn_01_watchdog_1 .
Der WD löst aus "triggered", sendet die Mail und geht wieder auf "defined". Das war's.
Er wurde angelegt aus dem "Event Monitor".
Der Status kommt vom HM-MOD-EM-8, hier der Sensorkanal 1.
Der HM-MOD-EM-8 setzt keine Status-Updates alle 3 Minuten oder so. Es gibt also keinen weiteren Trigger, der Status bleibt "closed", bis der Sensorkanal wieder auf "open" geht.
Das gesetzte Attribut event-min-intervall auf .*:60 zeigt keine Änderung am Verhalten (wieder gelöscht).
Was kann das sein?
Gruß Helmut
Hallo Helmut,
was erwartest Du denn für ein Verhalten?
Wenn der Kontakt das erste mal schließt wird der Hund scharf.
Wenn er dann unter einer Minute einmal open/closed macht, wird der Timer neu gesetzt und der Hund bliebt ruhig.
Wenn die Zeit verstreicht und es macht nicht nochmal closed, bellt er einmal und wartet wieder scharf gemacht zu werden.
Gruß Otto
Hallo Otto,
dank für deine Antwort!
Ich hatte das so verstanden, dass mit "SAME" geprüft wird, ob nach Ablauf der gesetzten Zeit der Status unverändert ist und der WD somit erneut auslöst.
Zitat: Wenn <regexp2> SAME ist , dann ist es das gleiche wie das erste regexp, und wird reaktiviert wenn es empfangen wird.
Ich brauche eine Mail jede Minute (später dann 30 Minuten...logisch).
Das ist für die Überwachung der Frischwasser-Einspeisung der Regenwasser-Zisterne. Die hatte schon mal gehangen und 6000 Liter Frischwasser sind über den Überlauf ab ins Regenwasser geflossen.
Problem ist halt, dass der EM-8 kein weiteres Event auslöst.
Ich denke, ich baue die Überwachung auf DOIF um.
Viele Grüße,
Helmut
Ich hab's noch nicht verstanden: Was macht der EM-8 oder was macht er nicht? Was passiert im Normfall und was im Gefahrenfall?
Du willst jede Minute ein Email solange der Schalter closed ist? Oder nach einer Minute wenn der Schalter nach einer Minute nicht wieder open geht?
Vermutlich wurde noch nicht richtig verstanden, wie so ein watchdog eigentlich funktioniert.
Beschreibe doch bitte mal den zeitlichen Ablauf, den Du überwachen möchtest.
Zeitpunkt 0: Die Frischwasserzufuhr ist geschlossen.
Zeitpunkt 1: (welcher Event löst das Öffnen der Frischwasserzufuhr aus? Was soll nun passieren?)
Zeitpunkt 2 (=Zeitpunkt 1 +1 Minute): Was soll nun passieren?
Zeitpunkt 3 (=Zeitpunkt 2 +1 Minute): Was soll nun passieren?
...
Zeitpunkt x: (welcher Event löst das Schließen der Frischwasserzufuhr aus?)
Moin auch betateilchen.
Also das Magentventil hat mal länger als erwartet Spannung gehabt.
Mit 12 V geht das Ventil auf, Wasser fließt. Ich möchte die Steuerung des Magnetventils überwachen.
Problem mit meinem WD: Die 1. Mail kommt, dann aber keine mehr. Es soll jede Minute eine Mail kommen, solange, bis die Steuerung auf 0 V schaltet.
Diese 12V aus der Steuerung werden mit dem EM-8 Sensoreingang überwacht.
Bei 12V geht der EM-8 in den Status "closed", ohne Spannung auf "open".
Wenn der EM-8 also länger als 1 Minute auf "closed" steht, soll die Mail gesendet werden und zwar jede Minute erneut, solange, bis der EM-8 wieder auf "open" (=spannungslos) geht.
Zitat von: dl4fbr am 18 November 2020, 20:29:02
Wenn der EM-8 also länger als 1 Minute auf "closed" steht, soll die Mail gesendet werden und zwar jede Minute erneut, solange, bis der EM-8 wieder auf "open" (=spannungslos) geht.
hier eine von vielen Alternativen, falls du mit Watchdog nicht weiterkommst:
defmod di_alarm DOIF {["HM_6674CF_Btn_01:closed"];set_Exec("timer",60,'fhem("send myphone alarm!")','ReadingsVal("HM_6674CF_Btn_01","state","") eq "closed"')}
Sowas würde ich auch nicht mit einem watchdog lösen.
- ein at anlegen, das alle 30 Minuten eine Mail verschickt
- ein notify anlegen, das auf den EM8 (open|closed) triggert. Dieses notify schaltet das at active oder inactive
defmod test_at at +*00:00:10 {Debug "test"}
setstate test_at inactive
defmod test_notify notify test_dummy:(closed|open) {$EVENT eq 'closed' ? CommandSet(undef,'test_at active') : CommandSet(undef,'test_at inactive')}
test_dummy musst Du natürlich durch Deinen EM-8 ersetzen, mit dem dummy hatte ich nur getestet, ob mein Plan so funktioniert.
Ich danke euch allen für den Support.
Morgen werden ich beide Vorschläge mal testen und hier das Ergebnis posten.
Für heute erst mal gute Nach!
Moin zusammen,
ich habe die Aufgabe jetzt so gelöst, wie ich mich mit den FHEM Funktionen / Befehlen auskenne, damit das erst mal funktioniert und ich Zeit habe, mich weiter in eure Vorschläge einzuarbeiten. :)
- Die Idee mit der Aktivierung und Deaktivierung der Alarm-Mail habe ich übernommen
- Notify habe ich mit DOIF ersetzt (@betateilchen: ich muss mich weiter in die Struktur im Bereich " ? CommandSet(undef,'test_at active') : CommandSet(undef,'test_at inactive')}" einarbeiten.
- DOIF @damian: Ich habe es nicht hinbekommen, mein {DebianMail(....)} einzubauen. Auch hier fehlen mit Kenntnisse, in die ich mich einarbeiten muss.
define Alarm_Zisterne at +*00:07:00 {DebianMail(.............)}
define Alarm_Zisterne_DOIF DOIF ([HM_6674CF_Btn_01] eq "closed") (set Alarm_Zisterne active) DOELSE (set Alarm_Zisterne inactive)
So läuft der private "WD" super.
Vielen Dank für eure Anregungen.
Zitat von: dl4fbr am 19 November 2020, 10:35:04
- DOIF @damian: Ich habe es nicht hinbekommen, mein {DebianMail(....)} einzubauen. Auch hier fehlen mit Kenntnisse, in die ich mich einarbeiten muss.
define Alarm_Zisterne at +*00:07:00 {DebianMail(.............)}
define Alarm_Zisterne_DOIF DOIF ([HM_6674CF_Btn_01] eq "closed") (set Alarm_Zisterne active) DOELSE (set Alarm_Zisterne inactive)
DebianMail ist vermutlich im main-Package, deswegen musst du es mit Doppelpunkt angeben, da DOIF gekapselt im eigenen Package arbeitet:
defmod di_alarm DOIF {["HM_6674CF_Btn_01:closed"];set_Exec("timer",60,'::DebianMail(.............)','ReadingsVal("HM_6674CF_Btn_01","state","") eq "closed"')}Wenn du dich mit DOIF im FHEM-Modus auskennst, dann dürfte diese Lösung für dich ebenfalls leicht verständlich sein:
define Alarm_Zisterne_DOIF DOIF ([HM_6674CF_Btn_01] eq "closed") {DebianMail(.............)}
attr wait 60
attr repeatcmd 420
Zitat von: dl4fbr am 19 November 2020, 10:35:04
ich muss mich weiter in die Struktur im Bereich " ? CommandSet(undef,'test_at active') : CommandSet(undef,'test_at inactive')}" einarbeiten.
Die korrekte (vollständige) Struktur ist:
$EVENT eq 'closed' ? CommandSet(undef,'test_at active') : CommandSet(undef,'test_at inactive')
und man könnte das auch so schreiben:
if( $EVENT eq 'closed') {
CommandSet(undef,'test_at active');
} else {
CommandSet(undef,'test_at inactive');
}
Das ? ersetzt sozusagen das "if" (es stellt die Frage: ist $EVENT closed?)
Der Doppelpunkt ersetzt die Unterscheidung "else"
Dann könnte man noch das CommandSet() ersetzen durch
if( $EVENT eq 'closed') {
fhem('set test_at active');
} else {
fhem('set test_at inactive');
}
Damit sollte klar werden, worum es da geht. Das ist alles purer perl Code.
Für einen Einzeiler ist die von mir verwendete Variante mit ?: einfach kürzer und weniger zu tippen :)
73, DG1UDO
Zitat von: dl4fbr am 19 November 2020, 10:35:04
define Alarm_Zisterne_DOIF DOIF ([HM_6674CF_Btn_01] eq "closed") (set Alarm_Zisterne active) DOELSE (set Alarm_Zisterne inactive)
Du hast in dem Fall aber ein Problem im DOELSE, wenn der Button einen anderen event erzeugt als "closed" oder "open".
Denn dann wird Alarm_Zisterne auf inaktiv gesetzt und der Mailversand beendet.
Und Homematic devices/channels erzeugen jede Menge andere events... 8)
Deshalb hatte ich in meinem vorgeschlagenen notify die beiden zulässigen Zustände open und closed explizit in der regex vorgegeben.
ZitatDeshalb hatte ich in meinem vorgeschlagenen notify die beiden zulässigen Zustände open und closed explizit in der regex vorgegeben.
Vielleicht wird das hier zu philosophisch - aber ich habe da in letzter Zeit etwas über den Mechanismus wie Rudi den Trigger im notify optimiert erfahren und mal was dazu gefragt (https://forum.fhem.de/index.php/topic,115414.msg1096774.html#msg1096774)
Danach wäre die etwas mehr ausformulierte Schreibweise
test_dummy:closed|test_dummy:openperformanter im System als der Vorschlag von Dir:
test_dummy:(closed|open)
Zitat von: Otto123 am 19 November 2020, 13:43:09
Danach wäre die etwas mehr ausformulierte Schreibweise
...
performanter im System als der Vorschlag von Dir:
Hast Du mal in den code von 91_notify.pm geschaut, bevor Du solche Aussagen triffst?
Deine Frage in dem zitierten Thread ging um NOTIFYDEV, soweit so gut.
Variante 1defmod n_test notify (t_1:open|t_1:closed) {}ergibt:
Internals:
.COMMAND {}
DEF (t_1:open|t_1:closed) {}
FUUID 5fb66ecb-f33f-22e2-bf46-009284ddcf140df4
NAME n_test
NR 24
NTFY_ORDER 50-n_test
REGEXP (t_1:open|t_1:closed)
STATE active
TYPE notify
.attraggr:
.attrminint:
READINGS:
2020-11-19 14:12:29 state active
Attributes:
Variante 2defmod n_test notify t_1:(open|closed) {}ergibt:
Internals:
.COMMAND {}
DEF t_1:(open|closed) {}
FUUID 5fb66ecb-f33f-22e2-bf46-009284ddcf140df4
NAME n_test
NR 24
NTFY_ORDER 50-n_test
REGEXP t_1:(open|closed)
STATE active
TYPE notify
.attraggr:
.attrminint:
READINGS:
2020-11-19 14:16:48 state active
Attributes:
Variante 3defmod n_test notify t_1:open|t_1:closed {}ergibt:
Internals:
.COMMAND {}
DEF t_1:open|t_1:closed {}
FUUID 5fb66ecb-f33f-22e2-bf46-009284ddcf140df4
NAME n_test
NR 24
NTFY_ORDER 50-n_test
REGEXP t_1:open|t_1:closed
STATE active
TYPE notify
.attraggr:
.attrminint:
READINGS:
2020-11-19 14:19:21 state active
Attributes:
In keinem der Fälle wird überhaupt ein NOTIFYDEV angelegt.
Zitat von: betateilchen am 19 November 2020, 14:23:08
In keinem der Fälle wird überhaupt ein NOTIFYDEV angelegt.
Gibt es denn das betreffende Device?
Hier mal ein list von den drei Versuchen in ander Reihenfolge, wenn es das betreffende Device "ot_dummy" gibt:
Internals:
.COMMAND {}
CFGFN
DEF ot_dummy:open|ot_dummy:closed {}
FUUID 5fb672e0-f33f-8d89-e3e1-8f3873c993f96266
NAME n_test
NOTIFYDEV ot_dummy
NR 80
NTFY_ORDER 50-n_test
REGEXP ot_dummy:open|ot_dummy:closed
STATE active
TYPE notify
.attraggr:
.attrminint:
READINGS:
2020-11-19 14:28:00 state active
Attributes:
Internals:
.COMMAND {}
CFGFN
DEF (ot_dummy:open|ot_dummy:closed) {}
FUUID 5fb672e0-f33f-8d89-e3e1-8f3873c993f96266
NAME n_test
NOTIFYDEV ot_dummy
NR 80
NTFY_ORDER 50-n_test
REGEXP (ot_dummy:open|ot_dummy:closed)
STATE active
TYPE notify
.attraggr:
.attrminint:
READINGS:
2020-11-19 14:29:29 state active
Attributes:
Internals:
.COMMAND {}
CFGFN
DEF ot_dummy:(open|closed) {}
FUUID 5fb672e0-f33f-8d89-e3e1-8f3873c993f96266
NAME n_test
NR 80
NTFY_ORDER 50-n_test
REGEXP ot_dummy:(open|closed)
STATE active
TYPE notify
.attraggr:
.attrminint:
READINGS:
2020-11-19 14:30:32 state active
Attributes:
Bei mir gibt es für Variante 3 schon ein NOTIFYDEV
Internals:
DEF t_1:open|t_1:closed {}
FUUID 5c4c566e-f33f-27f7-aca3-208d6b6c86d8b2e7
NAME n_test
NOTIFYDEV t_1
NR 76
NTFY_ORDER 50-n_test
REGEXP t_1:open|t_1:closed
STATE active
TYPE notify
READINGS:
2020-11-19 14:32:21 state active
Attributes:
room Test
Zitat von: Otto123 am 19 November 2020, 13:43:09
Vielleicht wird das hier zu philosophisch - aber ich habe da in letzter Zeit etwas über den Mechanismus wie Rudi den Trigger im notify optimiert erfahren und mal was dazu gefragt (https://forum.fhem.de/index.php/topic,115414.msg1096774.html#msg1096774)
Danach wäre die etwas mehr ausformulierte Schreibweise
test_dummy:closed|test_dummy:open
performanter im System als der Vorschlag von Dir:
test_dummy:(closed|open)
Aus dem genannten Thread kann ich aber nicht erkennen, dass es performanter ist.
Das FHEM-Konzept arbeitet an der Stelle nur mit Devices. Unabhängig von der Regex-Angabe wird ein Modul immer kontaktiert, sobald das Device übereinstimmt - das dürfte schon die meiste Performance kosten, vor allem abhängig davon, was das angesprochene Modul dann alles machen.
Noch schlimmer wird es, wenn man mit FHEM2FHEM auf Ereignisse von Devices reagieren will, die es im eignen System nicht gibt oder die Erkennung des Devices aus irgendwelchem Grund nicht klappt, dann wird NOTIFYDEV nicht belegt und dann wird bei jedem Event getriggert - für diesen Fall habe ich im DOIF-Modul ein eigenen NOTIFYDEV-Mechanismus eingebaut, um die Last zu reduzieren.
Eure Tests hängen davon ab, ob das Gerät im System existiert oder nicht - NOTIFYDEV wird belegt oder eben nicht
Ist vermutlich nicht der richtige Ort, um das zu diskutieren, aber nach meinem bisherigen - möglicherweise fehlerhaften - Verständnis ist es so, dass man die Last dadurch reduzieren kann, dass man die regex "notifyRegexpCheck()-konform" angibt. Dann sollten alle nicht involvierten Eventhandler vom jeweiligen bulk-Update gar nichts mitbekommen.
Und genau darum gibt es Otto123, wenn ich das richtig interpretiert hatte.
Und falls du bessere Erkenntnisse hast, wie man die regexp-Analyse in fhem.pl optimieren kann (ohne Nebenwirkungen...), wäre das ggf. auch ein Fortschritt für alle.
Eventuell wäre es auch hilfreich, wenn man irgendwie zentral rausfinden könnte, ob man (noch) solche Kandidaten hat, betrifft ja auch andere Eventhandler wie FileLog, DBLog, ...
Zitat von: Damian am 19 November 2020, 15:01:08
Eure Tests hängen davon ab, ob das Gerät im System existiert oder nicht - NOTIFYDEV wird belegt oder eben nicht
Eben:
Zitat von: Beta-User am 19 November 2020, 14:33:02
Gibt es denn das betreffende Device?
Hier mal ein list von den drei Versuchen in ander Reihenfolge, wenn es das betreffende Device "ot_dummy" gibt:
Zitat von: betateilchen am 19 November 2020, 12:36:06
if( $EVENT eq 'closed') {
fhem('set test_at active');
} else {
fhem('set test_at inactive');
}
So verstehe ich den Code! Abkürzen ist gut!
mni tnx es73's
Zitat von: Damian am 19 November 2020, 11:22:38
define Alarm_Zisterne_DOIF DOIF ([HM_6674CF_Btn_01] eq "closed") {DebianMail(.............)}
attr wait 60
attr repeatcmd 420
Auch eine gute Idee. Ich war nicht auf "repeatcmd" gekommen und hatte das "wait" mit drin und noch das Attribut "do always" welches nicht funktionierte.
--> Wie hängt den wait mit repeatcmd zusammen?
Ich hätte "wait" jetzt auch auf 420 gesetzt, damit die 1. Mail erst nach 420s gesendet wird.
Wenn beide Timer zusammenhängen, dann wird die zweite (und jede weitere Mail) nach 840s gesendet?
Macht auch nichts, dann kann man ja die Zeiten entsprechend anpassen
Na da hab ich wieder was gemacht :-[ :) - ich geh Kaffee trinken ☕
Was es an Performance bedeutet - werde ich mal in einem Versuchsaufbau versuchen herauszufinden - vielleicht bedeutet Optimierung ja nicht Performance sondern etwas Anderes ;)
https://forum.fhem.de/index.php/topic,111938.msg1074202.html#msg1074202
Zitat von: Otto123 am 19 November 2020, 15:41:41
Was es an Performance bedeutet - werde ich mal in einem Versuchsaufbau versuchen herauszufinden - vielleicht bedeutet Optimierung ja nicht Performance sondern etwas Anderes ;)
Optimierung würde ich mit Vermeiden von Performance-Einbußen übersetzen, und dafür ist es m.E. nicht nur erforderlich, dass NOTIFYDEV vorhanden ist,
sondern dass es keinen "not ok" Teil in der REGEXP gibt, denn - wie immer: sofern ich das richtig verstanden habe - alles, was "not ok" ist, führt dazu, dass der betreffende Eventhandler über alle Events informiert wird, egal, von welchem Device die stammen. Und das sollte schon Perfomance kosten und eben nicht "optimal" in diesem Sinne sein.
Daher auch
Zitat von: Beta-User am 19 November 2020, 15:08:42
Eventuell wäre es auch hilfreich, wenn man irgendwie zentral rausfinden könnte, ob man (noch) solche Kandidaten hat, betrifft ja auch andere Eventhandler wie FileLog, DBLog, ...
Da ging es genau darum rauszufinden, was denn alles (bzw. eigentlich: _welche Teile_) "not ok" im Sinne von notifyRegexpCheck() ist - was ja ggf. auch durch ein rename oder delete später der Fall werden kann...
EDIT: Da war ein gedanklicher Dreher drin...
EDIT 2: Noch ein gedanlicher Fehler. fhem.pl liefert dann kein NOTIFYDEV zurück, wenn irgendwas nicht in Ordnung ist. Ist es also da, müßte alles "gut" sein.
Zitat von: Otto123 am 19 November 2020, 15:41:41
Na da hab ich wieder was gemacht :-[ :) - ich geh Kaffee trinken ☕
Was es an Performance bedeutet - werde ich mal in einem Versuchsaufbau versuchen herauszufinden - vielleicht bedeutet Optimierung ja nicht Performance sondern etwas Anderes ;)
https://forum.fhem.de/index.php/topic,111938.msg1074202.html#msg1074202
ohne NOTIFYDEV zu arbeiten, hat in meinem Modul ca. 30 % mehr Systemlast für das jeweilige Device bedeutet. Das ist aber alles relativ, wenn ein Modul einen sehr kleinen Anteil an der Gesamt-Systemlast ausmacht, dann sind 30 % von annährend Null, annährend Null.
Na ja, letztlich ist es immer die Frage, wie schnell entschieden werden kann, ob es sich um was relevantes handelt, und 30% finde ich für einen ersten Filter schon eine Hausnummer, zumal die Zahl der Events, die ein "durchschnittliches System" (so es sowas gibt) erzeugt/zu verarbeiten hat, vermutlich in der jüngeren Vergangenheit ziemlich zugenommen haben dürfte.
V.a. "ungezähmte" MQTT-Geräte dürften in der Hinsicht einige in vielen Installationen dazugekommen sein, und einzelne Programmierer von Clients glauben, man wolle u.a. z.B. alle 5 Sekunden die IP des betreffenden Clients wissen, oder alle 30 Sekunden, ob das Relay noch an ist usw. usf. Zum Glück meistens via bulk update (JSON), aber eben bei weitem nicht immer (und auch nicht immer, wenn JSON-payloads im Spiel sind).
Zitat von: dl4fbr am 19 November 2020, 15:39:28
Auch eine gute Idee. Ich war nicht auf "repeatcmd" gekommen und hatte das "wait" mit drin und noch das Attribut "do always" welches nicht funktionierte.
--> Wie hängt den wait mit repeatcmd zusammen?
Ich hätte "wait" jetzt auch auf 420 gesetzt, damit die 1. Mail erst nach 420s gesendet wird.
Wenn beide Timer zusammenhängen, dann wird die zweite (und jede weitere Mail) nach 840s gesendet?
Macht auch nichts, dann kann man ja die Zeiten entsprechend anpassen
wait ist für die erste Ausführung, repeatcmd für alle weiteren, sie werden nicht miteinander addiert.
Cool :) :) :)