Warum mein Thread Border Router ständig abstürzte

Um auch im Winter im Büro nicht zu frieren und gleichzeitig die Heizkosten im Rahmen zu halten, wollte ich Home Assistant bei der Arbeit in Betrieb nehmen. Dafür setze ich auf einen Windows-Server mit Hyper-V, Bosch-Matter-over-Thread-Thermostate und einen SONOFF Dongle Max.

Kurz nach dem Aufbau brach OTBR wiederholt ab, obwohl ich bereits zwei Thermostate anlernen konnte und diese zeitweise funktionierten. Die Logmeldung sprach von RCP device disconnected (EOF). Erst mit einem Downgrade auf den OpenThread Border Router 3.0.2 konnte ich sämtliche Geräte anlernen. Seitdem ist der Fehler nicht mehr aufgetreten.

Problematisch ist ein solcher Ausfall, weil der OpenThread Border Router das Thread-Funknetzwerk mit dem normalen IP-Netzwerk verbindet. Er bildet damit in meinem Aufbau die Brücke, über die Home Assistant mit den Thread-Geräten kommunizieren kann.

In diesem Artikel zeige ich dir, auf welche Probleme ich bei der Fehlersuche gestoßen bin, welche Lösungsansätze nicht funktioniert haben, wie ich das Downgrade durchgeführt habe und wie sich die Verbindung anschließend verhalten hat.

Meine Ausgangssituation: Home Assistant, Hyper-V und SONOFF Dongle Max

Anders als in meinem Homelab habe ich mich bei der Einrichtung im Büro für eine andere Infrastruktur entschieden. Wir nutzen einen Windows Server mit Hyper-V, eine HAOS-VM und den SONOFF Dongle Max als Thread-RCP über Ethernet. Der Grund für Windows als Basis ist, dass der Windows Server bereits im Netzwerk aktiv ist und ausreichend Kapazität für eine solche Umgebung bietet. Ein zusätzlicher Server ist daher nicht nötig.

Um die Besonderheiten zwischen meinem eigenen Smart Home und der Büro-Umgebung zu zeigen, habe ich sie in einer Tabelle gegenübergestellt. Die Versionen beziehen sich auf den Zeitpunkt der Entstehung dieses Artikels (18.10.2026):

In meinem Homelab nutze ich statt des OTBR den Weg über MultiPAN. Dabei handelt es sich um eine andere Herangehensweise mit unterschiedlichen Softwarekomponenten, deren Versionsnummern sich nicht direkt miteinander vergleichen lassen. Deshalb sind sie in der Tabelle getrennt aufgeführt.

Als Thread-RCP (Radio Co-Processor) stellt der SONOFF Dongle Max die Funkschnittstelle zu den Geräten bereit. Für die Netzwerklogik des Thread-Netzwerks ist der OTBR (OpenThread Border Router) verantwortlich. Er verwendet den RCP und vermittelt zwischen Thread und dem restlichen Netzwerk. Der Matter-Server hingegen versteht das Matter-Protokoll. Er übernimmt die Matter-seitige Einbindung und Kommunikation der Geräte.

Vereinfacht lässt sich das Zusammenspiel der einzelnen Komponenten folgendermaßen darstellen:

Nutzer -> (sendet Befehl) -> Matter-Server -> (Matter-Kommunikation) -> OTBR -> (leitet IP-Pakete weiter) -> Thread-RCP -> (überträgt per Funk) -> Thermostat

RCP device disconnected (EOF): So zeigte sich der Fehler

Beim Anlernen neuer Matter-Geräte über die Companion-App von Home Assistant brach die OTBR-RCP-Verbindung ab. Die OTBR-App beendete sich und startete daraufhin neu. Eine zeitweise erfolgreiche Verbindung erschwerte das Problem, da sie keine Stabilität beweisen konnte und die Logs nach dem Abbruch auch nicht automatisch die Ursache gezeigt haben.

Während der OTBR einen Verbindungsverlust zum RCP meldete, zeigte der SONOFF Dongle Max, dass eine TCP-Verbindung von der Gegenseite geschlossen wurde. Beide Meldungen deuteten auf ein Problem in der Kommunikation zwischen OTBR und RCP hin. Welche Komponente den Abbruch tatsächlich verursachte, ließ sich daraus jedoch nicht eindeutig ableiten. Ich vermutete deshalb zunächst ein Problem in der Kommunikation zwischen OTBR und Thread-RCP und hatte insbesondere das Netzwerk und Hyper-V im Verdacht.

