Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[apollon77]

Hey, super zusammenfassung.

ich hab aber einige Kommentare udn eigene Meinungen zu einigen Punkten und garantiert nicht vollständig :-)

Wifi SSID Namen und generell 2.4GHz und 5GHz:
Also in meinen Augen sollte man gleiche namen nutzen weil man es sich sonst nur unnötig schwer macht. Auch das Thema "5GHz abschalten" ist in meinen Augen sehr grenzwertig. Ich denke das wichtigste ist das man die beiden Wifi Frequenzen und auch sein normales LAN im gleichen VLAN erreichbar hat und hier nichts segmentiert wird! Wenn das gegeben ist sollte es sehr egal sein wer worüber angebunden ist und das alles passen. Da seinige Hersteller in Ihre Anleitungen schreiben man sollte das so tun weiss ich aber ich habe den grund (ausser vor zig Jahren) noch nie verstanden und im normalfall keine Probleme. Wenn ein Gerät kein 5GHz kann dann wird es sich nie zu 5GHz verbinden und damit eh nur 2,4GHz sehen und nutzen. Auch unterschiedliche SSID machen einem selbst und seinen Mobilgeräten das Leben nur unnötig schwer.

Post2 "Den Thread Border Router an ioBroker übergeben":
Ich verstehe nicht was das bedeuten soll, ähnlich andere Texte. Den BR übergibt man nirgends - es sei denn man kennt sein Operational Dataset und möchte das in der Konfig im Adapter angeben, aber darum gehts in den Abschnitten nicht. In Abschnitt 2 geht es eher darum ein gerät was in einem Ökosystem angelernt ist an einem zweiten anzulernen. Das ist Matter Multi-Admin und wäre wenn "Gerät weitergeben" :-) Denke aktuelle Formulierungen sind da sehr verwirrend.
Weiterhin gilt für mich das klare Best practice: Wenn man Thread Geräte hat sollte man schauen das diese NICHT in meheren Ökosystemen aktiv genutzt werden sondern sich auf eines beschränken. Zum start - falls die ioBroker Visu App zum anlernen nicht geht (was Sie aber sollte) - ist das ggf ok, aber dann sollte man den "übergangs-Admin" wieder löschen. Das Gerät bleibt an sich im anderen Ökosystem drin.
Zum Warum: Naja einfach ... Thread ist Funk und hat eine maximale Bandbreite (theoretisch) von 250kbps (Achtung KiloBit!, nicht KiloByte). Jedes Update was die Geräte zu den Controllern senden wird bei zwei Ökosystemen verdoppelt, drei verdreifacht ... ihr seht schon wo das hingeht.

Geräte-Update: ... na wartet mal auf die nächste Version des Adapters :-)

Netzwerkwahl:
Von WLAN abzuraten ist eine interessante Meinung :-) Wenn dem so ist dann hat man entweder mehr Traffic als die Wifi Infrastruktur zulässt, dann heisst es upgraden! Wifi hat in jedem Fall mal höhere Bandbreiten als Thread.
Am Ende heisst es ganz einfach in meinen Augen das man sich um seine Netzwerke kümmern muss - betrifft Wifi, LAN und Thread und Zigbee und whatever und verstehen muss. Dann kann man optimieren
So oder so würde ich von nichts abraten sondern bei Problemen das Ziel haben diese zu verstehen.
Die nächste Version des Matter Adapters wird da auch was Thread und Wifi angeht helfen ... abwarten. :-)

Das. Risiko das Matter Ökosyteme "unzertifizierte Bridges" und so nicht länger zulassen ist minimal. Die option es zu erlauben ist in der Spezifikation enthalten. Da muss man keine Angst haben in meinen Augen.

Es ist generell korrekt das vor allem bei Thread aktuell hier und da noch nicht alles perfekt ist, aber es wird besser mit jedem Monat und mit jeder Matter Version. Seien wir mal realistisch: Von Matter (2 Jahre alt)aus dem Stand ehraus die gleiche Stabilität zu erwarten wie von zigbee (>10 Jahre) ist auch ein bissl utopisch :-)

[Bass-T]

Hi zusammen,

habe mich in der letzten Woche auch intensiv mit Thread auseinander gesetzt.

Aktuell habe ich 2 Thread Netze mit je einem Boarder Router.

1. Das Amazon Echo Thread Netz. das funktioniert soweit ganz gut, ist aber nur bedingt lokal.
2. meinen neuen Sonoff Max.

