Grundsätzliche Codingfragen / Performance

[Zrrronggg!]

"Anfängerfrage" ist ggf nicht ganz das richtige Unterforum, wusste aber nicht wohin damit.

Ich lasse FHEM auf einer recht betagten HW laufen. Gleichzeitig ist die config in den Jahren doch recht umfangreich geworden, was dazu führt, dass die Ausführungen machmal mit Verzögerungen einhergeht, wir reden hier von Sekunden.

Schon seit einiger Zeit beschäftigt mich der Gedanke, ob man die Anzahl der notifies und der Bedingungen darin nicht reduzieren könnte, um die Performance zu erhöhen. 


Ich meine z.b. folgendes: Die Heizungsventile werden in überwiegend in Abhängigkeit von der Raumbelegung gesteuert, diese wird mit Bewegungsmelder ermittelt. Grundsätzlich werden also nur Räume geheizt, in denen jemand ist.

Das sieht in etwa so aus:

Code Auswählen Erweitern

define Wohn_unten_nutzung_on notify PIRA_Wohn_unten:on.*  { if(($hour < 3 || $hour >= 7) && Value("Tuer_Wohn_u") ne "Open")  { fhem ("<heizung regeln>) ") } }

Wie man sehen kann, wird bei jeder Auslösung des PIRA bereits Kram getestet, hier wieviel Uhr es ist und ob nicht etwa die Eingangstür offen ist.


Das bedeutet, dass bei jeder Raumbewegung ein notify plus perl if/else mit 2 Bedingungen  durchlaufen wird. Wenn man DOIF verwendet, dürfte der tatsächliche Load sogar noch höher sein, da DOIF letztlich auch perls if verwendet ,nur mir zahlreichen Komfortfeatures drumherum.

Ein andere Lösung wäre aber das define selbst zu verändern, per define im define und delete oder per defmod.

Ich könnte z.b. jeweils mit erreichen von 07:00 Uhr

Code Auswählen Erweitern

define Wohn_unten_nutzung_on notify PIRA_Wohn_unten:on.*  { if(Value("Tuer_Wohn_u") ne "Open")  { fhem ("<heizung regeln>) ") } }
definieren, und dieses um 03:00 Uhr löschen.
Ebenso könnte ich das Event  Tuer_Wohn_u Open  dazu verwenden, das Define zu löschen, und wenn die Tür wieder Closed wird, das Define wieder anlegen, dann könnte das sogar auf

Code Auswählen Erweitern

define Wohn_unten_nutzung_on notify PIRA_Wohn_unten:on.* <heizung regeln>
reduziert werden, also ganz ohne if abfrage,
Tatsächlich gäbe es das define nur, wenn es auch tatsächlich etwas auslösen würde, im Rest der Zeit würden Bewegungsmelder events einfach kein notify auslösen.

Die Frage ist nun folgende: Was ist in der Ausführung schneller? Die .cfg wird durch die 2te Methode garantiert deutlich grösser, da das "define Wohn_unten_nutzung_on..." ja nun mehrmals vorkommen wird. Gleichzeitig werden die if-abfragen, ja sogar die notifys selber aber deutlich reduziert.

Wenn ich das konsequent für alle events/notifis die if-abfragen auslöse umsetze , also in allen Fällen wo die events häufig aber die Werteänderung der per if abzufragenden Parameter eher selten sind, (nur am Sonntag, nur wenn das Gästezimmer belegt ist, nicht nachts, nur im Winter, nur wenn es Tag ist, es sei den die Alarmanlage ist an etc etc.) wächst meine .cfg sicher um 200% oder so an und würde sicher auch komplexer. Gleichzeitig würde die Anzahl der "aktiven" notifies von aktuell über 100 und vor allem der if-Prüfungen deutlich sinken.

Abstrakt:

was ist in der Ausführung schneller

Code Auswählen Erweitern

define irgendwas notify a:on  { if(b) eq on)  { fhem ("<mach was>)" } }
(bzw. dessen DOIF Equivalent) oder

