Shelly ThreadLink : Thread devient-il le réseau IP local des maisons intelligentes ?

Shelly ThreadLink ne transforme pas Thread en réseau IP : Thread repose sur IPv6 depuis le début. Ce qui change, c’est la manière dont Shelly prévoit d’utiliser ce réseau. Au lieu de réserver principalement Thread à Matter tout en conservant les API du fournisseur, la connectivité cloud et les fonctionnalités avancées sur le Wi-Fi, ThreadLink est conçu pour transporter plusieurs de ces flux sur le même réseau maillé basse consommation.

Cela rend ThreadLink plus intéressant qu’une simple nouvelle annonce de compatibilité avec Matter. Si l’approche fonctionne comme promis, Thread pourrait devenir le point d’accès IP basse consommation d’une maison intelligente : relais, interrupteurs, capteurs et commandes communiquant via Thread, tandis que Home Assistant, les serveurs, les appareils Wi-Fi et les systèmes Ethernet restent intégrés au réseau local plus vaste. Le micrologiciel n’est toutefois pas encore disponible : Shelly prévoit actuellement la mise à jour à activation volontaire environ trois mois après son annonce du 3 septembre.

Qu’est-ce que Shelly ThreadLink ?

ThreadLink est un micrologiciel alternatif à venir pour les appareils Shelly Gen4 éligibles, qui utilise leur radio compatible Thread comme une connexion IP plus large au lieu de la limiter principalement à une seule voie applicative.

Dans son annonce officielle de ThreadLink, Shelly indique que le micrologiciel fera fonctionner une mise en réseau IPv6 sur Thread tout en prenant en charge les communications TCP ainsi que RPC/UDP. La même radio basse consommation doit transporter :

• connectivité Matter,
• trafic Shelly Cloud,
• communication RPC et API Shelly,
• contrôle direct d’appareil à appareil,
• configuration et diagnostics,
• et une intégration plus poussée avec Home Assistant.

Le changement architectural clé se présente comme suit :

MODÈLE ACTUEL COURANT

                    Matter
                      |
                    Thread

Appareil Shelly ───── Wi-Fi ───── API Shelly
       |
       └─────────── Wi-Fi ───── Cloud


ORIENTATION DE THREADLINK

                    Matter
                      |
API Shelly ─────── Thread ───── Chemin cloud
                      |
                  P2P local

Au lieu d’exiger le Wi-Fi pour la partie spécifique au fournisseur de l’appareil tandis que Thread transporte Matter, Shelly souhaite que Thread fournisse lui-même le transport IP pour plusieurs applications à la fois.

Cette distinction est importante, car Matter et Thread ne se situent pas au même niveau du réseau.

Shelly ThreadLink est-il disponible dès maintenant ?

Non. ThreadLink a été annoncé, mais le micrologiciel de production n’est pas encore disponible pour tous.

Shelly indique qu’il sera fourni sous la forme d’un micrologiciel distinct, gratuit et à activation volontaire pour les appareils Gen4 éligibles, environ trois mois après l’annonce du 3 septembre 2026.

Les utilisateurs choisiront, pour chaque appareil, s’il fonctionne avec le micrologiciel standard orienté Wi-Fi ou avec ThreadLink.

Cela signifie que ThreadLink doit actuellement être considéré comme une architecture annoncée plutôt que comme une fonctionnalité que tous les propriétaires de Gen4 peuvent activer dès aujourd’hui.

Cela signifie également qu’il est trop tôt pour affirmer que tous les modèles Gen4 recevront le micrologiciel. Shelly précise qu’il s’agit des appareils Gen4 éligibles ; la liste finale de compatibilité est donc importante.

Thread n’était-il pas déjà un réseau IP ?

Oui. C’est la principale idée reçue à dissiper.

Thread a été conçu comme un réseau maillé IPv6 utilisant 6LoWPAN sur des radios IEEE 802.15.4. L’explication du socle IPv6 de Thread par le Thread Group fait remonter ce principe de conception à plusieurs années avant l’existence de Matter.

