dewpoint: Nach Update deutlich CPU-Lastiger

[heikoh81]

Hallo zusammen,

ich schreibe auf Bitte von rudolf, da ich ein Performance-Problem nach einem Update von dewpoint festgestellt habe.
(siehe auch unsere Diskussion: https://forum.fhem.de/index.php/topic,83537.30.html).

Ich hatte in meinem fhem bislang folgende dewpoint-Definition:

Code Auswählen Erweitern


define dewpointToAllDeviceReadings dewpoint dewpoint .* temperature humidity dewpoint
attr dewpointToAllDeviceReadings room Temperaturen


Mit Rev. 6757 gab es keine Performance-Probleme, d.h. fhem war weiterhin sehr flink.
Nach Update auf Rev. 15551 dagegen wurde mein gesamtes fhem bei ca. jedem 2-3 Klick komplett lahmgelegt. Die Perl-Auslastung ging auf 100% hoch.

Ich möchte an dieser Stelle nicht über die Sinnhaftigkeit meiner Regex-Definition diskutieren.
Dass diese alle Devices umfasst, hatte rudolf bereits festgestellt.
Worum es mir geht ist, dass mit Rev. 6757 die Performance trotz dieser Definition noch sehr gut war, mit Rev. aber nicht mehr.
D.h. im Code von dewpoint wurde irgendetwas geändert, was zu einer deutlich ineffizienteren Abarbeitung der dewpoint-Berechnung führt. Dies könnte auch bei anderen Benutzern mit dewpoint-Definitionen zu Problemen führen, weswegen ich dies hier poste.

Da ich selbst dewpoint nicht weiterverfolgt habe in meiner Haussteuerung, waren für mich die Performance-Probleme durch Löschen der Definition beseitigt. Gerne kann ich aber zukünftige Code-Änderungen in meiner recht umfangreichen Installation (3000+ entities) testen.

Viele Grüße,
Heiko

[CoolTux]

Man kann sich ja die Unterschiede zwischen den Revisionen im SVN anschauen.

[heikoh81]

Ja, mit diesem Post soll ich ja den Entwickler von dewpoint erreichen.
Ich bin kein Programmierer, somit kann ich den Fehler nicht finden.

Wenn es das falsche Forum ist, bitte verschieben.
In den Development-Foren konnte ich keine neuen Beiträge erstellen...

[CoolTux]

Hier liest Du nach im welchen Forum dewpoint besprochen wird
https://svn.fhem.de/trac/browser/trunk/fhem/MAINTAINER.txt

Danach verschiebst Du selbst Deinen Beitrag. Ganz unten ganz links THEMA VERSCHIEBEN

[heikoh81]

Thema gemäß maintainer.txt ins Forum "Automatisierung" verschoben.

[heikoh81]

Der Maintainer von dewpoint hat sich bislang noch nicht hier geäußert.
Sollte dies laut maintainer.txt nicht nach spätestens 3 Wochen geschehen?

Ich als Anwender kann nicht den Code aus dem SVN vergleichen, oder gar im Code erkennen, was jetzt die höhere CPU-Last erzeugt.

Code Auswählen Erweitern

The third column specifies, where/how the maintainer should be contacted. If there is no reaction from the mainainer within 3 weeks, then rudolfkoenig (forum.fhem.de/FHEM Forum) should be contacted, in order to assign a new maintainer.

[blofield]

Dann lass' das Modul weg und implementiere via 99_myUtils, wie hier beschrieben:
https://wiki.fhem.de/wiki/Dewpoint#Variante_.C3.BCber_99_myUtils

klappt super, performant und seit langem stabil

Gruß
blofield

[Beta-User]

Der Maintainer von dewpoint hat sich bislang noch nicht hier geäußert.
Sollte dies laut maintainer.txt nicht nach spätestens 3 Wochen geschehen?

An sich ja, aber wie ich neulich lernen durfte ist es so, dass das Verschieben der Beiträge nicht immer optimal ist.
In der Regel ist es das richtige Vorgehen, aber nicht zwangsläufig bei echten PR's, die den Maintainer erreichen sollen:

Es werden beim Verschieben nämlich keine Benachrichtigungen versandt. Wer also z.B. nur Benachrichtigungen aus einem bestimmten Forumsbereich erhält, bekommt auch keine Benachrichtigung. Ein Maintainer, der ggf. diese Vorgehensweise wählt, bekommt daher uU. einen entsprechenden PR gar nicht mit (u.A. Rudi selbst hält es so).

Bitte daher für diesen Fall einen Doppelpost anlegen (kannst ja hierhin verlinken und - ebenfalls ausnahmsweise - den anderen Thread gleich wieder zu machen (oder umgekeht: diesen hier zu machen)).

Gruß, Beta-User

[FunkOdyssey]

Ich bin jetzt verwirrt. Sollte ich dewpoint nun löschen, wenn ich selbst noch keine Nachteile bemerkt habe?
Sollte man das im Auge behalte? Oder wie ist der aktuelle Stand nun?

[pc1246]

Moin zusammen
Ich habe da auch eine Frage dazu. Betrifft das auch doDewpoint bei z.B. Lacrosse?
Gruss Christoph

[hotbso]

An sich ja, aber wie ich neulich lernen durfte ist es so, dass das Verschieben der Beiträge nicht immer optimal ist.
In der Regel ist es das richtige Vorgehen, aber nicht zwangsläufig bei echten PR's, die den Maintainer erreichen sollen:

So war es auch, habe diesen Thread heute zufällig gefunden. Daher bitte nach Verschieben eine PM schreiben.
Werde mich des Problems annehmen.

[heikoh81]

So war es auch, habe diesen Thread heute zufällig gefunden. Daher bitte nach Verschieben eine PM schreiben.
Werde mich des Problems annehmen.

Danke, dass du dir dieses Problem ansiehst.
Ich hatte das Neuerstellen des Themas wie beschrieben auf meiner ToDo-Liste, bin aber in all der Zeit nicht dazu gekommen.

Ich bin jetzt verwirrt. Sollte ich dewpoint nun löschen, wenn ich selbst noch keine Nachteile bemerkt habe?
Sollte man das im Auge behalte? Oder wie ist der aktuelle Stand nun?

Ich denke nicht, dass du es löschen musst.
Die Konstellation bei mir ist die, dass ich sehr viele Dummies habe, insgesamt über 3000+ entities.
rudolf hat noch nie eine so große FHEM-Installation gesehen, also ist mein Fall sehr speziell.
D.h. unter Umständen bemerkst du die höhere CPU-Last des dewpoint gar nicht.

Mir ging es halt darum: In der alten Revision ging es performanter, also muss ja irgendwas verändert worden sein zum CPU-Lastigeren.
Für alle, die das Modul noch verwenden, wollte ich darauf hinweisen, damit es bei denen nicht irgendwann zum Problem wird.
Ich selbst hatte mit dem Taupunkt nur experimentiert, verwende diesen mometan aber nicht, so dass ich auch das Modul momentan nicht benötige. Aus diesem Grund konnte ich für mich das Problem durch entfernen des dewpoint-Devices beheben...

Viele Grüße,
Heiko

[hotbso]

Die Performance von dewpoint sollte jetzt wieder auf dem alten Stand sein.

Grundsätzlich gilt:
Dewpoint untersucht von allen Devices, die dem Regexp entsprechen, alle Events nach Temperatur und Feuchte.
Daher sollte der Regexp natürlich immer möglichst spezifisch sein.