Während EOD ist Dashboard nicht erreichbar

  • NUC Generic x86-64

  • CPU: Intel Pentium N3700, 4x 1.60GHz(2.4Ghz Burst), 2MB

  • InstallationsmethodeHome Assistant OS

  • Core2026.3.0

  • Supervisor2026.02.3

  • Operating System17.1

  • Solar Forecast ML Version 18.0.0

  • Problem auch schon vor Update 18.0.0.

Ich wollte hier nochmal das Thema mit Zugriffsproblemen in der Zeit während EOD aufgreifen.

Ich hab jetzt ein paar Tage um 23.30Uhr beobachtet, dass beim Start von EOD für ein paar Minuten das Dasboard nicht erreichbar ist.

Gestern z.B. hatte ich 16:59 Minuten EOD-Duration und davon war von 23.30Uhr bis 23.39Uhr das Dashboard nicht erreichbar. Es läd und läd, aber es passiert nicht und plötzlich geht es wieder.

Prozessorleistung geht nicht besonders hoch. von 10% auf 30%. Ähnlich auch der Arbeitsspeicher.

Ansonsten läuft SFML auch super und die Genauigkeit ist seit dem letzten Update auch wieder auf Kurs. Und sonst kann ich auch nichts anderes bisher feststellen.

Haben andere auch dieses Phänomen?? Danke??

Was hast du für eine CPU?

Das das System Träger ist in der Zeit, das haben ich und andere auch. Aber gar nicht laden ist bedenklich.

Kann aber zur 18er noch nicht viel sagen, da ich noch abwarte mit dem Live System auf 2026.3.1 zu gehen und damit auf V18.

Auf meinem Pi5 läuft zwar schon 2026.3.1. Aber ich kann dir nicht sagen wie er sich verhält, da ich geschlafen habe. :sweat_smile:

Mal gucken ob ichs nächste Woche mal testen kann, wie der Pi sich verhält.

Sieht bei mir in VM auf Synology DS220+ mit 2 CPU-Kernen und 4GB (ansonsten wie oben) praktisch identisch aus. Läuft ansonsten wie geschmiert.

Hab jetzt die fehlenden Infos auch oben mit dazugefügt.

-Phänomen war schon vor Update 18.0.0

-CPU: Intel Pentium N3700, 4x 1.60GHz(2.4Ghz Burst), 2MB

Also ich kann dir sagen, das die CPU nicht die schnellste ist.

Ein N100 ist 4-5x schneller! (reine Rechenleistung)

In der Theorie ist ein Pi5 auch wesentlich schneller.

Ich gehe davon aus, das da eine Limitierung von der CPU kommt.

Die CPU Last von ca. 25-30 % (wie bei allen anderen auch) kann ich mir nur damit erklären, daß HA nur einen Kern läuft und da die Integration im HA Thread läuft und in keinen eigenständigen Container läuft (wie bei Apps). Ist das die Limitierung.

@Tom-HA bitte um Korrektur wenn ich falsch liege.

1 „Gefällt mir“

Hallo @paul_meyer

Ein Satz vorweg.. ich bin großer Fan von Synology-NAS Systemen (habe selber 3 im Einsatz!!) - unverwüstlich, tolle Konfiguration, stabil ohne Ende.. ABER es sind NAS und gerade die kleineren / günstigeren Synology sind “NAS” und weniger Hosts.. ein Manko! → Da sind AsusTor und Qnap deutlich bessere aufgestellt, aber eben auch z.T. instabiler!

Kurzum:
Der Haupt-Flaschenhals in deinem Setup ist die CPU der DS220+ – der Intel Celeron J4025 (Gemini Lake Refresh, 2019 → Entwickelt 2017).
Das ist ein Dual-Core-Prozessor (2 Kerne / 2 Threads) mit Basis-Takt 2,0 GHz und Burst bis 2,9 GHz, aber sehr begrenzter Single-Thread-Leistung und ohne AVX2-Unterstützung.
Der Prozessor ist primär für NAS-typische Aufgaben (Dateispeicherung, -transfer, Medien-Transcoding) optimiert – nicht für anspruchsvolle Virtualisierung oder rechenintensive Anwendungen.

