Umstellung auf NOTIFYDEV-Filter

[Ellert]

Mit der Version 98_DOIF.pm      20254 2019-09-26 18:06:30Z Damian gibt es beim Neustart eine Warnung:

2019.09.27 19:17:39 1: PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_DOIF.pm line 2439.

[Damian]

Mit der Version 98_DOIF.pm      20254 2019-09-26 18:06:30Z Damian gibt es beim Neustart eine Warnung:

Wird mit dem nächsten Update korrigiert.

[Damian]

Neue Version eingecheckt. Es wird jetzt im Internal DOIFDEV der DOIF-Filter angezeigt, falls NOTIFYDEV-Filter nicht gesetzt werden konnte.

[Damian]

Ich teste gerade eine neue Version des DOIF mit einer neuen FHEM-API, welche den NOTIFYDEV Filter setzt. Normalerweise scheitert abhängig von der Definition immer wieder das Setzen des Filters, so dass FHEM-Module unnötig von der FHEM-Zentrale benachrichtigt werden und sich selbst um das Filtern der Nachrichten kümmern müssen.

Wenn meine Tests positiv ausfallen, werde ich die neue Version einchecken.

Damit wäre DOIF das erste Modul, welches bei jeder Definition mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst

[Damian]

Hier ist die neue DOIF-Version vorab zum Ausprobieren, sie wird nicht durch fremde Events geweckt. DOIF-Devices, die das Attribut disable 1 gesetzt haben (Zustand: deactivated), werden gar nicht mehr geweckt. Da es das erste Modul in FHEM ist, welches die neuen Möglichkeiten performanceschonend zu arbeiten nutzt, wäre gut, wenn der eine oder andere es bei sich vorab testet. Mein umfangreiches System läuft seit ein paar Tagen problemlos mit der neuen Version.

Wichtig: Die neue DOIF-Version funktioniert nur mit der aktuellen fhem.pl Version!

Edit: neue Version wurde eingecheckt

[Beta-User]

Damit wäre DOIF das erste Modul, welches bei jeder Definition mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst

Bei aller (berechtigten!) Freude darüber, dass DOIF demnächst dann auch die schon lange (2014?) bestehenden Möglichkeiten der Optimierung bei der Verteilung von Event-Benachrichtigungen nutzt:

Woher nimmst du die Gewissheit, dass DOIF damit "erster" wäre...? Vielleicht das erste Modul, das die neuen "Pseudo-API-calls" aus fhem.pl nutzt, aber - je nach vorhandenen Modulen - kommen ein paar mehr Treffer mit (performance-technisch betrachtet) korrekten Ergebnissen...:

Code: [Auswählen]

list .* NOTIFYDEVund

Code: [Auswählen]

list .* disableNotifyFn
(Und nicht alles davon hängt von "korrekten" Einstellungen durch den User ab!)

[Damian]

Bei aller (berechtigten!) Freude darüber, dass DOIF demnächst dann auch die schon lange (2014?) bestehenden Möglichkeiten der Optimierung bei der Verteilung von Event-Benachrichtigungen nutzt:

Woher nimmst du die Gewissheit, dass DOIF damit "erster" wäre...? Vielleicht das erste Modul, das die neuen "Pseudo-API-calls" aus fhem.pl nutzt, aber - je nach vorhandenen Modulen - kommen ein paar mehr Treffer mit (performance-technisch betrachtet) korrekten Ergebnissen...:

Code: [Auswählen]

list .* NOTIFYDEVund

Code: [Auswählen]

list .* disableNotifyFn
(Und nicht alles davon hängt von "korrekten" Einstellungen durch den User ab!)

Ich glaube du hast meine Aussage nicht richtig gelesen:

Damit wäre DOIF das erste Modul, welches bei jeder Definition mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst.

[Beta-User]

Ich glaube du hast meine Aussage nicht richtig gelesen:

Ich glaube, du hast nur auf "klassische" Eventhandler geschaut, ohne meine Beispielbefehle mal auf deine Installation(en) loszulassen .

EDIT: Zumindest, wer CUL_HM im Einsatz hat, wird für jede Instanz dieses Moduls einen der beiden Treffer finden, und es gibt noch eine Reihe weiterer Module, die die alten Funktionen/Möglichkeiten so genutzt haben, dass es IMMER für ALLE Instanzen gesetzt wurde.

