FHEM Performance tunen?

[Beta-User]

mach mal an dein notify das Attribute disabledAfterTrigger mit dem Wert 1....

Nicht imnmer gleich einen workaround vorschlagen! Das Problem sitzt in mehrfacher Hinsicht tiefer!

Ich bin mir sicher, dass dein Notify innerhalb kürzester Zeit dreimal getriggert wird

...wenn es nur 3x wäre...

[sn0000py]

Vielleicht kann man auf das "global:SAVE" reagieren und löschen, keine Ahnung, das ist zumindest gefühlt einfach ein übles Gewürge, mit dem ich mich nicht näher beschäftigen mag...
Variablen zu übergeben, die man nicht braucht, ist lustig... vielleicht solltest du einfach mal einen Zähler einbauen und schauen, wie oft das WIRKLICH ausgeführt wird. Meine Vermutung: noch deutlich öfter als 1 Hz...
Ahh, Weiterlesen hilft, und siehe da, NOTIFYDEF ist auch nicht gesetzt, und ab da wird es ziemlich sicher (nicht) "lustig"....

Was genau wäre das NOTIFYDEF dazu finde ich irgendwie nichts?
Diese readings in den fhem.save von dem dummy device, werden auch "nur" alle 30 minuten geladen - es ist halt praktisch im zweifelsfall dann die letzten werte zu sehen (Das sind die forecast PV Werte von einer Homepage)

[Beta-User]

Was genau wäre das NOTIFYDEF dazu finde ich irgendwie nichts?

Habe jetzt auch keine Lust zum suchen, wann das gesetzt wird, ist hier erklärt: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#notifyRegexpChanged. Die Kurzfassung: Ohne gesetztes NOTIFYDEF reagiert dieses notify eben auf ALLE Events des gesamten Systems... Würdest du dann direkt im Code prüfen, ob was "interessantes" dabei ist, wäre "nur" (ca.) 30% Performance vergeudet, aber so wird dann immer auch noch komplett durchgerechnet und weiterverteilt. Das kann in dieser Kombination m.E. nicht effektiv sein...

Diese readings in den fhem.save von dem dummy device, werden auch "nur" alle 30 minuten geladen - es ist halt praktisch im zweifelsfall dann die letzten werte zu sehen (Das sind die forecast PV Werte von einer Homepage)

Na ja, dürfte nicht "kriegsentscheidend" sein, aber auch da fragt man sich, warum das kein HTTPMOD oder jsonMod ist, sondern (vermutlich) irgendeine andere Krücke am werkeln ist, die diese Aufgabe und Infos auf mehrere Devices verteilt... Klingt einfach nach einem schlecht wartbaren System.

[sn0000py]

Habe jetzt auch keine Lust zum suchen, wann das gesetzt wird, ist hier erklärt: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#notifyRegexpChanged. Die Kurzfassung: Ohne gesetztes NOTIFYDEF reagiert dieses notify eben auf ALLE Events des gesamten Systems... Würdest du dann direkt im Code prüfen, ob was "interessantes" dabei ist, wäre "nur" (ca.) 30% Performance vergeudet, aber so wird dann immer auch noch komplett durchgerechnet und weiterverteilt. Das kann in dieser Kombination m.E. nicht effektiv sein...
Na ja, dürfte nicht "kriegsentscheidend" sein, aber auch da fragt man sich, warum das kein HTTPMOD oder jsonMod ist, sondern (vermutlich) irgendeine andere Krücke am werkeln ist, die diese Aufgabe und Infos auf mehrere Devices verteilt... Klingt einfach nach einem schlecht wartbaren System.

Ok danke, das mit dem NOTIFY werde ich mir noch anschauen.

Das dummy mit den vielen Readings kommt indirekt von nem jsonMOD, bzw es sind 3 jsonMOD die eben Daten vom webservice abgreifen, und dann werden diese 3 jsonMod in 2 dummy device aufgeteilt
(Konkret werden für die 3 Dachausrichtungen OSt, Süd, WEst die forecast geladen, und dann aufgeteilt in Fronius und victron daten dazu wird gerechnet Victron = 1*West+0.4*Süd+0.6*Ost    Fronius ? 0.6*Süd+0.4*Ost) und das muss dann für jedes Reading gemacht werden

[Beta-User]

