Matter/Thread] Multi-Fabric Chaos: Google Home, Alexa, Aqara, Smart Things Home Assistant – Pairing landet immer im falschen Thread-Netz

[HomeAssistent]

Hi zusammen,

ich bin inzwischen ziemlich verzweifelt und hoffe auf Einschätzungen von Usern mit tiefer Matter/Thread-Erfahrung. Dies ist mein erster Post – falls ich im falschen Unterforum gelandet bin, bitte ich die Admins um ein kurzes Verschieben.

Das Kernproblem:

Ich versuche, Matter-over-Thread stabil mit Home Assistant zu nutzen, scheitere aber an einem massiven Multi-Fabric-/Multi-Controller-Problem. Beim Pairing-Prozess (egal ob via HA oder Google Home) wird immer wieder versucht, das Aqara Thread Network (AqaraHome-xxxx) zu kontaktieren, obwohl dieses eigentlich gar nicht mehr existieren sollte.

Das passiert konkret:

Pairing-Prozess startet (Google Home oder HA).

Matter-Anmeldedaten werden generiert.

System meldet: “Versuche Aqara Thread Network zu kontaktieren…”

Pairing läuft ins Leere und scheitert.

Das Kuriose: Der Aqara Hub M3 ist stromlos, die App gestoppt und ein neues HA-Thread-Netzwerk ist als bevorzugt gesetzt. Dennoch “erzwingt” Android diesen Pfad.

Mein Setup

Komponente Details

HA Version Core 2026.1.3 / OS 17.0 / Supervisor 2026.01.1

Plattform Proxmox VM auf Mini-PC

Funk-Hardware SLZB-MR3 (OpenThread Border Router Add-on aktiv)

Anbindung LAN an Fritz-Repeater

Handys Pixel & Samsung S24 Ultra (gleicher Google Account)

Erkannte Netzwerke in der Umgebung:

ha-thread-xxxx (Home Assistant)

NEST-PAN-5137 (Google Nest)

AMZN-Thread-xxxx (Amazon Echo)

ST-TIZEN (Samsung)

AqaraHome-xxxx (Kein aktiver Border Router, trotzdem präsent!)

Bisherige Lösungsversuche

Mehrfach neue Thread-Netzwerke in HA erstellt und Credentials an Handys gesendet.

Google Home, Aqara, SmartThings & Alexa Apps gestoppt + Cache gelöscht.

Bluetooth neu initialisiert, Geräte auf Werkseinstellungen.

Aktuelle Erkenntnis: Viele Matter-Geräte hängen im Google Network (NEST-PAN-00000l). HA agiert hier offenbar nur als Matter-Client, nicht als Thread-Owner. Das erklärt die Sichtbarkeit, aber nicht den “Aqara-Zwang”.

Meine Fragen an euch

By Design? Ist dieses “Erzwingen” einer alten Fabric ein bekanntes Android/Matter-Problem im Google-Play-Services-Speicher?

Owner-Frage: Gibt es einen sauberen Weg, Google als Thread-Owner zu behalten, ohne dass die Aqara/Samsung-Fabrics permanent dazwischenfunken?

Clean Sweep: Übersehe ich eine zentrale Stelle (außerhalb der Apps), an der alte Thread-Credentials im Google-Konto/Android-System endgültig gelöscht werden können?

Mein Ziel ist ein stabiles Multi-Admin-Setup: HA als Zentrale, Google/Alexa als Backup (kein Single-Point-of-Failure).

Ich bin für jede fundierte Einschätzung dankbar – gern auch mit der ehrlichen Antwort: “Das ist aktuell einfach noch nicht stabil.”

Beste Grüße!

Zusatzbaustellen bei mir falls jemand ähnliche Probleme bereits gelöst hat:

• wie SLZB-MR3 Ausfälle (muss den Stecker ziehen und App startet nicht zuverlässig trotz Watchdog),
• Aqara FP2 (HomeKit) fällt häufig aus oder
• Reolink-Passwort-Resets klappt nicht richtig und man wirdhabe ich auf dem Schirm, würde den Fokus hier aber gern erst auf Matter/Thread lassen.)

[miami]

Hast du die Geräte auch in Werkseinstellung resettet, bevor Du sie neu verbinden willst.? Bei Matter kann man die mit dem aufgedruckten QR-Code nur mit einer Fabric verbinden. Alle weiteren Fabrics dann über einen Code den die erste Fabric bereitstellt.