Code Auswählen Erweitern

define erzeuge_irgendwas notify b:on define irgendwas notify blubber:on mach was
define loesche_irgendwas notify b:off delete irgendwas
für alle Anzahl Werteänderung a > Werteänderung b
(bitte Nebenbedingungen wie Werte für a oder b könnten auch andere sein als on/off ignorieren - ist nur ein vereinfachtes Beispiel)



Klar, ich könnte auch für 50€ ein RasPi kaufen, also CPU auf das Problem werfen, werde ich sicher auch bald machen. Ich finde die Frage aber trotzdem interessant.

[KölnSolar]

ich hab mal vor Jahrzehnen gelernt: ne ist schneller als eq

IOs schlimmer als ein bißchen vergleichen. ==> also auch define, defmod, delete....

Und ja, notifys reduzieren dürfte immens helfen, weil je event immer ALLE notifys(Regexp) geprüft werden.

Und ich vermute die Vielzahl von events tut sein übriges(notify-Loop, Logging[IO]). Also lieber mal timer(interval) etwas höher setzen, event-on.....

Wenn man DOIF verwendet, dürfte der tatsächliche Load sogar noch höher sein

sehe ich auch so.

könnte auch für 50€ ein RasPi kaufen, also CPU auf das Problem werfen

Nö. Ist zwar einfacher, aber Optimierung halte ich für den besseren Ansatz, sonst ist schnell das nächste upsizing fällig.

Alles nur meine Meinung u. Theorie. 

[Zrrronggg!]

ich hab mal vor Jahrzehnen gelernt: ne ist schneller als eq

Interessant, damit kann man ja schon mal was machen. Im Grunde sogar nachvollziehbar.

IOs schlimmer als ein bißchen vergleichen. ==> also auch define, defmod, delete....

Hm. Klar, aber die Frage ist ob das ein echtes Gegenargument: Wenn ich 10x am Tag IO wegen Umschreiben habe, hauen die statistisch und speziell im dem Moment wo's passiert ordentlich rein. Aber den Rest der Zeit könnte FHEM sich schon responsiver verhalten.
Überspitzt formuliert: Was ist schlimmer: 20x am Tag 5 Sekunden Verzögerung (und auch nur dann wenn man die 100 Sekunden am Tag genau trifft) aber ansonsten nur 1 Sekunde, oder den ganzen Tag über immer 2-3 Sekunden bei allen Operationen.

Und ja, notifys reduzieren dürfte immens helfen, weil je event immer ALLE notifys(Regexp) geprüft werden.

Eben, das war der Grundgedanke, weiss eben nur nicht, ob es da nicht noch ander Dinge zu bedenken gibt. IO ist sicher so eine "anderes" Thema.

Und ich vermute die Vielzahl von events tut sein übriges(notify-Loop, Logging[IO]). Also lieber mal timer(interval) etwas höher setzen, event-on.....

Das mache ich sowieso, ich will nicht sagen, dass ich das alles optimal habe, aber ich habe schon ein wenig Gehirnschmalz reingesetzt, die events gering zu halten. Das fängt wo es geht schon bei den Sendeintervallen der Sensoren an. Überlege aber gerade: Loglevel bzw. vielmehr verbose könnte ich noch überall runterdrehen. Danke für die Idee.

Nö. Ist zwar einfacher, aber Optimierung halte ich für den besseren Ansatz, sonst ist schnell das nächste upsizing fällig.

Ja, genau.
Danke schon mal.

[MadMax-FHEM]

Ich habe ja hier ähnlich schon auf eine ähnliche Frage geantwortet

https://forum.fhem.de/index.php/topic,117062.msg1114195.html#msg1114195

Bzgl. ne: aber aufpassen, oft ist ne "DasWillIchNicht" weil oft kommt ein "DasWillIchNicht" dazu (Events ändern sich: Beispiel Homematic vor einiger Zeit) und dann kann das auch mal schnell "nach hinten losgehen"

