Henrik aus der Home-Assistant-Community beschreibt es so, als wäre ihm die Decke auf den Kopf gefallen. Achtzig Zigbee-Geräte, gewachsen über drei Jahre. Temperatursensoren im Keller, Heizkörperventile von Sonoff, eine Handvoll Aqara-Türkontakte, zwanzig IKEA-Tradfri-Lampen, dazu ein paar Schalter von Tuya, die er damals auf Amazon für ein paar Euro mitgenommen hat. Alles läuft. Jede Nacht schalten die Lichter im Flur auf drei Prozent, damit die Katze nicht ins Leere tappt. Alles über ZHA, die in Home Assistant eingebaute Zigbee-Integration. Alles lief, bis er über das Weekend auf die Idee kam, seinen Home Assistant Yellow "zukunftssicher" zu machen und auf Multi-PAN umzustellen, um gleichzeitig Thread-Geräte nutzen zu können.

Am Sonntagabend war das Netz leer. Nicht gestört, leer. Die Geräte waren weg. Der Koordinator hatte Thread- und Zigbee-Radio gleichzeitig aktiv, aber das Backup war nicht sauber migriert, und Zigbee-Geräte können ihren Koordinator nicht einfach vermissen und zurückkommen wie verlorene Hunde. Sie mussten alle einzeln neu angelernt werden. Vier Abende. Der schönste Teil war die Dachrinnen-Aqara-Temperatursonde, an die er nur mit Leiter kommt. Henrik hat hinterher im Forum geschrieben: "Hätte ich vorher Z2M benutzt, wäre das Backup einfach importierbar gewesen."

Das ist natürlich nicht ganz fair. Ein sauberes ZHA-Backup lässt sich auch wiederherstellen. Aber Henrik hat ein Thema angesprochen, das quer durch die Home-Assistant-Welt geht und das spätestens einmal im Leben jeder HA-Nutzer ausdiskutieren muss: ZHA oder Zigbee2MQTT. Die beiden Stacks sind technisch grundverschieden, ihre Stärken liegen in verschiedenen Ecken, und wer sich einmal entschieden hat, der wechselt nicht mal eben. Das Umziehen eines gewachsenen Zigbee-Netzes ist eine Lebenszeitausgabe von mehreren Abenden. Also lohnt es sich, vorher drüber nachzudenken.

Woher die beiden Stacks kommen

Zigbee2MQTT wurde 2017 von Koen Kanters, einem niederländischen Entwickler, als Hobbyprojekt gestartet. Der Ausgangspunkt war pragmatisch: Es gab Zigbee-Geräte, es gab Home Assistant, es gab MQTT als Messaging-Protokoll, und es gab keine brauchbare Brücke dazwischen, wenn man nicht gleich einen Hue-Hub oder eine ConBee kaufen wollte. Kanters hat das Problem nicht grundsätzlich gelöst, sondern praktisch: Ein Node.js-Prozess liest den seriellen Port des Koordinators aus, übersetzt Zigbee-Nachrichten in MQTT-Topics, fertig. Der Genie-Aspekt lag in der Community-Struktur. Jedes Mal, wenn jemand ein neues Zigbee-Gerät kaufte, schickte er einen Pull Request mit einem "external converter" an das Repo. Das Ergebnis: Heute, April 2026, listet zigbee2mqtt.io 5.290 unterstützte Geräte von 562 Herstellern. Das ist keine runde Marketing-Zahl, das ist eine live gepflegte Datenbank.

