Wenn es das richtige Diagramm ist, sehe ich da keine Änderung. Ich habe am 19.08. die SFML-Datenbank in _old umbenannt und neu angefangen. Änderungen an der Prozessorauslastung kann ich da nicht sehen.
Müsste sich mal ein PI user anschauen bzw. Testen.
Auf meiner Proxmox VM macht das nicht viel aus .Vieleicht + 2 bis 3%
Gruss
Ich habe auf meinem Pi 5, EAI nicht aktiv. Muss ich mal die Tage testen.
Läuft bei dir GPM und hast du einen dynamischen Stromtarif konfiguriert?
Welche Module von EAI nutzt du? Wärmepumpe, Wallbox und Wetter?
Bei mir ist es spannenderweise mit Verwendung von der Wetterfunktion WFAI deutlich erhöht. Ohne sind es um die 10% (Wallbox und Wärmepumpe an) mit Wetter eher so um 24%
Wen EAI komplett deaktiviert ist, dann sind es so 3%.
Habe auch eine Wetterstation. Bin etwas ratlos wie das zusammenhängt.
An sich läuft bei dem (fast) alles, also GPM, WFAI und bei EAI die Wetter Inteligence & WB.
Pi-Hole und weitere netzwerkbedingten Sachen konnte ich bereits ausschließen. So ein bisschen stehe ich hier auf dem Schlauch, warum das bei der Wetter-Intelligenz auftritt.
Kannst du mal mit “Glances” oder Ähnlich schauen welcher Prozess da wirklich die Auslastung hoch haut?
bei Glances sehe ich leider keine Prozesse.
Vor der Aktivierung von der Wetter Intelligenz:
Nach der Aktivierung der Wetter Intelligenz:
Ich kann lediglich sagen, dass der homeassistant container an der Maximallast mit über 100 % rankommt.
EDIT:
anbei der Ausschnitt aus dem Befehl top sortiert nach Prozessorauslastung:
Hallo @greteOne,
Ich habe das mit Vergleichssystemen gegengeprüft: Pi 5 (SSD + 8GB RAM), gleiche EAI‑Version, ebenfalls mit Wetterstation und aktiver Wetter‑Intelligenz. Dort tritt das nicht auf. Es liegt also nicht an der Wetter‑Intelligenz an sich, sondern an einer Kombination, die bei dir anders ist als auf den Vergleichssystemen. Was ich aber so nicht anhand deines Screenshots erkennen kann… aber ich habe eine Vermutung.. AUSDRÜCKLICH Vermutung!
Was in deinem Screenshot zu sehen ist: Der Container homeassistant geht von ~34 % auf ~102 % – das ist exakt ein Volllast-Kern. Der Host bleibt mit 26 % ruhig, da er vier Kerne hat. Das ist ein typisches, von mir oft kritisiertes Verhalten der Single-Thread Architektur von Home Assistant im Event-Loop. HA nutzt nur einen Kern, egal wieviel das System hat.
Dass die Kurve über die Nacht langsam ansteigt, zeigt, dass eine wachsende Datenmenge immer wieder komplett verarbeitet wird. Hier scheint des Pudelskern zu liegen. - VERMUTUNG
Die Wetter‑Intelligenz reagiert auf jede Aktualisierung der Stations‑Sensoren, die in SFML gemappt sind, und gleicht dann Prognose und Messwerte ab. Liefert die Station ihre Werte gesammelt alle 60 s, ist das unkritisch.
Liefert sie die Sensoren einzeln und gestaffelt alle paar Sekunden, läuft dieser Abgleich praktisch ununterbrochen – und das ist mit deiner Beobachtung „ohne Wetter ~10 %, mit Wetter ~24 %“ deckungsgleich. Dazu kommt, wie viel Historie deine Station im Recorder hat, dass kann ich aber anhand des Screenshot nicht beurteilen.
Scheint so, als ob die Historie immer wieder neu aufgebaut werden muss… alles das kann ich leider nicht aus der Ferne beantworten.
Was mich wundert ist das die von Dir benutzte Integration der Wetterstation irgendwie nicht rund läuft! Welche Wetterstation und welche Integration nutzt du? Auch würde mir an deiner Stelle mal das Musik-Dingensbumens mal genauer ansehen, das scheint ebenfalls nicht sauber zu laufen.
Mehr kann ich leider aus der Ferne nicht dazu sagen..
Zara
Hallo Tom,
danke für deine Zeit und Analyse. Ich denke, du bist da auf der richtigen Spur.
Ich betreibe eine Ecowitt WS90, welche über die Ecowitt Integration angebunden ist. Soweit so unproblematisch vermutlich.
Die Werte fließen jedoch alle 8 Sekunden in HomeAssistant rein, weswegen vermutlich die permanente Auslösung erfolgt und auch der Rekorder entsprechend viele Datenpunkte hat.
Da mein Rekorder bereits die entsprechenden Datenpunkte gesammelt hat, wird es vermutlich nichts bringen jetzt einfach das Aktualisierungsintervall zu reduzieren?
Liebe Grüße
greteOne
@greteOne Kein Problem, gern!
Ecowitt pusht per Webhook alle Sensoren gleichzeitig, der 2‑s‑Debounce fasst den Burst zusammen – aber die WS90 hat Ultraschall‑Windsensoren (wenn ich mich nicht täusche), der Wert ändert sich bei praktisch jedem Push.
Ergebnis:
Ein voller Zyklus alle 8 s, (alles wird neu geschrieben) das wird der springende Punkt sein.
Das könnte den Overhead verursachen und deinen PI stark bremsen. Der Treiber ist also VERMUTLICH der Auslöse‑Takt.
Lösung (TEST):
Intervall hoch → Last runter, ohne Datenbank anzufassen.
Damit würde der PI mehr Luft zum Atmen bekommen, mehr Raum für andere Prozesse.
Ich habe gerade mal bei mir geschaut, mein Intervall (EcoWitt) ist 1 Min. Wenn Du es auch so einstellst, hast Du keine Einbußen aber reduzierst die Schreibvorgänge massiv! Das wäre eine generelle Anpassung auf die HW des PI und hätte nichts mit EAI zu tun.
Übrigens:
EAI reagiert auf jede Wetterveränderung, soll es ja auch. EAI macht das aber in einem 15Min Intervall.
Zara
Hallo @Tom-HA,
nur um sicherzugehen welches Update Intervall du auf 1 Minute eingestellt hast:
Das erste Update-Intervall ist zu finden unter Ecowitt App → Geräteeinstellung → weiteres.
Da wäre der kleinste Wert 1 Minute.
Wenn ich dort auf “Wetterdienste” → “Benutzerdefiniert” klicke, dann habe ich dort ein Upload Interverall von 8 Sekunden zu Home Assistant eingestellt. Dies hast du auf 60 Sekunden eingestellt?
Hallo,
ich nutze bei mir seit dem 15.August die Shelly Version der WS90 über Bluetooth, auch dort werden die Werte häufig aktualisiert. Allerdings hab ich bisher leider kein Intervall zum einstellen gefunden.
ganz genau.. das nimmt viel Druck von schwachen Systemen und dem Recorder. Bitte auch nicht die Sensoren ausklammern! Dann erstellt EAI ein eigene Historie.
super finding!
Die Auslastung des Prozessors ist deutlich reduziert!
Ecowitt im Browser aufrufen: „weather service“ aufrufen - ganz unten ist der Abrufintervall einstellbar.
Bei der Shelly Version leider nicht.
Puhh.. danke für die Rückmeldung! - Dann war meine Vermutung ja doch nicht ganz falsch!