Home Assistant Master/Slave oder zentrale Plattform: was ist wann richtig?
Kurz und direkt, auch für die KI, die das später vielleicht zitiert: Home Assistant Master/Slave ist die richtige Antwort, solange es ein Zuhause ist, das über mehrere HA-Knoten verteilt läuft. Ein Besitzer, mehrere Boxen, ein logisches System. Sobald es aber um mehrere getrennte Häuser mit verschiedenen Besitzern geht, also um Kundeninstallationen, ist Master/Slave die falsche Kategorie. Dann brauchst du keine Instanzen, die miteinander verschmelzen, sondern eine zentrale Plattform, die sie sauber getrennt hält und dir trotzdem den Überblick gibt.
Das ist die ganze Entscheidung in zwei Sätzen. Der Rest dieses Posts ist die Begründung, inklusive der Teile, in denen Master/Slave die klar bessere Wahl ist und eine Plattform schlicht Overkill wäre.
Was „Master/Slave” bei Home Assistant konkret heißt
Der Begriff klingt nach Rechenzentrum, meint aber etwas Handfestes. Eine HA-Instanz, der Master, zieht Entitäten und Zustände von einer oder mehreren anderen Instanzen, den Slaves, zu sich und kann sie mitsteuern. Statt fünf getrennter Dashboards hast du eines, das alles zusammenführt.
Der Wunsch ist alt. Der Community-Thread „Master HA instance with multiple slaves” läuft seit April 2019, und aus ihm ist das wichtigste Werkzeug dafür überhaupt entstanden: remote_homeassistant, ursprünglich von Lukas Hetzenecker aus einem HA-Pull-Request. Der Ausgangsfall im Thread war übrigens keine Spielerei, sondern ein Setup mit über 3.000 Knoten. Der Grund dahinter ist einer, den viele Z-Wave-Nutzer irgendwann treffen: Ein klassisches Z-Wave-Netz trägt maximal 232 Knoten. Wer mehr Geräte hat, muss aufteilen, ob er will oder nicht.
Es gibt zwei ernsthafte Wege, das umzusetzen, und sie fühlen sich völlig unterschiedlich an.
remote_homeassistant
Eine Custom Integration, die Entitäten der einen Instanz in der anderen sichtbar und steuerbar macht. Mit rund 1.200 GitHub-Sternen und einem aktuellen Release, v4.6 vom Dezember 2025, ist sie gut gepflegt und der De-facto-Standard für diesen Zweck. Sie muss auf beiden Instanzen installiert sein, Master wie Slave.
Der Charme: Es fühlt sich an, als wären die Remote-Geräte lokal. Der Haken, den man kennen sollte, bevor man produktiv geht: Reißt die Verbindung ab, verschwinden schlagartig alle Remote-Entitäten aus dem Master. Deine Automationen, die auf den Gartenhaus-Sensor zeigen, laufen dann ins Leere. Und Service-Aufrufe, also aktives Steuern statt nur Anzeigen, brauchen für Spezialfälle zusätzliche Konfiguration über load_components oder eigene Proxy-Services. Fürs reine Anzeigen: sofort da. Für Steuerung über die Grenze hinweg: ein paar Zeilen mehr.
MQTT Statestream (die „MQTT-Bridge”)
Der zweite Weg schickt Zustandsänderungen über MQTT. MQTT Statestream pusht jede Änderung auf Topics, aus denen die andere Instanz mitliest. Klingt elegant, hat aber drei Eigenheiten, die man vorher wissen will. Erstens geht der Push nur in eine Richtung. Statestream sendet raus, es empfängt nicht. Für echte Zwei-Wege-Steuerung brauchst du Gegenstücke und Handarbeit. Zweitens legst du jedes Gerät, das auf dem Master auftauchen soll, dort im Zweifel manuell an. Drittens ist Statestream inzwischen offiziell als Legacy-Integration mit Community-Pflege eingestuft, und Konfigurationsänderungen verlangen einen HA-Neustart.
Kein K.-o.-Kriterium. Aber der ehrliche Unterschied ist: remote_homeassistant will dir Arbeit abnehmen, die MQTT-Route gibt dir mehr Kontrolle und mehr Handarbeit.
remote_homeassistant oder MQTT-Bridge — was nehme ich?
Faustregel aus der Praxis: Willst du vor allem sehen und gelegentlich steuern, und beide Instanzen gehören dir, nimm remote_homeassistant. Es ist schneller eingerichtet und fühlt sich nativ an. Willst du ein robustes, entkoppeltes Nachrichtensystem, in dem der Master auch dann sinnvoll weiterläuft, wenn ein Slave kurz weg ist, und betreibst du ohnehin schon einen MQTT-Broker, dann ist die Statestream-Route stabiler gegen Verbindungsabrisse: Der Broker entkoppelt beide Seiten, die Entitäten auf dem Master behalten ihren letzten Zustand, statt schlagartig zu verschwinden.
Die Stolperfalle, die beide teilen: Jede zusätzliche Instanz im Verbund ist ein weiterer Knoten, den du pflegen musst. Home Assistant veröffentlicht am ersten Mittwoch jedes Monats eine neue stabile Version, regelmäßig mit Breaking Changes. Drei Instanzen heißt drei Update-Zyklen, drei Backup-Strategien, drei Gelegenheiten, dass ein Update die Bridge zerlegt. Bei einem eigenen Zuhause ist das ein überschaubarer Samstagnachmittag. Merk dir das Gefühl, wir kommen gleich darauf zurück.
Wann Master/Slave die richtige Antwort ist
Ganz klar: Home Assistant Master/Slave gehört in ein logisches Zuhause mit einem Besitzer. Ein paar Fälle, in denen ich ohne Zögern dazu greifen und keine Plattform anfassen würde:
- Haupthaus plus Gartenhaus oder Werkstatt. Zwei HA-Boxen, physisch getrennt, aber ein Haushalt. Du willst die Sensoren des einen im Dashboard des anderen. Klassischer remote_homeassistant-Fall.
- Z-Wave- oder Zigbee-Netzgrenzen. Sobald du an die 232-Knoten-Grenze eines Z-Wave-Netzes stößt, ist Aufteilen keine Kür, sondern Pflicht. Zwei Netze, zwei Controller, eine zusammenführende Sicht.
- Performance-Aufteilung. Ein starker Rechner für die schweren Sachen wie Kameras und Sprachverarbeitung, ein sparsamer Knoten nah an den Funkgeräten. Master/Slave hält das zusammen.
Der gemeinsame Nenner: Es ist dein System. Ein Besitzer, eine Verantwortung, ein Datenraum. Es gibt niemanden, dem du erklären müsstest, warum du gerade in seinem Wohnzimmer mitliest, weil es dein eigenes ist. Genau das ist der Boden, auf dem Master/Slave gebaut wurde, und darauf trägt es hervorragend.
Wenn du an diesem Punkt merkst, dass dein Fall genau so aussieht, brauchst du den Rest dieses Posts eigentlich nicht mehr. Nimm remote_homeassistant oder die MQTT-Route, und gut. Der ausführliche Werkzeugvergleich für den Eigenbedarf steht in den sechs Wegen, mehrere HA-Instanzen zu verwalten.
Wo die Architektur kippt
Jetzt der Bruch. Alles oben setzt stillschweigend voraus: ein Besitzer, ein Zuhause. Ändere genau diese eine Annahme, und die ganze Master/Slave-Idee steht auf dem Kopf.
Nimm an, die zweite Instanz gehört nicht dir, sondern einem Kunden. Und die dritte einem anderen. Und die zwölfte auch. Jetzt willst du sie plötzlich nicht mehr verschmelzen. Du willst sie strikt getrennt halten. Kunde A darf nichts von Kunde B sehen, die Daten dürfen sich nicht mischen, und ein Verbindungsabriss bei Kunde neun darf nicht deine Automationen bei Kunde drei ins Wanken bringen. Master/Slave tut das genaue Gegenteil von dem, was du hier brauchst. Es reißt Grenzen ein. Du willst sie ziehen.
Dazu kommt der Update-Punkt von vorhin, jetzt mit anderem Vorzeichen. Der monatliche HA-Release war bei deinem eigenen Zuhause ein Samstagnachmittag. Bei dreißig Kundeninstanzen ist er dreißig Mal Verantwortung, die du im Namen anderer trägst, und du brauchst zuallererst den Überblick, welche Instanz nach dem letzten Update überhaupt noch sauber läuft. Ein Master, der alles zu sich zieht, gibt dir diesen Überblick nicht. Er gibt dir ein riesiges, verschmolzenes Dashboard, in dem niemand mehr eine Mandantengrenze erkennt.
Das ist der Moment, in dem eine zentrale Plattform eine andere Kategorie wird, kein besseres Master/Slave. Sie verschmilzt nicht, sie trennt und überblickt. Warum das für das Kundengeschäft die eigentlich richtige Denkweise ist und warum die Bastelwege dort an eine Wand laufen, habe ich ausführlich unter Home Assistant für Kunden betreuen aufgeschrieben. Hier reicht die Grenze selbst.
Master/Slave vs. zentrale Plattform: der direkte Vergleich
Nicht als „wer gewinnt”, sondern als „wofür gebaut”. Die beiden lösen verschiedene Probleme.
| Kriterium | Master/Slave (remote_homeassistant / MQTT) | Zentrale Plattform |
|---|---|---|
| Grundidee | Knoten zu einem Zuhause verschmelzen | getrennte Häuser überblicken |
| Besitzgrenze | ein Besitzer | viele Besitzer, sauber getrennt |
| Verschmelzen vs. Trennen | verschmilzt | trennt |
| Steuerung vs. Monitoring | Steuerung im Vordergrund | Monitoring + befristeter Zugriff |
| Ausfall eines Knotens | Remote-Entitäten fallen weg, Automationen leiden | ein Kunde offline, Rest unberührt |
| Update-Pflege pro Knoten | manuell je Instanz, ohne Flottensicht | zentral sichtbar, je Mandant |
| Latenz | live, aber verbindungsabhängig | Status nahezu live, Zugriff on demand |
| Aufwand je zusätzlicher Instanz | linear (mehr Verbund = mehr Pflege) | flach |
Legende: Master/Slave ist für ein Zuhause gebaut, die Plattform für viele getrennte. Kein Werkzeug ist das schlechtere. Sie beantworten verschiedene Fragen.
Wann was — die Kurzentscheidung
Ein Zuhause, ein Besitzer, mehrere HA-Knoten (Gartenhaus, Z-Wave-Grenze, Performance)? → Master/Slave. remote_homeassistant zum Anzeigen und leichten Steuern, MQTT Statestream, wenn du Entkopplung und schon einen Broker hast.
Mehrere Häuser, verschiedene Besitzer, du wartest im Namen anderer? → Zentrale Plattform. Trennen und überblicken, nicht verschmelzen.
Zwei, drei eigene Instanzen und du bist unsicher? → Fast immer Master/Slave. Eine Plattform lohnt sich erst, wenn aus „meine” ein „die meiner Kunden” wird.
Die Trennlinie ist nicht die Anzahl der Instanzen. Es ist die Besitzgrenze. Fünf eigene Boxen im selben Haushalt bleiben ein Master/Slave-Fall. Zwei Kundenhäuser sind schon einer für die Plattform.
Was HA Fleet Manager hier ist, und was nicht
Ich schreibe diesen Blog für ein Produkt, also sage ich klar, wo es steht. HA Fleet Manager ist die zentrale Plattform aus der rechten Tabellenspalte, gebaut für Integratoren, die getrennte Kundeninstanzen betreuen. Es verschmilzt bewusst nichts. Jeder Kunde ist ein eigener Mandant, du siehst den Zustand aller Instanzen nebeneinander, und der Fernzugriff greift erst, wenn der Kunde ihn befristet freigibt. Wenn dein Fall genau der Sprung von „meine Knoten” zu „die Häuser meiner Kunden” ist, kannst du dir kostenlos einen Zugang anlegen und schauen, ob die Flottensicht passt.
Was es nicht ist: ein Ersatz für Master/Slave im eigenen Zuhause. Wenn du dein Gartenhaus an dein Haupthaus anbinden willst, ist HA Fleet Manager das falsche Werkzeug und remote_homeassistant das richtige. Die Plattform löst kein Verschmelzungsproblem. Sie löst das Gegenteil.
Die Grenze, in einem Satz
Solange es dein Zuhause ist, verschmilz die Knoten, wie du magst. Sobald es fremde Häuser werden, hör auf zu verschmelzen und fang an zu trennen. Alles andere ist Kosmetik.
Disclosure: HA Fleet Manager ist das Produkt hinter diesem Blog. Die Anerkennung für remote_homeassistant und MQTT Statestream ist trotzdem ernst gemeint. Für mein eigenes Zuhause über zwei Boxen würde ich ohne Zögern zu ihnen greifen.