ZHA dagegen ist die erwachsene, saubere Variante. 2018 wurde sie als offizielle Integration in Home Assistant eingeführt, basierend auf zigpy, einer in Python geschriebenen Zigbee-Protokollbibliothek. Der Unterschied ist schon auf Architekturebene sichtbar: ZHA ist kein eigener Prozess, sondern läuft im selben Python-Runtime wie Home Assistant selbst. Kein MQTT-Broker, keine Bridge, keine zusätzlichen Addons. Plug den Koordinator ein, ZHA erkennt ihn, fertig. Die Zahl der unterstützten Geräte liegt bei rund 2.000, ergänzt durch das Projekt zha-device-handlers (auch zhaquirks genannt), das Abweichungen vom Zigbee-Standard für einzelne Hersteller kompensiert. Xiaomi zum Beispiel, das laut der offiziellen zhaquirks-Doku "berüchtigt dafür ist, Zigbee-Spezifikationen nicht zu folgen", braucht für fast jedes Gerät eine Quirk.

Das ist schon der erste wichtige Unterschied: Z2M ist community-first, ZHA ist standards-first. Wenn ein chinesischer Hersteller eine neue Steckdose bringt, die Leistungsmessung auf dem falschen Cluster meldet, ist sie bei Z2M meistens innerhalb von Tagen durch einen externen Converter lauffähig. Bei ZHA kann das Wochen dauern, bis jemand eine Quirk schreibt, prüfen lässt und merged.

Was architektonisch passiert

ZHA lebt in Home Assistant. Wenn du zha einschaltest, startet zigpy, greift auf den seriellen Port deines Koordinators zu und spricht direkt Zigbee Cluster Library (ZCL) mit deinen Geräten. Eine Schalter-Nachricht geht vom Gerät über den Koordinator über zigpy direkt in den Event-Bus von Home Assistant. Die Latenz ist minimal, weil kein zweiter Prozess dazwischenhängt. Ein Klick auf einen IKEA-Tradfri-Schalter erreicht die Automation in typischerweise unter 50 Millisekunden.

Zigbee2MQTT dagegen ist ein eigener Node.js-Prozess. Üblicherweise läuft er als Add-on in Home Assistant OS oder als Docker-Container, aber architektonisch ist er unabhängig. Zwischen dem Gerät und deiner Automation stehen drei Stationen: Koordinator, Z2M-Prozess, MQTT-Broker. Erst dann kommt die Nachricht in Home Assistant an. Die Latenz ist höher, aber im Alltag nicht spürbar. Was du dafür gewinnst, ist Entkopplung. Wenn Home Assistant neu startet, läuft dein Zigbee-Netz weiter. Wenn du Z2M updatest, bleibt Home Assistant online. Du kannst Z2M auf einem separaten Raspberry Pi laufen lassen und über TCP an einen Remote-Koordinator anbinden, das steht auch so in der offiziellen Dokumentation.

Praktisch bedeutet das: ZHA ist einfacher aufzusetzen. Z2M ist robuster zu betreiben, sobald das Setup läuft. Neil Turner hat in seinem viel zitierten Blogpost vom November 2024 geschrieben, dass für Einsteiger ZHA die bessere Wahl ist, einfach weil drei Addons (Mosquitto, MQTT-Integration, Z2M-Addon) plus ein eigenes Webinterface schon viel sind, wenn man noch nicht mal verstanden hat, was eine Automatisierung ist.

Die Koordinator-Frage

Das ist die Stelle, wo sich viele Entscheidungen im Voraus festzementieren. Der Koordinator ist das USB-Dongle (oder eingebaut in HA Yellow/Green), das die Zigbee-Signale sendet. Drei Kandidaten dominieren 2026 den Markt, und sie sind für die beiden Stacks unterschiedlich gut geeignet.