(Gut bei "DasWillIch" auch aber eher nicht so "nebenher" weil es sollte ja alles was ich "damals" wollte ich immer noch wollen   )

Gruß, Joachim

[Otto123]

Hi,

die Beispiele oben sehen gut aus, aber vielleicht trotzdem mal nach "nicht optimierten " Suchmustern schauen.
https://forum.fhem.de/index.php/topic,115414.msg1096774.html#msg1096774

Schöne Weihnachten
Otto

[Wzut]

@Zrrronggg!, ohne jetzt gleich an die notifys und andere Logik zu gehen :
Ich mache oft einfach nur den Event Monitor auf und lasse ihn eine Weile laufen, dabei achte ich auf "Vielschwätzer"
Frei nach dem Motto musste der jetzt schon wieder das und das unbedingt als Event raushauen ?
Klar event-on-change-reading ist ein gutes Schweizer Messer, aber es gibt auch Fälle wo der Modulautor nicht ganz unschuldig ist und das sollte man dann im passenden Thread auch ansprechen.

[KölnSolar]

Hm. Klar, aber die Frage ist ob das ein echtes Gegenargument: Wenn ich 10x am Tag IO wegen Umschreiben habe, hauen die statistisch und speziell im dem Moment wo's passiert ordentlich rein. Aber den Rest der Zeit könnte FHEM sich schon responsiver verhalten.
Überspitzt formuliert: Was ist schlimmer: 20x am Tag 5 Sekunden Verzögerung (und auch nur dann wenn man die 100 Sekunden am Tag genau trifft) aber ansonsten nur 1 Sekunde, oder den ganzen Tag über immer 2-3 Sekunden bei allen Operationen.

Das ist mir zu viel Theorie für komplexes FHEM.
Ich denke, ein paar Grundregeln beachten reicht.
Und dann mit freezemon die Bösewichte ausfiltern.
Edit: Wzut war flotter und ich kann ihm nur zustimmen. In der Regel wird für jedes readingsupdate ein event rausgehauen.
event-on-change lässt sich im Modul realisieren, wird aber seltendst(nur von mir ? ) genutzt.

[Beta-User]

Na ja, ob man es im Modul einbaut oder der User filtert, macht schon einen Unterschied; wenn ich das richtig verstanden habe, kann die Entscheidung eines Maintainers,  trigger auf 0 zu setzen nicht vom User "overruled" werden, von daher beschränke ich das auch eher auf die ganz eindeutigen Fälle; jetzt bin ich aber sensibler für single-updates vs. bulk und versuche eher letzteres einzusetzen.

Was Optionen auf User-Seite angeht:

- bei dem MQTT-Kram kann man schauen, ob sich die "report"-Zeiten sinnvoll einschränken lassen; grade bei den Shellys kann man periodische Updates schon auf der Firmware-Ebene ganz unterdrücken, dann braucht man weniger event-on...
- Bei den attrTemplate für Tasmota hatte ich auch mal versucht, das einigermaßen einzudämmen, allerdings bin ich nicht sicher, ob das noch dem aktuellen Stand der fimwares entspricht...

- devspecs anschauen ist auf alle Fälle eine gute Idee. Hilfsmittelchen:

Code Auswählen Erweitern

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


- FHEMWEB-Aktionen in den Hintergrund schickten (plotfork&Co) ist sicher auch eine gute Idee (seit neuestem wohl default).

- Ganz grundsätzlich habe ich auch immer den Verdacht, dass speziell Netzwerkprozesse auch immer einen Extra-Blick wert sind. Siehe die aktuelle PRESENCE-Diskussion (sonos ist auch so ein Thema). Ggf. lohnt es sich, für "schwierige Fälle" ein separates FHEM aufzuziehen?

[Zrrronggg!]

Ich habe ja hier ähnlich schon auf eine ähnliche Frage geantwortet

https://forum.fhem.de/index.php/topic,117062.msg1114195.html#msg1114195

