Grundsätzliche Codingfragen / Performance

[Prof. Dr. Peter Henning]

Das Problem hierbei dürfte tatsächlich die Linkstation Mini sein. Da auch der Hersteller immer mehr Funktionalität in seine Firmware packt und die I/O-Bandbreite sehr begrenzt ist, behindern sich die diversen Lese- und Schreibvorgänge auf die Peripherie gegenseitig. Die CPU ist also weitestgehend unschuldig.

LG

pah

[Zrrronggg!]

Das Problem hierbei dürfte tatsächlich die Linkstation Mini sein.

Ja, ich fürchte auch. Das Teil ist ja in sich selber schon recht betagt.

... Klingt erst mal nach "nur zu brauchen wenn ich DOIF nutze", was ja bei einigen schon fast glaubensmäßig abgelehnt wird ...

Zu DOIF (off Topic) : Ich lehne das nicht ab, ich benutze es nur nicht. Das hat historische Gründe, als ich anfing gab's das schlicht noch nicht.

Ich bin bisher noch an nichts vorbei gekommen, was ich machen wollte und mit "perl-if" nicht auch ging. Daher hatte ich einfach keinen Bedarf das doch recht mächtigen DOIF zu "erlernen". Und das "erlernen" könnte mühsam sein: Ich habe  direkt am Anfang mal mitbekommen, dass - für mich total unintiutiv - ohne weiteres ein Event das die Bedingung erfüllt nicht mit jedem Eintritt das Ereignis auslöst sondern nur das erste mal.  Ich habe verstanden, dass man das mit irgendeinem Attribut a la "always" oder so  ändern kann. Aber mein Problem ist, dass meine Denke genau andersrum wäre: Wenn Bedingung erfüllt, mach es.  Jedes mal. Wenn es nur 1x sein soll, dann könnte man einen Parameter einführen ... Der umgekehrte Pfad mag eine Berechtigung haben, klingt für mich aber erstmal absurd.

An sich kein Problem, lässt mich aber befürchten, dass in DOIF noch mehr so Dinge schlummern, wo DOIF sich total anders verhält als ich es erwarten würde. Daher erwarte ich eine steile Lernkurve - die ich zugegeben scheue.

Wenn ich mal was brauche, was mit DOIF super einfach zu lösen ist und ansonsten nur kompliziert oder gar nicht, sehe ich mir DOIF sicher an.

(Im Moment sehe ich  hier im Forum aber eher das Gegenteil: komplexe "Lösungen" mit DOIF, für die es aber an sich viel einfachere Lösungen ohne DOIF gibt.)

Das die DOIFtools auch ohne DOIF Nutzung sinnvoll sein könnten habe ich aber kapiert 

[rudolfkoenig]

Ich könnte z.b. jeweils mit erreichen von 07:00 Uhr [...] definieren, und dieses um 03:00 Uhr löschen.

Oder man setzt disabledForIntervals
Das macht es nicht performanter, nur einfacher zu lesen.

was ist in der Ausführung schneller

Haengt davon ab, wie haeufig b oder a sich aendert.
Ein define erzeugt ein zusaetzliches Event, genauso wie ein delete, also am besten meiden.
Die if Abfrage innerhalb eines perl Evals duerfte schneller sein, als zwei NotifyFns der Reihe nach aufzurufen.

Viel wichtiger in diesem Zusammenhang ist NOTIFYDEV, wie Beta-User das erwaehnt hat.
fhem.pl benachrichtigt fuer ein Event vom Geraet XXXX alle NotifyFns (d.h. notify, FileLog, sequence, watchdog, DOIF, etc), die im NOTIFYDEV XXXX aufgefuehrt haben, und alle ohne ein NOTIFYDEV.
Im Idealfall haben alle NOTIFYDEV, dann wird niemand "sinnlos" aufgerufen, im Worst-Case (bei keinem der Instanzen ist NOTIFYDEV gesetzt) werden alle Instanzen fuer alle Events aufgerufen.
Kuerzlich hatten wir ein System mit ca 1000 NotifyFns, und 100 Events/Sek: im Idealfall (s.o) hat man 100 Funktionsaufrufe/sec, im Worst-Case 100 tausend.

Das alles ist dann relevant, wenn die CPU ausgelastet ist.

Die Groesse von FileLogs ist irrelevant, es sei denn, man will Grafiken haben, die Daten aus mehreren Dateien ziehen muessen.
Die Anzahl der alten Filelogs ist nur wg. Plattenplatz relevant, nicht aber aus Performance-Gruenden.

[Damian]

Viele Events können schon das System recht träge machen, da lohnt der Blick in den Event-Monitor.

Im Laufe der Zeit kann sich da einiges ansammeln. Ich war erschrocken, als ich bei mir feststellen musste, dass der Event-Monitor nur so durchlief und keine Eventpausen mehr zu sehen waren.

