Shelly ThreadLink: Is Thread Becoming the Local IP Network for Smart Homes?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Shelly ThreadLink: Is Thread Becoming the Local IP Network for Smart Homes? - Zima Store Online

Shelly ThreadLink does not turn Thread into an IP network—Thread has been built on IPv6 from the beginning. What changes is how Shelly plans to use that network. Instead of reserving Thread mainly for Matter while keeping vendor APIs, cloud connectivity, and advanced features on Wi-Fi, ThreadLink is designed to carry several of those paths over the same low-power mesh.

That makes ThreadLink more interesting than another Matter compatibility announcement. If the approach works as promised, Thread could become the low-power IP edge of a smart home: relays, switches, sensors, and controls communicating over Thread while Home Assistant, servers, Wi-Fi devices, and Ethernet systems remain part of the wider local network. The firmware is not available yet, however—Shelly currently plans the opt-in update for roughly three months after its September 3 announcement.

What Is Shelly ThreadLink?

ThreadLink is an upcoming alternative firmware for eligible Shelly Gen4 devices that uses their Thread-capable radio as a broader IP connection instead of limiting it mainly to one application path.

In its official ThreadLink announcement, Shelly says the firmware will run IPv6 networking over Thread while supporting TCP plus RPC/UDP communication. The same low-power radio is intended to carry:

Matter connectivity,
Shelly Cloud traffic,
Shelly RPC and API communication,
direct device-to-device control,
configuration and diagnostics,
and deeper Home Assistant integration.

The key architectural change looks like this:

COMMON CURRENT MODEL

                    Matter
                      |
                    Thread

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


THREADLINK DIRECTION

                    Matter
                      |
Shelly API ─────── Thread ───── Cloud path
                      |
                  Local P2P

Instead of requiring Wi-Fi for the vendor-specific side of the device while Thread carries Matter, Shelly wants Thread itself to provide the IP transport for several applications at once.

That distinction is important because Matter and Thread are not the same layer of the network.

Is Shelly ThreadLink Available Now?

No. ThreadLink has been announced, but the production firmware is not yet generally available.

Shelly says it will be delivered as a separate, free, opt-in firmware for eligible Gen4 devices approximately three months after the September 3, 2026 announcement.

Users will choose per device whether it runs the standard Wi-Fi-oriented firmware or ThreadLink.

ThreadLink Status	Current Position
Announced	Yes — September 3, 2026
Generally available	Not yet
Target hardware	Eligible Shelly Gen4 devices
Firmware type	Separate opt-in update
Expected timing	Approximately three months after announcement
Price	Planned as a free update

This means ThreadLink should currently be treated as an announced architecture rather than a feature that every Gen4 owner can enable today.

It also means it is too early to claim that every Gen4 model will receive the firmware. Shelly specifically says eligible Gen4 devices, so the final compatibility list matters.

Wasn't Thread Already an IP Network?

Yes. This is the most important misconception to clear up.

Thread was designed as an IPv6-based mesh network using 6LoWPAN over IEEE 802.15.4 radios. The Thread Group's explanation of Thread's IPv6 foundation dates this design principle back years before Matter existed.

The networking stack can be simplified as:

APPLICATIONS

Matter
Vendor protocols
Other IP services
       |
       v
TRANSPORT

UDP / TCP
       |
       v
NETWORK

IPv6
       |
       v
ADAPTATION

6LoWPAN
       |
       v
RADIO

IEEE 802.15.4

Thread is therefore not a Matter-specific radio protocol in the same sense that many people casually describe it.

It is a low-power IP network capable of carrying application protocols above it.

Matter is currently its most visible consumer smart-home application, but Thread itself is designed to be application-layer agnostic.

ThreadLink does not make Thread an IP network. It uses Thread more like the IP network it already is.

What Is Actually New About ThreadLink?

The novelty is not IPv6 itself. It is the decision to let one consumer IoT device use Thread for several application paths that often still depend on Wi-Fi.

THREAD AS A MATTER PIPE

Matter
  |
Thread


             ↓


THREAD AS A NETWORK

Matter ─────────┐
                |
Shelly RPC ─────┤
                |
Local API ──────┼── IPv6 / Thread
                |
P2P logic ──────┤
                |
Cloud path ─────┘

This changes the role of the radio.

Thread is no longer useful only because another ecosystem can control a relay through Matter. It can also carry Shelly's own application traffic, local logic, configuration, diagnostics, and potentially software updates.

Shelly describes ThreadLink as supporting UDP for responsive local communication and full TCP support for larger or reliability-sensitive transfers such as configuration data and diagnostics.

That is a much broader interpretation of what a Thread-connected consumer device can do.

