Hauptmenü

Umstellung auf NOTIFYDEV-Filter

Begonnen von Damian, 31 August 2019, 16:10:46

Vorheriges Thema - Nächstes Thema

Ellert

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

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

Damian

Zitat von: Ellert am 27 September 2019, 19:31:11
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Neue Version eingecheckt. Es wird jetzt im Internal DOIFDEV der DOIF-Filter angezeigt, falls NOTIFYDEV-Filter nicht gesetzt werden konnte.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

#18
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 :)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

#19
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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Beta-User

Zitat von: Damian am 22 Januar 2022, 16:41:32
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...:
list .* NOTIFYDEV
und
list .* disableNotifyFn

(Und nicht alles davon hängt von "korrekten" Einstellungen durch den User ab!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damian

Zitat von: Beta-User am 28 Januar 2022, 09:00:59
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...:
list .* NOTIFYDEV
und
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Beta-User

#22
Zitat von: Damian am 28 Januar 2022, 09:30:12
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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damian

Zitat von: Beta-User am 28 Januar 2022, 09:46:43
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 :)

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Beta-User

Zitat von: Damian am 28 Januar 2022, 10:23:30
ja, gemeint war natürlich:
Ob es "natürlich" gemeint war, sei mal dahingestellt...

Zitat
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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damian

ZitatAber 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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damian

Zitat von: Beta-User am 28 Januar 2022, 11:08:39
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

enno

Zitat von: Damian am 27 Januar 2022, 19:25:18Mein 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
Einfacher FHEM Anwender auf Intel®NUC

Damian

Zitat von: enno am 28 Januar 2022, 13:24:29
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF