Introduction : pourquoi « compatible Matter » cache deux technologies radio totalement différentes

Lorsqu’on achète un équipement domotique portant le logo Matter, une confusion très fréquente consiste à croire que tous les appareils Matter se connectent directement à la box Internet ou aux bornes Wi-Fi de la maison. En réalité, Matter est une couche applicative IPv6 unifiée qui peut circuler sur deux couches physiques (PHY) radicalement différentes :

1. Matter-over-Wi-Fi (ou Ethernet) : l’appareil possède une puce Wi-Fi classique (2,4 GHz / 5 GHz). Il rejoint directement votre réseau Wi-Fi existant et dialogue en IPv6 local avec Home Assistant sans aucune passerelle ou antenne domotique supplémentaire.
2. Matter-over-Thread : l’appareil utilise une puce radio IEEE 802.15.4 ultra-basse consommation (la même famille physique à 2,4 GHz que le Zigbee, conçue pour les capteurs sur pile CR2032, vannes thermostatiques et serrures). Or, ni votre serveur Linux ni vos bornes Wi-Fi classiques ne possèdent d’antenne 802.15.4 ! Exactement comme il faut un coordinateur PoE pour le Zigbee (voir notre article Zigbee POE SLZB-MR4U), faire du Matter-over-Thread exige obligatoirement une passerelle physique appelée OpenThread Border Router (OTBR).

Dans ce guide complet, nous allons détailler les différences techniques entre ces deux modes, expliquer pourquoi le coordinateur PoE bi-radio SMLIGHT SLZB-MR4U permet d’ajouter Thread sans perturber un réseau Zigbee existant de près de 100 appareils, et dérouler toute la procédure de configuration officielle SMLIGHT (Thread setup : network and USB connection (#otbr)).

1. Comparatif architectural : Matter-over-Wi-Fi vs Matter-over-Thread

Avant d’acheter un périphérique Matter ou de déployer un conteneur, il faut identifier quelle pile de transport il utilise :

[!IMPORTANT] Le point commun lors de l’appairage (Bluetooth LE) : Qu’un appareil soit Matter-over-Wi-Fi ou Matter-over-Thread, la première étape d’appairage (Commissioning) utilise presque toujours le Bluetooth Low Energy (BLE) de votre smartphone (via l’application Home Assistant Companion) pour vérifier le code QR Matter (protocole PASE) et injecter dans l’objet soit les identifiants Wi-Fi, soit le Thread Operational Dataset chiffré. Une fois commissionné, le Bluetooth n’est plus utilisé : tout passe en IPv6 natif (UDP 5540, protocole CASE) sur le réseau local.

2. Pourquoi la passerelle PoE bi-radio SMLIGHT SLZB-MR4U change la donne

Si vous possédez déjà un coordinateur Zigbee mono-radio, ajouter Matter-over-Thread oblige habituellement soit à brancher un second dongle USB sur le serveur, soit à tenter le mode Multi-PAN (Zigbee + Thread partagés sur une seule puce EFR32 avec siliconlabs-multiprotocol), une approche aujourd’hui officiellement déconseillée par Home Assistant et Nabu Casa en raison des instabilités radio et des pertes de trames.

Le coordinateur PoE SMLIGHT SLZB-MR4U résout ce problème à la racine en intégrant deux chaînes radio matériellement séparées dans un unique boîtier alimenté en PoE (192.168.1.10) :

1. Radio 1 (chip_index=0) : Silicon Labs EFR32MG26 :
   • Dédiée au réseau Thread en mode Thread RCP (Radio Co-Processor) ;
   • Exposée en Serial-over-IP sur le port TCP 6638 à 460800 bauds ;
   • Configurée sur le Canal 25 (2475 MHz).
2. Radio 2 (chip_index=1) : Texas Instruments CC2674P10 :
   • Dédiée à 100 % au réseau Zigbee2MQTT en mode Zigbee Coordinator (Z-Stack) ;
   • Exposée en Serial-over-IP sur le port TCP 7638 à 115200 bauds ;
   • Configurée sur le Canal 11 (2405 MHz).

Grâce à cette séparation physique (deux SoC distincts, deux amplificateurs RF, deux sockets TCP indépendants 6638 et 7638, et deux canaux fréquentiels aux extrémités opposées de la bande 2,4 GHz), le flashage et le redémarrage de la Radio 1 en mode Thread RCP n’entraînent pas une seule milliseconde de coupure sur la Radio 2 qui pilote nos 98 équipements Zigbee.

3. Les 2 options officielles SMLIGHT pour configurer Thread & OTBR

Conformément à la documentation officielle SMLIGHT (Thread setup : network and USB connection (#otbr)), les coordinateurs de la gamme SLZB-06x / MRx / MRxU / Ultima proposent deux architectures distinctes pour déployer un réseau Thread avec Home Assistant :

Option A : "Thread to remote OTBR" (OTBR sur le serveur Home Assistant / Docker, SLZB en mode Thread RCP)

• Principe : l’antenne SMLIGHT fonctionne uniquement comme un coprocesseur radio bas niveau (Thread RCP). Le démon OpenThread Border Router (otbr-agent) tourne sur le serveur Home Assistant (sous forme d’Add-on / App HAOS ou de conteneur Docker hass-otbr-docker) et communique avec la puce radio en USB ou par le réseau (Serial-over-IP sur le port 6638).
• Compatibilité : disponible sur tous les coordinateurs SLZB équipés d’une puce compatible Thread.
• Avantage majeur : stabilité maximale, contrôle complet de l’interface réseau wpan0 sur le serveur hôte, et possibilité d’appliquer un pare-feu Zero-Trust (ip6tables) au millimètre. C’est l’option que nous utilisons en production.

Option B : "Thread + OTBR running on device" (OTBR embarqué directement sur le boîtier SLZB)

• Principe : le démon OpenThread Border Router tourne directement sur le processeur du boîtier SMLIGHT. Vous n’avez pas besoin d’installer l’add-on OTBR sur Home Assistant : Home Assistant se connecte directement à l’API REST du boîtier sur http://<device-ip>:8080.
• Compatibilité : réservé aux gammes SLZB-06xU, SLZB-MRxU (dont le SLZB-MR4U) et SLZB-Ultima.
• Contraintes (mentionnées dans la doc SMLIGHT) : nécessite impérativement l’IPv6 sur le LAN (l’activation de ce mode force l’IPv6 sur le boîtier SLZB) et est actuellement qualifié par SMLIGHT d’intégration initiale (bêta) pouvant présenter des limitations.

4. Guide pas à pas : configuration complète selon la documentation SMLIGHT & déploiement Docker Zero-Trust

Voici la déclinaison complète des 9 étapes du manuel officiel SMLIGHT (lien direct vers la doc #otbr), accompagnée de notre implémentation exacte en production sur notre serveur domotique.

Étape 1 & 2 : Passer uniquement la Radio 1 (EFR32MG26) du SLZB-MR4U en mode Thread RCP

Dans l’interface web de votre coordinateur (http://192.168.1.10) :

1. Assurez-vous que le coordinateur dispose d’un accès Internet temporaire pour télécharger le firmware OTA SMLIGHT (ou flashez-le localement).
2. Ouvrez le menu Mode en sélectionnant exclusivement la Radio 1 (EFR32MG26, chip_index=0, port 6638) :
   • Si vous avez choisi l’Option A (Recommandée) : sélectionnez "Thread to remote OTBR" (mode Thread RCP). Le boîtier flashe la Radio 1 avec le firmware slzb06Mg26_openthread_rcp_2.7.2.0_460800.gbl (version 20251218, vitesse 460800 bauds).
   • Si vous avez choisi l’Option B (Bêta embarquée) : sélectionnez "Thread + OTBR running on device" (l’API REST sera exposée après redémarrage sur http://192.168.1.10:8080).

Vous pouvez vérifier instantanément via l’endpoint de diagnostic /ha_info du SLZB-MR4U que la Radio 1 est passée en mode Thread (zb_type: 2) sans que la Radio 2 Zigbee (zb_type: 0) n’ait bougé :

curl -s http://192.168.1.10/ha_info | jq '.radios'

[
  {
    "chip_index": 0,
    "zb_chip": "EFR32MG26",
    "zb_version": "20251218",
    "zb_type": 2,
    "port": 6638
  },
  {
    "chip_index": 1,
    "zb_chip": "CC2674P10",
    "zb_version": "20240716",
    "zb_type": 0,
    "port": 7638
  }
]

Étape 3 : Installer et démarrer Matter Server (requis pour Matter-over-Wi-Fi ET Matter-over-Thread)

Que vous utilisiez du Wi-Fi ou du Thread (Option A ou Option B), Home Assistant délègue la cryptographie Matter (certificats PAI/DAC, sessions CASE UDP 5540) au démon officiel python-matter-server :

• Sous Home Assistant OS (HAOS) : allez dans Paramètres → Appareils et services → Ajouter une intégration → Matter, laissez cochée l’option Use the official Matter Server Supervisor add-on, puis activez Start on boot et Watchdog.
• Sous Docker (notre architecture Zero-Trust sur notre serveur domotique) : nous exécutons ghcr.io/home-assistant-libs/python-matter-server:stable en network_mode: host (indispensable pour le multicast IPv6 mDNS sur enp3s0), mais en verrouillant le port WebSocket de contrôle 5580 uniquement sur l’IP du bridge interne Home Assistant (--listen-address 172.16.28.1).

Étape 4 : Configurer l’OpenThread Border Router (OTBR) en connexion Réseau (Serial-over-IP) ou USB

Cas 4.1 : Sous Home Assistant OS (Add-on / App officiel OpenThread Border Router)

La documentation officielle SMLIGHT précise les paramètres exacts à renseigner dans l’add-on OpenThread Border Router (Paramètres → Modules complémentaires → Boutique → OpenThread Border Router → Configuration) :

• En connexion USB :
  • Port : sélectionner le port USB série du SLZB ;
  • Hardware flow control : No (Désactivé) ;
  • Baud rate : 460800 ;
  • Flash firmware : No (Désactivé, car le firmware RCP est déjà flashé sur le SLZB).
• En connexion Réseau (Serial-over-IP sur le port 6638) & contournement du bug de validation HAOS :
  • Comme documenté par SMLIGHT dans la section OTBR config validation issues workarounds (home-assistant/addons#3993 et home-assistant/addons#4299), l’interface de configuration de l’add-on HAOS bloque parfois la sauvegarde si aucun périphérique /dev/tty* USB n’est sélectionné.
  • Workaround officiel SMLIGHT : activez Show unused optional configuration options, sélectionnez un port série USB présent sur l’hôte (ou branchez un dongle USB-série quelconque pour satisfaire le validateur de schéma), puis renseignez :
    • Hardware flow control : No ;
    • Baud rate : 460800 ;
    • Flash firmware : No ;
    • Network Device : 192.168.1.10:6638 (l’IP de votre SLZB et le port TCP de la Radio 1).

Cas 4.2 : Sous Docker (ghcr.io/ownbee/hass-otbr-docker : Notre déploiement en production)

En environnement Docker Core, le dossier du conteneur matter/ est placé exactement au même niveau d’arborescence que zigbee2mqtt/ au sein du répertoire domotique/ :

domotique/
├── home-assistant/
│   ├── docker-compose.yml
│   └── config/
├── matter/
│   ├── docker-compose.yml
│   ├── enforce_matter_zero_trust.sh
│   ├── data/          # Certificats PAI/DAC & fabrics python-matter-server
│   └── otbr_data/     # Dataset actif Thread TLV (Canal 25)
├── mosquitto/
│   └── docker-compose.yml
└── zigbee2mqtt/
    ├── docker-compose.yml
    ├── data/          # Configuration & base des 98 équipements Zigbee (Canal 11)
    └── log/

Nous utilisons le conteneur ghcr.io/ownbee/hass-otbr-docker:latest qui intègre nativement un pont socat reliant le socket TCP 192.168.1.10:6638 de la Radio 1 au pseudo-terminal /tmp/ttyOTBR consommé par otbr-agent.

Voici notre fichier domotique/matter/docker-compose.yml complet réunissant matter-server et matter-otbr (avec ses volumes relatifs ./data et ./otbr_data, sur le même modèle que domotique/zigbee2mqtt/docker-compose.yml) :

services:
  matter-server:
    image: ghcr.io/home-assistant-libs/python-matter-server:stable
    container_name: matter-server
    restart: unless-stopped
    network_mode: host
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_ADMIN
      - NET_RAW
    mem_limit: 256m
    memswap_limit: 256m
    cpus: 0.50
    pids_limit: 128
    volumes:
      - ./data:/data
      - ./data/credentials:/data/credentials
      - ./data/ota:/data/ota
      - /run/dbus:/run/dbus:ro
    command: >
      --storage-path /data
      --port 5580
      --listen-address 172.16.28.1
      --primary-interface enp3s0
      --paa-root-cert-dir /data/credentials
      --ota-provider-dir /data/ota
      --disable-server-interactions      

  otbr:
    image: ghcr.io/ownbee/hass-otbr-docker:latest
    container_name: matter-otbr
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    mem_limit: 256m
    memswap_limit: 256m
    cpus: 0.50
    pids_limit: 128
    environment:
      - TZ=Europe/Paris
      - NETWORK_DEVICE=192.168.1.10:6638
      - DEVICE=/tmp/ttyOTBR
      - BAUDRATE=460800
      - FLOW_CONTROL=0
      - AUTOFLASH_FIRMWARE=0
      - BACKBONE_IF=enp3s0
      - OTBR_REST_LISTEN_ADDR=172.16.28.1
      - OTBR_REST_PORT=5581
      - OTBR_WEB=
      - FIREWALL=1
      - NAT64=0
    volumes:
      - ./otbr_data:/data

Au démarrage de matter-otbr, les journaux confirment immédiatement le handshake Spinel avec la puce EFR32MG26 du SLZB-MR4U :

[s6-init] Using network device 192.168.1.10:6638...
socat[106] N successfully connected from local address AF=2 192.168.1.2 to 192.168.1.10:6638
otbr-agent[112]: [NOTE]-PLAT----: Radio Co-processor version: SL-OPENTHREAD/2.7.2.0_GitHub-fb0446f53; EFR32; Dec 18 2025 02:17:27
[s6-init] service otbr-agent successfully started

Nous formons ensuite le réseau Thread sur le Canal 25 (2475 MHz, totalement séparé du Canal 11 utilisé par la Radio 2 Zigbee) et vérifions que le Border Router passe à l’état leader :

docker exec matter-otbr sh -c '
  ot-ctl dataset init new &&
  ot-ctl dataset channel 25 &&
  ot-ctl dataset networkname HomeAssistant-OTBR &&
  ot-ctl dataset commit active &&
  ot-ctl ifconfig up &&
  ot-ctl thread start
'

# Vérification de l'état Leader via l'API REST OTBR
curl -s http://172.16.28.1:5581/node/state
# -> "leader"

Étapes 5 & 6 : Configurer les intégrations Home Assistant (Thread & OpenThread Border Router)

Dans Home Assistant (Paramètres → Appareils et services) :

1. Ajoutez l’intégration OpenThread Border Router :
   • En Option A (Add-on HAOS / Docker) : renseignez l’URL de l’API REST locale de votre conteneur OTBR (http://172.16.28.1:5581 sur notre serveur, ou détection automatique de l’add-on sous HAOS) ;
   • En Option B (OTBR sur le SLZB) : renseignez http://192.168.1.10:8080.
2. Ouvrez ensuite l’intégration Thread (Configurer) :
   • Définissez OpenThread Border Router (HomeAssistant-OTBR) comme Preferred network (Réseau préféré) ;
   • Activez Use router for Android + iOS credentials afin que ce Border Router puisse être utilisé pour les identifiants du téléphone, puis injectez le dataset actif TLV dans matter-server (set_thread_dataset).
3. Conformément à l’étape 6 du manuel SMLIGHT, lors d’une première installation sous HAOS, redémarrez Home Assistant pour consolider la découverte mDNS des Border Routers.

Étapes 7, 8 & 9 : Préparer le smartphone et appairer un équipement Matter-over-Thread

C’est une étape cruciale souvent oubliée lors du premier appairage depuis un téléphone Android ou iOS :

1. Étape 7 : Synchroniser les identifiants Thread sur le smartphone :
   • Installez l’application Home Assistant Companion (ainsi que l’application Google Home sur Android, requise par les services Google Play pour le trousseau d’identifiants Thread) ;
   • Connectez votre téléphone au même réseau Wi-Fi que Home Assistant ;
   • Dans l’application Home Assistant Companion, allez dans Paramètres → Application compagnon → Dépannage (Troubleshooting) → Synchroniser les identifiants Thread (Sync Thread credentials).
   • (Sur Android, si le téléphone indique « Vous n’avez aucun identifiant à importer », allez dans l’intégration Thread de Home Assistant, cliquez sur ⋮ à côté du Border Router sous Preferred network et sélectionnez Send credentials to phone).
2. Étape 8 & 9 : Ajouter l’appareil Matter-over-Thread :
   • Passez l’équipement Matter en mode appairage (clignotement LED) ;
   • Dans l’application mobile Home Assistant : Paramètres → Appareils et services → Ajouter une intégration → Ajouter un appareil Matter → Scanner le QR Code ;
   • Le smartphone se connecte en Bluetooth LE à l’appareil, lui transmet le dataset Thread du Canal 25, l’appareil rejoint le maillage HomeAssistant-OTBR via la Radio 1 du SLZB-MR4U, et remonte immédiatement dans Home Assistant !

5. Durcissement Zero-Trust IPv6 (ip6tables) : confiner Matter et Thread au LAN

Parce que Matter et Thread reposent intégralement sur IPv6, une erreur classique consiste à laisser le démon otbr-agent ou la box FAI exposer des adresses IPv6 Global Unicast (2000::/3) aux objets connectés vers Internet.

Sur notre infrastructure, le script enforce_matter_zero_trust.sh verrouille le plan de contrôle (5580 / 5581) et impose un Killswitch IPv6 Global Unicast strict :

• Les ports de contrôle 5580 (matter-server) et 5581 (matter-otbr) ne sont accessibles que depuis lo et le sous-réseau Docker de Home Assistant (172.16.28.0/24) ;
• Tout paquet Matter (UDP/TCP 5540) provenant ou à destination d’une IPv6 publique routable (2000::/3) est rejeté (DROP) dans INPUT et FORWARD ;
• Seuls les préfixes locaux Link-Local (fe80::/10) pour Matter-over-Wi-Fi et Unique Local Address (fd00::/8) sur l’interface Thread wpan0 sont autorisés. Aucun objet Matter ou Thread ne peut communiquer avec un cloud externe.

Conclusion

Comprendre la distinction entre Matter-over-Wi-Fi (transporté directement par vos bornes Wi-Fi) et Matter-over-Thread (maillage 802.15.4 nécessitant un Border Router) permet d’éviter les mauvais choix d’architecture. En associant un coordinateur PoE bi-radio comme le SMLIGHT SLZB-MR4U à la documentation officielle SMLIGHT (Thread setup #otbr), il devient possible de faire cohabiter sur un seul boîtier PoE un maillage Zigbee2MQTT massif sur la Radio 2 (CC2674P10, canal 11) et un réseau Matter-over-Thread (OTBR) ultra-réactif sur la Radio 1 (EFR32MG26, canal 25), le tout confiné en local sous Home Assistant.

Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome