Illustration zu Matter over Thread mit SONOFF

Matter over Thread mit SONOFF: IKEA-Geräte, Home Assistant und ioBroker in der Praxis

von

Matter over Thread mit SONOFF klingt erst einmal nach einer sauberen Lösung: Ein Thread-fähiger SONOFF-Dongle (bezahlter Link), Home Assistant als Matter-Zentrale, ioBroker als eigentliches Zielsystem und günstige IKEA-Geräte als praktische Endgeräte. In der Theorie müsste man nur den QR-Code scannen und alles läuft.

In der Praxis wurde daraus ein kleiner Ausflug durch Alexa, Echo, Thread Border Router, OpenThread, Proxmox, LXC, Home Assistant, ioBroker, Matter Server, Thread-Credentials und eine gut versteckte Funktion in der Home Assistant Companion App.

Oder kurz gesagt: Ich wollte eigentlich nur ein IKEA Matter-over-Thread-Gerät koppeln und endete mit einem eigenen OpenThread Border Router im Proxmox-LXC.

Schnellnavigation

Warum ich Matter over Thread mit SONOFF testen wollte

Ich nutze in meinem Smart Home bereits verschiedene lokale Systeme: ioBroker, Home Assistant, MQTT, Zigbee2MQTT und mehrere SONOFF-Dongles (bezahlter Link). Zigbee läuft stabil, Shelly-Geräte sind über lokale Schnittstellen gut integrierbar und vieles lässt sich ordentlich debuggen.

Dann kamen neue IKEA Matter-over-Thread-Geräte ins Spiel. Die Idee dahinter klingt gut: günstige Smart-Home-Geräte, moderner Standard, herstellerübergreifende Steuerung und im Idealfall kein zusätzlicher Hersteller-Hub.

Meine Erwartung war entsprechend simpel:

IKEA Matter-Gerät kaufen, QR-Code scannen, über Alexa oder Home Assistant koppeln und anschließend in ioBroker nutzen.

Da ich bereits Matter-Geräte mit Alexa erfolgreich verbunden hatte, wollte ich zunächst den naheliegenden Weg gehen: Alexa-App öffnen, Gerät hinzufügen, QR-Code scannen. Mein Echo 4. Generation, also die große Kugel, sollte als Thread Border Router dienen.

Das Ergebnis war ernüchternd.

Das Problem mit IKEA Matter-Geräten und Alexa

Andere Matter-Geräte ließen sich problemlos mit Alexa verbinden. Die IKEA Matter-over-Thread-Geräte dagegen nicht zuverlässig. Mal hing der Kopplungsvorgang, mal kam ein Fehler, mal tauchte ein Gerät kurz auf und war danach wieder offline.

Das Problem dabei: Alexa ist an dieser Stelle eine ziemliche Blackbox. Man sieht kaum, was wirklich passiert.

Offen bleiben zum Beispiel diese Fragen:

  • Welches Thread-Netz verwendet der Echo?
  • Gibt es mehrere Thread-Netze im Haushalt?
  • Hat das Gerät überhaupt Thread-Beitritt geschafft?
  • Sind die Thread-Credentials korrekt?
  • Scheitert es an BLE, Thread, IPv6, mDNS oder Matter selbst?
  • Ist das IKEA-Gerät wirklich noch im Pairing-Modus?
  • Hängt das Gerät halb in einer alten Matter-Fabric?

Genau das macht die Fehlersuche frustrierend. Alexa kann zwar grundsätzlich Matter und bestimmte Echo-Geräte können auch Thread Border Router sein, aber für ernsthaftes Debugging ist das zu intransparent.

In Home Assistant wurde später sichtbar, dass tatsächlich mehrere Thread-Netze existierten. Unter anderem ein Amazon-Netz:

AMZN-Thread-c227

und später mein eigenes OpenThread-Netz:

OpenThread-74e5

Genau solche Thread-Inseln sind in der Praxis ein Problem. Ein Gerät hängt dann eventuell in einem Thread-Netz, während ein anderer Controller oder Border Router nichts Sinnvolles damit anfangen kann.

Matter ist nicht automatisch Thread