Danke, die Frage ist *ähnlich*.  Zwar ist meine Frage auch allgemein performancegetrieben, aber ich habe eine konkrete Idee im Kopf, zu der ich hoffte Meinungen zu bekommen. Dein Post enthält eher andere (auch nützliche) Vorschläge, allgemeinen Perrformanceproblemen zu begegnen, werde ich mir auch alle ansehen. Die meisten Themen davon würde ich für mich aber als "hab ich schon richtig" abhaken, ausser  event-on-change ...


Konkret war die Frage vor allem, ob man modulierende Zustände (es ist Tag, Wochenende, August, kälter als X) besser on notify per if abfragt oder zum Anlass nimmt, mit defmod etc die Defines die notified werden moduliert. Das letzteres IO erzeugt ist schon mal ein einschränkender Parameter, den man in Betracht ziehen muss.

Bzgl. ne: aber aufpassen, oft ist ne "DasWillIchNicht" weil oft kommt ein "DasWillIchNicht" dazu (Events ändern sich: Beispiel Homematic vor einiger Zeit) und dann kann das auch mal schnell "nach hinten losgehen"

Jo, das ist klar.

So oder so: Danke für eure Antworten bisher. Übrigens läuft meine Installation an sich gut, ich habe nur das Problem, dass manchmal vom Event bis zu ausgelösten Aktion 3-4 Sekunden vergehen. Ist also noch kein echtes Problem.

[Beta-User]

Was das Ändern an der config im laufenden Betrieb angeht, bin ich persönlich eher sehr vorsichtig - das wäre mir schlicht zu unübersichtlich aufzupassen, ob es "Nebenwirkungen" hat, wenn ich irgendwo anders was umbaue...

An sich sind ein paar if-Abfragen vermutlich auch nicht das Problem, und wenn "Hänger" nur sporadisch auftreten, ist das eher irgendein parallel laufendes Ding oder z.B. ein nur unter bestimmten Umständen auftretendes Funkthema.

[Zrrronggg!]

Was das Ändern an der config im laufenden Betrieb angeht, bin ich persönlich eher sehr vorsichtig - das wäre mir schlicht zu unübersichtlich aufzupassen, ob es "Nebenwirkungen" hat, wenn ich irgendwo anders was umbaue...

Das sehe ich bisher auch als grösste Gefahr.

An sich sind ein paar if-Abfragen vermutlich auch nicht das Problem, und wenn "Hänger" nur sporadisch auftreten, ist das eher irgendein parallel laufendes Ding oder z.B. ein nur unter bestimmten Umständen auftretendes Funkthema.

Nee die treten immer auf, es ist ein generelle Verzögerung, daher gehe ich davon aus, dass FHEM so ein wenig an irgendeiner Grenze läuft
Allerdings: LOAD hat die Kiste nicht echt. Und Netzproblem soweit ich das bisher gesehen habe auch nicht und HMLANs sind auf loadLvl low.

msgParseDly steht aber beibeiden HMLANs auf bis zu 6000 ms, das ist recht hoch.

[Beta-User]

Na ja, wenn es dauert, die Nachrichten erst mal an das IO zu bringen, würde ich tendenziell wohl da mal ansetzen...

Falls du noch was anderes (ZigBee, WLAN-Gedöhns...) im Einsatz hast, wäre ja die spannende Frage, ob es da ähnlich ist? Wenn nein, suchst du innerhalb des FHEM-Codes wohl an der falschen Stelle.

[MadMax-FHEM]

Load, also Belastung oder gar "Überlastung" muss nicht der Grund sein für Verzögerungen.

Auch das Warten (z.B. Netzwerk, wurde ja schon angesprochen) führt zu Verzögerungen, wenn es "blocking" implementiert ist (ohne Hintergrund-Fork)...

Da ist "load" praktisch "Null"...

Da wäre evtl. Freezemon hilfreich...

Gruß, Joachim

[Zrrronggg!]