Nach meinen Messungen belastet ein Event das System zig-mal mehr, als das Schreiben eines Readings ohne Event.

Ich habe mir daraufhin das Leben einfach gemacht und einfach mit:

attr .* event-on-change-reading .*

viele Events erstmal stillgelegt.

Das System wurde sofort reaktionsschneller.

An zwei Stellen musste ich dann noch event-min-interval setzen, damit wichtige Temperaturen nicht zu lange ausblieben.

Leider gibt es immer noch unwichtige Events, die ich nicht unterbinden kann.

Leider sind einige Module sehr gesprächig - offenbar wussten die Autoren es nicht besser und haben es zu gut gemeint.

Ich würde mir ein no-event-Attribut (für alle Module) wünschen, um Events bewusst in solchen Fällen unterbinden zu können.

[Beta-User]

Pauschale Aktionen wie "event-on-... .* " sehe ich eher skeptisch, v.a., wenn man sich irgendwo "versehentlich" doch mal Gedanken gemacht hatte, wie es "passend" ist.

Erschreckend finde ich eher, wie "stressfrei" viele User damit umgehen, dass manche Geräte (und evtl. auch Module) FHEM mit Events (und teils Logeinträgen) "fluten", ohne dass irgendein Mehrwert erkennbar wäre. V.a. im MQTT-Umfeld kann man sich manchmal nur die Frage stellen, ob irgendwer auch nur eine Sekunde nachgedacht hat, als er die Schnittstelle designed hat... (Beispiel: Wie kommt man auf die Überlegung, dass irgendwen die (unveränderte) WLAN-SSID alle 5 Sekunden interessierten könnte)?!?
Von Userseite wird das aber dann nicht hinterfragt, sowas bekommt man dann teils erst Monate später mehr oder weniger zufällig mit... Hähhh!?!?!
Sowas wird dann durch eocr .* einfach zugedeckt - eigentlich sollte man den Hersteller kontaktieren und einen Teil seines Geldes zurückverlangen oder das Ding gleich zurückschicken! Wer an der Stelle so einen Unsinn treibt, steht stark im Verdacht, (mindestens!) softwareseitig eventuell  auch sonst irgendwas irdendwie hingepfriemelt zu haben...

patches (für "gesprächige" Module) könnte man ja durchaus anderen Maintainern liefern, wenn man mag. (Oder auch einfach nur erst mal Fragen zur "Informationspolitik" stellen, manchmal ist es ja in der Tat nur eine Kleinigkeit, das Meldeverhalten insgesamt umzustellen oder wenigstens von single- auf bulk-update...).

[Wzut]

Leider gibt es immer noch unwichtige Events, die ich nicht unterbinden kann.
Leider sind einige Module sehr gesprächig - offenbar wussten die Autoren es nicht besser und haben es zu gut gemeint.

Ist mir selbst schon passiert beim Modul schreiben/testen, inzwischen "verstecke" ich diese Events/Readings hinter einem debug Attribut.
Im Problemfall zur Fehlersuche hat man sie dann schnell zur Hand aber im Normalbetrieb fehlen sie.

patches (für "gesprächige" Module) könnte man ja durchaus anderen Maintainern liefern,

IMHO muss es nicht unbedingt gleich ein Patch sein, man sollte einfach die betreffenden Autoren direkt darauf ansprechen.

[Damian]

Ich denke, ich werde mal einen Patch für ein "no-Event"-Attribut in fhem.pl vorschlagen.

[rudolfkoenig]

Ich denke, ich werde mal einen Patch für ein "no-Event"-Attribut in fhem.pl vorschlagen.

"attr xx event-on-update-reading ," oder "attr xx event-on-change-reading ," duerfte die gleiche Wirkung haben.

[Damian]

"attr xx event-on-update-reading ," oder "attr xx event-on-change-reading ," duerfte die gleiche Wirkung haben.

Stimmt, beim Update muss man dann nur umdenken:

event-on-update-reading   blablabla

tut's schon

[Wzut]

aber nur dann wenn man nicht an ein Modul hat wo der Autor der Meinung war vor jedem Durchlauf alle Readings ins Nirwana schicken zu müssen und dann alle komplett neu zu betanken .... Ohne Frage gibt es Anwendungen wo dieses Vorgehen zum Teil sinnvoll ist (ich selbst mache das bei meinem MPD Modul bei einem Titelwechsel das alte Readings gelöscht werden, weil die Neuen zum Teil weniger Informationen haben als die Alten) aber ich hatte auch schon Module in der Hand wo über 30 Readings jedesmal im Event Monitor aufgeschlagen sind.

[Sany]

@Zrrronggg!

Zu DOIF (off Topic) : Ich lehne das nicht ab, ich benutze es nur nicht. Das hat historische Gründe, als ich anfing gab's das schlicht noch nicht.