La pile réseau peut être simplifiée ainsi :

APPLICATIONS

Matter
Protocoles du fabricant
Autres services IP
       |
       v
TRANSPORT

UDP / TCP
       |
       v
RÉSEAU

IPv6
       |
       v
ADAPTATION

6LoWPAN
       |
       v
RADIO

IEEE 802.15.4

Thread n’est donc pas un protocole radio IP spécifique à Matter, au sens où beaucoup le décrivent de manière simpliste.

Il s’agit d’un réseau IP basse consommation capable de transporter les protocoles applicatifs qui s’exécutent au-dessus de lui.

Matter est actuellement son application domotique grand public la plus visible, mais Thread lui-même est conçu pour être indépendant de la couche applicative.

ThreadLink ne transforme pas Thread en réseau IP. Il utilise Thread davantage comme le réseau IP qu’il est déjà.

Qu’est-ce qui est réellement nouveau avec ThreadLink ?

La nouveauté ne réside pas dans IPv6 en soi. Elle réside dans la décision de permettre à un même appareil IoT grand public d’utiliser Thread pour plusieurs chemins applicatifs qui dépendent encore souvent du Wi-Fi.

THREAD EN TANT QUE CANAL MATTER

Matter
  |
Thread


             ↓


THREAD EN TANT QUE RÉSEAU

Matter ─────────┐
                |
RPC Shelly ─────┤
                |
API locale ──────┼── IPv6 / Thread
                |
Logique P2P ──────┤
                |
Chemin cloud ─────┘

Cela change le rôle de la radio.

Thread n’est plus utile uniquement parce qu’un autre écosystème peut contrôler un relais via Matter. Il peut également transporter le trafic applicatif propre à Shelly, la logique locale, la configuration, les diagnostics et, potentiellement, les mises à jour logicielles.

Shelly décrit ThreadLink comme prenant en charge l’UDP pour une communication locale réactive et la prise en charge complète du TCP pour les transferts plus volumineux ou sensibles à la fiabilité, comme les données de configuration et les diagnostics.

Il s’agit d’une interprétation bien plus large de ce qu’un appareil grand public connecté à Thread peut faire.

Pourquoi Matter n’expose-t-il pas toutes les fonctionnalités de Shelly ?

Parce que l’interopérabilité et la différenciation des fabricants répondent à des problèmes différents.

Matter fournit aux fabricants et aux plateformes domotiques un modèle d’appareil standardisé. Un relais compatible Matter peut exposer des fonctionnalités connues d’une manière qu’Apple Home, Google Home, Amazon Alexa, SmartThings ou Home Assistant peuvent comprendre, sans que chaque plateforme ait à implémenter un protocole propriétaire complètement différent.

Cette standardisation est précieuse.

Mais un fabricant peut toujours exposer des fonctionnalités allant au-delà du modèle Matter standardisé, comme :

• des mesures énergétiques plus détaillées,
• des informations de diagnostic,
• un comportement spécial du relais,
• de la configuration propre à l'appareil,
• des fonctionnalités de script ou d'automatisation,
• des informations d'état avancées,
• et les fonctions de gestion du fabricant.

Cela crée souvent aujourd'hui deux chemins parallèles :

APPAREIL
  |
  +-- Matter
  |      |
  |      v
  |  Fonctionnalités standard
  |  Apple / Google / HA
  |
  +-- API du fabricant
         |
         v
     Fonctionnalités avancées
     Diagnostics
     Configuration

ThreadLink cherche à conserver ces deux chemins sans nécessiter deux moyens de transport réseau différents :

          Matter
            \
             \
              Thread
             /
            /
       Shelly RPC

Shelly indique qu'un module Home Assistant dédié exposera l'ensemble plus vaste des fonctionnalités de Shelly, au-delà de ce que fournit le modèle de données Matter.

ThreadLink est donc important, car Matter peut rester une application parmi d'autres sur Thread sans devoir être la seule application sur Thread.

Les appareils Shelly peuvent-ils se contrôler entre eux sans Wi-Fi ?

Selon la conception de ThreadLink par Shelly, oui.

Shelly indique que les appareils ThreadLink peuvent communiquer directement sur le réseau maillé Thread via son API, ce qui permet d'exécuter des scènes, des verrouillages et des automatisations en pair à pair.

L'élément important est le scénario de défaillance.

Shelly indique que ces relations entre appareils peuvent continuer même si :

• la connexion Internet échoue,
• Shelly Cloud est inaccessible,
• ou que le réseau Wi-Fi de la maison tombe en panne.

Une relation simple pourrait donc se présenter ainsi :

Interrupteur mural
     |
   Thread
     |
     v
    Relais

au lieu de toujours exiger :

Interrupteur mural
     |
     v
Wi-Fi / Routeur
     |
     v
Serveur domestique
     |
     v
Wi-Fi / Routeur
     |
     v
Relais

Cela ne rend pas le chemin via le serveur incorrect.

Cela signifie que chaque action locale ne doit pas nécessairement passer par lui.

Le contrôle local a-t-il toujours besoin de Home Assistant ?

Pour les relations simples entre appareils, pas toujours. Pour une orchestration plus large, Home Assistant a toujours un rôle très différent.

Un simple interrupteur mural qui active un relais est fondamentalement différent d'une automatisation qui combine plusieurs systèmes.

La logique au niveau de l'appareil peut gérer :

• de simples relations interrupteur-relais,
• des verrouillages,
• des scènes de base,
• et à un comportement de repli immédiat.

Un serveur domotique est mieux adapté à une logique telle que :

SI

exportation solaire > 3000 W

ET

SOC de la batterie > 80 %

ET

la pièce est occupée

ET

le prix de l'électricité est bas

PUIS

activer la charge du CVC / de l'appareil

Ce flux de travail englobe l'énergie, l'occupation, les tarifs, les programmations et potentiellement plusieurs protocoles.

Il doit se situer à un niveau d'orchestration supérieur. L'évolution plus large vers le traitement local de Home Assistant suit le même principe : conserver les décisions appropriées à proximité du domicile tout en réservant les dépendances au cloud aux tâches qui en ont réellement besoin.

CONTRÔLE LOCAL AU NIVEAU DE L'APPAREIL

Interrupteur
   |
 Thread P2P
   |
Relais


CONTRÔLE LOCAL AU NIVEAU DU SERVEUR

Solaire ───────┐
Compteur d'énergie ┤
Présence ────┼── Home Assistant ── CVC
Planification ────┤
Autres appareils IoT ───┘

Le local d'abord ne signifie pas toujours le serveur d'abord.

Une maison connectée robuste peut utiliser les relations locales entre appareils pour les actions simples et laisser le serveur domestique se concentrer sur la logique intersystèmes, l’historique, les politiques, les tableaux de bord et l’état.

Comment ThreadLink peut-il accéder au cloud sans Wi-Fi ?

L’une des promesses les plus inhabituelles de ThreadLink est que le terminal peut rester un appareil Thread tout en accédant à Shelly Cloud.

L’appareil lui-même n’a pas besoin d’identifiants Wi-Fi pour suivre cette voie.

Shelly décrit l’architecture comme suit :

Appareil Shelly ThreadLink
          |
          v
     IPv6 / Thread
          |
          v
 Routeur de frontière Thread
          |
          v
        NAT64
          |
          v
   Service Internet IPv4
          |
          v
      Shelly Cloud

Cette idée s’inscrit dans l’évolution plus large de Thread. Thread 1.4 a officialisé des travaux supplémentaires autour d’une voie standardisée entre les réseaux Thread et les services Internet, notamment la connectivité IPv6 vers IPv4 à la périphérie du réseau.