Ein wichtiger Punkt wird im Marketing oft nicht deutlich genug erklärt: Matter ist nicht gleich Thread.

Matter ist der Smart-Home-Standard auf Anwendungsebene. Die Verbindung darunter kann unterschiedlich aussehen.

Vereinfacht:

Matter over WLAN:
Gerät → WLAN → Router → Matter Controller

Matter over Thread:
Gerät → Thread → Thread Border Router → IPv6/LAN → Matter Controller

Matter-over-WLAN-Geräte sind häufig einfacher einzubinden, weil sie direkt im normalen IP-Netz landen. Matter-over-Thread-Geräte brauchen dagegen ein separates Thread-Funknetz und einen Thread Border Router, der dieses Thread-Netz mit dem normalen IPv6-Netz verbindet.

Das klingt erst einmal harmlos. In der Praxis kommen aber mehrere Schichten dazu:

Matter-Gerät
→ BLE-Ersteinrichtung
→ Thread-Credentials
→ Thread-Netz
→ Thread Border Router
→ IPv6
→ mDNS/Discovery
→ Matter Controller
→ Matter-Fabric

Wenn nur einer dieser Punkte nicht passt, scheitert die Einrichtung. Die Fehlermeldung zeigt aber selten eindeutig, welcher Punkt gerade das Problem ist.

Was ein Thread Border Router wirklich macht

Ein Thread Border Router ist nicht dasselbe wie ein Matter Controller. Das war eine der wichtigsten Erkenntnisse bei diesem Projekt.

Der Thread Border Router stellt nicht einfach „das Gerät in ioBroker bereit“. Er macht im Kern nur diese Aufgabe:

Thread-Funknetz ↔ IPv6/LAN

Er verbindet also das Thread-Funknetz mit dem normalen Netzwerk.

Der Matter Controller ist dagegen die Instanz, die Matter-Geräte anlernt, verwaltet und steuert. In meinem finalen Aufbau war Home Assistant der erste Matter Controller.

Die Rollen sahen am Ende so aus:

SONOFF Dongle Max
= Thread-Radio / RCP

OpenThread Border Router im LXC
= eigentlicher Thread Border Router

Home Assistant
= Matter Controller / Commissioner

ioBroker
= später zusätzlicher Matter Controller per Multi-Admin

Das ist wichtig, weil man sonst schnell denkt: „Ich habe doch einen Thread Border Router, warum kann ich das Gerät nicht einfach dort anlernen?“

Die Antwort ist: Weil das Anlernen eines Matter-Gerätes nicht vom Thread Border Router allein erledigt wird. Dafür braucht man einen Matter Commissioner, der dem fabrikneuen Gerät unter anderem die Thread-Zugangsdaten übergibt.

Warum der SONOFF-Dongle nicht direkt in Home Assistant eingebunden wird

Ein häufiger Denkfehler betrifft die Home-Assistant-Integration Open Thread Border Router.

Diese Integration bindet keinen nackten SONOFF-Dongle (bezahlter Link) direkt an. Sie ersetzt auch keinen Border Router. Sie verbindet Home Assistant lediglich mit der REST-API eines bereits laufenden OpenThread Border Routers.

In meinem Aufbau bedeutet das:

Home Assistant Open Thread Border Router Integration
        ↓ REST API
http://<IP-des-OTBR-LXC>:8081
        ↓
otbr-agent im LXC
        ↓
/tmp/ttyOTBR via socat
        ↓
SONOFF 192.168.0.23:6638

Der SONOFF selbst stellt im Thread-RCP-Modus keine OTBR-REST-API bereit. Er ist nur das Funkinterface beziehungsweise die RCP-Seite. Der eigentliche OpenThread Border Router läuft als Dienst im LXC.

Darum trägt man in Home Assistant nicht die SONOFF-IP ein:

http://192.168.0.23:8081

und auch nicht den RCP-Port:

192.168.0.23:6638

Sondern die REST-API des LXC:

http://<IP-des-OTBR-LXC>:8081

Das ist ein wichtiger Unterschied.