da warst Du gar nicht gemeint, es sollte nur "unterstützen" die DOIFtools unabhängig von DOIF als Werkzeug zu nutzen.

Das die DOIFtools auch ohne DOIF Nutzung sinnvoll sein könnten habe aber kapiert 

hat ja geklappt 



@rudolfkoenig

Die Groesse von FileLogs ist irrelevant, es sei denn, man will Grafiken haben, die Daten aus mehreren Dateien ziehen muessen.

gibt es da so etwas wie "best practice"?
Also z.B. wenn Daten von mehreren Devices in einem SVG-plot dargestellt werden sollen dann alles in einem gemeinsamen log aufzeichnen? Kann man Aussagen treffen, ab wann die Größe des Logs sich "schädlich" auswirkt, wenn man mehrere Logs in einem SVG-plot auswertet? Hat es einen Einfluss, ob im SVG-plot Daten direkt dargestellt werden (z.B. temperature Wert) oder noch "behandelt" werden ($fld[2]=~"open"?1:0)?
Ich denke, wenn es da Auswirkungen gibt, dann vermutlich auch abhängig von der gesamten Anzahl an plots. Also vermutlich gar nicht so pauschal zu beantworten, aber vielleicht gibts ja doch Größenordnungen, an denen man sich orientieren kann.

[Otto123]

@Sany Ich werfe mal meine Erfahrung mit ein:
Es wird langsamer dargestellt wenn:
Mehr Daten pro Zeiteinheit vorhanden sind als die Auflösung überhaupt erfordert
Wenn berechnet werden muss
Wenn Daten zerpflückt oder umgewandelt werden müssen
Wenn Daten aus mehrere Dateien zusammengesucht werden

Die Darstellungsgeschwindigkeit ist abhängig von der Anzahl Plots auf einer Seite.

Interessant ist vielleicht auch, dass der Umstieg von Filelog auf eine Datenbank sich nicht positiv auf die Geschwindigkeit auswirkt (gleiche Hardware Vorrausetzungen). Es kann sich sogar negativ auswirken.

Das typische Homematic Logging T:19 H:56 spart Platz im Logfile und ist nicht langsamer in der Darstellung gegenüber dem getrennten Log obwohl die Daten aus der Zeile "geteilt" werden müssen.
Die Auswertung des Konstruktes "T:19 H:56 " aus einer Datenbank ist wesentlich langsamer als die Auswertung von getrennten Werten temperature:19 und humidity:56 .

[Beta-User]

@rudolfkoeniggibt es da so etwas wie "best practice"?

Da ich die Frage vor kurzem auch gestellt hatte, hier die dortige Antwort (soweit über den hier schon mehrfach diskutierten Aspekt: Events reduzieren hinaus relevant):

Ist es jetzt geschickter, die state-Events mitzuschneiden (und den Rest nicht), oder besser die Einzelwerte?

Etwas vereinfacht skaliert der Aufwand im FileLog mit Anzahl der vorhandenen (d.h. ungefilterten) Spalten(!) im fraglichen Bereich.
Der Aufwand im SVG skaliert mit Anzahl der anzuzeigenden Werte.

D.h. optimal ist ein separates FileLog pro Linie, was nur die Wertspalte enthaelt, zusaetzlich zum Zeitstempel und Geraet. Die naechstbeste Loesung ist alle benoetigten Werte auf einer Zeile zu haben, moeglichst ohne ueberfluessige Spalten. [...]

[Zrrronggg!]

Nach den zahlreichen Beiträgen hier habe ich für mich meine Grundüberlegung beerdigt und bin dazu übergegangen mit attr xx event-on-change-reading zu arbeiten. Dazu brauche ich eigentlich nichtmal Tools, wenn ich info timer im Telnet aufmache rauschen bei mir auch die Events nur so vorbei und wenn man sieht das jetzt zum 4x gemeldet wird, das das Ventil im Gästezimmer noch zu ist, die Batterie noch gut, und die Luftfeuchte immer noch 60% ist ...

Inzwischen habe ich sogar schon mal 15 Sekunden, wo NIX an Meldungen kommt.

Ich habe auch nachteilige Effekte befürchtet und mach das daher recht langsam Schritt für Schritt und ergänze bei Readings für Graphen event-min-interval.
Das klappt bisher ganz gut.

Das die Grösse des Logs an sich egal ist war mir klar, nur mehr Daten im Log heisst ja auch, das die mal da rein geschrieben werden müssen, also IO.

disabledForIntervals hatte ich nicht auf dem Schirm. Wird ja letztlich auch nur ein verdecktes perl if sein, aber es würde bei mir zumindest so mache komplexere Bedingung vereinfachen, indem es Abfragen nach Zeiten quais auslagert.  Also wie Rudi sagt: Einfacher zu lesen.
Das werde ich daher auch einsetzen.

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?

[Otto123]

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?

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