Falls du noch was anderes (ZigBee, WLAN-Gedöhns...) im Einsatz hast, wäre ja die spannende Frage, ob es da ähnlich ist? Wenn nein, suchst du innerhalb des FHEM-Codes wohl an der falschen Stelle.

Naja, paar CULs. für SlowRF, IT und so weiter.  Da ist das Bild überall gleich.
Und die sind per USB angebunden, was gegen Netz spricht. Netz hab ich zumindest mal oberflächlich angesehen mit WireShark, da ist meist nix los.
Richtig tief hab ich da aber noch nicht gebohrt.

Und es korreliert eben mit dem Wachstum des Zoos.  Die Verzögerung wächst immer weiter, je mehr Geräte und notifies ich einführe. Kann Zufall sein.

Load, also Belastung oder gar "Überlastung" muss nicht der Grund sein für Verzögerungen.

Klar. Nur treten die Problem eben auch bei nicht mit dem Netz verbunden Schnittstellen/Geräten auf - ja ich weiss muss nix heissen.
Ich such auch an allen Fronten. Oder auch wieder nicht, denn ein echtes Problem ist es noch nicht.. Wir bewegen uns hier auch im akademischen Raum, die Installation  funktioniert an sich gut - seit Jahren. Nur je mehr sie wächst desto langsamer wird sie, obwohl FHEM mit Mühe und Not mal auf 25% CPU kommt und der Rest überwiegend idl ist. Ich bin schon froh wenn FHEM mal mehr CPU zieht als TOP selbst. Eher noch ist Mem ein Problem, da werden für fhem auch mal 40% fällig. Die Kiste (Linkstation mini) ist schon recht klein und mein Verdacht ist, das IRGENDEIN RasPi das Thema sofort löst.


Egal, ich kaue jetzt erstmal auf den diversen Tips rum, speziell eine flottes event-on-change-reading .* bei den top-geschwätzigen Dingern hab ich gerade einfach mal eingefügt und dann mal sehen, ob das was ändert. ggf ist das Schreiben des Logfiles schon das Thema.

[Sany]

Guten Morgen.

auch mein System wurde mit der Zeit und der Größe der config immer zäher, auch geschuldet dem Umstand, dass ich eher neue Dinge eingebaut/probiert habe als mich um die (vermeintlich) laufenden Sachen zu kümmern. Teilweise uralte Definitionen aus meinen Anfangstagen mit fhem. Ich habe gefühlt das Internet durchgelesen auf der Suche nach brauchbaren Informationen. Das Problem waren auch "Hänger" von ein paar Sekunden, aber durch nichts (freezwmon/apptime...) einem bestimmten Ereignis zuzuordnen.
Was bei mir geholfen hat: Ich habe sämtlich Logs überprüft und nahezu alle auf Wochenlogs umgestellt -%Y-%W.log sowie mit nrarchive auf 4 logs begrenzt. Weiterhin habe ich alle Devices auf events abgeklopft und mit event-on-change-reading und event-min-interval auf das Nötigste reduziert. Aus meiner Anfangszeit waren viele Log-Definitionen noch so, dass ich im Log per Regex angegeben habe, was gelogged werden soll. Die dazugehörigen Devices haben aber alle Events gefeuert, die sie hatten. jetzt sind diese per event-on-... reduziert und die Log-Definition zeichnet alles auf (.*).
Prima geholfen hat DOIF-Tools https://wiki.fhem.de/wiki/DOIFtools. Klingt erst mal nach "nur zu brauchen wenn ich DOIF nutze", was ja bei einigen schon fast glaubensmäßig abgelehnt wird, ist aber ein prima Tool, um eine Übersicht zu bekommen, was wie viele Events erzeugt und welche Module event-on... Beschränkungen haben oder nicht. Einfach mal "set doStatistics enable" anklicken und ein paar Stunden/Tage mitlaufen lassen. Per "get statisticsReport" gibts dann ein nach TYPE sortiertes Ergebnis und diverse andere Informationen. Devices/Module die viele Events erzeugen lassen sich damit sehr schön erkennen.

Viel Erfolg!