Im OTBR-Log erschien unter anderem folgende Fehlermeldung:

00:00:16.292 [C] Platform------: exit(1): Read line 207, RCP device disconnected (EOF), Failure

Auch auf dem SONOFF Dongle Max waren TCP-Verbindungsabbrüche protokolliert:

E (843994) tcp_server: TCP connection closed by peer
W (851345) tcp_server: Incoming connection from 10.XX.XX.XXX

Nachdem die Verbindung wiederhergestellt wurde, blieben jedoch die Matter-Geräte in Home Assistant im Zustand unknown stecken. Das deutete darauf hin, dass trotz wieder laufender Apps die Kommunikation mit den Geräten weiterhin gestört war. Ein über die Home-Assistant-Oberfläche ausgelöster Ping blieb entweder erfolglos oder ging mit einem erneuten Verbindungsabbruch zwischen OTBR und Thread-RCP einher.

Was ich gegen die OTBR-Abbrüche ausprobiert habe

Als Erstes überprüfte ich die Verbindung zum SONOFF Dongle Max. Dazu habe ich über Remote Desktop auf dem Windows Server einen Netzwerk-Ping gestartet und den TCP-Port 6638 überprüft. Beide waren erreichbar, was ein erstes positives Signal war. Ein Beweis war das jedoch nicht. Denn damit wusste ich noch nicht, wie sich der Dongle während eines Pairing-Versuchs verhält.

Ein weiterer Ansatzpunkt war es, unter Hyper-V VMQ (Virtual Machine Queue) testweise zu deaktivieren, die VM neu zu starten und das Verhalten erneut auszuprobieren. Bei bestimmten Kombinationen aus Netzwerkkarte, Treiber und Hyper-V-Konfiguration kann VMQ zu Netzwerkproblemen beitragen. Eine Verbesserung brachte die Deaktivierung allerdings nicht. Auch ein Paketmitschnitt mit Pktmon lieferte keinen eindeutigen Ursachenbefund.

Im nächsten Schritt griff ich zu härteren Maßnahmen und baute das Thread-Netzwerk neu auf. Zunächst schien das Abhilfe zu schaffen, dauerhaft löste jedoch auch diese Maßnahme das Problem nicht. Und so testete ich eine neue IP-Adresse für den SONOFF Dongle Max, was mich zuerst hoffnungsvoll stimmte. Schlussendlich war das jedoch auch nicht die Lösung.

Warum mich gerade diese Änderung zunächst so hoffnungsvoll gestimmt hat und was ich dabei beobachtet habe, erzähle ich ausführlicher in meinem Newsletter.

Am Tag darauf trat der Verbindungsfehler wieder auf und beschäftigte mich erneut. Es wurde zunehmend schwieriger, weitere sinnvolle Maßnahmen zu finden. Auch meine Recherche im Netz lieferte zunächst nur wenige Hinweise auf mögliche Fehlerquellen.

Ebenso wenig Erfolg brachte der Austausch des Netzwerkkabels, ein Wechsel des Switchports und die Nutzung einer separaten Stromversorgung. Bis dahin habe ich den Dongle über PoE betrieben.

Warum ich verschiedene OTBR-Versionen getestet habe

Nachdem meine Untersuchungen von Hyper-V und Netzwerk erfolglos geblieben waren, wollte ich eine andere Hypothese testen: Könnte die eingesetzte OTBR-Version für die Verbindungsabbrüche verantwortlich sein?

Die Hypothese kam im Zusammenhang mit einer Recherche durch mich und ChatGPT zustande. Wir haben nach ähnlichen Fehlerbildern gesucht und es gab auf GitHub einen Fehlerbericht, der ähnliche Probleme schilderte^[Quelle]. Hinzu kam noch ein weiterer Fehlerbericht in einer Community, der ebenfalls Verbindungsprobleme mit dem SONOFF Dongle Max schilderte^[Quelle]. Deshalb wollte ich durch einen gezielten Versionswechsel überprüfen, ob sich die Verbindungsabbrüche damit beheben lassen.

