Wie kann im Thread-Netzwerk nachvollziehen, welchen Router ein Gerät zur Verbindung nutzt?

Ich habe seit einigen Wochen ein Aqara U200 in einem Thread-Netzwerk mit einem Sonoff E-Dongle als OTBR laufen. Ab & An hatte ich Verbindungsabbrüche, welche u.U. auf die Entfernung des Schlosses vom Sonoff zurückzuführen sind.

Um das in den Griff zu bekommen, gibt es nun eine Smarte Steckdose von Onvis im Mesh, welche als Router dienen soll. Installiert ist diese auf halben Weg zwischen Sonoff & U200.

Wie kann ich feststellen / nachsehen, ob das Schloss die Steckdose zur Verbindung nutzt?

Im z2m Umfeld kann ich ja die Karte ansehen, in der alle Verbindung grafisch dargestellt werden. Ich weiß schon, dass es diese Karte im Thread Umfeld nicht gibt. Mir würde es schon reichen, wenn ich beim U200 oder der neuen Steckdose textlich einsehen könnte, welche Route das U200 nun nimmt.

Habe mir gerade diue Details des Onvis angesehen und folgendes gefunden:

image

Kann mir diesem Gerät dann überhaupt ein Mesh entstehen? Oder hat der Parameter “Is bridge” damit gar nichts zu tun?

Umgebung: HA als VM, Matter Server und OpenThread Border Router als Add-Ons im HA

Moin

Da ich ja auch gerade meine ersten Gehversuche mit Thread mache, buddel ich mal diesen Beitrag wieder aus und stelle hier die Frage. Vielleicht hat sich bei dem Thema innerhalb des letzten rund einem Jahr ja etwas getan bzw. verändert. :slightly_smiling_face:

Ich frage mich auch gerade ob ich irgendwie und irgendwo erkennen kann über welchen Border-Router - in meinem Fall mehrere Nest Hub - ein Thread Gerät - hier halt die Ikea Tür-/Fenstersensoren - angelernt wurde und welchen Border-Router es danach dann für die Verbindung nutzt? Weil weder bei der Geräte-Info selber


noch bei der Matter oder Thread Integration oder dem Matter Server Addon, sehe ich dazu irgendwelche Infos.

Wobei ich bei dem Matter Server Addon den Log Level auf Info stehen habe


und der Eintrag für das anlernen eines Thread Gerätes dann z.B. so aussieht:

2025-12-05 16:48:11.551 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning using Node ID 3 and IP fd69:479b:7ede:1:xxxx:xxxx:xxxx:b6e0.
2025-12-05 16:48:12.877 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
2025-12-05 16:48:21.479 (Dummy-2) INFO [chip.ChipDeviceCtrl] Commissioning complete
2025-12-05 16:48:21.480 (MainThread) INFO [matter_server.server.device_controller] Matter commissioning of Node ID 3 successful.
2025-12-05 16:48:21.483 (MainThread) INFO [matter_server.server.device_controller] Interviewing node: 3
2025-12-05 16:48:25.956 (MainThread) INFO [matter_server.server.device_controller] <Node:3> Setting-up node...
2025-12-05 16:48:25.959 (MainThread) INFO [matter_server.server.device_controller] <Node:3> Setting up attributes and events subscription.
2025-12-05 16:48:26.155 (MainThread) INFO [matter_server.server.device_controller] <Node:3> No new update found.
2025-12-05 16:48:30.414 (MainThread) INFO [matter_server.server.device_controller] <Node:3> Subscription succeeded with report interval [0, 1800]
2025-12-05 16:48:30.417 (MainThread) INFO [matter_server.server.device_controller] Commissioning of Node ID 3 completed.

Aber ich glaube nicht das eine Änderung an dem Server Log Level etwas daran ändern würde und mir dann trotzdem nicht angezeigt wird mit welchem Border-Router sich ein Thread Geräte beim anlernen oder danach verbunden hat, oder?