Why Doesn't Matter Expose Every Shelly Feature?

Because interoperability and vendor differentiation solve different problems.

Matter gives manufacturers and smart-home platforms a standardized device model. A Matter-compatible relay can expose known capabilities in a way Apple Home, Google Home, Amazon Alexa, SmartThings, or Home Assistant can understand without each platform implementing a completely different proprietary protocol.

That standardization is valuable.

But a vendor may still expose capabilities beyond the standardized Matter model, such as:

deeper energy measurements,
diagnostic information,
special relay behavior,
device-specific configuration,
scripting or automation features,
advanced status information,
and vendor management functions.

That often creates two parallel paths today:

DEVICE
  |
  +-- Matter
  |      |
  |      v
  |  Standard features
  |  Apple / Google / HA
  |
  +-- Vendor API
         |
         v
     Advanced features
     Diagnostics
     Configuration

ThreadLink tries to keep those two paths without requiring two different network transports:

          Matter
            \
             \
              Thread
             /
            /
       Shelly RPC

Shelly says a dedicated Home Assistant module will expose the broader Shelly feature set beyond what the Matter data model provides.

ThreadLink therefore matters because Matter can remain one application on Thread without needing to be the only application on Thread.

Can Shelly Devices Control Each Other Without Wi-Fi?

According to Shelly's ThreadLink design, yes.

Shelly says ThreadLink devices can communicate directly over the Thread mesh using its API, allowing scenes, interlocks, and automations to execute peer-to-peer.

The important part is the failure path.

Shelly says these device-to-device relationships can continue even if:

the internet connection fails,
Shelly Cloud is unreachable,
or the home's Wi-Fi network goes down.

A simple relationship could therefore look like:

Wall Switch
     |
   Thread
     |
     v
    Relay

instead of always requiring:

Wall Switch
     |
     v
Wi-Fi / Router
     |
     v
Home Server
     |
     v
Wi-Fi / Router
     |
     v
Relay

This does not make the server path wrong.

It means not every local action has to use it.

Does Local Control Still Need Home Assistant?

For simple device relationships, not always. For broader orchestration, Home Assistant still has a very different job.

A local wall switch turning on one relay is fundamentally different from an automation that combines multiple systems.

Device-level logic can handle:

simple switch-to-relay relationships,
interlocks,
basic scenes,
and immediate fallback behavior.

A home automation server is better suited to logic such as:

IF

solar export > 3000 W

AND

battery SOC > 80%

AND

room is occupied

AND

electricity price is low

THEN

enable HVAC / appliance load

That workflow crosses energy, occupancy, pricing, schedules, and potentially several protocols.

It belongs at a higher orchestration layer. The broader move toward Home Assistant local processing follows the same principle: keep suitable decisions close to the home while reserving cloud dependencies for workloads that actually need them.

DEVICE-LEVEL LOCAL CONTROL

Switch
   |
 Thread P2P
   |
Relay


SERVER-LEVEL LOCAL CONTROL

Solar ───────┐
Energy Meter ┤
Presence ────┼── Home Assistant ── HVAC
Schedule ────┤
Other IoT ───┘

Local-first does not always mean server-first.

A robust smart home can use local device relationships for simple actions and keep the home server focused on cross-system logic, history, policies, dashboards, and state.

How Can ThreadLink Reach the Cloud Without Wi-Fi?

One of ThreadLink's more unusual promises is that the endpoint can remain a Thread device while still accessing Shelly Cloud.

The device itself does not need Wi-Fi credentials for that path.

Shelly describes the architecture as:

Shelly ThreadLink Device
          |
          v
     IPv6 / Thread
          |
          v
 Thread Border Router
          |
          v
        NAT64
          |
          v
   IPv4 Internet Service
          |
          v
      Shelly Cloud

The idea fits broader Thread development. Thread 1.4 formalized additional work around a standard path from Thread networks toward internet services, including IPv6-to-IPv4 connectivity at the network edge.

The important conceptual change is:

Cloud connectivity no longer has to imply Wi-Fi connectivity on the endpoint.

A low-power device can use Thread locally while IP routing farther up the network handles access to external services.

That does not make ThreadLink local-only.

It demonstrates the opposite: local device communication and optional cloud connectivity can share the same IP architecture.

What Does a Thread Border Router Actually Do?

A Thread Border Router connects the Thread mesh to the wider IP network. It is fundamentally a router, not a protocol translator for every smart-home command.

The Thread Group's explanation of the Thread Border Router role makes this distinction explicit.

Traditional smart-home architectures often look like:

Zigbee Device
     |
     v
Zigbee Network
     |
     v