[Damian]

Ich glaube, du hast nur auf "klassische" Eventhandler geschaut, ohne meine Beispielbefehle mal auf deine Installation(en) loszulassen .

EDIT: Zumindest, wer CUL_HM im Einsatz hat, wird für jede Instanz dieses Moduls einen der beiden Treffer finden, und es gibt noch eine Reihe weiterer Module, die die alten Funktionen/Möglichkeiten so genutzt haben, dass es IMMER für ALLE Instanzen gesetzt wurde.

ja, gemeint war natürlich:

Damit wäre DOIF das erste Modul, welches bei jeder Definition mit beliebiger Device-Regex mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst.

Also wer jetzt denkt, sein System würde doppelt so schnell laufen, der irrt. Es handelt sich um ein Feintuning um paar Millisekunden herauszuholen.  Dennoch ist es eine zentrale Änderung im Modul, daher hier nochmal der Hinweis, die neue Version vorab zu testen, bevor ich sie einchecke: https://forum.fhem.de/index.php/topic,103401.msg1203851.html#msg1203851

um keine bösen Überraschungen zu erleben

[Beta-User]

ja, gemeint war natürlich:

Ob es "natürlich" gemeint war, sei mal dahingestellt...

Damit wäre DOIF das erste Modul, welches bei jeder Definition mit beliebiger Device-Regex mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst.

Je nachdem, auf welchen Aspekt man schielt, würde ich mal (abgesehen vom Sonderfall "auf alles hören") behaupten, dass auch das nicht sachlich 100% stimmt. Du hast vermutlich kein statistics im Einsatz.

Aber ab von solchen Feinheiten: DOIF ist im Unterschied zu notify jetzt an der Stelle so optimiert, dass der User nicht selbst aufpassen muss, was er tut, soweit ist es "natürlich" bald richtig.

[Damian]

Aber ab von solchen Feinheiten: DOIF ist im Unterschied zu notify jetzt an der Stelle so optimiert, dass der User nicht selbst aufpassen muss, was er tut, soweit ist es "natürlich" bald richtig.

Würde ich so nicht behaupten. Egal, ob der User DOIF oder notify benutzt, er sollte sich immer Gedanken machen, was er mit seiner Definition auslöst. Wer z. B. im DOIF [":bla"] definiert, dem wird auch die neue DOIF-Version nicht viel helfen, weil das Modul auch beim gesetzten NOTIFY-Filter bei jedem Event im System geweckt wird.

[Beta-User]

Hmmm, bin da nicht 100% durch, aber mAn. braucht man NOTIFYDEV nicht setzen, wenn (wirklich!) alle Devices den Eventhandler triggern sollen. Kann sogar sein, dass das (aber nur für diese Ausnahme) einfach nur unnötigerweise die zu durchsuchenden Daten vergrößert und daher die Laufzeit für "den Rest" geringfügig erhöht...

[Damian]

Hmmm, bin da nicht 100% durch, aber mAn. braucht man NOTIFYDEV nicht setzen, wenn (wirklich!) alle Devices den Eventhandler triggern sollen. Kann sogar sein, dass das (aber nur für diese Ausnahme) einfach nur unnötigerweise die zu durchsuchenden Daten vergrößert und daher die Laufzeit für "den Rest" geringfügig erhöht...

Wird hier langsam OT, aber, ob man NOTIFYDEV mit .* oder gar nicht setzt, beides führt zur (einmaligen) Bildung der gleichen Benachrichtigungslisten in fhem.pl: für jedes Device im System wird das jeweilige zu benachrichtigende Device eingetragen.

[enno]

Mein umfangreiches System läuft seit ein paar Tagen problemlos mit der neuen Version.

Mein FHEM (NUC mit Proxmox, Debian 11 (bullseye), Perl v5.32.1) läuft seit heute Morgen mit deiner neuen Version. Ohne Fehlermeldungen oder anderen Auffälligkeiten.

Gruss
  Enno

[Damian]

Mein FHEM (NUC mit Proxmox, Debian 11 (bullseye), Perl v5.32.1) läuft seit heute Morgen mit deiner neuen Version. Ohne Fehlermeldungen oder anderen Auffälligkeiten.

Gruss
  Enno

Danke für´s Feedback.