Eine direkte Anbindung über Home Assistant wäre nur möglich, wenn der OpenThread-Border-Router-Dienst direkt in Home Assistant läuft und den Netzwerk-/PoE-Dongle sauber unterstützt. Bei einem USB-Dongle (Anleitung) ist dieser Weg oft naheliegender. Bei meinem SONOFF Zigbee/Thread PoE Dongle Max über TCP war der separate LXC transparenter und besser wartbar.

Mein Zielaufbau mit SONOFF, OTBR-LXC, Home Assistant und ioBroker

Ich wollte meinen vorhandenen SONOFF-Dongle für Zigbee nicht anfassen. Der funktioniert produktiv mit Zigbee2MQTT und bleibt genau so, wie er ist.

Für Thread habe ich einen zweiten SONOFF Zigbee/Thread PoE Dongle Max verwendet.

Der Zielaufbau:

IKEA Matter-over-Thread-Gerät
        ↓ Thread
SONOFF Zigbee/Thread PoE Dongle Max
        ↓ TCP/RCP
OpenThread Border Router im Proxmox-LXC
        ↓ IPv6/LAN
Home Assistant Matter Server
        ↓ optional per Multi-Admin
ioBroker Matter Adapter

Damit war Alexa aus dem Spiel. Das war wichtig, weil ich sonst nie sicher hätte sagen können, welches Thread-Netz gerade verwendet wird.

OpenThread Border Router als LXC in Proxmox installieren

Für den OpenThread Border Router habe ich einen eigenen LXC in Proxmox verwendet. Dadurch bleibt der Aufbau sauber getrennt:

  • Zigbee bleibt produktiv
  • ioBroker bleibt unangetastet
  • Home Assistant muss den Dongle nicht direkt verwalten
  • Logs und Dienste sind im LXC gut sichtbar
  • der Thread Border Router wird zu einer eigenen Infrastrukturkomponente

Ich habe dafür das Community Script für OpenThread Border Router genutzt.

Auf dem Proxmox-Host:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/openthread-border-router.sh)"

Im Script kann man einen kleinen Debian-LXC erstellen. Beispielwerte:

Hostname: openthread-br
CPU: 1 Core
RAM: 1024 MB
Disk: 4–8 GB
Netzwerk: vmbr0
IP: statisch empfohlen

Nach der Installation wechselt man in den Container:

pct enter <CTID>

Die IP des LXC sollte man später fest vergeben, da Home Assistant über diese IP die REST-API des OpenThread Border Routers anspricht.

SONOFF Dongle Max im Thread-RCP-Modus anbinden

Der SONOFF Dongle Max muss im Webinterface auf Thread RCP Mode gestellt werden.

Bei mir hatte der SONOFF die IP:

192.168.0.23

Der aktive RCP-Port war:

6638

Das lässt sich im LXC testen:

nc -vz 192.168.0.23 6638

Ergebnis:

Connection to 192.168.0.23 6638 port [tcp/*] succeeded!

Ein anderer Port, zum Beispiel 6683, war bei mir nicht aktiv:

nc -vz 192.168.0.23 6683

Ergebnis:

Connection refused

Damit war klar:

SONOFF Thread RCP:
192.168.0.23:6638

socat: SONOFF TCP-Port als lokales Gerät bereitstellen

Der otbr-agent wollte bei mir nicht direkt mit der TCP-Adresse arbeiten. Eine Radio-URL wie diese funktionierte nicht:

spinel+hdlc+uart://192.168.0.23:6638?uart-baudrate=115200

Der Fehler war:

Init() at hdlc_interface.cpp:154: No such file or directory

Die Lösung war socat. Damit wird die TCP-Verbindung zum SONOFF als lokales Pseudo-TTY bereitgestellt.

Ziel:

192.168.0.23:6638
        ↓
/tmp/ttyOTBR
        ↓
otbr-agent

Zuerst socat installieren:

apt update
apt install -y socat

Dann einen systemd-Dienst anlegen:

nano /etc/systemd/system/sonoff-rcp-socat.service

Inhalt:

[Unit]
Description=SONOFF Thread RCP TCP to local PTY
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/socat -d -d pty,link=/tmp/ttyOTBR,raw,echo=0,waitslave tcp:192.168.0.23:6638
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Dienst aktivieren:

systemctl daemon-reload
systemctl enable --now sonoff-rcp-socat.service

Prüfen:

systemctl status sonoff-rcp-socat.service --no-pager
ls -l /tmp/ttyOTBR

Wenn /tmp/ttyOTBR existiert, ist die Brücke vom SONOFF zum LXC eingerichtet.

otbr-agent konfigurieren

Die Konfiguration des otbr-agent liegt bei mir in:

/etc/default/otbr-agent

Dort habe ich folgende Optionen gesetzt:

OTBR_AGENT_OPTS="-I wpan0 -B eth0 --vendor-name SONOFF --model-name DongleMax --rest-listen-address 0.0.0.0 --rest-listen-port 8081 spinel+hdlc+uart:///tmp/ttyOTBR?uart-baudrate=115200"

Wichtig waren bei mir auch diese Parameter:

--vendor-name SONOFF
--model-name DongleMax

Ohne diese Angaben brach der Dienst ab mit:

Vendor name must be set.

Danach den Dienst neu starten:

systemctl daemon-reload
systemctl restart otbr-agent
systemctl status otbr-agent --no-pager

Wenn alles passt, sollte otbr-agent aktiv laufen.

Thread-Netz starten und prüfen

Nach dem Start kann der Thread-Zustand geprüft werden:

ot-ctl state

Wenn der Zustand disabled ist, muss das Thread-Netz gestartet werden.

Falls noch kein Dataset vorhanden ist, kann man ein neues erzeugen:

ot-ctl thread stop
ot-ctl ifconfig down

ot-ctl dataset init new
ot-ctl dataset networkname OpenThread-74e5
ot-ctl dataset channel 15
ot-ctl dataset commit active

ot-ctl ifconfig up
ot-ctl thread start

Danach kurz warten:

sleep 10
ot-ctl state

Erwartetes Ergebnis:

leader
Done

Die REST-API des OpenThread Border Routers kann man lokal testen:

curl http://127.0.0.1:8081/node/state

Ergebnis:

"leader"

Damit läuft der OpenThread Border Router.

Thread-Dataset sichern

Das Thread-Dataset sollte man sichern. Es enthält die Betriebsdaten des Thread-Netzes.

Lesbar anzeigen:

ot-ctl dataset active

Als Hex-Wert anzeigen:

ot-ctl dataset active -x

Diese Hex-Zeile ist wichtig, weil Home Assistant an bestimmten Stellen genau diesen Datensatz erwartet.

Falsch ist:

OpenThread-74e5

Richtig ist eine lange Hex-Zeile:

0e080000000000010000000300000f35060004001fffe0...

Nur die Hex-Zeile kopieren, ohne Done, ohne Leerzeichen und ohne Zeilenumbruch.

Home Assistant mit dem OpenThread Border Router verbinden

In Home Assistant wird die Integration Open Thread Border Router hinzugefügt.

Dort muss die REST-API des LXC eingetragen werden:

http://<IP-des-OTBR-LXC>:8081

Beispiel:

http://192.168.0.50:8081

Wichtig: Das ist die IP des LXC, nicht die IP des SONOFF.

Danach sollte unter Thread das neue Netzwerk auftauchen:

OpenThread-74e5

Bei mir war zusätzlich noch ein Amazon-Netz sichtbar:

AMZN-Thread-c227

Das OpenThread-Netz musste als bevorzugtes Netzwerk gesetzt werden.

Außerdem sollte es für Android- und iOS-Zugangsdaten verwendet werden.

Der versteckte Durchbruch: Thread-Credentials aufs Handy synchronisieren

Hier lag am Ende der entscheidende Punkt.

Obwohl der OpenThread Border Router lief, Home Assistant das Thread-Netz sah und das Netzwerk als bevorzugt gesetzt war, scheiterte das Pairing zunächst weiter.

Die Home Assistant App meldete sinngemäß, dass ein Thread Border Router benötigt wird.

Das war irreführend.

Der Border Router war vorhanden. Was fehlte, waren die Thread-Zugangsdaten auf dem Handy.

Beim Matter-over-Thread-Commissioning spielt das Handy eine wichtige Rolle. Es spricht per BLE mit dem neuen Gerät und übergibt ihm die Zugangsdaten zum Thread-Netz. Wenn das Handy diese Zugangsdaten nicht kennt, kann es das Gerät auch nicht korrekt in das Thread-Netz bringen.

Die entscheidende Funktion sitzt in der Home Assistant Companion App:

Einstellungen
→ Companion App
→ Fehlerbehebung
→ Thread-Credentials synchronisieren

Je nach Sprache heißt der Punkt ähnlich:

Thread-Zugangsdaten synchronisieren
Sync Thread credentials

Erst nachdem ich diese Synchronisation durchgeführt hatte, funktionierte das Pairing.

Das war der eigentliche Durchbruch.

IKEA Matter-over-Thread-Gerät koppeln

Danach lief das Pairing über die Home Assistant Companion App.

Ablauf:

1. IKEA-Gerät komplett zurücksetzen
2. Home Assistant Companion App öffnen
3. Gerät hinzufügen
4. Matter-Gerät hinzufügen
5. QR-Code oder Matter-Code vom IKEA-Gerät scannen/eingeben
6. OpenThread-74e5 als Thread-Netz verwenden

Währenddessen kann man im OTBR-LXC beobachten, ob das Gerät dem Thread-Netz beitritt:

watch -n 2 'ot-ctl state; echo "--- children ---"; ot-ctl child table; echo "--- neighbors ---"; ot-ctl neighbor table'

Wenn das Gerät verbunden ist, sollte es in der Child- oder Neighbor-Tabelle auftauchen.

Gerät anschließend in ioBroker übernehmen

Mein eigentliches Zielsystem ist ioBroker. Home Assistant habe ich in diesem Aufbau vor allem genutzt, weil das Matter-over-Thread-Commissioning dort am Ende funktionierte.

Der ioBroker-Matter-Adapter kann Matter-Geräte übernehmen, aber in meinem Fall war der direkte Weg für ein fabrikneues Matter-over-Thread-Gerät nicht praktikabel. Der Adapter erwartete ein bereits verbundenes Matter-Gerät und einen neuen Pairing-Code aus einem anderen Matter-Ökosystem.

Der Ablauf ist daher:

IKEA-Gerät zuerst in Home Assistant koppeln
→ in Home Assistant neuen Matter-Pairing-Code erzeugen
→ diesen Code in ioBroker eintragen

Wichtig:

Für ioBroker darf man dann nicht den originalen IKEA-Code vom Gerät verwenden.

Der originale Matter-Code ist für das erste Commissioning. Für Multi-Admin braucht man einen neuen Code aus Home Assistant.

Typische Fehler und Lösungen

Fehler: Alexa koppelt das IKEA-Gerät nicht zuverlässig

Das war mein Ausgangsproblem. Andere Matter-Geräte funktionierten, die IKEA Matter-over-Thread-Geräte machten Probleme.

Mögliche Ursache:

Alexa/Echo als Thread Border Router ist zu intransparent
Amazon-Thread-Netz ist nicht sauber mit anderen Thread-Netzen verbunden
IKEA Matter-over-Thread ist in Kombination mit Alexa instabil

Lösung in meinem Aufbau:

Alexa aus dem Test entfernen
eigenes OpenThread-Netz mit SONOFF und OTBR-LXC verwenden
Home Assistant als Matter Controller nutzen

Fehler: Vendor name must be set.

Der otbr-agent startet nicht und meldet:

Vendor name must be set.

Lösung:

In /etc/default/otbr-agent folgende Parameter ergänzen:

--vendor-name SONOFF --model-name DongleMax

Fehler: No such file or directory bei direkter TCP-Radio-URL

Der otbr-agent scheitert mit:

Init() at hdlc_interface.cpp:154: No such file or directory

Ursache:

Die direkte TCP-Radio-URL wurde nicht korrekt als UART-Quelle akzeptiert.

Lösung:

socat verwenden:

SONOFF TCP-Port → /tmp/ttyOTBR → otbr-agent

Fehler: non-hexadecimal number found in fromhex()

In Home Assistant wurde versehentlich der Netzwerkname eingetragen:

OpenThread-74e5

Home Assistant erwartete aber den Hex-Datensatz.

Lösung:

ot-ctl dataset active -x

Die lange Hex-Zeile kopieren und eintragen.

Fehler: Discovery timed out

Der Matter Server findet das Gerät beim Commissioning nicht.

Mögliche Ursachen:

Gerät nicht korrekt zurückgesetzt
Gerät nicht im Pairing-Modus
Handy kennt Thread-Credentials nicht
BLE-Commissioning scheitert
falsches Thread-Netz

Bei mir war die Lösung:

Thread-Credentials in der Home Assistant Companion App aufs Handy synchronisieren

Fehler: Thread-Netz steht wieder auf disabled

Prüfen:

ot-ctl state

Starten:

ot-ctl ifconfig up
ot-ctl thread start

Falls kein Dataset mehr vorhanden ist:

ot-ctl dataset init new
ot-ctl dataset networkname OpenThread-74e5
ot-ctl dataset channel 15
ot-ctl dataset commit active

Nützliche Befehle

Status des otbr-agent:

systemctl status otbr-agent --no-pager

Status der socat-Bridge:

systemctl status sonoff-rcp-socat.service --no-pager

Thread-Zustand:

ot-ctl state

Thread-Dataset anzeigen:

ot-ctl dataset active

Thread-Dataset als Hex:

ot-ctl dataset active -x

REST-API lokal prüfen:

curl http://127.0.0.1:8081/node/state

REST-API von außen prüfen:

curl http://&lt;IP-des-OTBR-LXC>:8081/node/state

Thread-Geräte anzeigen:

ot-ctl child table
ot-ctl neighbor table
ot-ctl router table

Sollte man Matter over Thread mit SONOFF so nachbauen?

Wenn man einfach nur stabile Smart-Home-Geräte möchte, würde ich aktuell noch vorsichtig sein.

Für ein produktives Smart Home sind Zigbee2MQTT, Shelly/MQTT oder Matter-over-WLAN oft deutlich stressfreier.

Wenn man aber verstehen will, wie Matter over Thread mit SONOFF, OpenThread, Home Assistant und ioBroker wirklich zusammenspielt, ist dieser Aufbau extrem lehrreich.

Man lernt dabei sehr schnell:

Matter ist nicht automatisch Thread.
Thread Border Router ist nicht gleich Matter Controller.
Der SONOFF ist nur das Thread-Radio.
Die OpenThread-Border-Router-Integration in HA braucht eine REST-API.
Ein funktionierender Border Router reicht nicht.
Das Handy braucht ebenfalls die Thread-Credentials.
Alexa ist als Thread-Infrastruktur sehr intransparent.

Für Bastler, Homelab-Freunde und Smart-Home-Nerds ist das spannend. Für normale Nutzer ist es aktuell noch zu viel Krampf.

Fazit

Mein ursprünglicher Plan war simpel:

IKEA Matter-Gerät kaufen, Alexa-App öffnen, QR-Code scannen, fertig.

Die Realität sah anders aus:

Alexa koppelte die IKEA-Geräte nicht zuverlässig.
Der Echo als Thread Border Router war zu intransparent.
Ein eigener SONOFF/OpenThread-Border-Router funktionierte.
Home Assistant erkannte das Thread-Netz.
Das Pairing scheiterte trotzdem, bis die Thread-Credentials aufs Handy synchronisiert wurden.
ioBroker konnte das Gerät danach per Multi-Admin übernehmen.

Die wichtigste Erkenntnis lautet:

Matter over Thread scheitert in der Praxis oft nicht am Funkstandard, sondern am Commissioning.

Thread selbst lief am Ende. Der SONOFF-Dongle funktionierte. Der OpenThread Border Router lief. Das eigentliche Problem war das Zusammenspiel aus Matter, BLE, Thread-Credentials, Companion App, Controller und Border Router.

Oder anders gesagt:

Ich wollte nur ein IKEA-Gerät koppeln und endete mit einem eigenen Thread Border Router im Proxmox-LXC.

Für Nerds spannend. Für „einfach Smart Home“ aktuell noch ziemlich weit weg.

FAQ zu Matter over Thread mit SONOFF

Kann ich einen SONOFF Zigbee/Thread PoE Dongle Max direkt in Home Assistant als Thread Border Router nutzen?

Nicht direkt über die Home-Assistant-Integration Open Thread Border Router. Diese Integration verbindet Home Assistant nur mit der REST-API eines bereits laufenden OpenThread Border Routers. Der SONOFF im Thread-RCP-Modus ist nur das Funkinterface. Der eigentliche Border Router muss als Dienst laufen, zum Beispiel in einem Proxmox-LXC oder als Home-Assistant-Add-on, sofern der Dongle unterstützt wird.

Welche URL muss ich in Home Assistant für den Open Thread Border Router eintragen?

In Home Assistant wird die REST-API des OpenThread-Border-Router-Dienstes eingetragen, nicht die IP des SONOFF-Dongles. Beispiel:

http://&lt;IP-des-OTBR-LXC>:8081

Der SONOFF-RCP-Port wie 192.168.0.23:6638 ist keine REST-API und gehört dort nicht hinein.

Warum braucht ein Matter-over-Thread-Gerät Bluetooth?

Bluetooth wird beim ersten Commissioning genutzt. Das fabrikneue Gerät kennt das Thread-Netz noch nicht. Die Home Assistant Companion App spricht per BLE mit dem Gerät und übergibt ihm die Thread-Credentials. Danach kommuniziert das Gerät über Thread.

Warum meldet Home Assistant „Thread Border Router benötigt“, obwohl einer vorhanden ist?

Diese Meldung kann irreführend sein. In meinem Fall war der Border Router vorhanden, aber das Handy kannte die Thread-Credentials noch nicht. Erst nach dem Synchronisieren der Thread-Credentials in der Home Assistant Companion App funktionierte das Pairing.

Wo synchronisiert man Thread-Credentials in Home Assistant?

In der Home Assistant Companion App:

Einstellungen
→ Companion App
→ Fehlerbehebung
→ Thread-Credentials synchronisieren

Je nach Sprache kann der Menüpunkt leicht anders heißen.

Kann ich IKEA Matter-over-Thread-Geräte direkt in ioBroker koppeln?

In meinem Test war das nicht praktikabel. Der ioBroker-Matter-Adapter konnte Geräte übernehmen, die bereits in einem anderen Matter-System verbunden waren. Das erstmalige Commissioning des fabrikneuen Thread-Gerätes funktionierte dagegen über Home Assistant. Danach konnte das Gerät per Multi-Admin-Code zu ioBroker hinzugefügt werden.

Sollte man statt Matter over Thread lieber Zigbee verwenden?

Für ein stabiles produktives Smart Home ist Zigbee2MQTT aktuell oft einfacher und transparenter. Matter over Thread ist technisch spannend, aber das Commissioning ist noch deutlich komplexer als bei Zigbee.

Passende Smart-Home-Artikel auf Prokrastinerd

Wenn dich das Thema lokale Smart-Home-Integration interessiert, passen dazu auch einige meiner anderen Beiträge. Im Artikel Smart Home ohne Hersteller-App zeige ich, warum lokale Steuerung oft angenehmer ist als App-Zwang und Cloud-Abhängigkeit. Wie schnell aus einer vermeintlich simplen Idee ein größeres Projekt wird, beschreibe ich in Eine einfache Automation ist selten einfach. Wer Matter eher aus der Shelly-Richtung betrachtet, findet in Shelly Power Strip 4 Gen4 im Test – Smart-Home-Steckdosenleiste mit Matter, Zigbee und MQTT weitere Praxisbeispiele. Für klassische lokale Automationen ohne Cloud passt außerdem Shelly Direktverknüpfung – lokale Automationen ohne Cloud (mit Beispiel). Und wenn es eher um das Finden passender Geräte für dein Smart Home geht, ist Smart Home Geräte finden: Der Gerätefinder für dein Zuhause eine passende Ergänzung. Für eine generelle Übersicht zum Thema Cloudfreise Smart Home, solltest du dir Smart Home ohne Cloud anschauen.

Schreibe einen Kommentar