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

[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.