dazu wird gerechnet Victron = 1*West+0.4*Süd+0.6*Ost    Fronius ? 0.6*Süd+0.4*Ost) und das muss dann für jedes Reading gemacht werden

Danke für die Erläuterung. Wie gesagt, es ist - ausgeführt "alle halbe Stunde" - sicher nicht so, dass das das System ausbremst (auch nicht beim Starten), aber beim Lesen irritiert mich trotzdem das "muss" für "jedes" Reading. Es ist sicher nicht falsch, sich (häufig benötigte) Berechnungsgrößen irgendwo zwischenzuspeichern und ggf. auch anzeigen lassen zu können, aber ob es wirklich ein "muss" ist, musst du selbst wissen.
Manchmal ist es erfahrungsgemäß halt sinnvoll, mal die ganze Kette zu betrachten und sich die Frage zu stellen, ob "althergebrachte" Glaubenssätze ("muss") denn wirklich einer Überprüfung standhalten, denn nicht eben solten "tickt" FHEM eben konkret doch anders, als man das so in Erinnerung hatte (qed).

[sn0000py]

So noch mal die Fragen wegen dem langen starten von FHEM?

Kann ich da noch was machen (das attr initialUsbCheck disable 1 hat leider nichts gebracht)

bzw wie lange dauert das bei euch?

Bei mir bleibt das Teil relativ lange so stehen. (also so ca 2-3 minuten)

[rob]

Musst Du zufällig auch custom packages vorinstallieren lassen wie hier beschrieben https://github.com/fhem/fhem-docker#add-custom-packages?

Für meinen Roomba (99_RoombaUtils.pm) muss ich das machen

Code Auswählen Erweitern


-e CPAN_PKGS="Device::Firmata Math::Polygon::Calc Math::ConvexHull"


Installieren per cpan braucht halt seine Zeit. Der Start vom FHEM-Docker dauert bei mir dadurch bis zu 7 Min. insgesamt.

[sn0000py]

nein ich habe keine custom packages zu installieren.
Im Moment läuft noch alexa direkt auf der docker Installation (sprich das braucht nach dem update immer ein sudo npm install -g alexa-fhem) aber das habe ich bei dem log noch nicht gehabt und wurde erst nach dem starten dann ausgeführt
und kommt nun in ne eigene docker-image

7 minuten oho - das ich ja mal echt lange, vielleicht sind dann die 3 minuten bei mir normal?

[rob]

...vielleicht sind dann die 3 minuten bei mir normal?

Würde ich Dir nicht so pauschal ins Ohr flüstern wollen. Wenn ich ein Testsystem starte (quasi frische Installation von FHEM) geht es ratzfatz.
Hängt imho also von der individuellen Situation ab. Ich denke, weitere Rückmeldungen könnten Dir mehr Aufschluss geben

[Beta-User]

Wenn es speziell um den Start geht, und du ggf. MQTT2_SERVER im Einsatz hast, könnte das Löschen der retain-Einträge und das nicht-Speichern beim Beenden des betreffenden Readings helfen (siehe die entsprechenden Setter und Attribute bei M2S).

[sn0000py]

nein habe keinen MQTT2-SERVER im einsatz (nur einen externen der in einem eigenen docker-Image läuft)

gibt es noch eine möglichkeit das logging beim starten zu verfeinern?

Bei mir bleibt er die meiste Zeit hier stehen

Code Auswählen Erweitern

6. Enforcing file and directory permissions for /opt/fhem ...

[rob]

Wenn er wirklich an dem Punkt hängt, der dort steht - ist denn Dein Volume für /opt/fhem sehr umfangreich?

Entere ich meinen Container und lasse dort ein

Code Auswählen Erweitern

du -hc --max-depth=1 /opt/fhem/los, erhalte ich als Total 2,5GB, wobei 2,3GB allein auf /opt/fhem/log entfallen.

Und wenn ich

Code Auswählen Erweitern

find /opt/fhem/ | wc -l ausführe, bekomme ich 8281.

Ist das bei Dir ggf. deutlich mehr und deshalb ein möglicher Verzögerer beim Ändern der File-Attribute?

[sn0000py]

Ok danke das wars, hatte ein zusatzliches volume ins /opt/fhem/cache eingebunden, wo dann unterverzeichnisse mit 60000 Files waren (in diversen dirs)
ohne dem startet er jetzt wieder so wie es sein sollte
Danke