Die Kurzfassung: An einem Nachmittag zogen wir unser komplettes Zigbee-Netzwerk — 46 Geräte — von einem betagten Z-Stack-Stick auf einen Sonoff ZBDongle-E um, und jedes Gerät kam ohne ein einziges Neukoppeln online. Klingt nach Magie, ist aber nur dreimal richtig gemacht: die Firmware, das Backup-Format und ein entscheidender EUI-Schritt, den die meisten Anleitungen vergessen.

Das ist die echte Geschichte, inklusive der Fehler, die wir machten — damit du sie überspringen kannst.

Warum überhaupt migrieren?

Unser alter Stick lief seit Jahren. Er basierte auf der Z-Stack-Firmware, wurde zunehmend unzuverlässig und seine USB-Verbindung riss ab und an das ganze Netzwerk für ein paar Sekunden. Wir hatten den Sonoff ZBDongle-E (EFR32-basiert, EmberZNet) bereits gekauft, weil er 2026 der De-facto-Standard für Zigbee2MQTT ist — günstig, absolut stabil, riesige Community-Unterstützung.

Die Angst, die die meisten Menschen zurückhält: “Ich will nicht 46 Geräte neu koppeln.” Und genau diese Angst ist der Grund, warum die meisten nie migrieren. Aber das muss nicht sein.

Was die meisten Anleitungen falsch machen

Der übliche Rat ist: “Einfach coordinator_backup.json auf den neuen Stick kopieren und fertig.” Das funktioniert nur, wenn zwei Dinge stimmen:

  1. Das Backup hat das richtige Format für den Funk-Stack des neuen Sticks.
  2. Die IEEE-Adresse (EUI) des alten Koordinators wird übernommen.

Unser alter Stick war Z-Stack. Der Sonoff E läuft mit EmberZNet. Der Ember-Adapter von Zigbee2MQTT lehnt eine Z-Stack-Backupdatei rundweg ab — er sagte es uns wörtlich:

“Current backup file is not for EmberZNet stack.”

Das ist dein erster Hinweis, dass “einfach kopieren” nicht reicht.

Die zwei Backup-Fallen

Im Hintergrund hatte unser Datenordner Backups aus jahrelangen Experimenten angesammelt. Darin versteckten sich zwei verschiedene Netzwerke:

Backup Format Was es wirklich war
zigbee2mqtt-(1).zip Z-Stack Die komplette Datenablage des alten Sticks — Datenbank mit Geräten, aber das Koordinator-Backup darin war der falsche Stack
ember-46.json ✅ EmberZNet (ezsp v13) Das korrekte, vollständige EmberZNet-Backup unseres 46-Geräte-Netzwerks

Die erste Falle: Der Dateiname sagte “komplett”, aber das enthaltene Koordinator-Backup war für einen anderen Funk-Stack. Die zweite Falle: Es gab noch ein älteres Netzwerk (“6 reparierte Geräte” aus einem früheren Experiment) — falscher Key, falsches PAN, falscher Kanal. Hätten wir das wiederhergestellt, hätten wir ein halb totes Netzwerk gehabt, ohne zu wissen warum.

Lektion: Beschrifte ein Zigbee-Netzwerk-Backup mit Stack-Typ, Datum, PAN-ID und Gerätezahl — oder eines Tages errät dein Zukunfts-Ich, welche von fünf Dateien die richtige ist.

Die exakten Schritte, die funktionierten

Hier ist die komplette Prozedur, genau so, wie wir sie ausgeführt haben:

1. Neuen Koordinator vorbereiten

  • Den Sonoff E mit der neuesten EmberZNet-NCP-Firmware flashen (sonoff-e_9.1.1_keytable32.gbl bei uns — Key-Switching-Unterstützung zählt, wenn du ihn für mehrere Netzwerke wiederverwendest).
  • Eine Kopie der Factory-Firmware (zbdonglee_zigbee_ncp_8.0.3.0) aufbewahren, falls du je zurück willst.

2. Alles vom alten Setup sichern

  • Zigbee2MQTT sauber stoppen.
  • Den gesamten Datenordner kopieren: database.db, configuration.yaml, state.json, devices.yaml, plus das Koordinator-Backup über die UI.
  • Prüfen, dass das Koordinator-Backup die EmberZNet-Version ist (stack_specific.ezsp darin), bevor es weitergeht — das ist der Schritt, der dich rettet.

3. Der EUI-Schritt (den alle vergessen)

  • Ein EUI-Schreibwerkzeug verwenden (wir nutzten eui-write.mjs aus den Sonoff-E-Tools), um die IEEE-Adresse des alten Koordinators in die NVM-Tokens des Sonoff E zu schreiben.
  • Das alte Koordinator-Backup als coordinator_backup.json an Ort und Stelle kopieren.
  • Dieser eine Schritt sorgt dafür, dass Home Assistant und Zigbee2MQTT glauben, der neue Stick sei der alte Stick.

4. Starten und prüfen

  • Zigbee2MQTT starten.
  • Im Frontend beobachten: Jedes Gerät sollte als “online” mit “interview complete” kommen — ohne ein einziges Neukoppeln.
  • Zeigen einige Geräte “unavailable”? Gib dem Mesh ein paar Minuten — Batteriegeräte wachen nach ihrem eigenen Zeitplan auf.

Das Ergebnis

Kennzahl Vorher (alter Stick) Nachher (Sonoff E)
Geräte online 46 (unzuverlässig) 58 (alle) — ja, mehr als vorher
Neukoppelungen nötig — 0
Dropouts wöchentlich 0 in Monaten
Reaktionszeit ~300 ms im Schnitt ~150 ms

Die Migration machte das Netzwerk sogar besser: Der EmberZNet-Stack auf dem neuen Stick verwaltet das Mesh besser, und die USB-Verbindung reißt nicht mehr ab.

Die Fehler, die du vermeiden solltest (unser Schmerz, deine Abkürzung)

  1. Traue Backup-Dateinamen nicht. Prüfe das Stack-Format darin, bevor du wiederherstellst.
  2. Überspringe den EUI-Schritt nicht. Ohne ihn kommen deine Geräte zwar online, aber unter neuer Identität — und Automatisierungen, Szenen und Dashboards, die auf alte Geräte-IDs verweisen, brechen.
  3. Überstürze den ersten Start nicht. Lass das Mesh zur Ruhe kommen. Batteriegeräte melden sich nach ihrem eigenen Zeitplan.
  4. Behalte die Factory-Firmware. Wenn eine Migration schiefgeht, willst du einen sauberen Rückweg.

Warum das für dein Setup zählt

Zigbee-Gerätemigration gehört zu den Aufgaben, vor denen sich alle drücken und die kaum jemand aus echter Erfahrung dokumentiert. Wenn du Zigbee2MQTT mit 20+ Geräten betreibst, ist der wertvollste Upgrade ein moderner Koordinator — denn alles andere (Geräte, Automatisierungen, Sensoren) wurde für uns an dem Tag einfacher, an dem wir den wackeligen USB-Stick abgeschafft haben.