Anm.: Ja ich kenne auch diesen Beitrag und ja weiß das ein Thread Netzwerk sich selber organisiert und auch “selbstheilend” sein soll/sollte. Das ist hier also nicht die Frage. :laughing:

Also, gibt es irgendeine Möglichkeit mir die Verbindungen zwischen den verschiedenen Border-Routern und den Thread Geräten anzeigen zu lassen, sprich welches Thread Gerät hat sich mit welchem Border-Route verbunden?

VG Jim

Wenn Du Du einen OTBR am Start hast in der Add-On Konfiguration die Netzwerk Ports für die WEB und Rest API aktivieren. Über den WEB Port kannst Du dann auf den OTBR zugreifen und unter Topology findest Du dann sowas wie eine Thread Netzwerk Karte.

Gruß Osorkon

Jo danke, die Open Thread Border Router Integration ist mir bekannt und die hattest Du in dem von mir verlinkten Beitrag ja auch schon mal erwähnt, aber hier kommen halt nur Nest Hubs als Border Router zum Einsatz und somit bringt mir die Open Thread Border Router Integration leider nichts.

Anm.: Ich weiß das sich Matter und auch Thread natürlich erst noch “entwickeln” muss, aber eine Netzwerktechnologie scheinbar/quasi ohne jegliche Kontrollmöglichkeit oder zumindest Info bzgl. dem Routing ist schon ziemlich ungewöhnlich. Das wäre für mich schon fast ein K.o.-Kriterium. :laughing:

VG Jim

Außer einer Visualisierung hast Du nichts davon. Das Routing beeinflussen kannst Du ohnehin nicht. Mir persönlich fehlt es nicht. Habe die Port vom OTBR nur geöffnet zur Demonstrationszwecken. Ansonsten ist mir die Thread Topologie ziemlich Schnuppe. :grin:

In jedem Zimmer sitzt ein TBR, somit ist eine Flächendeckende Abdeckung sichergestellt. :grin:

Gruß Osorkon

Das sehe ich eben anders. Ja ich kann das Routing nicht beeinflussen, was man ja jetzt nicht unbedingt auch als Vorteil werten muss oder sollte, aber ohne eine entsprechende Kontrollmöglichkeit und Infos hat man eben gar keine Change evtl. Probleme im Thread Netzwerk erkennen zu können. OK man könnte natürlich auch einfach nach dem Motto vorgehen viel hilft viel und je mehr Border-Router vorhanden sind um so besser und stabiler sollte das Thread Netzwerk auch werden, aber man kann es eben gar nicht beurteilen, eben weil scheinbar jegliche Kontrollmöglichkeit fehlt. Wenn man mal von der “Kontrollmöglichkeit” absieht das sich ein Thread Geräte ggf. erst gar nicht anlernen lässt, weil es ggf. zu weit entfernt von einem Border-Router ist.

Nehmen wir einfach mal das Beispiel WLAN. Wenn es dort ebenfalls keine Kontrollmöglichkeiten und Infos zu dem Routing gebe, würde das nach Deiner Thread Lesart dann dort bedeutet. Ich packe in jeden Raum einfach einen Access-Point (oder WLAN Mesh Client) und dann sollte das WLAN wohl stabil genug sein. :laughing: Gleiches dann halt bei einem Zigbee Netzwerk. Also in jeden Raum einen Zigbee Router und schon ist das Zigbee Netzwerk stabil. Das Letzteres in der Realität nicht immer gilt weißt Du ja selber.

Was aber ist wenn ein WLAN Access Point oder eben Thread oder Zigbee Router ggf. “herumspinnt” und/oder ggf. ganz ausfällt und eben das zu irgendwelchen Problemen im Netzwerk führt? Bei WLAN und Zigbee kann ich erkennen ob und welche Verbindungen bestehen, bei Thread aber nicht weil es scheinbar gar keine Kontrollmöglichkeit für das Thread Netzwerk gibt.

Und das weiß Du dann wodurch/woher? :laughing: Du kannst es eben nur “hoffen”, eben weil Du gar keine Kontrollmöglichkeit hast um das irgendwie beurteilen zu können. Ein “Bei mir gibt es keine Probleme im Thread Netzwerk” ist einfach nur eine Feststellung, aber eben keine auf irgendwelchen konkreten Infos basierende Beurteilung. :wink:

Ein kontretes Beispiel von mir hier: Ich habe hier am Haus einen Raum beim Carport und bedingt durch dessen Lage ist es schwierig dort ein “Funksignal” vom Haus aus zu bekommen, um einen Zigbee Tür-/Fenstersensor stabil in das Zigbee Mesh integrieren zu können. Mit Zigbee konnte ich das schaffen in dem ich einfach in zwei Räumen im Haus (einer obenhalb des Raumes am Carport und einer der am nächsten an diesem Raum beim Carport liegt) Zigbee Router - in dem Fall Plugs - installiert habe. Den Installationsort dieser Zigbee Plugs in den Räumen habe ich dann per try and error, aber eben auch im Laufe der Zeit über das Zigbee Protokoll und evtl. Fehlermeldungen darin, die Zigbee LQI-Werte und die Z2M Karte als Kontrollmöglichkeiten gefunden, sodass ich dann anhand dieser Kontrollmöglichkeiten die scheinbar besten Einsatzorte für die Zigbee Plugs gefunden habe und so wusste in welcher “Qualität/Stabilität” das Zigbee Signal bei dem Zigbee Tür-/Fenstersensor in dem Raum beim Carport vorhanden ist.

Jetzt kommt das Thread Netzwerk. Es gibt bei mir drei Nest Hubs als Border Router. Einer steht in der Küche im EG, einer im Wohnzimmer im EG und einer im Arbeitszimmer im OG. Jetzt will ich in dem Raum beim Carport einen Thread Tür-/Fenstersensor installieren und da stellen sich dann halt die Fragen:
a) Über welchen der möglichen Border-Router hat sich der Thread Sensor dann verbunden - wenn er sich denn verbindet?
b) Wie gut und stabil ist die Verbindung?

Da kann ich ohne jegliche Kontrollmöglichkeit oder Infos halt nur raten und müsste dann nach dem Motto viel hilft viel vorgehen und einfach “nach Lust und Laune” x weitere Border-Router irgendwo in das Thread Netzwerk hinzufügen. Wobei ich dann letztendlich immer noch nicht wüsste wie sich das auf das Thread Netzwerk auswirkt.

Ich hoffe dadurch wird etwas klarer warum mir so etwas wie Kontrollmöglichkeiten und Infos im Thread Netzwerk fehlen und warum ich es für eher ungewöhnlich halte das es diese in einem Netzwerk nicht gibt. Muss man eine Kontrollmöglichkeit haben? Nein nicht zwangsweise. Macht eine Kontrollmöglichkeit Sinn? Meiner Meinung nach auf jeden Fall.

Aber nach all dem was ich dazu jetzt bereits an Infos gelesen hatte scheint es so etwas bei Thread tatsächlich nicht zu geben, es sei denn mir wäre irgendeine Info dazu entgangen. Daher letztendlich ja auch hier meine Frage danach. :slightly_smiling_face:

VG JIm

Nicht nur BR Router, sonder auch Router, also so wie Du es von ZigBee kennst.
Und ja, viel hilft viel. Oder zumindest schadet es nicht wenn zu viel Router im Netzwerk anwesend sind.

Die Kontrollmöglichkeit ist doch relativ simple. Funktioniert ein Gerät am Aufstellort nicht oder fehlt regelmässig aus, muss das Mesh erweitert werden. :wink:
Da bringt mir eine Karte auch nichts, außer das mir diese ggf. bestätigt was isch schon weiss, nämlich das Geräte kein Verbindung hat. :wink:

Weil jedes Gerät an seinem Aufstellort zuverlässig seinen Arbeit verrichtet. :wink:

Dazu hast Du aber Die ZigBee Karte nicht gebraucht, oder diese hätte Dir auch nicht sagen können am welchen Standort ein Router fehlt. :wink:

Zum Thema Link Quality wirft OTBR auch was raus. Wie das ganze zu interpretieren ist, musste man die OTBR Dokumentation studieren.

Da Du ein Nest Hubs als BR in Verwendung hast, ggf. mal die Google Dokumentation zum Thema BR studieren.

Gruß Osorkon

Sag das mal Deinen Aqara Geräten die bei Dir immer wieder Probleme im Mesh hatten, sodass Du diese wohl entsorgt hast. Du hättest da einfach nur Dein Mesh erweitern müssen. :rofl:

Wobei wir wieder dabei sind,

sprich bei einer Feststellung und nicht bei etwas was man auch mit konkreten Infos wie z.B. Werten/Daten bewerten, belegen und nachvollziehen kann.

Aber wir sollten diese Diskussion bzgl. Kontrollmöglichkeit bei Thread sinnvoll oder nicht hier auch abschließen, eben weil wir dazu halt unterschiedliche Ansichten haben.

VG Jim

Am Mesh liegt es nicht, das ist mehr als ausreichend ausgebaut. Die Aqara Zicken sind einfach nur Mist! :wink: Zumindest die, die ich im Einsatz hatte. :man_shrugging:

Sei mir bitte nicht böse, aber ständig irgendwelche LQI Werte und Netzwerkkarten im Auge behalten, gehört bei mir nicht zu einem frustfreien SmartHome. Ein neues Geräte wird angelernt und das hat bis zu seinem Tod zu funktionieren. Wenn es nicht der Fall, fliegt es einfach raus.
So betreibe ich Z-Wave, ZigBee, Matter over Thread und EnOcean seit Jahren und erfreue mich an dem Komfort der damit einher kommt.

Gruß Osorkon

Du hast es nicht verstanden oder willst es nicht verstehen. :slightly_smiling_face: Ich habe nie etwas davon geschrieben ständig irgendetwas im Auge zu behalten, sondern es geht darum wenn es ggf. Probleme mit einem Gerät geben sollte. Also das Beispiel was bereits @LvS21 hier erwähnt hat. Man hat entweder direkt von Anfang an ein Verbindungsproblem, oder ggf. auch erst im Laufe der Zeit. Dann hat man nach Deiner Vorgehensweise genau zwei Möglichkeiten:

  1. Man installiert weitere Router und hofft das das Problem dann weg ist.
  2. Man entsorgt das Gerät mit dem man Probleme hat.

Ja so kann man natürlich vorgehen, aber das entspricht nicht so ganz meinem Verständnis einer Problem- oder Fehleranalyse und wie man dabei vorgeht. Das Thema Optimierung mal ganz außen vor.

Wenn ich hier z.B. mit einem WLAN Gerät ein Problem hätte komme ich auch nicht auf die Idee einfach noch einen zusätzlichen Access-Point oder WLAN Mesh Client zu installieren, in der Hoffnung das das Problem dann weg ist und wenn nicht entsorge ich eben einfach das WLAN Gerät und schon ist das Problem “gelöst”. :laughing:

Und ja, bevor Du jetzt ggf. noch schreibst das Du ja gar nichts optimieren willst oder musst, weil bei Dir natürlich alles perfekt funktioniert: Schön für Dich, aber das hat dann auch nichts mit der ursprünglichen Frage von @LvS21 und mir zu tun.

Die Vorgehensweise und Einstellung kannst Du ja auch gerne haben, aber ich handhabe das eben anders. :slightly_smiling_face: Daher ganz einfach: Mach Du es so wie Du es möchtest/brauchst und ich mache es so wie ich es möchte/brauche. So einfach kann es sein. :laughing:

VG Jim

2 „Gefällt mir“