Gestützt wurde diese Hypothese vor allem durch das GitHub-Issue, in dem Version 3.0.2 als stabil beschrieben wurde. In meinem eigenen Smart Home ist das bislang nicht aufgefallen, weil hier ein anderer technologischer Stack genutzt wird. Der Vergleich zeigte mir jedoch, dass sich die beiden Umgebungen insbesondere bei der Thread-Anbindung unterscheiden. Deshalb wollte ich gezielt untersuchen, welchen Einfluss die OTBR-Version auf die Verbindungsabbrüche haben könnte.

Ebenso interessant am GitHub-Issue war, dass der Nutzer eine Proxmox-VM einsetzt. Das Verhalten schien demnach auch nicht zwangsläufig mit Hyper-V zu tun zu haben. So wurde meine Hypothese gestärkt, weshalb ich ein Downgrade auf die Version 3.2.0 versucht habe, um schrittweise vorzugehen. Es entstand jedoch das gleiche Fehlerbild, was mich zur Version 3.0.2 führte, wie der Nutzer auf GitHub beschrieben hatte. Erst mit dieser Version baute sich eine scheinbar stabile Verbindung zwischen OTBR und RCP auf, die nicht mehr abgebrochen ist.

Mein Test lässt demnach die Vermutung zu, dass Änderungen in den OTBR-Versionen nach 3.0.2 die Verbindung in meiner Umgebung beeinträchtigen könnten. Welche konkrete Änderung dafür verantwortlich ist, kann ich nicht sagen. Auch der verlinkte GitHub-Bericht liefert bislang keine bestätigte Ursache. Durch mehrere Berichte deutet sich jedoch an, dass Version 3.0.2 zumindest in bestimmten Umgebungen stabiler funktioniert.

Die Tabelle zeigt die Beobachtungen aus meiner eigenen Umgebung sowie die Angaben aus dem verlinkten GitHub-Issue. Da sich die eingesetzte Hardware und Software unterscheiden können, lassen sich die Ergebnisse nicht ohne Weiteres auf andere Installationen übertragen.

Vorbereitung: Backup und Thread-Konfiguration sichern

Vor dem Downgrade habe ich zunächst ein Backup meiner Home-Assistant-Installation über die Einstellungen erstellt. Das damals erstellte Home-Assistant-Backup umfasste ca. 1,45 MB und schloss sowohl OTBR, Matter-Server als auch Terminal & SSH sowie die Einstellungen mit ein. Ein VM-Backup habe ich zu dieser Zeit nicht gemacht. Da die Installation noch relativ neu war und erst zwei Geräte angelernt waren, hätte ich einen vollständigen Neuaufbau im schlimmsten Fall noch vertreten können.

Wichtig zu wissen ist außerdem, dass ich an dieser Stelle keinen universellen Rat für Downgrades geben kann. Ältere Versionen können Sicherheitsrisiken mit sich bringen und Kompatibilitätsprobleme verursachen. Dadurch können einzelne Funktionen eingeschränkt sein oder nicht mehr zur Verfügung stehen. Es ist daher wichtig, die weitere Entwicklung des OTBR zu verfolgen und auf eine neuere Version zu wechseln, sobald der Fehler behoben und die Kompatibilität mit der eigenen Umgebung geprüft ist.

Bevor die ältere OTBR-Version gestartet wird, muss die bisherige Instanz beendet werden. Beide Versionen würden sonst versuchen, gleichzeitig auf denselben Thread-RCP zuzugreifen, was zu Konflikten führen kann. Der Autostart sollte ebenfalls deaktiviert werden.

Ein weiterer wichtiger Punkt ist die bestehende Thread-Netzwerkkonfiguration. Das sogenannte Active Operational Dataset enthält die Netzwerkinformationen, die Thread-Geräte für die Teilnahme am bestehenden Netzwerk benötigen. Wer seinen Border Router austauscht oder neu einrichtet, sollte deshalb sicherstellen, dass das bestehende Thread-Netzwerk erhalten bleibt. Andernfalls kann es passieren, dass bereits eingebundene Geräte nicht mehr erreichbar sind.

Ob ich das Dataset bei meinem damaligen Downgrade zusätzlich separat gesichert habe, kann ich rückblickend nicht mehr nachvollziehen. Deshalb möchte ich diesen Schritt ausdrücklich als zusätzliche Vorsichtsmaßnahme empfehlen. Da zu diesem Zeitpunkt lediglich zwei Geräte angelernt waren, hätte sich der Aufwand für eine erneute Einrichtung in Grenzen gehalten. Das Risiko war für mich deshalb auch ohne separate Sicherung des Thread-Datasets vertretbar.

OpenThread Border Router in Home Assistant downgraden

Zunächst habe ich über die App Terminal & SSH das offizielle Home-Assistant-Add-on-Repository geklont. Über dessen Git-Historie konnte ich anschließend auf frühere Versionsstände der OTBR-App zugreifen. Dafür habe ich folgende Befehle verwendet:

git clone https://github.com/home-assistant/addons.git /share/ha-addons-source
cd /share/ha-addons-source

Für meinen ersten Test mit Version 3.2.0 habe ich den Git-Commit ddcc5b1 verwendet. Die zugehörigen Dateien habe ich anschließend in ein lokales App-Verzeichnis exportiert. Dafür nutzte ich folgende Befehle:

mkdir -p /local_apps/otbr-test-320
git archive ddcc5b1 openthread_border_router | tar -x -C /local_apps/otbr-test-320 --strip-components=1

In meiner Installation war das Verzeichnis /local_apps/ innerhalb der Terminal-&-SSH-App auf /supervisor/apps/local eingebunden. Dort konnte ich die lokalen Apps ablegen, die Home Assistant anschließend im App-Store erkannte. Je nach verwendeter Terminal-App und Home-Assistant-Installation kann dieser Pfad allerdings abweichen.

Anschließend habe ich den Anzeigenamen in der config.yaml angepasst, damit die Testversion für mich klar erkennbar ist. Das geschah durch folgenden Befehl:

sed -i 's/^name:.*/name: OpenThread Border Router Test 3.2.0/' /local_apps/otbr-test-320/config.yaml

Anschließend öffnete ich in Home Assistant den Bereich Apps und wechselte zum App-Store. Über das Drei-Punkte-Menü oben rechts ließ ich nach Updates suchen. Kurz darauf wurde mir die lokale OTBR-Version 3.2.0 angezeigt. Wichtig war, dass zu diesem Zeitpunkt die ursprüngliche OTBR-App beendet war.

Die Installation erfolgte dann wie gewohnt über die Weboberfläche. Die Konfiguration für die App konnte ich aus der deaktivierten neuesten Version übernehmen, indem ich die gleichen Konfigurationswerte erneut hinterlegt habe.

Da die Verbindungsabbrüche auch mit Version 3.2.0 auftraten, suchte ich in der Git-Historie nach Version 3.0.2. Dabei stieß ich auf den Commit 73a34f9. Um sicherzugehen, dass dieser tatsächlich zur gewünschten Version gehört, überprüfte ich die Versionsangabe in der config.yaml:

git show 73a34f9:openthread_border_router/config.yaml

Dort stand Version 3.0.2.

Der Ablauf zur Vorbereitung als lokale App lief dann wie bereits oben für Version 3.2.0 ab. Folgende Befehle kamen dafür bei mir zum Einsatz:

mkdir -p /local_apps/otbr-test-302
git archive 73a34f9 openthread_border_router | tar -x -C /local_apps/otbr-test-302 --strip-components=1
sed -i 's/^name:.*/name: OpenThread Border Router Test 3.0.2/' /local_apps/otbr-test-302/config.yaml

Beim anschließenden Aktualisieren des App-Stores wurde die lokale Version 3.0.2 allerdings zunächst nicht angezeigt. Bei der Fehlersuche fiel mir auf, dass beide Testversionen denselben internen slug verwendeten. Ob das tatsächlich die Ursache war, konnte ich nicht eindeutig feststellen. Deshalb deinstallierte ich Version 3.2.0 über die Home-Assistant-Oberfläche, löschte anschließend deren lokales Quellverzeichnis und ließ den App-Store erneut nach Updates suchen. Für das Löschen des Quellverzeichnisses habe ich diesen Befehl genutzt, der das Verzeichnis mitsamt dem Inhalt unwiederbringlich löscht:

rm -r /local_apps/otbr-test-320

Home Assistant hat dann die korrekte Version gefunden und ich habe sie installiert.