Home Assistant SkyConnect / Connect ZBT-1 (Silicon Labs EFR32MG21, EZSP-Firmware) ist der offizielle Nabu-Casa-Stick. Er funktioniert mit beiden Stacks gut. ZHA bevorzugt ihn faktisch, weil das ezsp-Radio-Backend in zigpy mit am besten gewartet ist und Install-Codes (für sichere Geräte wie Bosch-Schlösser) sauber funktionieren. Sonoff ZBDongle-E (Silicon Labs EFR32MG21, ebenfalls EZSP) ist die günstigere Silabs-Variante. Technisch fast identisch zum SkyConnect, in Foren-Threads wie "Sonoff ZBDongle-E VS SZLB-06" wird er regelmäßig als preiswerteste Option empfohlen. Der ältere ZBDongle-P (Texas Instruments CC2652) funktioniert auch, wird aber in Z2M-Communities immer noch beliebter, weil das znp-Backend als besonders stabil gilt. ConBee III von Dresden Elektronik ist der problematische Fall. Technisch kompetent, mit eigenem Formfaktor und guter Reichweite. Aber die ZHA-Entwickler haben im Mai 2025 im GitHub-Issue zigpy/zha#447 explizit vorgeschlagen, ConBee in den ZHA-Docs als "nicht empfohlen" zu markieren, bis das Join-Verhalten mit Install-Codes stabil ist. Dresden Elektronik hat inzwischen neue Firmware geliefert, und ein kompletter Refactor des deconz-Adapters in Z2M (durch manup, der bei Dresden Elektronik arbeitet) hat in der Z2M-Welt vieles verbessert. Der Stand April 2026 ist: ConBee III läuft in Z2M mittlerweile sauber, in ZHA bleibt er offiziell "supported, aber nicht empfohlen". Wer einen ConBee hat, ist bei Z2M besser aufgehoben.

Multi-PAN, Thread, und warum Henrik vom Anfang Pech hatte

Multi-PAN ist das Feature, das auf dem Papier hervorragend klingt: Ein einziger Silabs-Dongle lässt sich so konfigurieren, dass er gleichzeitig Zigbee und Thread spricht. Beide Protokolle nutzen 802.15.4 auf 2,4 GHz, also warum nicht. Home Assistant hat das als "experimentell" eingeführt, und viele Nutzer haben es aktiviert, um Matter-über-Thread-Geräte (z.B. ein Eve Energy) ohne zweiten Stick einzubinden.

Die Realität, Stand 2026: Home Assistant empfiehlt inzwischen ausdrücklich, pro Koordinator nur ein Protokoll zu nutzen. Haade.fr dokumentiert in einer ausführlichen Anleitung, dass Multi-PAN funktioniert, aber die Zigbee-Performance leidet, weil sich die beiden Netze denselben Funkkanal teilen müssen. Schlimmer noch: Mit Multi-PAN ist Z2M aktuell nicht kompatibel, das Zigbee-Herdsman-Backend funktioniert in diesem Mixed-Modus nicht. Der PR #93831 in home-assistant/core aus 2023 führt bereits eine "automatische Migration zurück zu reiner Zigbee-Firmware" ein, ein deutliches Signal, wohin die Reise geht.

Die bessere Lösung, auf die die Community inzwischen einschwenkt, ist Multi-Radio: Zwei separate Dongles, einer für Zigbee, einer für Thread. Ein SkyConnect als Thread-Border-Router, ein ZBDongle-E als Zigbee-Koordinator. Die Störungen sind minimal, wenn man die Kanäle sauber trennt (Zigbee auf Kanal 15 oder 20, Thread auf 11 oder 25), und beide Netze können ihre volle Bandbreite nutzen. Henriks Fehler war nicht, dass er den falschen Stack hatte. Sein Fehler war, dass er den richtigen Stack in den falschen Modus gezwungen hat.

Device-Support in Zahlen

Wer ein Regal voller exotischer Tuya-Sensoren hat, sollte Z2M nehmen. Wer Philips-Hue, IKEA-Tradfri und ein paar Aqara-Standardgeräte hat, bei dem funktionieren beide. Die Zahlen: Z2M unterstützt 5.290 Geräte von 562 Herstellern (Stand April 2026, laut offizieller zigbee2mqtt.io/supported-devices). Die ZHA-Seite nennt keine harte Zahl, aber die Community geht von rund 2.000 offiziell unterstützten Geräten plus mehreren hundert durch Quirks abgedeckten aus. Die Lücke ist real, und sie wächst vor allem in den Segmenten, wo chinesische Billighersteller aktiv sind.