Home Assistant selbst hat offiziell immer noch sehr niedrige Mindestanforderungen (ca. 1,5–2 GHz CPU und 4 GB RAM für ein Basis-Setup), läuft aber in der Praxis 2026 mit modernen Features deutlich ressourcenintensiver:

  • Viele Integrationen, Add-ons (z. B. Zigbee2MQTT, ESPHome, MQTT, Frigate, Energy-Dashboard)
  • Lokale KI-Funktionen (z. B. Assist-Pipeline mit Speech-to-Text/Text-to-Speech, lokale Modelle via Ollama/Wyoming, Object/Person-Detection)
  • Neueres Dashboard (Home/Overview als Standard), Python 3.14, parallele Automatisierungen, Matter/Thread-Unterstützung

Hierfür empfehlen Community und Praxiserfahrungen inzwischen klar mindestens 4–8 GB RAM + Quad-Core-CPU (idealerweise moderner Architektur wie Alder Lake-N oder neuer) für ein flüssiges Erlebnis.
Dein Setup läuft Home Assistant in einer VM über den Virtual Machine Manager (VMM) der Synology – das bringt zusätzliche Probleme mit sich:

  • Der Hypervisor von Synology hat spürbaren Overhead (besonders bei I/O und CPU-Scheduling).
  • Die NAS-Funktionen (SMB/NFS-Freigaben, Backups, evtl. Plex/Photos usw.) laufen parallel und teilen sich die ohnehin schon sehr sehr schwache CPU – selbst bei RAM-Upgrades (z. B. auf 6–10 GB).

Fazit:
Dein aktuelles Setup (DS220+ mit J4025 in VM) ist für ein grundlegendes Home Assistant noch machbar, aber für eine moderne, komfortable Nutzung – insbesondere mit Erweiterungen im Bereich lokaler KI und erweiterter Automatisierung – deutlich unterdimensioniert.
Es handelt sich nicht um ein Konfigurations- oder Code-Problem, sondern um eine klare Hardware-Limitierung (CPU-Architektur, Kerne, Virtualisierungs-Overhead).

Leider kann ich dir hier technisch nicht weiterhelfen, ohne dass die Hardware getauscht wird. Realistische Alternativen wären z. B.:

  • Dedizierter Mini-PC (z. B. mit Intel N100/N305, 8+ GB RAM, HA OS direkt installiert)
  • Stärkeres NAS-Modell mit besserer CPU (z. B. DS9xx-Serie mit Ryzen/Intel Core)

Zara

1 „Gefällt mir“

Das konnte ich gestern beim EOD auch für wenige Sekunden feststellen. Evtl. lässt sich da durch QoS-Einstellungen (reservieren von CPU-Threads) noch was verbessern? Bisher war das für mein HA (ohne KI) noch nicht notwendig und daher aus.

VM auf DS920+ (Intel Celeron J4125)
20 GB RAM / 512 GB SSD
HAOS 17.1
HA 2026.2.3
SFML Version 16.8.4

Die Host-CPU ging dabei auch nicht über 30-40% .. normalerweise dümpelt die so bei 11-12% rum.

EOD dauert bei mir meist so zwischen 10~20 min.

Moin Tom,

besten Dank für die außerordentlich ausführliche Antwort. Wo nimmst du nur die Zeit her? (Coffee ist raus).

Hatte schon befürchtet, dass es langsam eng wird auf der DS220+. Ist halt viel dazugekommen über die Jahre. Dein super spannendes Projekt beendet nun die HA-Zeit dort in VM und läutet die Ära von bare metal ein. Hoffe, mein Deal-Alarm zu Mini-Pcs spuckt die Tage mal was Brauchbares aus.

Die DS220+ wird mir sicher noch lange gute Dienste als Datengrab und für paperless-ngx leisten.

Beste Grüße aus dem heute eher bewölkten Wattenbek und danke für deinen Einsatz für uns alle!

Paul

4 „Gefällt mir“

Ich reihe mich mal hier ein. Mit meinem Pi5 ist beim EOB Lauf auch das Dashboard nicht erreichbar und manche Sensoren haben Aussetzer.

1 „Gefällt mir“

