das ist meines wissen eine Limitation von HA.
Da SFML als Integration ausgeführt wird, läuft die Berechnung im HA “Container”
Für Multithreading müsste das alles als App laufen.
Bitte um ggf. Berichtigung.
1 „Gefällt mir“
Das macht HA Bare-Metal selbstständig. Aber genau hier liegt der immer noch nicht gelöste BUG in HA-2026.3.x → bis heute (Event-Loop).
Ich möchte mich dazu nicht näher einlassen, da ich massiv mit einem HA-DEV-Admin aneinandergeraten bin als ich am Code und Kernel-Code den Nachweis erbracht habe.. das es hier ein immer noch nicht gefixtes Problem im Core gibt der sich nun seit mehreren Versionen durchzieht und nicht mehr zeitgemäß ist:
Der kritische Pfad (der Event-Loop) bleibt single-threaded und wird nicht automatisch auf mehrere Cores verteilt, wenn er überlastet ist.
Zusatz-Info (persönlich)
Wenn HA hier moderne und seit Jahren bewährtes Design folgen würde.. würde HA plötzlich HW-Anforderungen haben und nicht mehr auf Oma´s Rechenschieber laufen.. das ist also vermutlich ein Kompromis. ABER würden die Herren und Damen einen HW-Check einbauen wäre das Problem gelöst und HA würde die Vorhandene HW nutzen. So macht es aktuell keinen Sinn große Prozessoren zu nutzen, da sie von HA nativ nicht angesprochen werden.. SAD!
Wer den SFML-Beta-Thread kennt, weiß, dass ich schon früh einen HW-Check eingebaut habe, um Last optimal zu verteilen.
Bei HA nutze ich aktuell Await-Steps als Workaround, damit der Event-Loop nicht blockiert und das System atmen kann – auch wenn das Ressourcen verschwendet.
Große Prozessoren bringen daher im reinen HA-Ökosystem oft weniger Vorteil als erwartet.
Das ist aus meiner Sicht ein Design-Kompromiss mit Nachteilen. AMD-Prozessoren scheinen deutlich besser zu performen als vergleichbare Intel-CPUs – vermutlich weil sie bei Add-ons und Nebenprozessen (die mehrere Cores nutzen) stärker sind. Ob sie ‚an HA vorbei‘ besser skalieren, und intern doch mehrere Cores nutzen. Die Benchmarks dazu sind auch im SFML Beta-Thread zu sehen.. kann ich nicht sicher sagen.
Der HA-Core-Event-Loop ist single-threaded und skaliert nicht automatisch auf mehrere Cores. - Korrekt!
Gut geschriebene Integrationen können und sollen aber sehr wohl den Thread-Pool und damit mehrere Cores nutzen, um den Loop nicht zu blockieren.
Das machte SFML auch bis zum Update von HA2026.3.x seit dem gibt es einen BUG im Core von HA (HA läuft noch primär mit GIL).
SFML nutzt standartmäßig immer: async_add_executor_job und nutzt Blocking/Sync sowie echte async-Bibliotheken (aiohttp statt requests)
Fazit die Aussage ist nicht ganz korrekt.. ABER trifft auf vermutlich 98% der Integrationen zu, die sich “stumpf” auf dem Event-Loop (single-core) verlassen
1 „Gefällt mir“
in dem Zuge macht es also kaum einen Unterschied ob ich der HA VM mehr als einen Core gebe? das ist wirklich blöd, selbst ein alter Raspi hat ja schon Multicore, für HA ist es dann erstmal eher wichtig, das die Single-Core Performance gut ist…schade eigentlich
Doch macht sinn, da ja die anderen Container auch andere Threads belegen können.
Rückmeldung zu meinem System Intel NUC 7i5BNK / i5 / 7260U / 16GB / Crucial P310 500GB NVMe 2280 M.2 SSD / Bare Metal nach Update auf SW 18.6.0
07.04. EOD: 9:12 Min / Samples: 583 | Sensoren wie gehabt kurz nicht erreichbar
08.04. EOD: 5:35 Min / Samples: 578 | Sensoren wie gehabt kurz nicht erreichbar
09.04. EOD: 2:52 Min / Samples: 569 | Sensoren bleiben erreichbar
10.04. EOD: 4:34 Min / Samples: 561 | Sensoren bleiben erreichbar
Vielen Dank @ottokar !!! Kannst Du mir bitte sagen auf welcher HA Version du bist und wann du das Update gemacht hast..
LG
Zara
JaEin… der Event-Loop bleibt trotzdem Single-Core.
Ich glaube, wir müssen hier mal mit einem Missverständnis aufräumen. Theoretisch klingt es super: „Gib der Kiste mehr Kerne, dann läuft’s flüssiger.“ Aber in der Realität von Home Assistant (HA) funktioniert das leider nicht so.
Das Problem: Der Event-Loop als Nadelöhr Home Assistant Core läuft fast ausschließlich in einem einzigen Asynchronous Event Loop (basierend auf Python asyncio). Das bedeutet: Jede Automatisierung, jede Statusänderung und jedes Skript muss durch diese eine, winzige Schleife.
Klar, die Daten kommen vielleicht aus verschiedenen Containern, die der Linux-Kernel wunderbar auf alle verfügbaren Kerne verteilt hat. Aber sobald diese Daten im HA-Core verarbeitet werden sollen, stehen sie alle an derselben Schlange an.
Der „Async-Bug“ und blockierte Threads Eigentlich sollten async-Prozesse das System entlasten, aber genau hier liegt aktuell der Hund begraben: Auch ein Async-Prozess kann den Event-Loop komplett blockieren, wenn er zu rechenintensiv ist oder unsauber läuft. Da hilft es dir gar nichts, wenn die anderen 11 Kerne deines Prozessors Däumchen drehen – die Daten kommen schlicht nicht durch die blockierte Schleife. Der gesamte Core „denkt“ dann nach und das System hängt.
Die Executor-Tasks funktionieren nicht mehr sauber Früher war der Ausweg, solche Prozesse „non-blocking“ über sogenannte Executors auszulagern. Aber seit den Versionen 2026.3.x läuft das alles andere als stabil. Das ist genau das Problem, das @ottokar und viele andere gerade spüren:
- Der RAM läuft plötzlich voll.
- Das Dashboard reagiert träge oder friert ein.
- Sensoren werden als „nicht aktiv“ angezeigt.
- HA startet ohne Vorwarnung neu (Watchdog-Reboot).
Fazit:
HA ist und bleibt (leider) Single-Core Auch wenn das Update 2026.4.1 einiges verbessert hat, bleibt das Grundproblem: HA selbst ist nicht Multi-Core-fähig. Alles, was auf anderen Kernen landet, wird dort nur vom Linux-Kernel hingeschoben, damit das Betriebssystem überhaupt noch atmen kann. Aber für die Performance von HA selbst ist es fast egal, ob du 1 oder 12 Kerne hast – die Zusatzleistung verpufft einfach. SFML lagert schon seit der 2 Version in den Executer aus, aber aktuell ist es ein Core-Problem.
Die Entwickler fordern schon lange, dass HA die Kerne nativ nutzen sollte, anstatt sich auf die (aktuell instabilen) Executor-Tasks zu verlassen. Bis dahin bleibt aber leider die alte Regel: Single-Core-Performance ist bei HA alles.
Es bringt absolut keine Punkte einen Prozessor mit mehr Kernen zu kaufen, wenn das System langsam wird.. es ist ein reines Architektur-Problem von HA selbst. Auch Container auf anderen Kernen helfen nicht, da sie trotzdem durch den 1 Kern durch müssen..
3 „Gefällt mir“
Die HA-Version war die 2026.4.1, Update erfolgte am 07.04. gegen 18 Uhr. Habe eben das HA-Update auf 2026.4.2 gemacht.
Ich überlege den Umstieg auf einen GEEKOM A5 Mini-PC mit einem AMD-Ryzen 7 5825U Prozessor; dann aber wieder mit Proxmox und VMs… 
1 „Gefällt mir“
Ein schöner kleiner klassischer NoteBook Prozessor! Mit VM`s sollte der keine Probleme haben und was noch besser ist, er hat einen für die Zeit wirklich gute Single-Core Performance! Deutlich besser als der Intel Core i7-1255U 12.Generation (!!) ich habe die “große Version” also nicht die kleine NoteBook-Version und bin damit super zufrieden! Der macht hier das Training im Tandem mit 32GB RAM und 2x Radeon .. und super sparsam ist er auch noch.. da wird die kleinere Notebook Version sicherlich auch bzw noch sparsamer sein! .. Viel Spaß damit!!
PS:
Ein Freund von mir hat sich mit der " Großen Version" (also der Desktop-Version) ein NAS gebaut und super happy damit. Der läuft schon seit 5 Jahren ohne murren und zucken. AMD Prozessoren sind ja eh als stabile Arbeitstiere bekannt, denen besonders bei VM und Single-Core Aufgaben so schnell keiner was vor macht.
Viel Spaß damit!!! - Gute Wahl… (wenn du etwas mehr willst: Die Desktop-Version davon mit einem MINI-ATX in einem schicken kleinen Gehäuse.. der Prozessor kostet auch nicht die Welt.. ca. 80 Euro und im Bundel mit Lüfter und allem was dazugehört um die 100 - 120 EUR
PPS:
Du bekommst aber auch echt gute Laptops mit dem AMD-Ryzen 7 5825U für rund 300 - 400 Euro (neu) - Einzeln gibt es den leider nicht, da es ein OEM Prozessor ist der fest verlötet ist 
Der Prozessor ist einem Mini-PC von Geekom verbaut, ist kein Notebook,
Richtig, aber es handelt sich um einen Laptop-Prozessor, der fest verlötet ist — darauf wollte ich hinaus.
Das ist bei den meisten Mini-PCs so: Sie verwenden Notebook-Prozessoren, die in der Regel etwas kleiner bzw. effizienter ausgelegt sind als ihre Desktop-Pendants, um Strom zu sparen. Im Grunde sind Mini-PCs (nicht alle) nichts anderes als Laptops ohne Akku und Display. → daher mein Hinweis auf Mini-ATX und Desktop-CPU wenn man mehr möchte und auch mal die CPU austauschen möchte.
Zum Prozessor selbst:
Zitat: (…) Der AMD Ryzen 7 5825U ist ein 8-Kern/16-Thread Mobile-Prozessor aus dem Jahr 2022. Er gehört zur Barcelo-Refresh-Serie (Zen 3) und ist im Wesentlichen ein leicht aufgetakteter Ryzen 7 5800U — ein echter Allrounder für Office, Multitasking, Content Creation und auch leichtes Gaming über die integrierte Grafik (…) übrigens das „U" steht bei AMD für Ultra-Low Voltage, also besonders stromsparenden Betrieb. (Quelle AMD)
Meine persönliche Meinung — ganz ohne Wertung:
Ich greife lieber zu einem Notebook. Der Stromverbrauch ist identisch mit einem Mini-PC (manches Mal so gar geringer, da die Kühlungen besser abgestimt sind), aber man bekommt gleich Monitor und Tastatur dazu — Also quasi eine eingebaute USV mit der Möglichkeit direkt am Gerät einzugreifen wenn es mal hängt.
Bei einem Stromausfall läuft das Gerät einfach weiter. Home Assistant unterstützt außerdem den Betrieb mit geschlossenem Deckel, was es als Always-On-System sehr alltagstauglich macht. Aber das ist letztlich Geschmackssache — jeder so, wie es für ihn am besten passt. 
Viele Wege führen nach Rom — es gibt kein Richtig oder Falsch, kein Besser oder Schlechter. Es muss einfach zu einem selbst passen und das sein, was man möchte.
Hallo in die Runde!
Auch ich habe die Probleme das zum Zeitpunkt vom EOD-Lauf mein HA nur noch zum Teil funktioniert. Ich habe mein HA direkt auf einem “Mini PC”. Ich habe irgendwann mal bei Smarthome Yourself ein Artikel über eine günstige Varriante zum RPi gefunden. Dabei geht es um ein Fujitsu Futro S920 mit SSD und 16gb DDR3 RAM
. Thin Client als Alternative zu einem Raspberry
Seid dem läuft der bei mir. Dann habe ich durch Zufall mal mitbekommen das es so ab ca 23Uhr30 Probleme gibt. Hier im Forum habe ich dann wohl auch den Grund dafür gefunden, so vermute ich jedenfalls. So sieht das dann aus:
Mittlerweile ist der EOD bei 4888s! Da ich mir jetzt nicht unbedingt neue Hardware anschaffen möchte werde ich mich wohl an dieser Stelle auch aus dem Projekt verabschieden. Es war auf jedenfall Interassant in den letzen Monaten dabei zu sein und natürlich vielen Dank für die ganze Arbeit von @Tom-HA und alle anderen.
Gruß Günter
Gute Entscheidung 
Hatte ähnliches Setup und nur Probleme mit SFML. Bin seit einiger Zeit wieder zurück auf Solcast PV Forecast mit aktivem Auto-Dampening. Durchschnittliche Genauigkeit in den letzten Wochen liegt über 90%.
1 „Gefällt mir“
Bei der Hardware Konstellation vermutlich wirklich eine gute Entscheidung. Nur lässt sich Solcast natürlich überhaupt nicht mit SFML vergleichen.
Das ist ja auch gut so. Die Frage, die man sich stellen müsste ist doch: Was will ich?
Und meiner Meinung nach, hilft das hier doch bei der Entscheidungsfindung:
1 „Gefällt mir“
Kann ich mich nur anschließen, da die CPU Leistung auf einem Pi4 liegt.
Wieviel Panel Gruppen sind denn angelegt? Wenn mehr als 1 hinterlegt ist, kann es sein, warum der EOD so lange braucht.
1 „Gefällt mir“
Hallo, ich habe zwei Panel Gruppen angelegt
Was hast du noch auf dem HA laufen?