Vendor Hub
     |
protocol translation
     |
     v
IP Network

Thread instead uses IP on the device network itself:

Thread Device
     |
 IPv6 / Thread
     |
     v
Border Router
     |
 IP routing
     |
     v
Home LAN

The Border Router forwards packets between physical network segments.

It does not need to translate every application command from Thread into a proprietary LAN protocol.

This means Home Assistant can sit elsewhere on the local network:

Thread Device
     |
Thread Mesh
     |
Border Router
     |
Ethernet / Wi-Fi LAN
     |
     +-- Home Assistant
     +-- Home Server
     +-- Other IP Services

A Matter controller and a Thread Border Router therefore perform different roles. The Border Router provides network reachability; Matter provides an application and controller relationship above that network. If several platforms independently control the same Matter devices, multiple Matter controllers introduce a separate trust and ownership layer that Thread routing alone does not solve.

Once traffic leaves the Thread mesh, ordinary IP rules still matter. Home Assistant network reachability still depends on usable addressing, routing, policy, and a working return path between the controller and the endpoint.

Does ThreadLink Mean Thread Will Replace Wi-Fi?

No. Thread and Wi-Fi are optimized for different kinds of traffic.

Home Assistant's current Thread documentation describes Thread as both low-power and low-bandwidth, making it especially appropriate for devices that exchange relatively small amounts of data.

Workload	Natural Network
Motion sensor	Thread
Wall switch	Thread
Relay	Thread
Door lock	Thread
Low-rate environmental sensor	Thread
Security camera	Wi-Fi / Ethernet
Video display	Wi-Fi / Ethernet
Laptop	Wi-Fi / Ethernet
NAS	Ethernet

A low-power relay does not need the bandwidth of Wi-Fi.

A 4K security camera should not be pushed onto Thread simply because Thread is IP-based.

Thread is not becoming the new Wi-Fi. It may become the low-power IP edge of the same home network.

Is Thread Becoming the Low-Power Edge of the Home LAN?

This is where ThreadLink becomes more interesting than the individual Shelly firmware announcement.

A future local network could look less like several isolated smart-home ecosystems and more like one IP architecture spread across several physical transports:

                     HOME SERVER
                          |
                          |
                    HOME IP NETWORK
                          |
        +-----------------+----------------+
        |                 |                |
     ETHERNET           WI-FI            THREAD
        |                 |                |
       NAS             Cameras          Relays
     Servers           Phones           Sensors
   Workstations          TVs            Switches
                                       Locks

The endpoint does not need every device to use the same radio.

It matters more that the higher layers can communicate through standard routing where appropriate.

This is fundamentally different from trying to make Thread, Wi-Fi, and Ethernet compete for one winner.

The future smart home may not have one wireless network. It may have one IP architecture across several physical networks.

What Does ThreadLink Change for Home Assistant?

ThreadLink potentially gives Home Assistant two useful paths to the same physical Shelly device.

The first is standard Matter:

Shelly Device
      |
Matter over Thread
      |
Thread Border Router
      |
Home Assistant Matter Controller
      |
Standard Matter features

The second is the vendor-specific path Shelly is planning:

Shelly Device
      |
Shelly RPC over Thread
      |
Thread Border Router
      |
Home Assistant
      |
Shelly-specific features

The official Home Assistant Matter architecture already makes the network/application distinction clear: Matter is an application-level control protocol that can communicate over Wi-Fi, Ethernet, or Thread depending on the device.

ThreadLink builds on that layered design.

Matter can provide ecosystem interoperability while the Shelly integration can retain deeper device-specific functionality.

This is a stronger architecture than forcing users to choose between interoperability and advanced vendor features.

Is One Thread Network Really Possible Today?

Not always. Today's Thread deployments can still be more fragmented than the ideal architecture suggests.

Home Assistant currently describes its Thread integration as a work in progress and explicitly tracks the different Thread networks present in a home.

A household may discover something like:

Apple Thread Network
       |
different credentials


Google Thread Network
       |
different credentials


Home Assistant Thread Network
       |
different credentials

Devices on separate Thread networks do not automatically become one large mesh simply because all of them use Thread.

Home Assistant can help users inspect existing networks and, in supported cases, join a Home Assistant Border Router to a preferred existing network. But the consumer ecosystem is not yet equivalent to one perfectly unified Thread mesh in every home.

This is an important reality check for ThreadLink.

A technically elegant IP architecture still depends on border-router compatibility, shared credentials, network topology, and actual implementation support.

How Does Thread 1.4 Change the Picture?

Thread 1.4 pushes the ecosystem closer to the unified-network idea.