Dieser hat auch sein eigenes Thread aufgebaut.
Leider habe ich es bisher noch nicht geschafft ein Thread Gerät in das 2. Netz zu bekommen. Ich scheiter aktuell am Commisioning.
Erst hieß es du brauchst eine VM, LXC reicht nicht, dann hieß es du brauchst Bluetooth an der VM, ... Leider schaffe ich immer noch kein Pairing.

Das Pairing beim Echo funktioniert gut, aber ich wollte eine Lokale Verbindung.
Klar, das Amazon Thread ist Lokal, aber die Kommunikation ioBroker <-> Thread nicht mehr, ...

Aktuell habe ich eine HA VM als Übermittler dazwischen. Ich habe es geschafft HA als Teilnehmer im Thread zu etablieren und somit per HA - MQTT - ioBroker eine halbwegs lokale Verbindung.

am Pairing bleib ich dran.

Zum Thema "von WLAN abraten" - ich habe mittlerweile selbst ein umfangreiches Netzwerk Setup installiert und WLAN Geräte auf 2 Unifi U6Pro umgestellt.
Mehrere VLANS für die bessere übersicht und Sicherheit.
Thread hat den vorteil dass es Komplett Mesh fähig ist. Somit wächst die Reichweite mit jedem Aktiven Teilnehmer. Das macht für m ich Thread sehr interessant. Auch der geringe Energiebedarf macht es für Battery Clients sehr schonend.

Natürlich ist meine Smarthome gedöns alles im selben VLAN.

Als FW nutze ich eine pfsense in einer Proxmox VM.

PS: Wann kommt denn die nächste Version des Adapters :)

ChatGPT shclägt aktuell noch nicht iobroker als alleiniger Matter Thread Manager vor, ...

Grüße
BassT

[arteck]

@Bass-T sagte in Matter over Thread/Matter over Wlan Voraussetzung:

Klar, das Amazon Thread ist Lokal, aber die Kommunikation ioBroker <-> Thread nicht mehr, ...

wie kommst du dadrauf ?

[Bass-T]

@arteck sagte in Matter over Thread/Matter over Wlan Voraussetzung:

@Bass-T sagte in Matter over Thread/Matter over Wlan Voraussetzung:

Klar, das Amazon Thread ist Lokal, aber die Kommunikation ioBroker <-> Thread nicht mehr, ...

wie kommst du dadrauf ?

Logische Schlussfolgerung 😁
Da Alexa nicht wirklich lokal im ioBroker ist. Kommunikation findet immer zu Amazon Server statt.
Wäre mir neu, wenn der Alexa Adapter lokal kommuniziert 🫠

Ziel ist ja sowieso auf das amazon mesh zu verzichten. Bzw Amazon nur als "Client" mitspielt zu lassen.
Dafür extra der Sonoff Max.

Grüße

[arteck]

verstehe jetzt nicht was Alexa/Echo mit lokaler iobroker kommunikation soll ?? ausser dass die Dose als BR dient.. was soll da über die Server laufen ? und vor allem was hat der alexa adapter damit zu tun ??

die Dose ist reiner durchlauferhitzer für die Daten.. mehr nicht.. also was hat der alexa adapter mit matter und das mit deren Servern zu tun ??

nach deiner

@Bass-T sagte in Matter over Thread/Matter over Wlan Voraussetzung:

Logische Schlussfolgerung

[Bass-T]

@arteck das wird jetzt hier aber doch ziemlich OT :D

Ich versuche es kurz zu machen;
Aktuell bekomme ich mein "self hosted" Thread Router nicht zum pairing. Da meine Echo aber ein Thread Router ist und ich damit Pairen kann sitzen nun meine Geräte im Amazon Mesh.
Somit ist die Kommunikation wie folgt: "Thread Client" <> Echo <> Amazon Server <> Alexa Adapter <> iobroker (lokal)
Durch den Server umweg ist die Kommunikation aber sehr träge.

Aktuell habe ich es jetzt geschafft, mit einer HA VM welche als Mitglied im Mesh hängt die Kommunikation zu halten, was deutlich schneller funktioniert.

Gerne würde ich aber auch auf die HA VM verzichten und die Leuchtmittel in mein Lokales Mesh lassen - ohne den Durchlauferhitzer, der für mich hilfreich ist, wenn ich die "Fernbedienung" nicht suchen mag, weil sie ein Kind verschleppt hat :D

Meine Lokalen Schnitstellen:

• ioBroker in previligiertem LXC auf Proxmox
• SONOFF Dongle Max (im Thread RCP Mode)
• IKEA KAJPLATS GU10 Leuchtmittel (2 Leuchen a 3 Leuchtmittel - in einem Flur)