Aber Quantität ist nicht alles. Die owon-smart-Analyse von Anfang 2026 bringt es auf den Punkt: Z2M ist gut, wenn Geräte Abweichungen vom Standard haben, aber jedes Update kann neue Probleme bringen, weil du von Community-Convertern abhängst. ZHA ist konservativer, weniger Geräte, aber die, die unterstützt werden, laufen im Durchschnitt stabiler über Jahre. Für ein produktives Smart Home in einem Haushalt mit Menschen, die den Lichtschalter benutzen wollen, ist Stabilität oft wichtiger als die letzte 2-Euro-Steckdose aus AliExpress.

OTA-Updates: Z2Ms heimliche Stärke

Hier liegt einer der unterschätzten Unterschiede. Zigbee2MQTT hat einen eingebauten, voll funktionalen OTA-Update-Mechanismus. Die offizielle Doku beschreibt ihn im Detail: In der configuration.yaml definiert man einen update_check_interval, Z2M greift auf das von Koenkk gepflegte Zigbee-OTA-Repository zu, und wenn ein Gerät ein Update anfragt, wird es automatisch angeboten. Du kannst per MQTT-Befehl gezielt zigbee2mqtt/bridge/request/device/ota_update/update auf einen IKEA-Aktor loslassen und zuschauen, wie seine Firmware während du Kaffee trinkst aktualisiert wird.

ZHA hat das inzwischen auch, aber eingeschränkt. Es funktioniert, wenn der Hersteller einen standardkonformen OTA-Server definiert, und es funktioniert über zigpy's eigene OTA-Mechanismen für IKEA, Inovelli, Philips und einige weitere. Aber der Umfang und die Bequemlichkeit sind nicht vergleichbar mit Z2M. Wer regelmäßig Firmware seiner Zigbee-Geräte aktuell halten will, sei es für Security-Patches oder Bugfixes, führt mit Z2M das ruhigere Leben.

Wann Z2M, wann ZHA

Lass uns konkret werden. Nach dem jetzigen Stand (April 2026), nach zehntausend Forenthreads und einer Menge Erfahrung echter Nutzer:

Nimm ZHA, wenn du:
  • ein kleines bis mittleres Zigbee-Netz (bis ca. 30-40 Geräte) mit Markenware (Hue, IKEA, Aqara) betreibst
  • ein Einsteiger bist, der nicht mit Mosquitto, MQTT-Topics und Docker kämpfen will
  • ein minimalistisches Setup willst, bei dem alles im Home-Assistant-Prozess lebt
  • deinen SkyConnect oder ZBDongle-E hast und bei Silabs-Firmware bleiben willst
  • Wert auf enge Integration mit Home-Assistant-Features (Geräteregistrierung, Areas, Labels) legst, die in ZHA nativ sind
Nimm Z2M, wenn du:
  • ein größeres Netz (50+ Geräte) oder ein gemischtes mit vielen Tuya- und No-Name-Geräten betreibst
  • auf exotische Geräte angewiesen bist, die Z2Ms 5.290-Zeiler-Liste nutzen
  • Zigbee und Home Assistant voneinander entkoppeln willst (Updates, Neustarts, Backups)
  • den Koordinator per Ethernet remote anbinden willst
  • regelmäßige OTA-Updates deiner Zigbee-Geräte willst
  • ein ConBee III nutzt und nach dem jetzigen Z2M-Refactor die besseren Karten hast
  • bereit bist, mehr Komplexität für mehr Kontrolle einzutauschen

Migrationstools: Hin und zurück