The Thread Group describes one of its major improvements as one mesh network made easier.

The goal is for updated devices and Border Routers from different ecosystems to recognize and join an existing Thread network instead of unnecessarily creating another mesh.

Thread 1.4 also adds or improves:

a standardized path toward cloud connectivity,
Thread over infrastructure,
network diagnostics and troubleshooting visibility,
cross-ecosystem network convergence,
and commissioning improvements.

This gives ThreadLink a broader context.

EARLIER THREAD

Low-power IPv6 mesh
      |
Matter becomes dominant
consumer application


THREAD 1.4

Better network convergence
Better border-router infrastructure
Cloud path
Diagnostics
      |
      v


THREADLINK IDEA

Matter
Vendor API
Cloud
P2P
      |
same low-power IP transport

ThreadLink is therefore not proof that every vendor will adopt the same approach.

But it is a concrete example of the kind of application diversity Thread's network architecture has always made possible.

Should Every Smart-Home Automation Go Through the Home Server?

No. A resilient system can distribute logic according to how complex and important the action is.

Layer	Good Responsibility
Device	Immediate local behavior and fallback
Thread mesh	Low-power local IP transport and peer communication
Border Router	Routing between Thread and the wider LAN
Home Assistant	Cross-device and cross-protocol orchestration
Home server	Persistent services, automation, history, policies
NAS	Backups and durable data
Cloud	Optional remote services and vendor functions

A simple interlock does not necessarily need a server round trip.

A whole-home energy automation probably does.

This separation can make the network more resilient because failure of one layer does not automatically remove every local function. It also explains why the real Home Assistant performance path includes radios, networks, brokers, target devices, and storage rather than only the CPU running Home Assistant.

Does ThreadLink Make a Home Server Less Important?

It may make the home server less important as a protocol gateway, but more clearly defined as an orchestration layer.

Traditional smart homes accumulated bridges because many device networks could not participate directly in the home IP network.

OLD MODEL

Zigbee devices ── Vendor Hub ──┐
                               |
Other devices ─── Gateway ─────┼── Home Server
                               |
Wi-Fi devices ─────────────────┘

A more IP-oriented architecture can look different:

DEVICE LAYER

Thread devices
Wi-Fi devices
Ethernet devices
       |
       v

IP NETWORK LAYER
       |
       v

CONTROL LAYER

Home Assistant
       |
       +-- Automations
       +-- State
       +-- History
       +-- Policies
       +-- Dashboards
       +-- Cross-protocol logic
       |
       v

DATA LAYER

Backups
NAS
Persistent storage

The server no longer needs every packet to pass through it to justify its existence.

Its value increasingly comes from maintaining the bigger picture:

which devices exist,
what state they are in,
how unrelated systems interact,
what happened yesterday,
which automations should run,
what should happen when a service fails,
and how configuration and history are protected.

Those responsibilities have different storage and recovery requirements. Separating Home Assistant persistent data from temporary runtime state makes the data layer in this architecture much easier to protect.

Thread reduces the need for protocol translation, not the need for home automation software.

It also does not mean Home Assistant suddenly needs powerful hardware. The current Home Assistant server hardware requirements remain modest for ordinary automation; cameras, long history, local voice, databases, and additional services are what usually create a larger server workload.

If several of those services are expected to live together, smart home server sizing should be based on the whole service stack rather than the number of Thread devices.

Should Shelly Gen4 Owners Switch From Wi-Fi to ThreadLink?

It is too early to make that recommendation.

The firmware has not yet reached general availability, the final eligible-device list matters, and real interoperability with existing Thread networks and Border Routers still needs to be tested outside demonstrations.

When ThreadLink becomes available, Gen4 owners should evaluate:

whether their exact Shelly device is eligible,
whether a suitable Thread Border Router already exists,
whether the home's Thread networks are unified or fragmented,
whether required Shelly features work through the new Home Assistant module,
whether cloud access is needed,
whether direct device-to-device logic is useful,
and whether the existing Wi-Fi installation already works reliably.

Situation	ThreadLink Outlook
Wi-Fi Shelly devices already work perfectly	No urgent reason to switch
Dense relay installation	Potentially interesting
Need Matter plus deeper Shelly features	Strong use case to watch
Want local P2P during Wi-Fi outages	Strong architectural benefit
No Thread Border Router	Additional infrastructure required for LAN/cloud access
Several fragmented Thread networks	Topology should be understood first
Unsupported Gen4 model	ThreadLink may not be available

The correct 2026 position is therefore to watch the implementation rather than migrate a working installation based only on the announcement.

Is Thread Becoming the Local IP Network for Smart Homes?