Das war bei meinem System mit Celeron JD4105 genauso. Bei solchen massiven Beeinträchtigungen hört der Spaß für mich auf. Ich habe eine ganz einfache Lösung dafür gefunden :wink: Nach 3 Monaten Beta-Test habe ich letzte Woche SFML und alle dafür angelegten Sensoren komplett gelöscht :nerd_face: Ich werde mich für diese Solar Prognose Spielerei (BKW ohne Speicher und dynamischen Stromtarif) garantiert keine neue Hardware anschaffen.

3 „Gefällt mir“

Hi, tolles Projekt! Respekt vor der ganzen Arbeit Tom. Aber tatsächlich scheinbar für schwächere Hardware schwierig. Bei mir reagiert das System auch kaum noch während des EOD (Intel j5005). Das System habe ich bewusst eingesetzt, da es extrem energiesparsam ist (5-6W).

Hallo VSA,
ich bin da schon dran - Ich teste gerade den Event-Loop von HA zu verbesseren.. der ist dafür vernatwortlich.

Ein abschließendes Fazit kann ich aber noch nicht geben.. - irgendwo gibt es physikalische Grenzen. Alle DSM mit AMD-Prozessoren funktioineren, also auch PI`s die nicht schon eine hohe Grundlast haben.

1 „Gefällt mir“

Ich schließe mich dir an und hab mich heute auch von diesem Projekt verabschiedet.

Hier meine Entscheidungspunkte:

  1. mein NUC hat auch diese Probleme bei EOD und ich möchte meine Hatdware auch nicht ändern wegen Verbrauch
  2. Beim letzten bewölktem Wetter waren die Prognosen viel zu hoch. Nachdem Update auf 18.0.0 wurden die Prognosen recht gut, aber auch das Wetter war top. Nun ist das Wetter wieder gleich (Wolken, Luftdruck, Luftfeuchtigkeit und Solareinstrahlung) vor dem Update und die Prognosen sind wieder 10kWh bis 15kWh zu hoch. (Es wurde an den Sensoren nichts geändert)
  3. Zudem bin ich schon seit ca. 7 Wochen dabei und hab da jetzt echt viel Zeit investiert, aber dafür ist mir das Ganze momentan noch zu ungenau und instabil.

Trotzdem vielen Dank an Tom und das ganze Team für die Arbeit

1 „Gefällt mir“

@Larrythehammer @GooglyEyz

Vielen Dank für euer ehrliches und sachliches Feedback, dass weiß ich sehr zu schätzen und nehme es gerne an!

Ich wünsche Euch gutes gelingen mit euren eigenen Projekten und verbleibe mit besten Grüßen und Wünschen…

Zara

1 „Gefällt mir“

Ich habe wegen der Performance-Empfehlungen vor drei Monaten HA von Proxmox (VM) auf einen NUC (Bare Metal) migriert. Trotzdem geht das System ab 23:30 Uhr in die Knie, wie berichtet.

Ich warte noch das Update 18.2.0 ab. Sollte es damit nicht besser werden, werde ich mich auch komplett von SFML verabschieden.

Hallo @ottokar

ich verstehe den Frust und auch das Problem. Gefunden habe ich es auch.. es ist nicht die Leistung, nicht die i/o es ist der sogenannte Event-Loop von Home Assitant selber, der besonders in der aktuellen Version von HA noch Probleme macht. Das führt dazu, dass Sensoren für wenige Sekunden (ja nach HW) die Verbindung verlieren, wenn ein Event läuft. Es betrifft nicht nur " Mich" sondern alle großen Integrationen, die Daten verarbeiten, pullen, .. es ist kein reines SFML Problem

Ich bin an dem Thema dran, bin ehrlich gesagt aber auch im Zwiespalt.. zum Einen liegt es nicht an der Integration sondern an HA selbst und zum anderen weiß ich nicht ob HA da aktuell dran arbeitet. - Ich bin da gerade “on-Hold” (habe schon die HA Dev angeschrieben und den Fehler gemeldet) .. aber das Thema " Event Loop" wird gerade nicht als Priorität gesehen, da es noch zahlreiche andere BUGS in 2026.3 gibt.. :frowning:

Ich halte euch hier auf dem Laufenden!

Weiterführende Info:

In Home Assistant ist der Event Loop (Ereignisschleife) das schlagende Herz des Systems. Da Home Assistant auf Python und der Bibliothek asyncio basiert, ist dieser Mechanismus dafür verantwortlich, dass hunderte von Automatisierungen, Sensoren und Geräten gleichzeitig laufen können, ohne dass das System einfriert.

Stell dir den Event Loop wie einen sehr effizienten Kellner in einem Restaurant vor: Er nimmt Bestellungen auf, gibt sie an die Küche weiter und bedient in der Zwischenzeit andere Tische, anstatt untätig vor der Küchendurchreiche zu warten, bis das Essen fertig ist.

Das aktuelle Problem:
Viele Integrationen kommen “noch” nicht mit dem aktuelle HA 2026.3x klar und sterben still im Hintergrund und werden dauernd neugestartet, das blockiert den “Loop” fällt im Alltag aber nicht immer auf (dauernder Restart im Hintergrund) wenn dann eine Integration wie SFML Resourchen anforderd ist nicht genügend Leistung mehr da..

Fazit:
Es ist nicht eindeutig was den Event-Loop träge werden lässt.. es gibt zig möglichkeite, zig Integratonen,.. eines ist aber sicher: SFML ist nicht das auslösende Moment sondern ein Symptom.. für:

a) der Event Loop im HA ist defekt / buggy → meine These
b) eine andere Integration blockiert ihn still weil sie noch nicht 100% 2026.3x fähig ist

Mit der HW hat das erstmal nur zweitranig was zu tun..

Wie ihr selber prüfen könnt.. :

  • Schaut ins Protokoll … wenn ihr eine Menge Einträge habt " ich konnte dies nicht, ich konnte das nicht".. ist das ein sicherers Zeichen
  • Wenn Ihr im HA " Blocking-Calls" habt.. unbedingt beheben ggf. den Entwickler anschreiben und berichten das die Integration den HA lahmlegt - lasst euch nicht täuschen ein Detected Blocking ist eine miese Sache, auch wenn der HA erstmal weiterläuft!
8 „Gefällt mir“

Vielen Dank für deine ausführliche Erklärung. Das hab sogar ich verstanden :rofl:

Aber bei mir war das Problem auch schon vor dem Update auf HA 26.3 und auch vor dem Update auf 18.0.0

Rückmeldung von mir noch hierzu:

Mein Umstieg von VM auf Synology DS220+ auf Bare Metal auf Lenovo M910q, Core i7 2,8GHz, 16GB, NVME-SSD, (war mir der Spaß wert) hat die EOD-Zeiten von 12 - 30 Minuten auf 1 bis 4 Minuten reduziert. System bleibt während EOD verfügbar und Sensoren reißen nicht ab währenddessen.

1 „Gefällt mir“

Update zu der Problematik:

Es ist weiterhin so, dass ich den Fehler / das Verhalten auf keinen meiner Testsysteme nachbilden konnte. → aber da ich eure BUG`s und Meldungen sehr ernst nehme, leider immer noch keine Rückmeldung von den HA-DEV bekommen habe, ich nicht spekulieren möchte.. habe ich den EOD prophylaktisch umgebaut:

Durch die Umstellung von synchronen CPU-Intensiven Tasks auf Executors und die konsequente Nutzung von Cooperative Multitasking (Yields) wird die Systemstabilität während des EOD deutlich verbessert.
Der Event Loop während der KI-Berechnungen auf Sensor-Events reagieren.

Da ich es leider nicht selber testen kann → keines der Testsysteme auf das ich direkten Zugriff habe, zeigt das hier von @ottokar , @GooglyEyz @Larrythehammer beschriebene Problem ←
bitte ich euch es selber zu beobachten.

FIX ist im kommenden Update.

So der FIx greift.. man kann gut sehen, dass die i/o Performance und auch Systemlast im Mittel nicht mehr so sehr ansteigt. Zwar wird der EOD " länger" aber die Pausen zwischen den Schritten geben dem Event-Loop genügend Zeit sich zu stabilisieren.

4 „Gefällt mir“