Wer wechseln will, steht vor dem Problem, dass beide Stacks inkompatible Netzwerkschlüssel und Gerätedatenbanken nutzen. Es gibt keinen Knopf "alles übertragen". Was es gibt:

  • ZHA zu Z2M: Ein Community-Skript namens zha2mqtt (auf GitHub unter diversen Forks) überträgt zumindest die Gerätename und Areas, aber die Geräte müssen trotzdem neu angelernt werden. Viele Nutzer berichten, dass sie den Weg trotzdem gehen, weil es ihnen mehr Sinn ergibt. Der Aufwand: je nach Anzahl der Geräte ein bis drei Abende.
  • Z2M zu ZHA: Faktisch noch schwieriger, weil Z2Ms Datenbankformat komplett anders ist. Hier existiert Stand 2026 kein ausgereiftes Migrationstool, und die Community-Empfehlung lautet schlicht: "Geräte neu anlernen."
Die Planungskonsequenz: Die erste Entscheidung zählt. Wer heute mit Zigbee startet, sollte sich eine halbe Stunde Zeit nehmen, den Use-Case durchzudenken, und dann committen. Ein Fehlstart kostet dich hinterher mehr Abende als die ursprüngliche Recherche.

Die Schwachstellen, die niemand zugibt

Damit du nicht nur die Verkaufsseiten zu Gesicht bekommst: Beide Stacks haben Schwachstellen, die ihre jeweiligen Communities gern unter den Tisch kehren.

Z2M-Schwachstellen: Die 2.0.0-Release im Januar 2025 hat eine Menge Legacy-Features entfernt, und viele Nutzer haben nach dem Update festgestellt, dass ihre Geräteerkennung kaputt war, mit der freundlichen Meldung "USB adapter discovery error (No valid USB adapter found)". Der Issue-Thread dazu ist lang. Die permit-join-Funktion ist auf maximal 254 Sekunden limitiert worden, "dauerhaft offen lassen" geht nicht mehr. Und die Abhängigkeit von Community-Convertern bedeutet, dass ein Gerät, das heute funktioniert, nach einem Update plötzlich komisch reagieren kann, weil der Converter umgeschrieben wurde. Das ist selten, aber es passiert. ZHA-Schwachstellen: Neue Gerätetypen haben oft lange Wartezeiten, bis sie offiziell funktionieren. Der ConBee-III-Zwist hat jahrelang geschwelt, ohne dass Endnutzer es verstanden haben, und hat zu vielen frustrierten Forum-Threads geführt. Quirks zu schreiben ist für Nicht-Entwickler unerreichbar, weil es Python-Kenntnisse braucht. Und die enge Kopplung an Home Assistant bedeutet: Wenn HA selbst ein Problem hat, hat dein Zigbee-Netz auch eins.

Das Fazit, das Henrik inzwischen gezogen hat

Nach seinen vier Abenden Neuanlernen hat Henrik nicht auf Z2M gewechselt. Er hat stattdessen sein ZHA-Setup sauber aufgesetzt, Multi-PAN abgeschaltet, einen zweiten SkyConnect für Thread gekauft und ein ordentliches Backup-Skript in n8n angelegt, das jeden Sonntag seine zigbee.db wegspeichert. Er sagt, er habe in der Zwischenzeit gelernt, dass der beste Stack nicht der ist, der das meiste kann, sondern der, mit dem man selber am wenigsten kaputt macht.

Das ist nicht ganz falsch. Die ehrliche Antwort auf "Z2M oder ZHA 2026" ist: Beide sind reif. Beide sind im produktiven Einsatz in zehntausenden Haushalten. Die Frage ist nicht, welcher besser ist, sondern welcher zu deinem Setup passt. Wenn du Schraube und Mutter in der Hand hältst und sicher bist, welche Richtung die Schraube reinmuss, dann kauf dir das richtige Werkzeug. Wenn du dir nicht sicher bist, fang mit ZHA an. Umziehen kannst du später immer noch. Nur weniger gern, als du jetzt denkst.