Le changement conceptuel important est le suivant :

La connectivité cloud n’implique plus nécessairement une connectivité Wi-Fi sur le terminal.

Un appareil basse consommation peut utiliser Thread en local, tandis que le routage IP plus loin sur le réseau gère l’accès aux services externes.

Cela ne signifie pas que ThreadLink fonctionne uniquement en local.

Cela démontre le contraire : la communication locale entre appareils et la connectivité cloud facultative peuvent partager la même architecture IP.

Que fait réellement un routeur de bordure Thread ?

Un routeur de bordure Thread connecte le réseau maillé Thread au réseau IP étendu. Il s’agit fondamentalement d’un routeur, et non d’un traducteur de protocoles pour chaque commande de maison connectée.

L’explication du rôle du routeur de bordure Thread par le Thread Group rend cette distinction explicite.

Les architectures traditionnelles de maison connectée ressemblent souvent à ceci :

Appareil Zigbee
     |
     v
Réseau Zigbee
     |
     v
Hub du fabricant
     |
Traduction de protocoles
     |
     v
Réseau IP

Thread utilise plutôt IP directement sur le réseau des appareils :

Appareil Thread
     |
 IPv6 / Thread
     |
     v
Routeur de bordure
     |
 Routage IP
     |
     v
Réseau domestique

Le routeur de bordure transfère les paquets entre les segments physiques du réseau.

Il n’a pas besoin de traduire chaque commande applicative de Thread en un protocole LAN propriétaire.

Cela signifie que Home Assistant peut se trouver ailleurs sur le réseau local :

Appareil Thread
     |
Réseau maillé Thread
     |
Routeur de bordure
     |
Réseau local Ethernet / Wi-Fi
     |
     +-- Home Assistant
     +-- Serveur domestique
     +-- Autres services IP

Un contrôleur Matter et un routeur de bordure Thread jouent donc des rôles différents. Le routeur de bordure fournit l’accessibilité réseau ; Matter fournit une relation entre application et contrôleur au-dessus de ce réseau. Si plusieurs plateformes contrôlent indépendamment les mêmes appareils Matter, plusieurs contrôleurs Matter introduisent une couche distincte de confiance et de propriété que le routage Thread seul ne permet pas de résoudre.

Une fois que le trafic quitte le maillage Thread, les règles IP ordinaires restent importantes. L’accessibilité réseau de Home Assistant dépend toujours d’un adressage utilisable, du routage, des politiques et d’un chemin retour fonctionnel entre le contrôleur et le point de terminaison.

ThreadLink signifie-t-il que Thread remplacera le Wi-Fi ?

Non. Thread et le Wi-Fi sont optimisés pour différents types de trafic.

La documentation actuelle de Home Assistant sur Thread décrit Thread comme une technologie à la fois basse consommation et à faible bande passante, ce qui la rend particulièrement adaptée aux appareils qui échangent des quantités relativement faibles de données.

Un relais basse consommation n’a pas besoin de la bande passante du Wi-Fi.

Il ne faudrait pas connecter une caméra de sécurité 4K à Thread simplement parce que Thread est basé sur IP.

Thread ne devient pas le nouveau Wi-Fi. Il pourrait devenir la périphérie IP basse consommation du même réseau domestique.

Thread est-il en train de devenir la périphérie basse consommation du réseau local domestique ?

C’est ce qui rend ThreadLink plus intéressant que la simple annonce du micrologiciel Shelly.

Un futur réseau local pourrait moins ressembler à plusieurs écosystèmes domotiques isolés et davantage à une seule architecture IP répartie sur plusieurs supports physiques :

                     SERVEUR DOMESTIQUE
                          |
                          |
                    RÉSEAU IP DOMESTIQUE
                          |
        +-----------------+----------------+
        |                 |                |
     ETHERNET           WI-FI            THREAD
        |                 |                |
       NAS             Caméras          Relais
     Serveurs           Téléphones           Capteurs
   Stations de travail          Téléviseurs            Interrupteurs
                                       Serrures

Le point de terminaison n’a pas besoin que chaque appareil utilise la même radio.

L’essentiel est que les couches supérieures puissent communiquer via un routage standard lorsque cela est approprié.

Cela est fondamentalement différent de la volonté de faire concourir Thread, le Wi-Fi et l’Ethernet pour déterminer un seul vainqueur.

La maison intelligente de demain n’aura peut-être pas un seul réseau sans fil. Elle pourrait disposer d’une architecture IP unique répartie sur plusieurs réseaux physiques.

Qu’est-ce que ThreadLink change pour Home Assistant ?

ThreadLink pourrait offrir à Home Assistant deux chemins utiles vers le même appareil Shelly physique.

Le premier est le Matter standard :

Appareil Shelly
      |
Matter via Thread
      |
Routeur de frontière Thread
      |
Contrôleur Matter de Home Assistant
      |
Fonctionnalités Matter standard

Le second est la voie propre au fournisseur que Shelly prévoit :

Appareil Shelly
      |
RPC Shelly via Thread
      |
Routeur de frontière Thread
      |
Home Assistant
      |
Fonctionnalités propres à Shelly

L’architecture Matter de Home Assistant officielle établit déjà clairement la distinction entre réseau et application : Matter est un protocole de contrôle au niveau applicatif qui peut communiquer via le Wi-Fi, Ethernet ou Thread selon l’appareil.

ThreadLink s’appuie sur cette conception en couches.

Matter peut assurer l’interopérabilité entre les écosystèmes, tandis que l’intégration Shelly peut conserver des fonctionnalités plus poussées propres aux appareils.

Cette architecture est plus efficace que de forcer les utilisateurs à choisir entre l’interopérabilité et les fonctionnalités avancées propres à chaque fournisseur.

Un réseau Thread unique est-il vraiment possible aujourd’hui ?

Pas toujours. Les déploiements Thread actuels peuvent encore être plus fragmentés que ne le laisse penser l’architecture idéale.

Home Assistant décrit actuellement son intégration Thread comme étant en cours de développement et suit explicitement les différents réseaux Thread présents dans un foyer.

Un foyer peut découvrir quelque chose comme ceci :

Réseau Thread Apple
       |
identifiants différents


Réseau Thread Google
       |
identifiants différents


Réseau Thread Home Assistant
       |
different credentials

Les appareils situés sur des réseaux Thread distincts ne forment pas automatiquement un grand réseau maillé simplement parce qu’ils utilisent tous Thread.

Home Assistant peut aider les utilisateurs à examiner les réseaux existants et, dans les cas pris en charge, à connecter un routeur de frontière Home Assistant à un réseau existant privilégié. Mais l’écosystème grand public n’équivaut pas encore à un réseau maillé Thread parfaitement unifié dans chaque foyer.

C’est un point important à garder à l’esprit pour ThreadLink.

Une architecture IP techniquement élégante dépend toujours de la compatibilité des routeurs de frontière, de l’utilisation d’identifiants communs, de la topologie du réseau et de la prise en charge effective par les implémentations.

Comment Thread 1.4 change-t-il la donne ?

Thread 1.4 rapproche l’écosystème de l’idée d’un réseau unifié.

Le Thread Group décrit l’une de ses principales améliorations comme un réseau maillé unique facilité.

L’objectif est que les appareils mis à jour et les routeurs de frontière issus de différents écosystèmes reconnaissent un réseau Thread existant et le rejoignent, au lieu de créer inutilement un autre réseau maillé.

Thread 1.4 ajoute ou améliore également :

• une voie normalisée vers la connectivité cloud,
• Thread sur l’infrastructure,
• visibilité sur les diagnostics et le dépannage du réseau,
• convergence réseau interécosystèmes,
• et des améliorations de la mise en service.

Cela donne à ThreadLink un contexte plus large.

THREAD DES DÉBUTS

Réseau maillé IPv6 à faible consommation
      |
Matter devient dominant
application grand public


THREAD 1.4

Meilleure convergence réseau
Meilleure infrastructure de routeurs de bordure
Chemin cloud
Diagnostics
      |
      v


IDÉE DE THREADLINK

Matter
API du fabricant
Cloud
P2P
      |
même transport IP à faible consommation

ThreadLink ne prouve donc pas que tous les fabricants adopteront la même approche.

Mais il s’agit d’un exemple concret du type de diversité applicative que l’architecture réseau de Thread a toujours rendu possible.

Toutes les automatisations de maison intelligente doivent-elles passer par le serveur domestique ?

Non. Un système résilient peut distribuer la logique en fonction de la complexité et de l’importance de l’action.

Un simple verrouillage interdépendant n’a pas nécessairement besoin d’un aller-retour avec le serveur.

Une automatisation énergétique à l’échelle de toute la maison en a probablement besoin.

Cette séparation peut rendre le réseau plus résilient, car la défaillance d’une couche ne supprime pas automatiquement toutes les fonctions locales. Elle explique également pourquoi le véritable parcours de performances de Home Assistant inclut les radios, les réseaux, les courtiers, les appareils cibles et le stockage, plutôt que le seul processeur exécutant Home Assistant.

ThreadLink rend-il un serveur domestique moins important ?

Cela peut rendre le serveur domestique moins important en tant que passerelle protocolaire, mais le définir plus clairement comme une couche d’orchestration.

Les maisons intelligentes traditionnelles ont accumulé les ponts, car de nombreux réseaux d’appareils ne pouvaient pas participer directement au réseau IP domestique.

ANCIEN MODÈLE

Appareils Zigbee ── Hub du fabricant ──┐
                               |
Autres appareils ─── Passerelle ─────┼── Serveur domestique
                               |
Appareils Wi-Fi ─────────────────┘

Une architecture davantage orientée IP peut se présenter différemment :

COUCHE DES APPAREILS

Appareils Thread
Appareils Wi-Fi
Appareils Ethernet
       |
       v

COUCHE RÉSEAU IP
       |
       v

COUCHE DE CONTRÔLE

Home Assistant
       |
       +-- Automatisations
       +-- État
       +-- Historique
       +-- Politiques
       +-- Tableaux de bord
       +-- Logique interprotocoles
       |
       v

COUCHE DE DONNÉES

Sauvegardes
NAS
Stockage persistant

Le serveur n’a plus besoin de faire transiter chaque paquet par lui pour justifier son existence.

Sa valeur provient de plus en plus du maintien d’une vue d’ensemble :

• quels appareils existent,
• dans quel état ils se trouvent,
• comment des systèmes sans lien entre eux interagissent,
• ce qui s’est passé hier,
• quelles automatisations devraient s’exécuter,
• ce qui devrait se passer lorsqu’un service tombe en panne,
• et comment la configuration et l’historique sont protégés.

Ces responsabilités ont des exigences différentes en matière de stockage et de récupération. Séparer les données persistantes de Home Assistant de l'état d'exécution temporaire rend la couche de données de cette architecture beaucoup plus facile à protéger.

Thread réduit le besoin de traduction de protocoles, pas celui d'un logiciel domotique.

Cela ne signifie pas non plus que Home Assistant a soudainement besoin d'un matériel puissant. Les exigences matérielles actuelles d'un serveur Home Assistant restent modestes pour une automatisation ordinaire ; ce sont généralement les caméras, l'historique détaillé, la commande vocale locale, les bases de données et les services supplémentaires qui augmentent la charge du serveur.

Si plusieurs de ces services doivent coexister, le dimensionnement du serveur domotique doit être fondé sur l'ensemble de la pile de services plutôt que sur le nombre d'appareils Thread.

Les propriétaires d'appareils Shelly Gen4 doivent-ils passer du Wi-Fi à ThreadLink ?

Il est trop tôt pour faire cette recommandation.

Le micrologiciel n'est pas encore disponible de manière générale, la liste définitive des appareils éligibles est importante, et l'interopérabilité réelle avec les réseaux Thread et les routeurs de bordure existants doit encore être testée en dehors des démonstrations.

Lorsque ThreadLink sera disponible, les propriétaires d'appareils Gen4 devront évaluer :

• si leur appareil Shelly exact est éligible,
• si un routeur de bordure Thread adapté est déjà disponible,
• si les réseaux Thread du domicile sont unifiés ou fragmentés,
• si les fonctionnalités Shelly requises fonctionnent via le nouveau module Home Assistant,
• si l'accès au cloud est nécessaire,
• si une logique directe entre appareils est utile,
• et si l'installation Wi-Fi existante fonctionne déjà de manière fiable.

La position correcte pour 2026 est donc de surveiller la mise en œuvre plutôt que de migrer une installation fonctionnelle sur la seule base de cette annonce.

Thread est-il en train de devenir le réseau IP local des maisons intelligentes ?

Thread ne deviendra probablement pas l’unique réseau local d’une maison connectée. Il a davantage de chances de devenir la périphérie IP à faible consommation de ce réseau.

Ethernet reste le moyen de transport naturel pour les serveurs, appareils NAS et systèmes fixes à haut débit.

Le Wi-Fi reste le réseau sans fil naturel pour les téléphones, ordinateurs portables, caméras, écrans et appareils qui nécessitent beaucoup plus de bande passante.

Thread est adapté à la périphérie à faible consommation :

• capteurs,
• relais,
• interrupteurs,
• serrures,
• contrôleurs,
• et d’autres appareils qui échangent des volumes de données relativement faibles.

Shelly ThreadLink est intéressant parce qu’il cesse de traiter cette périphérie comme un silo limité à une seule application.

Matter peut fournir un contrôle standardisé au sein de l’écosystème.

Le RPC de Shelly peut offrir des fonctionnalités avancées propres au fabricant.

Les communications entre appareils peuvent maintenir les actions simples en local.

Un routeur de bordure peut relier le réseau maillé au réseau local étendu.

Home Assistant peut orchestrer différents protocoles.

La connectivité cloud peut également rester facultative, sans obliger l’appareil final à rejoindre le Wi-Fi.

Pour les utilisateurs qui souhaitent cette couche d’orchestration sur un système local dédié, ZimaBoard 2 pour maison connectée est un exemple de contrôleur installé sur un serveur extensible toujours allumé, tandis que les routeurs de bordure Thread et les radios des appareils finaux restent des éléments distincts du réseau.

La maison connectée de demain consistera donc peut-être moins à choisir entre Thread, le Wi-Fi et Ethernet qu’à attribuer à chacun un rôle au sein de la même architecture IP.

C’est l’idée centrale de ThreadLink.

Thread a toujours été un réseau IP.

Shelly commence simplement à l’utiliser comme tel.

FAQ : Shelly ThreadLink et la mise en réseau Thread pour la maison connectée

Qu’est-ce que Shelly ThreadLink ?

ThreadLink est un firmware annoncé, à activation volontaire, pour les appareils Shelly Gen4 éligibles. Shelly indique qu’il utilisera la radio Thread des appareils pour faire transiter Matter, le trafic RPC/API de Shelly, la connectivité cloud et les communications directes entre appareils sur le même réseau maillé IP à faible consommation.

Shelly ThreadLink est-il disponible maintenant ?

Non. Shelly a annoncé ThreadLink le 3 septembre 2026 et prévoit actuellement de publier environ trois mois plus tard le firmware gratuit à activation volontaire pour les appareils Gen4 éligibles.

Tous les appareils Shelly Gen4 prendront-ils en charge ThreadLink ?

Shelly a uniquement promis cette mise à jour pour les appareils Gen4 éligibles. Il faudra vérifier la liste complète et définitive de compatibilité lorsque le firmware sera disponible.