Thread is unlikely to become the only local network in a smart home. It has a stronger chance of becoming the low-power IP edge of that network.

Ethernet remains the natural transport for servers, NAS devices, and fixed high-bandwidth systems.

Wi-Fi remains the natural wireless network for phones, laptops, cameras, displays, and devices that need substantially more bandwidth.

Thread fits the low-power edge:

sensors,
relays,
switches,
locks,
controls,
and other devices that exchange relatively small amounts of data.

Shelly ThreadLink is interesting because it stops treating that edge as a one-application silo.

Matter can provide standardized ecosystem control.

Shelly RPC can provide richer vendor functionality.

Peer communication can keep simple actions local.

A Border Router can connect the mesh to the wider LAN.

Home Assistant can orchestrate across protocols.

And cloud connectivity can remain optional rather than requiring the endpoint itself to join Wi-Fi.

For users who want that orchestration layer on a dedicated local system, ZimaBoard 2 smart home is one example of keeping the controller on an expandable always-on server while Thread Border Routers and endpoint radios remain separate parts of the network.

The future smart home may therefore be less about choosing between Thread, Wi-Fi, and Ethernet and more about giving each one a role inside the same IP architecture.

That is the bigger idea behind ThreadLink.

Thread has always been an IP network.

Shelly is simply starting to use it like one.

FAQ: Shelly ThreadLink and Thread Smart-Home Networking

What is Shelly ThreadLink?

ThreadLink is an announced opt-in firmware for eligible Shelly Gen4 devices. Shelly says it will use the devices' Thread radio to carry Matter, Shelly RPC/API traffic, cloud connectivity, and direct device-to-device communication over the same low-power IP mesh.

Is Shelly ThreadLink available now?

No. Shelly announced ThreadLink on September 3, 2026 and currently plans to release the free opt-in firmware approximately three months later for eligible Gen4 devices.

Will every Shelly Gen4 device support ThreadLink?

Shelly has only promised the update for eligible Gen4 devices. A complete final compatibility list should be checked when the firmware becomes available.

Does ThreadLink turn Thread into an IP network?

No. Thread has always been based on IPv6, 6LoWPAN, and IEEE 802.15.4. ThreadLink changes how Shelly intends to use that existing IP network by running more than Matter over it.

Is Matter the same thing as Thread?

No. Matter is an application-level smart-home control standard. Thread is a low-power IPv6 mesh network that can carry Matter or other compatible application protocols.

Can Thread work without Matter?

Yes. Thread is application-layer agnostic. Consumer Thread products are strongly associated with Matter today, but Thread itself can carry other IP-based application protocols.

Can ThreadLink devices work without Wi-Fi?

Shelly says ThreadLink devices can use Thread for Matter, local API communication, peer-to-peer automation, and cloud connectivity through a Thread Border Router, without the endpoint itself joining Wi-Fi.

Can ThreadLink work without the internet?

Shelly says direct device-to-device scenes, interlocks, and automations can operate locally inside the Thread mesh even if the internet connection or Wi-Fi network goes down.

Does ThreadLink require a Thread Border Router?

A Border Router is required when ThreadLink devices need to communicate with the wider home LAN, apps, Home Assistant, or cloud services. Shelly says device-to-device scenes can operate within the Thread mesh itself.

Does ThreadLink replace Home Assistant?

No. Direct peer-to-peer logic can remove the need for a server in simple device relationships, while Home Assistant remains useful for cross-protocol automation, history, dashboards, policies, schedules, and whole-home orchestration.

Will Thread replace Wi-Fi?

Probably not. Thread is designed for low-power, relatively low-bandwidth IoT devices. Wi-Fi remains better suited to higher-bandwidth products such as cameras, displays, phones, and computers.

What is the difference between a Thread Border Router and a smart-home hub?

A Thread Border Router primarily routes IPv6 traffic between the Thread mesh and the wider IP network. A traditional hub or bridge often translates between a non-IP device network and an IP-based LAN or application.

Can a home have more than one Thread network?

Yes. Current homes may contain separate Apple, Google, Home Assistant, or other Thread networks with different credentials. Thread 1.4 is intended to make convergence onto one existing mesh easier, but real-world implementations still depend on device and ecosystem support.

What does Thread 1.4 change?

Thread 1.4 improves cross-ecosystem network joining, Border Router infrastructure, cloud connectivity, diagnostics, commissioning, reliability, and the ability to maintain a larger unified Thread mesh.

Why is ThreadLink important for home servers?

It suggests that the home server can focus less on translating proprietary device networks and more on orchestration, state, history, policies, cross-system automation, and durable data while Thread, Wi-Fi, and Ethernet handle the underlying IP transport.