Grundsätzliche Codingfragen / Performance

[MadMax-FHEM]

device:on|device:off aufwändiger aber exakter und optimal - NOTIFYDEV

Jetzt hab ich das auch verstanden

Danke, Joachim

[TomLee]

device:o[nf]+ optimal - NOTIFYDEV
device:on|device:off aufwändiger aber exakter und optimal - NOTIFYDEV

Warum ist device:on|device:off exakter ? Woran erkennt ihr jetzt den Unterschied der beiden Definitionen, in NOTIFYDEV steht doch bei beiden "device".

[Otto123]

o[nf]+ matched auch auf onnn onnnnnfffff onfnfnfn usw.

ich weiß kommt nicht vor nur theoretisch.

[Damian]

Ich würde NOTIFYDEV nicht überbewerten. Meine Untersuchungen haben gezeigt, dass man mit NOTIFYDEV ca. 30 % Systemlast (im DOIF) einspart (https://forum.fhem.de/index.php/topic,103401.msg971224.html#msg971224), ein eingespartes Event bringt dagegen ca. 99 % Einsparung und das nur beim Schreiben des Readings also ohne Folgekonsequenzen (https://forum.fhem.de/index.php/topic,113228.msg1080655.html#msg1080655)

[MadMax-FHEM]

Danke für die "Messungen"!

Drum versuche/mache ich beides...

Events hab ich schon (fast) so weit möglich auf das eingeschränkt was ich brauche (Logs/Automatismen), jetzt kommen die 30% dran...

Gruß, Joachim

[Jamo]

Gibt es einen intelligenten Filter, mit dem man die notify ohne NOTIFYDEV herausfinden kann? Das folgende funktuioniert nicht, im Wiki steht fuer Internals wird immer nur der erste Wert gefunden...

Code Auswählen Erweitern

list TYPE=notify:FILTER=Internals!=NOTIFYDEV

[Zrrronggg!]

Hast Du mit der Wahl Deiner Suchmuster beim notify voll in der Hand.
device:(on|off) nicht optimal - kein NOTIFYDEV
device:o[nf]+ optimal - NOTIFYDEV
device:on|device:off aufwändiger aber exakter und optimal - NOTIFYDEV

Oh, okay.

[Beta-User]

Gibt es einen intelligenten Filter, mit dem man die notify ohne NOTIFYDEV herausfinden kann?

Hilfsmittelchen:

Code Auswählen Erweitern

count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF


Ergänzend sei aber nochmal erwähnt, dass auch ich voll zustimme, dass man vorrangig die Eventseite ansehen muss.
Reihenfolge:
- Externer "Verursacher" (firmware-Einstellungen)
- eocr-Attribute - aber mit Augenmaß. Wie hier auch abgerissen, ist es nur ein erster Ansatz, eines dieser Attribute auf .* zu setzen. Für Shelly@MQTT2-Module gibt es z.B. einen Vorschlag (zu finden über den "Workshop zu M2-Device"), zu dem bisher aber zu wenig Rückmeldung vorliegt, um das fest in die attrTemplate einzuarbeiten. Da werden übrigens dann manche Topic-Zweige ganz ignoriert.

[Damian]

Nur mal zur Info:

Falls NOTIFYDEV nicht gesetzt werden kann, wird im DOIF ein eigener Filter gesetzt, der in den ersten Zeilen der Notify-Routine angewendet wird, daher dürfte der Einspareffekt durch NOTIFYDEV inzwischen beim DOIF nur noch ein paar Prozent ausmachen.

[rudolfkoenig]

Mit NOTIFYDEV werde ich mich auch mal befassen, aber soweit ich das verstanden habe, kann ich das ja nicht echt beinflussen, da das ja wohl bei der Modulerstellung gemacht werden muss, oder hab ich das falsch verstanden?

Fuer die Module steht eine fhem.pl-Funktion bereit (notifyRegexpChanged), der aus dem (ueblicherweise vom Benutzer gesetzten) Regexp versucht abzuleiten, welche Geraete betroffen sind. Wenn das bekannt ist. dann wird NOTIFYDEV gesetzt, und das betroffene notify/FileLog/DOIF/etc fuer Events von anderen(!) Geraeten nicht aufgerufen. Leider kann diese Routine nicht immer rausfinden, was gemeint ist (siehe die Beispiele von Otto), mit { notifyRegexpCheck("myregexp") } kann man sehen, wie notifyRegexpCheck "denkt".

daher dürfte der Einspareffekt durch NOTIFYDEV inzwischen beim DOIF nur noch ein paar Prozent ausmachen.

Bei einer Konfiguration mit vielen(!) DOIFs/FileLogs/etc machen die paar Prozente einen wesentlichen Unterschied.
Das ist kein Problem auf einem Test- oder Spielsystem, wird aber eins mit einer groessen Konfiguration.

Wir hatten kuerzlich den Fall, wo aus den ca 1000 FileLogs und notifies "nur" 2/3 ein NOTIFYDEV hatten.
Hier sind es mehr als ein paar Prozent Unterschied, wenn bei jedem Event statt eine Funktion 300 Weitere sinnlos aufgerufen werden.

Um die CPU-Last zu reduzieren sollte man die Anzahl der Events und Anzahl der Funktionsaufrufe minimieren.
Am ersten Parameter zu drehen ist einfacher, der Zweite ist aber deswegen nicht sinnlos.
Wie geschrieben, das wird relevant, wenn die CPU zu ist.

[Zrrronggg!]

Habe inzwischen ein Menge gelesen, auch eure Kommentare alle und es lichtet sich etwas der Nebel bezüglich NOTIVYDEF.

Ich darf eventuell anmerken, das die Doku dazu etwas zu dünn und vor allem zu zerstreut ist, um Leuten auf meine Level einen einigermassen brauchbaren Einstig zu bieten. Ohne diesen Thread wäre das noch schwerer gewesen. Eventuell verfasse ich mal einen Wikiartikel - sobald ich sicher bin es auch richtig kapiert zu haben.

Ein Aspekt in meinem konkreten Fall ist, dass ich nicht mal weiss, ob CPU überhaupt das Problem ist. TOP sagt eher nein, aber  da ich im Grunde nicht weiss wie der CPU% Wert bei TOP im Anzeigeintervall ermittelt wird, könnte es schon sein, das FHEM immer wieder mal auf 100% springt für sehr kurze Zeit.

Ich habe trotz der Bedenken von Beta-User jetzt erstmal recht grossflächig eocr eingesetzt, das hat aber in der Tat auch Nebenwirkungen (z.b. bei meiner "Alarmanlage"), bisher vielen die mir aber immer noch vorher ein ...

Das

Hilfsmittelchen:
Code: [Auswählen]
count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF

hatte ich gesehen. Ich war nur noch nicht so weit, genug von NOTIFYDEV kapiert zu haben um damit schon was anfangen zu können.

[MadMax-FHEM]

Naja die Nebenwirkungen von eocr .* lassen sich z.B. durch eour: event-on-update-reading Reading1,Reading2 usw. wieder "zurückstellen".
Es gibt auch andere Mechanismen wie mininterval...

Am besten mal lesen...
https://wiki.fhem.de/wiki/Event-on-change-reading
https://wiki.fhem.de/wiki/Event-on-update-reading
https://wiki.fhem.de/wiki/Event-min-interval

Um bzgl. Logging (da nehme ich ab und an ein mininterval dazu) aber v.a. "gewohnte" Automatismen wie vor eocr.* zu haben nehme ich eben über eour wieder einige "wichtige" Readings aus eocr.* "raus"...

Gruß, Joachim

[Beta-User]

Vielleicht noch ein paar Anmerkungen:

"Event" und das, was man im Event-Monitor sieht, sind betreffend der Systemlast nicht ganz dasselbe. Werden mehrere Readings "auf einen Rutsch" aktualisiert (bulk-update), ist das bzgl. der Info an Eventhandler EIN Durchlauf, der dann nur etwas länger dauert, weil der "Eventstapel" eben größer ist und nicht nur ein Reading enthält. Beispiel: zwei readingList-Einträge in einem MQTT2_DEVICE ergeben zwei Event-Verarbeitungsdurchläufe (wenn nicht {}), egal, ob jeweils nur ein einzelnes Klartext-Reading kommt oder auf beiden Topics je ein Mammut-JSON mit vielen Elementen .

Doku ist sicher eine gute Idee, und notifyRegexpCheck() als Funktion ist auch noch nicht besonders alt (es ist afaik eine Reaktion auf "Optimierer" wie mich, die ihre regexp (ehemals) gerne optimierten, um möglichst viele Buchstaben zu sparen ). Das ganze Thema ist auch erst jüngst v.a. deswegen zum Thema geworden, weil manche Devices unglaublich viele unnötige Events produzieren, und wenn man "ein paar" davon hat, dann summiert sich das halt.

Es wird auch immer noch ein Freiwilliger gesucht, der mal "anfängerfreundlich" erklärt, wie die Attribute event-on-change-reading, ... und timestamp-on-change-reading (@MadMax-FHEM: Danke für den Beleg, dass man sich da gerne was vergisst, wenn man es nicht einmal gründlich macht...) denn sinnvoll zu setzen wären - mein Vorschlag für ein Demo-Device wäre ein shelly-plug (mit Leistungsmessung)@MQTT2, aber wen den Job übernimmt, darf gerne auch was anderes nehmen. ("Wechselwirkungen" ist m.E. nur verständlich, wenn man es verstanden hat...).

Weiter hoffe ich, dass angekommen ist, dass ich nicht grundsätzlich der Ansicht bin, dass "event-on-change-reading .*" falsch ist. Es ist nur oft zu kurz gegriffen (oder .* kommt an der falschen Stelle/zu früh in der Kette).

Und da Wiederholung scheinbar manchmal hilft: Bitte immer erst checken, was man bereits von extern abfangen kann und will (und "notfalls" mal auf den Hersteller/Anbieter/github-Repo-Inhaber zugehen!)

[Otto123]

Ich darf eventuell anmerken, das die Doku dazu etwas zu dünn und vor allem zu zerstreut ist, um Leuten auf meine Level einen einigermassen brauchbaren Einstig zu bieten. Ohne diesen Thread wäre das noch schwerer gewesen. Eventuell verfasse ich mal einen Wikiartikel - sobald ich sicher bin es auch richtig kapiert zu haben.

Zustimm + unterstreich + Daumen hoch 
Dieses Thema köchelt so seit ein paar Monden in ein paar Threads - ich habe schon mal wenigsten das eine oder andere verlinkt.

[Beta-User]

Zustimm + unterstreich + Daumen hoch 
Dieses Thema köchelt so seit ein paar Monden in ein paar Threads - ich habe schon mal wenigsten das eine oder andere verlinkt.

Freue mich übrigens auch, wenn hier noch ein paar Leute aufspringen und das ganze etwas mehr in die Breite bringen . Danke auf alle Fälle (u.a.!) an Otto, der "still und leise" an vielen Stellen dafür sorgt, dass v.a. im Wiki u.a. auch solche Dinge dann zu finden sind!

Da hier vermutlich viele interessiert mitlesen: Falls da wer dabei ist, der irgendwann mal einen Wiki-Artikel geschrieben hat, wäre es super, wenn ihr mit dem aktuellen Wissen (nicht nur zu diesen Aspekten) nochmal kritisch (v.a.) über "eure" Werke drüberschaut und ggf. auch mal checkt, ob die Welt sich nicht weiter gedreht hat (oder manches noch in euren Augen verständlicher formuliert werden kann) .