[Homoran]

@Bass-T sagte in Matter over Thread/Matter over Wlan Voraussetzung:

Somit ist die Kommunikation wie folgt: "Thread Client" <> Echo <> Amazon Server <> Alexa Adapter <> iobroker (lokal)

wieso??

Thread Client <-> Echo <-> (W)LAN <-> ioBroker (lokal)

[arteck]

@Bass-T sagte in Matter over Thread/Matter over Wlan Voraussetzung:

Somit ist die Kommunikation wie folgt: "Thread Client" <> Echo <> Amazon Server <> Alexa Adapter <> iobroker (lokal)

setzten 6...

:-)

ne leider nein.. siehe @homoran drüber

[Bass-T]

@homoran und @arteck ok, das wäre ja super. Lasse mich da sehr gerne korrigieren.
Hätte dann aber gerne etwas mehr input :)

Wie findet die kommunikation Echo <> (W)LAN <> iobroker statt?

welcher adapter?

alexa adapter mit alexa2.0.Smart-Home-Devices Datenpunkten ist extrem träge.
matter.0 adapter bekomme ich nicht als Controller mit rein (ins Echo Mesh), ...

[arteck]

@Bass-T Die Kommunikation zwischen Matter, ioBroker und Echo-Geräten (also Amazon Echo mit Amazon Alexa) ist ein Zusammenspiel mehrerer Protokolle und Rollen. Ich erkläre dir das praxisnah – besonders relevant für deine ioBroker-Use-Cases.

---

🧠 Grundprinzip: Wer spricht mit wem?

Es gibt 3 zentrale Rollen:

1. Matter Controller

Das ist die Instanz, die Geräte steuert:

• Alexa (Echo-Geräte)
• Google Home
• Apple Home

👉 In deinem Fall: Echo = Matter Controller

---

2. Matter Device

Das eigentliche Gerät:

• Steckdose
• Licht
• Sensor
• etc.

👉 Kann sein:

• echtes Matter-Gerät (z. B. Eve, Nanoleaf)
• oder virtuell über ioBroker

---

3. ioBroker

Mit dem Adapter:

• ioBroker + Matter Adapter

👉 ioBroker kann sein:

• Matter Bridge (wichtig!)
• oder (seltener) Controller

---

🔌 Der wichtige Punkt: ioBroker als Matter Bridge

In 99 % der Fälle läuft es so:

👉 ioBroker fungiert als Matter Bridge

Das bedeutet:

• ioBroker „übersetzt“ seine Geräte in Matter
• Echo sieht diese Geräte als echte Matter Devices

---

📡 Kommunikationsfluss (vereinfacht)

Schritt 1: Pairing

• Du verbindest Alexa mit ioBroker (Matter Bridge)
• z. B. via QR-Code / Setup-Code

👉 Ergebnis:
Echo kennt ioBroker als Matter-Bridge

---

Schritt 2: Geräte-Expose

• ioBroker stellt Objekte bereit:

  • Licht
  • Switch
  • Sensor

👉 Diese werden als Matter Devices „exportiert“

---

Schritt 3: Steuerung

Wenn du sagst:

„Alexa, schalte Licht an“

läuft das so:

1. Echo verarbeitet Sprache (Alexa Cloud)
2. Alexa sendet Befehl an Matter Controller im Echo
3. Echo → ioBroker (lokal via Matter / IP)
4. ioBroker setzt State (.setState)
5. Gerät reagiert

---

🌐 Technische Details

Transport

Matter nutzt:

• IP (WLAN / Ethernet)
• optional Thread

👉 Echo Geräte (neuere):

• unterstützen Matter over WiFi
• teilweise Thread Border Router

---

Protokoll

Matter basiert auf:

• TCP/UDP (IPv6!)
• mDNS (Discovery)
• CASE (Secure Sessions)

👉 Wichtig:

• alles ist lokal, kein Cloud-Zwang

---

Sicherheit

• Geräte authentifizieren sich per Zertifikaten
• verschlüsselte Sessions (CASE / PASE)

---

🔄 ioBroker intern

Der Matter Adapter macht:

Mapping:

ioBroker State	Matter Cluster
switch	OnOff Cluster
level	Level Control
temperature	Temperature Measurement

---

🧩 Unterschied zur alten Alexa-Integration

Früher:

• ioBroker → Alexa Adapter → Cloud → Echo

Jetzt mit Matter:

• ioBroker → Matter → Echo (lokal)

👉 Vorteile:

• schneller
• stabiler
• keine Cloud-Abhängigkeit

---

⚠️ Einschränkungen aktuell

• Nicht alle Gerätetypen unterstützt
• Alexa Matter Support noch im Ausbau
• ioBroker Matter Adapter noch relativ neu

---

🧠 Wichtig für dich (Praxis)

Mit deinem Setup (ioBroker + viele Geräte):

👉 Beste Strategie:

• ioBroker = zentrale Logik
• Matter Bridge = Export zu Alexa

👉 NICHT:

• Alexa als zentrale Logik nutzen

---

🧪 Beispiel aus deinem Setup

Du hast z. B.:

• Zigbee Rauchmelder
• Z-Wave Geräte
• X-Sense (Cloud)

👉 ioBroker sammelt alles → stellt es als Matter bereit

Echo sieht dann:

• „virtuelle Geräte“, die physisch gar kein Matter sprechen

---

🔥 Kurz gesagt

• Echo ist der Controller
• ioBroker ist die Bridge
• Kommunikation läuft lokal über IP
• Matter ersetzt die klassische Alexa-Cloud-Anbindung

[arteck]

finde hat der gut gemacht :-) die kiste

[Homoran]

@Bass-T sagte in Matter over Thread/Matter over Wlan Voraussetzung:

Wie findet die kommunikation Echo <> (W)LAN <> iobroker statt?

gar kein Adapter, das ist die Funktion eines Border Routers

@Bass-T sagte in Matter over Thread/Matter over Wlan Voraussetzung:

Wie findet die kommunikation Echo <> (W)LAN <> iobroker statt?

Matter Adapter

[Fabio]

Sehr interessant,

die CSA hat die Version 1.6 Veröffentlicht.

Und auch sehr interresant der Artikel aus Caschys Blog
Thread: Neue Diagnose-App für das Smart Home

Grüße
Fabio

[Pharao001]

Hallo,

ich versuche mit einem "ESP-IDF OpenThread Border Router" auf einem Sonoff Dongle-M verschiedene IKEA Geräte ( Timmerflotte, Grillplats) einzubinden. Der Border Router ist via LAN erreichbar und über das Webinterface konfiguriert.
Im Matter Adapter habe ich den Border router über die Thread-Anmeldeinformationen (Thread-Network-Name, Thread operational dataset) eingetragen. Mit Hilfe der VISU App versuche ich die Geräte zu koppeln. Nach Scannen der QR codes wird das Gerät erkannt und es erscheint: "Verbindung mit dem Gerät wird hergestellt" und später "Dein Gerät benötigt einen Thread Border Router". IPv6 und UDP sind o.k. da sich WLAN Matter Geräte verbinden lassen.
Der OTBR ist erreichbar, mDNS _meshcop._udp ist sichtbar, Thread Dataset vorhanden, IPv6 Geräte erreichbar, Matter-Geräte werden per _matter._tcp gefunden.
"Dein Gerät benötigt einen Thread Border Router" kommt vielleicht vom Matter-Commissioning ? Muss man den Border router anderweitig bekannt machen?
Was mache ich falsch?

[Pharao001]

Noch eine Ergänzung zu meinem vorigen post:
Gemäss Wiki: "Aktuell ist die Verwendung von einem OTBR + ioBroker VISU App zum anlernen von Matter-over-Thread Geräten (noch) nicht möglich. In diesem Fall muss man die BLE Funktion im ioBroker Matter Controller (siehe Screenshot) / ioBroker Host verwenden und das Matter-over-Thread Gerät muss dann auch in der Nähe des ioBroker Hosts (der das BLE bereitstellt) sein."
Das habe ich nun auch getan. Beim Scannen (Geräte erkennen und Koppeln) wird nur der Identifier gefunden: f2:f4:e1:f7:25:xx.
Name und Hersteller ID bleiben leer. Wenn ich auf das Verbindungssymbol gehe, öffnet sich das Fenster: "Gerät „undefined / -“ per Pairing-Code oder QR-Code hinzufügen"
Hier der Hinweis:"Bitte verwenden Sie NICHT den QR-Code/Pairing-Code, der auf dem Matter-Gerät aufgedruckt ist" Da das Gerät "frisch" ist und nicht in einem anderen Ökosystem angelernt ist, habe ich keinen Pairing Code aus einem anderen Ökosystem. Ein Versuch den Herstelle Code zu benutzen scheitert auch erwartungsgemäss. Noch ein Auszug aus dem log:"armFailSafe returned 0" und "Could not connect to device at ControllerCommissioner.#establishPaseFromCandidates"
Bin leider ratlos!