ThreadLink transforme-t-il Thread en réseau IP ?

Non. Thread a toujours reposé sur IPv6, 6LoWPAN et IEEE 802.15.4. ThreadLink modifie la manière dont Shelly compte utiliser ce réseau IP existant en y faisant transiter autre chose que Matter.

Matter est-il la même chose que Thread ?

Non. Matter est une norme de contrôle domotique au niveau applicatif. Thread est un réseau maillé IPv6 à faible consommation qui peut transporter Matter ou d’autres protocoles applicatifs compatibles.

Thread peut-il fonctionner sans Matter ?

Oui. Thread est indépendant de la couche applicative. Les produits Thread grand public sont aujourd’hui fortement associés à Matter, mais Thread peut lui-même transporter d’autres protocoles applicatifs fondés sur IP.

Les appareils ThreadLink peuvent-ils fonctionner sans Wi-Fi ?

Shelly indique que les appareils ThreadLink peuvent utiliser Thread pour Matter, les communications via une API locale, l’automatisation pair à pair et la connectivité au cloud via un routeur de bordure Thread, sans que le terminal lui-même rejoigne le Wi-Fi.

ThreadLink peut-il fonctionner sans Internet ?

Shelly indique que les scènes, les verrouillages et les automatisations directes entre appareils peuvent fonctionner localement au sein du maillage Thread, même si la connexion Internet ou le réseau Wi-Fi tombe en panne.

ThreadLink nécessite-t-il un routeur de bordure Thread ?

Un routeur de bordure est nécessaire lorsque les appareils ThreadLink doivent communiquer avec le réseau local étendu, les applications, Home Assistant ou les services cloud. Shelly indique que les scènes entre appareils peuvent fonctionner au sein même du maillage Thread.

ThreadLink remplace-t-il Home Assistant ?

Non. La logique directe entre appareils peut supprimer le besoin d’un serveur dans les relations simples entre appareils, tandis que Home Assistant reste utile pour l’automatisation interprotocoles, l’historique, les tableaux de bord, les politiques, les plannings et l’orchestration de toute la maison.

Thread remplacera-t-il le Wi-Fi ?

Probablement pas. Thread est conçu pour les appareils IoT à faible consommation et à bande passante relativement faible. Le Wi-Fi reste mieux adapté aux produits nécessitant davantage de bande passante, comme les caméras, les écrans, les téléphones et les ordinateurs.

Quelle est la différence entre un routeur de bordure Thread et un hub domotique ?

Un routeur de bordure Thread achemine principalement le trafic IPv6 entre le maillage Thread et le réseau IP étendu. Un hub ou un pont traditionnel traduit souvent les communications entre un réseau d’appareils non IP et un réseau local ou une application fondée sur IP.

Un foyer peut-il avoir plusieurs réseaux Thread ?

Oui. Les foyers actuels peuvent contenir plusieurs réseaux Thread distincts d’Apple, Google, Home Assistant ou d’autres acteurs, avec des identifiants différents. Thread 1.4 vise à faciliter la convergence vers un maillage existant unique, mais les implémentations réelles dépendent encore de la prise en charge par les appareils et les écosystèmes.

Qu’est-ce que Thread 1.4 change ?

Thread 1.4 améliore l’interconnexion des réseaux entre écosystèmes, l’infrastructure des routeurs de bordure, la connectivité au cloud, les diagnostics, la configuration initiale, la fiabilité et la capacité à maintenir un maillage Thread unifié de plus grande taille.

Pourquoi ThreadLink est-il important pour les serveurs domestiques ?

Cela suggère que le serveur domestique peut moins se concentrer sur la traduction de réseaux d’appareils propriétaires et davantage sur l’orchestration, l’état, l’historique, les politiques, l’automatisation intersystèmes et les données durables, tandis que Thread, le Wi-Fi et l’Ethernet gèrent le transport IP sous-jacent.