Shelly ThreadLink: ¿Se está convirtiendo Thread en la red IP local para hogares inteligentes?

Shelly ThreadLink no convierte Thread en una red IP: Thread se basa en IPv6 desde el principio. Lo que cambia es la forma en que Shelly planea utilizar esa red. En lugar de reservar Thread principalmente para Matter mientras mantiene las API del fabricante, la conectividad en la nube y las funciones avanzadas en Wi-Fi, ThreadLink está diseñado para transportar varias de esas rutas a través de la misma red mallada de bajo consumo.

Eso hace que ThreadLink sea más interesante que otro anuncio de compatibilidad con Matter. Si el enfoque funciona como se promete, Thread podría convertirse en el extremo IP de bajo consumo de una casa inteligente: relés, interruptores, sensores y controles se comunicarían mediante Thread, mientras Home Assistant, los servidores, los dispositivos Wi-Fi y los sistemas Ethernet seguirían formando parte de la red local más amplia. Sin embargo, el firmware todavía no está disponible: Shelly planea actualmente la actualización opcional para aproximadamente tres meses después de su anuncio del 3 de septiembre.

¿Qué es Shelly ThreadLink?

ThreadLink es un firmware alternativo próximo para dispositivos Shelly Gen4 elegibles que utiliza su radio compatible con Thread como una conexión IP más amplia, en lugar de limitarla principalmente a una sola ruta de aplicación.

En su anuncio oficial de ThreadLink, Shelly afirma que el firmware ejecutará redes IPv6 sobre Thread y admitirá comunicaciones TCP y RPC/UDP. La misma radio de bajo consumo está diseñada para transportar:

• conectividad Matter,
• tráfico de Shelly Cloud,
• comunicación RPC y API de Shelly,
• control directo entre dispositivos,
• configuración y diagnóstico,
• y una integración más profunda con Home Assistant.

El cambio arquitectónico clave es el siguiente:

MODELO ACTUAL HABITUAL

                    Matter
                      |
                    Thread

Dispositivo Shelly ───── Wi-Fi ───── API de Shelly
       |
       └─────────── Wi-Fi ───── Nube


DIRECCIÓN DE THREADLINK

                    Matter
                      |
API de Shelly ─────── Thread ───── Ruta a la nube
                      |
                  P2P local

En lugar de requerir Wi-Fi para el lado específico del fabricante mientras Thread transporta Matter, Shelly quiere que Thread proporcione por sí mismo el transporte IP para varias aplicaciones a la vez.

Esa distinción es importante porque Matter y Thread no son la misma capa de la red.

¿Está disponible Shelly ThreadLink ahora?

No. ThreadLink ha sido anunciado, pero el firmware de producción todavía no está disponible de forma general.

Shelly afirma que se ofrecerá como un firmware independiente, gratuito y opcional para dispositivos Gen4 elegibles, aproximadamente tres meses después del anuncio del 3 de septiembre de 2026.

Los usuarios elegirán por dispositivo si este ejecuta el firmware estándar orientado a Wi-Fi o ThreadLink.

Esto significa que ThreadLink debería considerarse actualmente una arquitectura anunciada, en lugar de una función que todos los propietarios de dispositivos Gen4 puedan activar hoy.

También significa que es demasiado pronto para afirmar que todos los modelos Gen4 recibirán el firmware. Shelly especifica que se trata de dispositivos Gen4 elegibles, por lo que la lista final de compatibilidad es importante.

¿Acaso Thread no era ya una red IP?

Sí. Este es el malentendido más importante que hay que aclarar.

Thread se diseñó como una red en malla basada en IPv6 que utiliza 6LoWPAN sobre radios IEEE 802.15.4. La explicación del fundamento IPv6 de Thread por parte de Thread Group remonta este principio de diseño a varios años antes de que existiera Matter.

La pila de red se puede simplificar de la siguiente manera:

APLICACIONES

Matter
Protocolos del fabricante
Otros servicios IP
       |
       v
TRANSPORTE

UDP / TCP
       |
       v
RED

IPv6
       |
       v
ADAPTACIÓN

6LoWPAN
       |
       v
RADIO

IEEE 802.15.4

Por lo tanto, Thread no es un protocolo de radio IP específico de Matter, en el mismo sentido en que muchas personas lo describen coloquialmente.

Es una red IP de bajo consumo capaz de transportar protocolos de aplicación sobre ella.

Matter es actualmente su aplicación de consumo para hogares inteligentes más visible, pero Thread está diseñado para ser independiente de la capa de aplicación.

ThreadLink no convierte Thread en una red IP. Utiliza Thread más bien como la red IP que ya es.

¿Qué hay de nuevo realmente en ThreadLink?

La novedad no es el propio IPv6. Es la decisión de permitir que un único dispositivo IoT de consumo use Thread para varias rutas de aplicaciones que a menudo aún dependen de Wi-Fi.

THREAD COMO TÚNEL DE MATTER

Matter
  |
Thread


             ↓


THREAD COMO RED

Matter ─────────┐
                |
RPC de Shelly ─────┤
                |
API local ──────┼── IPv6 / Thread
                |
Lógica P2P ──────┤
                |
Ruta de la nube ─────┘

Esto cambia el papel de la radio.

Thread ya no es útil únicamente porque otro ecosistema pueda controlar un relé mediante Matter. También puede transportar el tráfico de aplicaciones propio de Shelly, la lógica local, la configuración, los diagnósticos y, potencialmente, las actualizaciones de software.

Shelly describe ThreadLink como compatible con UDP para una comunicación local rápida y con compatibilidad completa con TCP para transferencias más grandes o sensibles a la fiabilidad, como datos de configuración y diagnósticos.

Esa es una interpretación mucho más amplia de lo que puede hacer un dispositivo de consumo conectado mediante Thread.

¿Por qué Matter no expone todas las funciones de Shelly?

Porque la interoperabilidad y la diferenciación del fabricante resuelven problemas distintos.

Matter proporciona a los fabricantes y a las plataformas de hogares inteligentes un modelo de dispositivo estandarizado. Un relé compatible con Matter puede exponer capacidades conocidas de una forma que Apple Home, Google Home, Amazon Alexa, SmartThings o Home Assistant puedan entender, sin que cada plataforma tenga que implementar un protocolo propietario completamente diferente.

Esa estandarización es valiosa.

Pero un fabricante aún puede exponer capacidades que van más allá del modelo Matter estandarizado, como:

• mediciones de energía más detalladas,
• información de diagnóstico,
• comportamiento especial del relé,
• configuración específica del dispositivo,
• funciones de scripting o automatización,
• información de estado avanzada,
• y funciones de gestión del proveedor.

Hoy en día, eso suele crear dos rutas paralelas:

DISPOSITIVO
  |
  +-- Matter
  |      |
  |      v
  |  Funciones estándar
  |  Apple / Google / HA
  |
  +-- API del proveedor
         |
         v
     Funciones avanzadas
     Diagnóstico
     Configuración

ThreadLink intenta mantener esas dos rutas sin exigir dos transportes de red diferentes:

          Matter
            \
             \
              Thread
             /
            /
       RPC de Shelly

Shelly afirma que un módulo dedicado de Home Assistant expondrá el conjunto más amplio de funciones de Shelly, más allá de lo que ofrece el modelo de datos de Matter.

Por eso ThreadLink es importante: Matter puede seguir siendo una aplicación en Thread sin necesidad de ser la única aplicación en Thread.

¿Pueden los dispositivos Shelly controlarse entre sí sin Wi-Fi?

Según el diseño ThreadLink de Shelly, sí.

Shelly afirma que los dispositivos ThreadLink pueden comunicarse directamente a través de la red mallada Thread mediante su API, lo que permite ejecutar escenas, interbloqueos y automatizaciones entre pares.

Lo importante es la ruta de fallo.

Shelly afirma que estas relaciones entre dispositivos pueden continuar incluso si:

• falla la conexión a Internet,
• no se puede acceder a Shelly Cloud,
• o la red Wi-Fi del hogar se cae.

Por lo tanto, una relación sencilla podría ser:

Interruptor de pared
     |
   Thread
     |
     v
    Relé

en lugar de exigir siempre:

Interruptor de pared
     |
     v
Wi-Fi / Router
     |
     v
Servidor doméstico
     |
     v
Wi-Fi / Router
     |
     v
Relé

Esto no significa que la ruta del servidor sea incorrecta.

Significa que no todas las acciones locales tienen que usarlo.

¿El control local todavía necesita Home Assistant?

Para relaciones sencillas entre dispositivos, no siempre. Para una orquestación más amplia, Home Assistant sigue desempeñando una función muy diferente.

Que un interruptor de pared local active un relé es fundamentalmente distinto de una automatización que combina varios sistemas.

La lógica a nivel de dispositivo puede gestionar:

• relaciones sencillas entre interruptores y relés,
• interbloqueos,
• escenas básicas,
• y un comportamiento de respaldo inmediato.

Un servidor de automatización doméstica es más adecuado para lógicas como:

SI

exportación solar > 3000 W

Y

SOC de la batería > 80%

Y

la habitación está ocupada

Y

el precio de la electricidad es bajo

ENTONCES

activar la climatización / la carga de los electrodomésticos

Ese flujo de trabajo abarca la energía, la ocupación, los precios, los horarios y, potencialmente, varios protocolos.

Pertenece a una capa de orquestación superior. El avance más amplio hacia el procesamiento local de Home Assistant sigue el mismo principio: mantener las decisiones adecuadas cerca del hogar y reservar las dependencias de la nube para las cargas de trabajo que realmente las necesitan.

CONTROL LOCAL A NIVEL DE DISPOSITIVO

Interruptor
   |
 Thread P2P
   |
Relé


CONTROL LOCAL A NIVEL DE SERVIDOR

Solar ────────────┐
Medidor de energía ┤
Presencia ────────┼── Home Assistant ── Climatización
Programación ─────┤
Otros dispositivos IoT ───┘

El enfoque local no siempre significa centrarse primero en el servidor.

Un hogar inteligente robusto puede utilizar relaciones locales entre dispositivos para acciones sencillas y mantener el servidor doméstico centrado en la lógica entre sistemas, el historial, las políticas, los paneles y el estado.

¿Cómo puede ThreadLink conectarse a la nube sin Wi‑Fi?

Una de las promesas más inusuales de ThreadLink es que el dispositivo final puede seguir siendo un dispositivo Thread y, al mismo tiempo, acceder a Shelly Cloud.

El propio dispositivo no necesita credenciales de Wi‑Fi para esa ruta.

Shelly describe la arquitectura de la siguiente manera:

Dispositivo ThreadLink de Shelly
          |
          v
     IPv6 / Thread
          |
          v
 Enrutador fronterizo Thread
          |
          v
        NAT64
          |
          v
   Servicio de Internet IPv4
          |
          v
      Shelly Cloud

La idea encaja con la evolución más amplia de Thread. Thread 1.4 formalizó trabajos adicionales en torno a una ruta estándar desde las redes Thread hacia los servicios de Internet, incluida la conectividad de IPv6 a IPv4 en el borde de la red.

El cambio conceptual importante es:

La conectividad con la nube ya no tiene por qué implicar conectividad Wi‑Fi en el dispositivo final.

Un dispositivo de bajo consumo puede utilizar Thread localmente, mientras que el enrutamiento IP en niveles superiores de la red gestiona el acceso a servicios externos.

Eso no convierte ThreadLink en una solución exclusivamente local.

Demuestra lo contrario: la comunicación local entre dispositivos y la conectividad opcional con la nube pueden compartir la misma arquitectura IP.

¿Qué hace realmente un enrutador fronterizo Thread?

Un enrutador fronterizo Thread conecta la malla Thread con la red IP más amplia. Fundamentalmente, es un enrutador, no un traductor de protocolos para cada comando del hogar inteligente.

La explicación del Grupo Thread sobre la función del enrutador fronterizo Thread hace explícita esta distinción.

Las arquitecturas tradicionales de hogares inteligentes suelen tener este aspecto:

Dispositivo Zigbee
     |
     v
Red Zigbee
     |
     v
Hub del fabricante
     |
traducción de protocolos
     |
     v
Red IP

En cambio, Thread utiliza IP en la propia red de dispositivos:

Dispositivo Thread
     |
 IPv6 / Thread
     |
     v
Router fronterizo
     |
 Enrutamiento IP
     |
     v
LAN doméstica

El enrutador fronterizo reenvía paquetes entre segmentos de red físicos.

No necesita traducir cada comando de aplicación de Thread a un protocolo LAN propietario.

Esto significa que Home Assistant puede estar ubicado en otro punto de la red local:

Dispositivo Thread
     |
Malla Thread
     |
Router fronterizo
     |
LAN Ethernet / Wi‑Fi
     |
     +-- Home Assistant
     +-- Servidor doméstico
     +-- Otros servicios IP

Por lo tanto, un controlador Matter y un enrutador fronterizo Thread cumplen funciones diferentes. El enrutador fronterizo proporciona conectividad de red; Matter proporciona una relación de aplicación y controlador por encima de esa red. Si varias plataformas controlan de forma independiente los mismos dispositivos Matter, los múltiples controladores Matter introducen una capa independiente de confianza y propiedad que el enrutamiento Thread por sí solo no resuelve.

Una vez que el tráfico sale de la malla Thread, las reglas IP habituales siguen siendo importantes. La accesibilidad de red de Home Assistant sigue dependiendo de un direccionamiento utilizable, del enrutamiento, de las políticas y de una ruta de retorno operativa entre el controlador y el dispositivo final.

¿Significa ThreadLink que Thread reemplazará al Wi‑Fi?

No. Thread y Wi‑Fi están optimizados para distintos tipos de tráfico.

La documentación actual de Thread de Home Assistant describe Thread como una tecnología de bajo consumo y bajo ancho de banda, por lo que resulta especialmente adecuada para dispositivos que intercambian cantidades relativamente pequeñas de datos.

Un relé de bajo consumo no necesita el ancho de banda de Wi‑Fi.

Una cámara de seguridad 4K no debería conectarse a Thread simplemente porque Thread se basa en IP.

Thread no se está convirtiendo en el nuevo Wi‑Fi. Podría convertirse en el extremo IP de bajo consumo de la misma red doméstica.

¿Se está convirtiendo Thread en el extremo de bajo consumo de la red LAN doméstica?

Aquí es donde ThreadLink resulta más interesante que el anuncio individual del firmware de Shelly.

Una red local del futuro podría parecerse menos a varios ecosistemas aislados de hogares inteligentes y más a una arquitectura IP unificada distribuida entre varios medios físicos:

                     SERVIDOR DOMÉSTICO
                          |
                          |
                    RED IP DOMÉSTICA
                          |
        +-----------------+----------------+
        |                 |                |
     ETHERNET           WI‑FI            THREAD
        |                 |                |
       NAS             Cámaras          Relés
     Servidores           Teléfonos           Sensores
   Estaciones de trabajo          Televisores            Interruptores
                                       Cerraduras

El dispositivo final no necesita que todos los dispositivos utilicen la misma radio.

Es más importante que las capas superiores puedan comunicarse mediante enrutamiento estándar cuando corresponda.

Esto es fundamentalmente diferente de intentar hacer que Thread, Wi‑Fi y Ethernet compitan para determinar cuál gana.

Es posible que el hogar inteligente del futuro no tenga una sola red inalámbrica. Podría tener una arquitectura IP unificada sobre varias redes físicas.

¿Qué cambia ThreadLink para Home Assistant?

ThreadLink podría proporcionar a Home Assistant dos vías útiles hacia el mismo dispositivo Shelly físico.

La primera es Matter estándar:

Dispositivo Shelly
      |
Matter sobre Thread
      |
Enrutador fronterizo Thread
      |
Controlador de Matter de Home Assistant
      |
Funciones estándar de Matter

El segundo es el camino específico del proveedor que Shelly está planificando:

Dispositivo Shelly
      |
RPC de Shelly sobre Thread
      |
Enrutador fronterizo Thread
      |
Home Assistant
      |
Funciones específicas de Shelly

La arquitectura oficial de Matter de Home Assistant ya deja clara la distinción entre red y aplicación: Matter es un protocolo de control a nivel de aplicación que puede comunicarse mediante Wi-Fi, Ethernet o Thread, según el dispositivo.

ThreadLink se basa en ese diseño por capas.

Matter puede proporcionar interoperabilidad entre ecosistemas, mientras que la integración de Shelly puede conservar una funcionalidad más profunda y específica para cada dispositivo.

Esta es una arquitectura más sólida que obligar a los usuarios a elegir entre la interoperabilidad y las funciones avanzadas del proveedor.

¿Es realmente posible tener una única red Thread hoy?

No siempre. Las implementaciones actuales de Thread pueden seguir estando más fragmentadas de lo que sugiere la arquitectura ideal.

Actualmente, Home Assistant describe su integración de Thread como un trabajo en curso y realiza un seguimiento explícito de las distintas redes Thread presentes en un hogar.

Un hogar podría descubrir algo como lo siguiente:

Red Thread de Apple
       |
credenciales diferentes


Red Thread de Google
       |
credenciales diferentes


Red Thread de Home Assistant
       |
different credentials

Los dispositivos de redes Thread independientes no se convierten automáticamente en una única malla grande simplemente porque todos utilicen Thread.

Home Assistant puede ayudar a los usuarios a inspeccionar las redes existentes y, en los casos compatibles, unir un enrutador fronterizo de Home Assistant a una red existente preferida. Sin embargo, el ecosistema de consumo aún no equivale a una única malla Thread perfectamente unificada en todos los hogares.

Esta es una importante comprobación de la realidad para ThreadLink.

Una arquitectura IP técnicamente elegante sigue dependiendo de la compatibilidad de los enrutadores fronterizos, las credenciales compartidas, la topología de red y la compatibilidad real de las implementaciones.

¿Cómo cambia el panorama Thread 1.4?

Thread 1.4 acerca el ecosistema a la idea de una red unificada.

El Thread Group describe una de sus principales mejoras como una red de malla unificada más fácil de lograr.

El objetivo es que los dispositivos actualizados y los enrutadores fronterizos de distintos ecosistemas reconozcan una red Thread existente y se unan a ella, en lugar de crear innecesariamente otra malla.

Thread 1.4 también añade o mejora:

• un camino estandarizado hacia la conectividad en la nube
• Thread sobre la infraestructura
• visibilidad del diagnóstico y la resolución de problemas de red
• convergencia de redes entre ecosistemas
• y mejoras en la puesta en servicio.

Esto sitúa ThreadLink en un contexto más amplio.

THREAD ANTERIOR

Malla IPv6 de bajo consumo
      |
Matter se vuelve dominante
aplicación de consumo


THREAD 1.4

Mejor convergencia de red
Mejor infraestructura de routers fronterizos
Ruta en la nube
Diagnóstico
      |
      v


IDEA DE THREADLINK

Matter
API del proveedor
Nube
P2P
      |
el mismo transporte IP de bajo consumo

Por tanto, ThreadLink no demuestra que todos los proveedores vayan a adoptar el mismo enfoque.

Pero es un ejemplo concreto del tipo de diversidad de aplicaciones que la arquitectura de red de Thread siempre ha hecho posible.

¿Debería pasar por el servidor doméstico toda automatización del hogar inteligente?

No. Un sistema resiliente puede distribuir la lógica según la complejidad y la importancia de la acción.

Un interbloqueo simple no necesariamente necesita un trayecto de ida y vuelta al servidor.

Probablemente sí lo haga una automatización energética para toda la casa.

Esta separación puede hacer que la red sea más resiliente, porque el fallo de una capa no elimina automáticamente todas las funciones locales. También explica por qué la verdadera ruta de rendimiento de Home Assistant incluye radios, redes, brokers, dispositivos objetivo y almacenamiento, y no solo la CPU que ejecuta Home Assistant.

¿Hace ThreadLink que un servidor doméstico sea menos importante?

Puede hacer que el servidor doméstico sea menos importante como puerta de enlace de protocolos, pero definirlo más claramente como una capa de orquestación.

Las casas inteligentes tradicionales acumularon puentes porque muchas redes de dispositivos no podían participar directamente en la red IP doméstica.

MODELO ANTIGUO

Dispositivos Zigbee ── Hub del proveedor ──┐
                               |
Otros dispositivos ─── Puerta de enlace ─────┼── Servidor doméstico
                               |
Dispositivos Wi-Fi ─────────────────┘

Una arquitectura más orientada a IP puede tener un aspecto diferente:

CAPA DE DISPOSITIVOS

Dispositivos Thread
Dispositivos Wi-Fi
Dispositivos Ethernet
       |
       v

CAPA DE RED IP
       |
       v

CAPA DE CONTROL

Home Assistant
       |
       +-- Automatizaciones
       +-- Estado
       +-- Historial
       +-- Políticas
       +-- Paneles
       +-- Lógica entre protocolos
       |
       v

CAPA DE DATOS

Copias de seguridad
NAS
Almacenamiento persistente

El servidor ya no necesita que cada paquete pase por él para justificar su existencia.

Su valor proviene cada vez más de mantener una visión general:

• qué dispositivos existen,
• en qué estado se encuentran,
• cómo interactúan los sistemas no relacionados,
• qué ocurrió ayer,
• qué automatizaciones deberían ejecutarse,
• qué debería ocurrir cuando falla un servicio,
• y cómo se protegen la configuración y el historial.

Esas responsabilidades tienen distintos requisitos de almacenamiento y recuperación. Separar los datos persistentes de Home Assistant del estado temporal de ejecución facilita mucho la protección de la capa de datos en esta arquitectura.

Thread reduce la necesidad de traducir protocolos, no la necesidad de contar con software de automatización del hogar.

Tampoco significa que Home Assistant necesite de repente hardware potente. Los requisitos actuales de hardware del servidor de Home Assistant siguen siendo modestos para la automatización habitual; las cámaras, los historiales extensos, la voz local, las bases de datos y los servicios adicionales son los que normalmente generan una mayor carga de trabajo para el servidor.

Si se espera que varios de esos servicios funcionen juntos, el dimensionamiento del servidor doméstico inteligente debería basarse en toda la pila de servicios, no en el número de dispositivos Thread.

¿Deberían los propietarios de Shelly Gen4 cambiar de Wi-Fi a ThreadLink?

Es demasiado pronto para hacer esa recomendación.

El firmware aún no ha alcanzado la disponibilidad general, la lista final de dispositivos compatibles es importante y la interoperabilidad real con las redes Thread y los Border Routers existentes aún debe probarse fuera de las demostraciones.

Cuando ThreadLink esté disponible, los propietarios de dispositivos Gen4 deberían evaluar:

• si el dispositivo Shelly exacto es compatible,
• si ya existe un Thread Border Router adecuado,
• si las redes Thread del hogar están unificadas o fragmentadas,
• si las funciones necesarias de Shelly funcionan mediante el nuevo módulo de Home Assistant,
• si se necesita acceso a la nube,
• si resulta útil la lógica directa entre dispositivos,
• y si la instalación Wi-Fi existente ya funciona de forma fiable.

Por lo tanto, la postura correcta en 2026 es observar la implementación en lugar de migrar una instalación que funciona basándose únicamente en el anuncio.

¿Se está convirtiendo Thread en la red IP local para los hogares inteligentes?

Es poco probable que Thread se convierta en la única red local de un hogar inteligente. Tiene más posibilidades de convertirse en el extremo IP de bajo consumo de esa red.

Ethernet sigue siendo el medio de transporte natural para servidores, dispositivos NAS y sistemas fijos de gran ancho de banda.

Wi-Fi sigue siendo la red inalámbrica natural para teléfonos, portátiles, cámaras, pantallas y dispositivos que necesitan un ancho de banda considerablemente mayor.

Thread encaja en el extremo de bajo consumo:

• sensores,
• relés,
• interruptores,
• cerraduras,
• controles,
• y otros dispositivos que intercambian cantidades relativamente pequeñas de datos.

Shelly ThreadLink resulta interesante porque deja de tratar ese extremo como un silo de una sola aplicación.

Matter puede proporcionar un control estandarizado del ecosistema.

La RPC de Shelly puede proporcionar funciones más avanzadas del fabricante.

La comunicación entre pares puede mantener las acciones sencillas en el ámbito local.

Un router fronterizo puede conectar la malla con la LAN más amplia.

Home Assistant puede orquestar distintos protocolos.

Además, la conectividad en la nube puede seguir siendo opcional, sin exigir que el propio dispositivo final se conecte a Wi-Fi.

Para los usuarios que quieran esa capa de orquestación en un sistema local dedicado, ZimaBoard 2 para hogares inteligentes es un ejemplo de cómo mantener el controlador en un servidor ampliable y siempre encendido, mientras los routers fronterizos Thread y las radios de los dispositivos finales permanecen como partes independientes de la red.

Por tanto, el hogar inteligente del futuro podría depender menos de elegir entre Thread, Wi-Fi y Ethernet, y más de asignar a cada uno una función dentro de la misma arquitectura IP.

Esa es la idea principal detrás de ThreadLink.

Thread siempre ha sido una red IP.

Shelly simplemente está empezando a utilizarla como tal.

Preguntas frecuentes: Shelly ThreadLink y las redes Thread para hogares inteligentes

¿Qué es Shelly ThreadLink?

ThreadLink es un firmware anunciado, de activación voluntaria, para dispositivos Shelly Gen4 elegibles. Shelly afirma que utilizará la radio Thread de los dispositivos para transportar Matter, el tráfico RPC/API de Shelly, la conectividad en la nube y la comunicación directa entre dispositivos a través de la misma malla IP de bajo consumo.

¿Shelly ThreadLink ya está disponible?

No. Shelly anunció ThreadLink el 3 de septiembre de 2026 y actualmente planea lanzar el firmware gratuito de activación voluntaria aproximadamente tres meses después para los dispositivos Gen4 elegibles.

¿Todos los dispositivos Shelly Gen4 serán compatibles con ThreadLink?

Shelly solo ha prometido la actualización para dispositivos Gen4 elegibles. La lista completa y definitiva de compatibilidad deberá consultarse cuando el firmware esté disponible.

¿ThreadLink convierte Thread en una red IP?

No. Thread siempre se ha basado en IPv6, 6LoWPAN e IEEE 802.15.4. ThreadLink cambia la forma en que Shelly pretende utilizar esa red IP existente, al ejecutar sobre ella más servicios además de Matter.

¿Matter es lo mismo que Thread?

No. Matter es un estándar de control del hogar inteligente de nivel de aplicación. Thread es una red de malla IPv6 de bajo consumo que puede transportar Matter u otros protocolos de aplicación compatibles.

¿Puede funcionar Thread sin Matter?

Sí. Thread es independiente de la capa de aplicación. Actualmente, los productos Thread de consumo están estrechamente asociados con Matter, pero Thread puede transportar otros protocolos de aplicación basados en IP.

¿Pueden funcionar los dispositivos ThreadLink sin Wi‑Fi?

Shelly afirma que los dispositivos ThreadLink pueden usar Thread para Matter, la comunicación mediante API local, la automatización entre pares y la conectividad en la nube a través de un enrutador fronterizo Thread, sin que el propio dispositivo final se conecte a Wi‑Fi.

¿Puede ThreadLink funcionar sin Internet?

Shelly afirma que las escenas, los enclavamientos y las automatizaciones directas entre dispositivos pueden funcionar localmente dentro de la malla Thread, incluso si se interrumpe la conexión a Internet o la red Wi‑Fi.

¿ThreadLink requiere un enrutador fronterizo Thread?

Se necesita un enrutador fronterizo cuando los dispositivos ThreadLink deben comunicarse con la LAN doméstica, las aplicaciones, Home Assistant o los servicios en la nube. Shelly afirma que las escenas entre dispositivos pueden funcionar dentro de la propia malla Thread.

¿Reemplaza ThreadLink a Home Assistant?

No. La lógica directa entre pares puede eliminar la necesidad de un servidor en relaciones sencillas entre dispositivos, mientras que Home Assistant sigue siendo útil para la automatización entre protocolos, el historial, los paneles, las políticas, las programaciones y la orquestación de todo el hogar.

¿Reemplazará Thread a Wi‑Fi?

Probablemente no. Thread está diseñado para dispositivos IoT de bajo consumo y ancho de banda relativamente reducido. Wi‑Fi sigue siendo más adecuado para productos que requieren mayor ancho de banda, como cámaras, pantallas, teléfonos y ordenadores.

¿Cuál es la diferencia entre un enrutador fronterizo Thread y un concentrador de hogar inteligente?

Un enrutador fronterizo Thread enruta principalmente tráfico IPv6 entre la malla Thread y la red IP más amplia. Un concentrador o puente tradicional suele traducir entre una red de dispositivos que no usa IP y una LAN o aplicación basada en IP.

¿Puede haber más de una red Thread en un hogar?

Sí. Los hogares actuales pueden contener redes Thread independientes de Apple, Google, Home Assistant u otros, con credenciales diferentes. Thread 1.4 pretende facilitar la convergencia en una malla existente, pero las implementaciones reales siguen dependiendo de la compatibilidad de los dispositivos y los ecosistemas.

¿Qué cambia con Thread 1.4?

Thread 1.4 mejora la incorporación a redes de distintos ecosistemas, la infraestructura de los enrutadores fronterizos, la conectividad en la nube, los diagnósticos, la puesta en marcha, la fiabilidad y la capacidad de mantener una malla Thread unificada más grande.

¿Por qué es importante ThreadLink para los servidores domésticos?

Sugiere que el servidor doméstico puede centrarse menos en traducir redes de dispositivos propietarios y más en la orquestación, el estado, el historial, las políticas, la automatización entre sistemas y los datos duraderos, mientras Thread, Wi‑Fi y Ethernet se encargan del transporte IP subyacente.