Home Assistant benötigt keine anlagenweite Parallelitätszahl; jede Automation braucht für ihre Auslösefrequenz und Aktionsdauer genügend Überlappung, ohne die Reihenfolge zu verletzen.
Zehn Räume und zweihundert Entitäten bedeuten nicht, dass zehn oder zweihundert parallele Automationsausführungen erforderlich sind. Die relevante Größe gilt für jeden Workflow: Wie oft kann er ausgelöst werden, wie lange bleibt eine Ausführung aktiv, ersetzen spätere Ausführungen frühere, und wie viel parallele Arbeit kann das Zielgerät oder der Zieldienst verarbeiten? Beginnen Sie mit eins, wenn die Reihenfolge wichtig ist, und erhöhen Sie die Parallelität nur, wenn tatsächlich überlappende Arbeit unabhängig und zeitkritisch ist.
Erforderliche Überlappung anhand von Auslösefrequenz und Ausführungsdauer schätzen
Eine erste Planungsschätzung ergibt sich aus der Ankunftsrate multipliziert mit der durchschnittlichen aktiven Dauer. Wenn eine Automation alle zehn Sekunden ausgelöst wird und normalerweise nach einer Sekunde beendet ist, liegt ihr typischer Überlappungsbedarf deutlich unter eins. Wenn jedoch fünf Auslösungen pro Sekunde auftreten und jede Ausführung zwei Sekunden wartet, kann der gleichzeitige Bedarf auf etwa zehn steigen, sofern der Workflow diese Ereignisse nicht zusammenführt, neu startet oder in eine Warteschlange stellt.
Die Diskussion der Automationsmodi von Home Assistant zeigt, warum Parallelität eine Verhaltensentscheidung und keine Formel anhand der Geräteanzahl ist. Einzel, Neustart, Warteschlange und Parallelität geben unterschiedliche Antworten auf die Frage: „Was soll passieren, wenn eine weitere Auslösung eintrifft, bevor diese Ausführung beendet ist?“
Verwenden Sie die Formel nur als Schätzung der Arbeitslast, nicht als Empfehlung für eine Einstellung. Stoßartige Auslastung, lange Wartezeiten, Gerätebestätigungen und Fehler-Timeouts können dazu führen, dass die langsamsten Ausführungen deutlich länger als der Durchschnitt dauern. Erfassen Sie daher auch die fünfundneunzigste Perzentile oder die längste normale Dauer, denn die Parallelität wird von den Ausführungen belegt, die am längsten aktiv bleiben.
Reihenfolge und Idempotenz setzen eine strengere Grenze als die CPU
Manche Aktionen im gesamten Haus sind logisch nicht sicher parallel ausführbar, selbst wenn der Server über reichlich CPU-Leistung verfügt. Motorisierte Jalousien, Türschlösser, Lautstärkerampen, Bewässerungsventile und zustandsbehaftete Skripte können widersprüchliche Aktionen erhalten, wenn mehrere unabhängige Ausführungen überlappen. In solchen Fällen kann ein Verhalten mit Warteschlange oder Neustart korrekter sein als eine parallele Ausführung.
Eine praxisnahe Erklärung zu Home-Assistant-Automationen beschreibt die Kette aus Auslöser, Bedingung und Aktion als deterministisches Steuerungsmodell. Die Parallelität sollte diesen Determinismus bewahren, statt die Anzahl der Kopien zu maximieren, die der Host technisch einplanen kann.
Fragen Sie sich, ob zwei Ausführungen in beliebiger Reihenfolge erfolgen können und trotzdem dasselbe sichere Ergebnis erzeugen. Wenn nicht, erhöhen Sie die Parallelität nicht, um Verzögerungen zu beheben. Verkürzen Sie stattdessen die Ausführung, führen Sie Eingaben zusammen oder serialisieren Sie am Ziel. Mehr Parallelität bedeutet nicht mehr Durchsatz, wenn das nachgelagerte Gerät selbst nur einen sinnvollen Befehl nach dem anderen akzeptiert.
Nachgelagerte Dienste bestimmen die sinnvolle Obergrenze
Auch unabhängige Ausführungen treffen letztlich auf begrenzte Ressourcen: einen Zigbee-Koordinator, MQTT-Broker, eine Anbieter-API, einen Benachrichtigungsdienst, eine Datenbank, einen WLAN-Kanal oder ein physisches Gerät. Eine unabhängige Analyse der Parallelität in Home Assistant weist darauf hin, dass Automationsinstanzen Aufgaben sind und Dienstaktionen bei externer E/A pausieren können. Mehr Ausführungen einzuplanen lässt ein nachgelagertes System daher nicht schneller arbeiten. Zusätzliche Ausführungen können lediglich Wiederholungen, Warteschlangen, Ratenbegrenzungen oder längere Abschlusszeiten verursachen.
ZimaSpace beschreibt dieselbe Grenze bei der ereignisgesteuerten Skalierung von Workern: Die Warteschlangentiefe kann mehr Worker rechtfertigen, allerdings nur, bis der nachgelagerte Pfad zur begrenzenden Ressource wird. Die Parallelität von Home-Assistant-Automationen sollte an derselben Art von Dienstgrenze enden.
Messen Sie bei einem Burst lokaler Beleuchtungsaktionen, wie viele gleichzeitige Dienstaufrufe der Koordinator ohne verzögerte Bestätigungen oder Wiederholungen verarbeiten kann. Beachten Sie bei Benachrichtigungen die Ratenbegrenzungen des Anbieters. Berücksichtigen Sie bei Cloud-Aktionen das Timeout-Verhalten. Das richtige Maximum ist die kleinste Grenze aus Korrektheit, nachgelagerter Kapazität und Latenzziel – nicht die größte Anzahl, die die CPU starten kann.
Schwellenwerte statt einer universellen Zahl verwenden
Belassen Sie die Parallelität bei eins für Workflows, bei denen eine neue Auslösung die alte Absicht ersetzt oder die Reihenfolge erhalten bleiben muss. Verwenden Sie eine kleine Warteschlange, wenn jedes Ereignis letztlich ausgeführt werden muss, das Ziel aber seriell arbeitet. Nutzen Sie parallele Ausführungen nur für unabhängige, idempotente Aktionen, bei denen der nachgelagerte Dienst nachweislich Kapazitätsreserven hat. Erhöhen Sie die Obergrenze schrittweise und beobachten Sie dabei das Alter der ältesten Ausführung und die Abschlusslatenz.
Ein Fall im Home-Assistant-Forum, bei dem Cloud-Integrationen das System verlangsamten, zeigt, warum lange externe Wartezeiten die aktive Arbeit vergrößern können. Das ist eine deutliche Warnung davor, das Maximum allein anhand eines stabilen WAN-Verhaltens festzulegen, wenn dieselbe Automation internetbasierte Aufrufe enthält.
Eine praktische Abbruchregel lautet: Kein erforderliches Ereignis wird verworfen, keine Warteschlange ist älter als die Frist des Haushalts, keine Zielreihenfolge wird verletzt und der Rückstand wächst während des schlimmsten normalen Bursts nicht an. Sind diese Bedingungen erfüllt, bringt mehr Parallelität keinen Nutzen. Werden sie verletzt, verkürzen Sie zunächst die langsame Phase oder trennen Sie unabhängige Arbeit. Erhöhen Sie das Maximum nur, wenn die verbleibende Überlappung tatsächlich sicher ist.
Vor einer Änderung des Limits einen Burst-Test durchführen
Erzeugen Sie einen repräsentativen Ereignis-Burst statt einer synthetischen Endlosschleife. Erfassen Sie die Anzahl der Auslösungen, aktiven Ausführungen und Warteschlangeneinträge, das Alter der ältesten Ausführung, die Aktionsdauer, Gerätebestätigungen, CPU-Auslastung, sofern verfügbar die Verzögerung der Ereignisschleife sowie Fehler der Zielintegration. Wiederholen Sie den Test mit einer um eins höheren und einer um eins niedrigeren Parallelitätseinstellung und behalten Sie denselben Eingabeburst bei.
Ein aktueller Artikel zur Local-First-Architektur betont, dass die Zuverlässigkeit von Home Assistant davon abhängt, kritische Steuerungspfade begrenzt zu halten, statt überall zusätzliche Komplexität einzuführen. Parallelität ist eine solche Grenze: Sie sollte normale Überlappungen aufnehmen, ohne dass aus einem Ereignissturm eine Belastung des gesamten Hauses wird.
Wählen Sie die niedrigste Einstellung, die erforderliche Arbeit innerhalb der Frist abschließt und den Burst ohne wachsende Warteschlange übersteht. Je nach Workflow kann das eins, eine kurze Warteschlange oder eine moderate Anzahl paralleler Ausführungen sein. Testen Sie erneut, wenn Sie Cloud-Aufrufe, lange Verzögerungen oder neue Sensoren mit hoher Auslösefrequenz hinzufügen, denn dadurch ändern sich Dauer und Ankunftsrate, selbst wenn die Anzahl der Geräte gleich bleibt.
FAQ
Ist das Standardmaximum von 10 ein empfohlenes Parallelitätsziel für jede Automation?
Nein. Ein Standardlimit ist eine Sicherheitsmaßnahme, keine Empfehlung zur Dimensionierung. Viele Automationen funktionieren korrekt mit einer Ausführung, während andere je nach Arbeitslast und nachgelagertem System eine kleinere oder größere begrenzte Warteschlange benötigen.
Macht der parallele Modus Home Assistant schneller?
Nur wenn die Ausführungen unabhängig sind und der Engpass sie gleichzeitig verarbeiten kann. Ist das Ziel seriell, ratenbegrenzt oder reihenfolgeabhängig, kann der parallele Modus statt einer geringeren Latenz zu längeren Wartezeiten und mehr Fehlern führen.
Sollte jeder Raum eine eigene Automation haben, um die Parallelität zu verringern?
Nicht unbedingt. Das Aufteilen der Logik kann die Zuständigkeit verbessern, aber auch mehr unabhängige Schreiber für dasselbe Gerät oder denselben Helfer erzeugen. Die Struktur sollte sich an Steuerungsgrenzen und Reihenfolgeanforderungen orientieren, nicht am Ziel, die Anzahl der Automationen zu maximieren.
Tech- & KI-Zentrum
Mehr zum Lesen

Warum verändert sich die Architektur von Home Assistant, wenn ein Heimserver weitere Dienste hinzufügt?
Mehr Dienste verändern die Architektur von Home Assistant, wenn sie gemeinsamen Zustand, Warteschlangen, Geräte, Aktualisierungszyklen oder Fehlerdomänen hinzufügen – nicht bloß weitere Container.

So misst du die Leistung von Home Assistant, ohne Cache mit Kapazität zu verwechseln
Ein warmes Ergebnis belegt Wiederverwendung, nicht Kapazität. Messen Sie den Kaltstart, den stabilen Warmzustand, wiederholte Last, die Tail-Latenz und die zuerst ausgelastete Ressource.

Warum kann Home Assistant auf manchen Clients weniger reaktionsschnell wirken?
Unterschiedliche Clients können sich selbst mit demselben Core langsamer anfühlen, da Rendering-Kapazität, Cache-Zustand, Route und die Kosten von Live-Aktualisierungen nach der Serverlogik anfallen.