Matter

[HomeAssistent]

Ja, das ist der Initiale Prozess mit dem originalen Matter Code. Resetet wurden die Geräte auch. Das Problem ist, dass ich bei Android in den verschieden Handys unterschiedliche bevorzugte Thread Netzwerke habe. Bei dem einen Handy passt es auch, kann aber keine Verbindung herstellen, nachdem die Matter Anmeldedaten generiert wurden.

[HomeAssistent]

Hi Zusammen,

Auf meinem Samsung Handy funktioniert es weiterhin nicht. Auf dem Pixel Handy hat es nun zumindest das richtige Home Assistant thread Netzwerk gewählt. Das funktioniert leider auch nicht. Ich habe die KI einmal gebeten die Unterhaltung zusammen zu fassen. Wir bzw ich

System & Setup (Kurzüberblick)
Home Assistant OS: 17.0
Home Assistant Core: 2026.1.3
OTBR Add-on: 2.16.0
Thread-Version: 1.3
Hardware:
SLZB-MR3 (Dual-Chip: Zigbee + Thread)
FRITZ!Box 5690 Pro
FRITZ!Repeater (LAN-Bridge)
Smartphone: Google Pixel (Thread-fähig)
Matter-Geräte: u. a. Aqara Matter Remote
Netzwerk:
HA per Ethernet
SLZB-MR3 per Ethernet (kein WLAN)
Ziel
Home Assistant als primärer Matter Commissioner
Eigenes Thread-Netz über OTBR
Keine Abhängigkeit von Alexa / Google / Aqara Hubs
Ausgangsproblem
Matter-Geräte lassen sich nicht stabil über Home Assistant anlernen
Commissioning bricht ab mit:
„Keine Verbindung zum Thread-Netzwerk möglich“
„Prüfe, ob dein Gerät diesen Netzwerktyp unterstützt“
Bereits durchgeführte Maßnahmen (chronologisch)
Thread-/Matter-Umgebung bereinigt
Amazon Echo stromlos
Google Nest Hub stromlos
Aqara Hub stromlos
Keine weiteren aktiven Thread Border Router im Netz
Home Assistant bereinigt
Zigbee2MQTT gestoppt
OTBR Add-on mehrfach neu gestartet
Keine parallelen Thread-Stacks aktiv
Smartphone / Companion App
Home Assistant Companion App → Problemlösung
Thread-Zugangsdaten synchronisiert
Pixel zeigt korrekt das HA-Thread-Netz
Commissioning startet, bricht aber beim Verbindungsaufbau ab
WLAN-Optimierung (FRITZ!Box)
2,4 GHz WLAN manuell fixiert
Finales Setup:
WLAN: Kanal 1
5 GHz & 6 GHz aktiv
Gastnetz nicht aktiv genutzt
WLAN-Auslastung laut FRITZ!Box moderat, kein Extrempegel
Thread-Kanal-Anpassung
Ursprünglich: Thread Kanal 15
Umgestellt auf: Thread Kanal 20
Hinweis: HA zeigt an, dass der Kanalwechsel bis zu 5 Minuten (teils länger) benötigt
Aktueller Stand: Thread bleibt über Nacht auf Kanal 20, um Einpendelphase abzuwarten
Physische Umpositionierung (wichtig)
SLZB-MR3 war ursprünglich:
nahe an Switch / Repeater / Router
Aktuell:
ca. 1 Meter Abstand
hinter einer Wand positioniert
weiterhin per LAN angebunden
Aktuelle OTBR-Logs (anonymisiert, exemplarisch)
Code kopieren
Text
[NOTE]-AGENT—: Thread version: 1.3.0
[NOTE]-AGENT—: Thread interface: wpan0
[NOTE]-ILS-----: Infra link selected: enp0s18

