[gelöst] Wieder mal: Watchdog triggert nur 1 mal

[Beta-User]

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:

Code Auswählen Erweitern


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:

[Otto123]

Bei mir gibt es für Variante 3 schon ein NOTIFYDEV

Code Auswählen Erweitern

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

[Damian]

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
Danach wäre die etwas mehr ausformulierte Schreibweise

Code Auswählen Erweitern

test_dummy:closed|test_dummy:open
performanter im System als der Vorschlag von Dir:

Code Auswählen Erweitern

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.

[Damian]

Eure Tests hängen davon ab, ob das Gerät im System existiert oder nicht - NOTIFYDEV wird belegt oder eben nicht

[Beta-User]

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

Eure Tests hängen davon ab, ob das Gerät im System existiert oder nicht - NOTIFYDEV wird belegt oder eben nicht

Eben:

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:

[isy]

Code Auswählen Erweitern


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

[isy]

Code Auswählen Erweitern


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

[Otto123]

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

[Beta-User]

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

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.

[Damian]

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.

[Beta-User]

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

[Damian]

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.

[isy]

Cool