[Fabio]

@Pharao001 sagte:

Bin leider ratlos!

Ich würde dir gern helfen, aber bei dir steckt der Teufel im Detail, ich denken wenn ich da so lese das es so nicht gehen wird.

Herzliche Grüße
Fabio

[Homoran]

@Pharao001 sagte:

Im Matter Adapter

Welche Version?
Siehe:
https://forum.iobroker.net/post/1349007

[Pharao001]

@Homoran
Habe bisher die Matter Adapter v.1.2.2 und v.1.3.0 versucht und werde nun auf v.1.3.1 upgraden, danke für den Hinweis!

[Pharao001]

Matter 1.3.1 – BLE funktioniert jetzt deutlich weiter, Commissioning bricht aber weiterhin während PASE ab

Ich habe soeben auf den neuen Matter-Adapter 1.3.1 aktualisiert. Leider lässt sich das eigentliche Commissioning weiterhin nicht abschließen.

Testumgebung

• ioBroker Matter 1.3.1
• Debian 13 VM
• Node.js 22.23.0
• Intel Bluetooth 4.2 (interner Adapter)
• Sonoff Dongle-M als ESP-IDF OpenThread Border Router
• OTBR wird per mDNS korrekt gefunden (_meshcop._udp)
• IPv6 ist aktiv und funktioniert

Getestete Geräte

Ich habe mit zwei unterschiedlichen Matter-over-Thread-Geräten getestet:

• Lidl TIMMERFLOTTE
• IKEA GRILLPLATS

Beide zeigen das gleiche Verhalten.

Discovery

Die Geräte werden per BLE problemlos gefunden.

Beispiel:

• VP: 4476+32773
• Discriminator: 428
• Commissioning Mode: 1

Auch ein manueller Verbindungsaufbau mit bluetoothctl funktioniert problemlos.

Was gegenüber den älteren Versionen jetzt funktioniert:

Mit Version 1.3.1 kommt der Adapter deutlich weiter als zuvor.

Im Debug-Log sieht man erfolgreich:

• BLE-Verbindung wird aufgebaut
• Matter-Service FFF6 wird gefunden
• C1-, C2- und C3-Characteristics werden erkannt
• BTP-Handshake erfolgreich
• ATT_MTU wird auf 247 Bytes ausgehandelt
• anschließend wird bereits der SC/PbkdfParamRequest gesendet

Das Gerät antwortet auch darauf und sendet BTP-ACKs zurück.

Im Log sieht das beispielsweise so aus:

• Received Matter handshake response
• Sending SC/PbkdfParamRequest
• Received BTP packet 080001
• Received BTP packet 080102

Damit scheint der komplette BLE-Transport inzwischen korrekt zu funktionieren.

Das eigentliche Problem

Danach passiert jedoch nichts mehr.

Es kommt keine weitere Antwort auf den PBKDF-Request und das Commissioning endet schließlich mit:

Could not connect to device

bzw.

discovery of node with discriminator ... failed

Weitere Beobachtung

Während des Scans wird lediglich die BLE-Adresse erkannt, Name und Hersteller-ID bleiben leer.

Im verbinden Fenster > "Gerät 'undefined / -' per Pairing-Code oder QR-Code hinzufügen"

Kann ich nur den Hersteller Code eingeben, da ich nichts aus einem anderen Ökosystem habe.

Sollte das das Problem sein?

Ich weiß nicht, ob das lediglich ein kosmetisches Problem der Oberfläche ist oder ob hier bereits Informationen fehlen, die später für das Commissioning benötigt werden.

Meine Einschätzung

Da inzwischen

• BLE funktioniert,
• der Matter-Service gefunden wird,
• sämtliche GATT-Characteristics erkannt werden,
• der BTP-Handshake erfolgreich abgeschlossen wird,
• und sogar bereits der PBKDF-Request übertragen wird,

vermute ich, dass das Problem inzwischen nicht mehr im Bluetooth-Teil liegt, sondern irgendwo im eigentlichen PASE-Commissioning.

Kann das jemand nachvollziehen oder sieht in den Logs einen offensichtlichen Fehler?

[Pharao001]

Matter over Thread mit ESP-IDF OpenThread Border Router auf Sonoff Dongle-M + ioBroker VISU – weitere Testergebnisse

Ich möchte einige Testergebnisse teilen, die teilweise von der aktuellen Dokumentation abweichen.

Im Wiki steht aktuell:

"Aktuell ist die Verwendung von einem OTBR + ioBroker VISU App zum Anlernen von Matter-over-Thread Geräten (noch) nicht möglich."

In meinem Testaufbau konnte ich dieses Verhalten nicht vollständig nachvollziehen.

Testumgebung
ioBroker Matter Adapter 1.3.x
aktuelle ioBroker VISU App
Sonoff Dongle-M
ESP-IDF OpenThread Border Router Firmware (kein Docker-OTBR)
Thread Active Dataset im Matter Controller eingetragen
IPv6 vollständig aktiviert
statische IPv6-Routen zum Thread-ULA (Proxmox/VM)
Android 16 (Vivo)
Android 16 (Oppo)
Android 15 (Sony)
Testergebnisse

1. Direktes Commissioning über ioBroker VISU + Sonoff OTBR

Mit dem Vivo (Android 16) konnten folgende Matter-over-Thread-Geräte direkt über die ioBroker VISU angelernt werden:

IKEA GRILLPLATS
IKEA TIMMERFLOTTE

Dabei war auf dem Smartphone:

keine Alexa App installiert
keine Home Assistant Companion App installiert

Das Smartphone war bezüglich Matter/Thread praktisch jungfräulich.

Nach erfolgreichem Pairing versucht das Vivo auch später noch, sich mit dem Thread-Netz

ESP BR D598

zu verbinden, obwohl das Thread Active Dataset zuvor bereits aus dem ioBroker Matter Controller gelöscht wurde.

2. Sony / Oppo

Mit identischem Aufbau

gleicher Matter Controller
gleicher Sonoff OTBR
gleiches Netzwerk

zeigen sowohl das Sony (Android 15) als auch das Oppo (Android 16) folgenden Ablauf:

QR-Code wird erfolgreich erkannt.
Es erscheint:

„Verbindung mit Gerät wird hergestellt..."

Nach einigen Sekunden folgt:

„Dein Gerät benötigt einen Border Router."

Das Pairing wird anschließend abgebrochen.

3. Gegenprobe mit Home Assistant

Mit dem gleichen Sony, bei dem die ioBroker VISU nach

„Verbindung mit Gerät wird hergestellt..."

anschließend

„Dein Gerät benötigt einen Border Router."

meldet, wurde zusätzlich die Home Assistant Companion App getestet.

Dort funktionierte das Pairing grundsätzlich.

Damit konnte das Pairing mit demselben Smartphone und demselben Matter-over-Thread-Gerät erfolgreich durchgeführt werden.

4. Bluetooth des ioBroker Hosts

Gemäß Wiki wurde auch der empfohlene Weg über Bluetooth des ioBroker Hosts getestet.

Der BLE-Adapter des Hosts funktionierte grundsätzlich und Matter-Geräte wurden erkannt.

Ein direktes Matter-over-Thread-Commissioning war auf diesem Weg jedoch nicht erfolgreich.

5. Alexa Multi-Admin

TIMMERFLOTTE wurde zusätzlich erfolgreich

zunächst mit Alexa gekoppelt,
anschließend per Multi-Admin (Sharing Code) in den ioBroker Matter Controller übernommen.

Die VISU meldete zwar

„Gerät konnte nicht gefunden werden."

das Gerät wurde aber vollständig angelegt.

Temperatur- und Feuchtigkeitswerte werden seitdem korrekt und dauerhaft aktualisiert.

Weitere Beobachtungen

Während der Fehlersuche stellte sich außerdem heraus, dass der Matter Controller über statische IPv6-Routen Zugriff auf die Thread-ULA des Border Routers benötigt.

Nach Einrichtung dieser Routen funktioniert die Kommunikation mit den Thread-Geräten zuverlässig.

Offene Fragen

Für mich ergeben sich aktuell zwei Fragen:

Ist die Aussage im Wiki bezüglich

OTBR + ioBroker VISU aktuell nicht möglich

noch aktuell oder hat sich das Verhalten inzwischen geändert?

Warum funktioniert das direkte Commissioning mit einem Android-16-Gerät (Vivo), während Sony und Oppo bereits nach

„Verbindung mit Gerät wird hergestellt..."

mit

„Dein Gerät benötigt einen Border Router."

abbrechen?

Hinweis

Alle beschriebenen Tests wurden mehrfach wiederholt.

Das Verhalten der jeweiligen Smartphones (Vivo, Sony und Oppo) war reproduzierbar.