[W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure
[N] MeshForwarder-: Failed to send IPv6 UDP msg
error: NoAck

[W] P-RadioSpinel-: Error processing result: NoAddress
[W] DuaManager----: Failed to perform next registration: NotFound

[Mle-----------]: Role detached → leader
[NOTE]-BBA-----: Backbone Router becomes Primary
Interpretation (aktueller Stand)
OTBR startet sauber
SLZB-MR3 wird korrekt erkannt
Thread-Netz wird erstellt (Leader-Rolle aktiv)
Aber:
Funkseitig instabile Kommunikation
Geräte/Router antworten nicht zuverlässig
NoAck, ChannelAccessFailure, NoAddress wiederkehrend
Aktueller Status (Stand jetzt)
WLAN stabil
Keine konkurrierenden Thread Border Router aktiv
SLZB-MR3 physisch entkoppelt
Thread auf Kanal 20
Abwarten über Nacht, ob sich:
ChannelAccessFailure reduziert
Mesh stabilisiert
Commissioning anschließend funktioniert
Offene Fragen an die Community
Erfahrungen mit SLZB-MR3 + OTBR:
Bevorzugte Thread-Kanäle (15ll vs. 20 vs. 16)?
Bekannte Probleme mit:
Ethernet-angebundenen Thread-RCPs nahe Switches?
Ist ein kompletter Thread-Reset (Dataset löschen) der empfohlene nächste Schritt, falls Kanal 20 keine Besserung bringt?

[HomeAssistent]

Hi Zusammen,
nachdem ich nahezu ein komplettes Wochenende damit verbracht habe, Thread und Zigbee parallel stabil über einen SMlight SLZB-MR3 in Home Assistant zum Laufen zu bekommen, möchte ich meine final funktionierende Lösung teilen.
Vielleicht hilft das anderen, die aktuell im gleichen Thread-/Zigbee-Dschungel feststecken.

---

Ausgangssituation

• SLZB-MR3 per Ethernet angebunden

• Nutzung gleichzeitig für Zigbee und Thread

• Zigbee lief von Anfang an stabil

• Thread war extrem instabil (wechselnde Netzwerke, Commissioner-Chaos)

Parallel vorhanden (und problematisch):

• FRITZ!Box

• Aqara Hub (Thread)

• Google Nest

• Amazon Echo

• Samsung SmartThings

→ mehrere konkurrierende Thread Border Router / Commissioner

---

Finale funktionierende Architektur

1. Klare Trennung von Zigbee und Thread

Der entscheidende Schritt war eine saubere Trennung der Zuständigkeiten:

Zigbee

• SLZB-MR3 nicht mehr über Ethernet

• Stattdessen USB-Anbindung

• USB-Device in Proxmox direkt an die Home-Assistant-VM durchgereicht

• Ergebnis: absolut stabil

Thread

• SLZB-MR3 ausschließlich über Ethernet

• Keine parallele USB-Nutzung für Thread

Zigbee (USB) + Thread (Ethernet) gleichzeitig über denselben SLZB-MR3 – aber klar getrennt.

---

SLZB-MR3 WebUI – Konkrete Einstellungen (sehr wichtig)

2. Verbindungsmodus

Auswahlmöglichkeiten:

• Ethernet-Verbindung

• WLAN-Verbindung

• USB-Verbindung

Genutzt:
Ethernet-Verbindung

---

3. WLAN/Ethernet & USB-Modus

• „WLAN/Ethernet-Netzwerk und Webserver im USB-Modus eingeschaltet lassen“
  → aktiviert

Das ist wichtig, damit WebUI und Netzwerkkommunikation auch bei internen Umschaltungen stabil bleiben.

---

4. Auswahl: Verbindungsmodus für Radio und USB

Einer der kritischsten Punkte:

• EFR32MG24 (Hardwareverbindung) – deaktiviert

• EFR32MG24 (Softwareverbindung) – deaktiviert

• CC2674P10 (Softwareverbindung) – aktiv / ausgewählt

Nur mit dieser Kombination war es bei mir möglich, Thread (Ethernet) und Zigbee (USB) parallel stabil zu betreiben.
Alle Hardware-Varianten oder EFR32-Routings führten zu instabilem Verhalten oder Thread-Problemen.

---

Wichtiger Zusatz: Matter-over-Thread Firmware / Revision

Für Matter-over-Thread am SLZB-MR3 ist die Revision entscheidend:

• Revision: 20250212 → funktioniert

• Revision: 20251218 → hat bei mir partout nicht funktioniert

Auffällig:

• Die Revision 20251218 ist nicht gelb hervorgehoben, im Gegensatz zu allen anderen DEV-Firmware-Varianten.

Empfehlung:
Wenn Matter-over-Thread Probleme macht: Revision prüfen und auf 20250212 wechseln.

---

Funk & Umgebung optimieren

5. Platzierung & Kanäle

• SLZB-MR3 möglichst weit weg von:

  • FRITZ!Box

  • Aqara Hub

  • anderen Zigbee-/Thread-Hubs

WLAN 2,4 GHz

• fest auf Kanal 1. Schaut hier einmal in eure FB-Kanalansicht. Die ist sehr hilfreich.

Zigbee

• Kanal 20 lief deutlich stabiler als 15

---

Thread-Netzwerke & Commissioner-Problematik

6. Mehrere Thread-Netzwerke = Hauptursache

Das größte Problem war nicht Home Assistant, sondern Android-Geräte, die unterschiedliche Thread-Netzwerke bevorzugen.

Samsung S24 Ultra

• bevorzugt weiterhin Aqara Thread Network

• nicht entfernbar

• selbst nach:

  • Cache & Speicher löschen

  • Google Home entfernen

  • Aqara deaktivieren
    → keine saubere Lösung gefunden

Auf diesem Gerät kein zuverlässiges Re-Pairing möglich.

---

7. Workaround: Zweites Android-Gerät

Der Durchbruch kam über ein älteres Google Pixel:

• Dort war es möglich:

  • das Home-Assistant-Thread-Netzwerk zu übernehmen

  • Matter-Geräte sauber zu pairen

---

8. Thread-Credentials & Home Assistant

Zwischendurch habe ich:

• ein neues HA-Thread-Netzwerk erstellt

• das bestehende zurückgesetzt

Theorie:

• Thread-Credentials lassen sich über die HA Companion App synchronisieren:

  • Einstellungen → Companion App → Fehlerbehebung/Problemlösung → Thread-Credentials synchronisieren

Praxis:

• Mit dem neu erstellten Thread-Netzwerk hat das nicht funktioniert.

• Lösung:

  • HA-Backup einspielen, in dem das ursprüngliche Thread-Netz noch vorhanden war und hier muss es natürlich für die Anmeldung über iOS und Android genutzt werden und es muss dann explizit wieder als bevorzugtes Netzwerk ausgewählt werden.

  • Erst damit konnte sich das Google Pixel korrekt verbinden

Hinweis:
Selbst wenn Aqara-Hubs stromlos sind, behalten Android-Geräte deren Thread-Netz teilweise weiterhin bei.
Bei mir hat es ~8 Stunden gedauert, bis das Pixel wieder sauber auf das HA-Thread-Netz gewechselt ist.

---

Aufräumen anderer Ökosysteme

9. SmartThings / Google / Amazon

• In Samsung SmartThings:

  • alle Hubs (TVs, Monitore etc.) hart gelöscht

• Andere Thread-Border-Router:

  • mehrere Stunden stromlos lassen

Ergebnis:

• Google Nest & Amazon Echo verschwanden nach einiger Zeit automatisch aus Home Assistant

• Aqara Hub:

  • taucht weiterhin als Thread-Netzwerk auf

  • selbst stromlos

  • lässt sich bei mir einfach nicht dauerhaft entfernen
    → aktuell ignorieren

---

Hinweis zu IKEA Bilresa Fernbedienungen

Kleiner, aber wichtiger Praxis-Hinweis:

• Die IKEA Bilresa Fernbedienungen haben innen einen Magneten

• Dieser kann die Batterien minimal aus der Position ziehen

Symptome:

• In Home Assistant als „schläfriges Endgerät“

• Teilweise reagieren sie nach Inaktivität erst nach mehreren Minuten

Kein Thread- oder Zigbee-Bug, sondern Kontaktproblem der Batterien.

---

Fazit

• Trennung von Zigbee (USB) und Thread (Ethernet) war der Gamechanger für mich

• Software-Mode & CC2674P10 im SLZB-MR3 zwingend erforderlich

• Matter-o-Thread-Revision 20250212 nutzen

• Android-Geräte sind aktuell der größte Unsicherheitsfaktor bei Thread und mein aktuelles Handy kann ich nicht nutzen für das Pairen

• Ein zweites (älteres) Android/iOS-Gerät kann extrem helfen

• Geduld ist bei Thread leider offensichtlich Teil der Lösung, auch wenn ich nicht wirklich zu den Geduldigen gehöre

Ich hoffe, das hilft anderen weiter und erspart ein sehr langes Wochenende, wenn man diese Punkte durchgeht.
Fragen beantworte ich gern - sofern ich es kann :).

Beste Grüße
Euer HomeAssistent