Hinweis: Mit den gezeigten Git-Befehlen wird die historische App-Konfiguration bereitgestellt. Für die Installation muss zusätzlich das passende Container-Image verfügbar sein. Dass eine ältere Version im App-Store angezeigt wird, garantiert deshalb nicht, dass sie sich auch installieren lässt. Bei mir hat die Installation von OTBR 3.0.2 funktioniert, die zukünftige Verfügbarkeit des Images kann ich jedoch nicht garantieren.

Mit der Version 3.0.2 konnte ich schließlich alle Geräte über Matter-over-Thread anlernen und in Home Assistant in Automationen verwenden.

Das Ergebnis: Mit OTBR 3.0.2 funktioniert es wieder

Nach dem Downgrade des OTBR habe ich zur Sicherheit den Matter-Server neu gestartet. Sobald beide Komponenten wieder liefen, versuchte ich erneut, die Thermostate über die Home-Assistant-Companion-App anzulernen. Diesmal konnte ich alle sieben Thermostate ohne weitere Probleme mit Home Assistant verbinden.

Bei einzelnen Thermostaten hat der Prozess etwas länger gedauert, die Verbindung blieb jedoch stabil. Auch am nächsten Tag konnte ich anhand der Historie der einzelnen Geräte sehen, dass es zu keinem Ausfall mehr gekommen war. Auch eine Woche später konnte ich in der Gerätehistorie keine weiteren Verbindungsabbrüche feststellen.

Mittlerweile habe ich mithilfe von Claude auch eine Automation eingerichtet, die alle sieben Thermostate über Home Assistant steuert. Auch diese funktioniert seit dem Downgrade zuverlässig.

Eine kleine Stolperfalle ist mir im Anschluss allerdings noch aufgefallen.

Beim Blick in die installierten Apps habe ich später versehentlich die falsche OTBR-Version ausgewählt. Sind mehrere OTBR-Versionen installiert, besteht die Gefahr, versehentlich die falsche Version auszuwählen. Nicht mehr benötigte Testversionen können entfernt werden, um Verwechslungen und versehentliche Starts zu vermeiden.

Meine Erkenntnisse aus der Fehlersuche

Die Fehlersuche in dieser Umgebung war nach einer anfänglichen Frustration durchaus spannend und für mich erkenntnisreich. Denn nicht jede naheliegende Ursache ist die tatsächliche Ursache. Ich habe das Netzwerk geprüft, Hyper-V-Einstellungen verändert sowie die Stromversorgung geändert. Eine kurzfristige Besserung gab mir zunächst Hoffnung, die jedoch am nächsten Tag wieder verflog.

Die Entscheidung für ein Downgrade hat sich rückblickend als erfolgreich herausgestellt. Hier hat mir vor allem die Recherche geholfen, bei der mich ChatGPT unterstützt hat. Dabei waren vor allem vereinzelte Informationen zu den OTBR-Versionen 3.2.0 sowie 3.0.2 nützlich. Gleichzeitig lässt sich daraus nicht ableiten, dass ein konkreter Softwarefehler oder eine bestimmte Codeänderung für die Probleme verantwortlich war.

Gleichzeitig muss ich mir vor Augen halten, dass der Einsatz einer älteren Software keine ideale Dauerlösung ist. Zwar funktioniert Thread in der Umgebung aktuell zuverlässig, jedoch können ältere Versionen über Sicherheitslücken verfügen oder es fehlt ihnen schlichtweg an Kompatibilitätsverbesserungen. Neuere Versionen sollte man daher nicht grundsätzlich abschreiben und bei Bedarf eher auf einen erneuten Test setzen.

Persönlich nehme ich vor allem die Erkenntnis mit, dass eine gründliche Recherche und ein systematischer Vergleich manchmal zielführender sind als weitere Änderungen an einer zunächst verdächtigen Komponente. Zwar waren meine Maßnahmen zielgerichtet, sie konnten die Verbindungsabbrüche jedoch nicht dauerhaft beheben. Es zeigt auch, dass die Administration in einem Smart Home mit Komplexität und Zeitaufwand verbunden sein kann.

Für die Zukunft weiß ich nun aber auch, wie ein solches Downgrade vorbereitet und kontrolliert durchgeführt werden kann. Komme ich wieder in eine solche Situation, kann ich das Gelernte erneut anwenden und Probleme im Smart Home gezielt adressieren. Der Zeitaufwand ist daher für mich kein Nachteil, sondern vielmehr eine Investition in mein eigenes Know-how.