Shelly ThreadLink is a new opt-in firmware for eligible Gen4 smart-home devices that turns the built-in Thread radio into a full IP network connection. Shelly says the same Thread mesh can carry Matter, Shelly Cloud connectivity through a Thread Border Router, and direct device-to-device control. Local scenes, interlocks and automations can run peer-to-peer and continue even if the internet or the Wi-Fi network goes down, while cloud and app access still require a working path through a Thread Border Router.

Your Wi-Fi Goes Down — But Some Local Automations Can Keep Going

Your Wi-Fi goes down. The internet disappears. But a light switch can still tell another Shelly device what to do. That is the practical hook behind ThreadLink, a new firmware announced by Shelly at IFA 2026 for eligible Gen4 devices. Shelly says ThreadLink turns the built-in Thread radio into a full IP network connection. The same radio can carry Matter, connect the device to Shelly Cloud through a Thread Border Router, and let Shelly devices communicate directly with each other through Shelly’s API. The most useful consequence is local control. Scenes, interlocks and automations between ThreadLink devices can execute peer-to-peer inside the Thread mesh and, according to Shelly, continue running even if the internet — or the entire Wi-Fi network — goes down. That does not mean the whole smart home works without networking. It means the local Thread path can keep doing its job when that automation does not need the cloud or Wi-Fi. That distinction is what keeps the headline useful without turning it into a promise Shelly did not make.

First: What Exactly Keeps Working?

The answer needs to be precise. Shelly is not claiming that every smart-home function survives every outage. The company specifically says device-to-device scenes, interlocks and automations can run locally across the Thread mesh. That creates a local route: Shelly device → Thread mesh → another Shelly device. If that automation only depends on those devices, it does not need a cloud round trip. Remote access is different. Shelly Cloud still requires a path from the Thread network to the wider home network and the internet. App control outside the mesh also depends on that broader network path. So there are two separate ideas: local control can continue inside the mesh; cloud and remote access still need external connectivity. Keeping those two paths separate is the easiest way to understand ThreadLink.

ThreadLink Is Not a New Box You Have to Buy

ThreadLink is firmware, not a new proprietary hub. Shelly Gen4 hardware uses a multiprotocol radio platform that supports IEEE 802.15.4 alongside Wi-Fi and Bluetooth-class connectivity. Thread uses that IEEE 802.15.4 radio. Shelly’s change is to make the existing radio do more. Instead of treating Thread only as a transport for one smart-home application layer, ThreadLink gives the device a broader IP networking role. For eligible Gen4 hardware, the user will be able to choose a separate ThreadLink firmware path when Shelly releases it. That makes this an architectural update to devices people may already own rather than a completely separate product family. It also explains why the announcement is more interesting than a normal firmware changelog: Shelly is changing what the radio is allowed to be used for.

One Thread Radio, Three Jobs

Shelly describes ThreadLink around three simultaneous uses. First: Matter. The device can appear in compatible ecosystems such as Apple Home, Google Home, Amazon Alexa, SmartThings and Home Assistant through Matter. Second: Shelly Cloud. The device can reach Shelly’s cloud through a Thread Border Router even though the Shelly device itself is not joined to Wi-Fi. Third: direct Shelly-to-Shelly communication. Devices can talk across the Thread mesh using Shelly’s API for local logic. That produces a useful stack: Matter | Cloud | Direct Control, all sharing one Thread network connection. The interesting part is not any one of those functions alone. It is that Shelly is trying to make the Thread radio serve all three at the same time, instead of dedicating Thread only to Matter while using Wi-Fi for everything else.

Matter and Thread Are Not the Same Thing

Matter and Thread are often mentioned together, so it is easy to treat them as the same technology. They are not. Thread is an IPv6-based low-power mesh network. Matter is a smart-home application standard that can run over IP networks, including Thread. A simple way to think about it is: Thread = the network path. Matter = one application layer that can use that path. That distinction is central to ThreadLink. Shelly is not announcing Matter over Thread as a new idea. The company is asking what else the device can do over the same Thread network once it is treated as a normal IP connection. That is why Matter can coexist with Shelly’s own local API traffic and cloud connectivity instead of being the only thing traveling over the radio.

Shelly Is Treating Thread Like a Full IP Network

This is the technical center of the announcement. Shelly says ThreadLink runs IPv6 over Thread with 6LoWPAN, UDP and full TCP support. That means the Thread radio is not being reserved for one narrow smart-home protocol. The device can participate in a broader IP stack over the mesh. In plain language: the Shelly device is not treating Thread as a special lane used only by Matter. It is treating Thread as the device’s network connection. That is why Shelly can put Matter traffic, direct Shelly communication and cloud connectivity on the same radio. Thread was designed around IP from the beginning. ThreadLink is Shelly’s attempt to use more of that foundation and make the radio useful for the vendor’s own device logic as well as ecosystem interoperability.

A Shelly Device Can Reach the Cloud Without Joining Wi-Fi

One of the more unusual effects is cloud connectivity without Wi-Fi credentials on the Shelly device. The path becomes: Shelly ThreadLink device → Thread mesh → Thread Border Router → home network → internet → Shelly Cloud. Shelly says the border of the network uses standards-based NAT64 translation so an IPv6-only Thread device can reach IPv4 services on the internet. The device therefore does not need to associate directly with the home Wi-Fi access point. That does not remove the home network or internet from the equation. It changes which radio the end device uses to reach them. The cloud is still remote. The Wi-Fi radio simply stops being mandatory on the Shelly end device when ThreadLink is the chosen firmware path.

If the Device Is Not on Wi-Fi, Why Is a Border Router Still Needed?

Because Thread is its own network link. A Thread Border Router connects the Thread mesh to the rest of the IP network. Thread Group describes the role as bidirectional IPv6 connectivity between Thread and non-Thread networks such as Wi-Fi and Ethernet. So no Wi-Fi connection on the Shelly device does not mean no network infrastructure. For local Thread-to-Thread automation, the devices can communicate inside the mesh. For app control, LAN access or cloud connectivity beyond that mesh, the Thread network needs a path outward. That path is provided by a Thread Border Router. The Border Router is not translating a proprietary smart-home language into IP. It is routing between IP-based network links.

You May Already Have a Thread Border Router

A Border Router does not have to be a Shelly-branded box. Shelly says ThreadLink can work with suitable Thread Border Routers from ecosystems including Apple, Google, Amazon and Home Assistant. Thread Border Router functionality is often integrated into another device rather than sold as a separate proprietary bridge. The exact product still matters. Not every smart speaker, router or hub from those brands is automatically a Thread Border Router. A user still needs compatible hardware and a functioning Thread network. But the architecture means ThreadLink is designed to sit inside an existing standards-based Thread environment instead of requiring a mandatory Shelly-only gateway.

No Proprietary Shelly Hub Is Required

Shelly explicitly says no proprietary gateway, hub or bridge is required for ThreadLink. That is possible because the connection path stays within standard IP networking concepts. Inside the mesh, Thread carries IPv6 traffic. At the edge, a Thread Border Router connects that mesh to the home LAN. From there, ordinary IP routing can carry traffic toward local services or the internet. This is different from a proprietary-radio design where a vendor-specific hub has to translate a non-IP device protocol into something the rest of the network can understand. ThreadLink’s architecture keeps the device on an IP-based path from the start. That does not mean there is no infrastructure; it means the required infrastructure can be standards-based rather than vendor-exclusive.

The Most Interesting Part Happens Inside the Home

Cloud access is useful, but the local route is the part that changes the outage story. If one Shelly device needs to trigger another Shelly device, ThreadLink can let that instruction move directly across the mesh. The simplified route is: device → Thread mesh → device. There is no requirement for that local action to travel to a remote cloud and back. That matters for scenes and interlocks where two devices need to coordinate with each other. Shelly says those peer-to-peer automations can keep running even when the internet fails or the Wi-Fi network itself goes down. The key phrase is peer-to-peer. The automation survives because its required communication path still exists inside Thread. That is a much stronger consumer story than simply saying the firmware adds another protocol.

Losing the Internet Is Different From Losing the Automation

Smart-home outages can look similar from the user’s point of view even when different parts of the network have failed. If the internet is down but the local Thread mesh is healthy, a ThreadLink device-to-device automation can still have a valid local path. If the Wi-Fi network itself is unavailable, Thread devices can still communicate inside their separate Thread mesh. If an action requires Shelly Cloud, remote access or another service outside the mesh, that external path still has to be available. So the correct takeaway is not that ThreadLink makes the home independent of networking. It is that ThreadLink can separate local automation from Wi-Fi and cloud availability when the automation only needs devices inside the Thread mesh. That separation is the practical reliability benefit Shelly is highlighting.

Thread Is a Mesh, So the Network Is Not Built Around One Wi-Fi Access Point

Thread is a low-power wireless mesh protocol built on IPv6. Eligible Thread devices can participate in the mesh and route traffic according to their role in the network. That produces a topology different from conventional Wi-Fi clients that normally communicate through an access point. The practical benefit for ThreadLink is that local device communication can live on the Thread mesh itself. The Border Router becomes the connection between that mesh and other IP links such as Wi-Fi or Ethernet. It is a network of networks rather than every end device needing to join the same Wi-Fi radio environment. This is also why a Wi-Fi outage does not automatically erase the Thread mesh: they are separate wireless network links even when both ultimately belong to the same smart-home system.

Why 6LoWPAN Is Part of the Story

Thread runs IPv6 over low-power IEEE 802.15.4 radios, where packet sizes are much smaller than on ordinary Ethernet. 6LoWPAN is part of what makes that practical. It adapts IPv6 networking for constrained low-power wireless links, including header compression and other mechanisms that make IP traffic fit the environment more efficiently. The important point for this article is not the packet format. It is that Thread does not stop being an IP network because the radio is small and low-power. Shelly can therefore build ThreadLink around familiar IP transports and routing concepts while still using a mesh radio designed for smart-home devices. That is the bridge between a tiny relay behind a wall switch and a full IP participant on the home network.

Why Full TCP Support Matters

Shelly specifically calls out full TCP support as part of ThreadLink. UDP is useful for fast, compact communication. TCP adds a reliable transport option for larger data transfers where ordered delivery matters. Shelly gives examples including configuration data, diagnostics and updates. Thread Group documentation also describes TCP as part of modern Thread networking and notes larger-data use cases such as firmware transfer. This gives ThreadLink more room than a design focused only on small control messages. The same Thread network can carry quick device commands and larger management traffic using the transport that fits the job. That is part of Shelly’s argument that Thread should be treated as a general network connection rather than a single-purpose Matter transport.

Home Assistant Gets More Than the Matter View

Shelly is also building a dedicated Home Assistant integration for ThreadLink. The company says the module will expose the broader Shelly feature set instead of limiting Home Assistant to only the capabilities represented by the Matter data model. That distinction will matter most to advanced smart-home users. Matter is useful as a common interoperability layer. A vendor can still have device-specific features that extend beyond the standard model. Shelly’s plan is to keep Matter available while also giving Home Assistant a deeper path into ThreadLink devices. That makes ThreadLink interesting to both mainstream ecosystem users and people building more customized local automations. It also lets Shelly keep its own richer device controls without giving up Matter compatibility.

What Happens to Wi-Fi on the Device?

ThreadLink is being delivered as a separate opt-in firmware choice. Shelly says customers will choose per eligible Gen4 device whether it runs the standard Wi-Fi firmware or ThreadLink. That means the announcement should not be read as every Gen4 device now running full Wi-Fi and ThreadLink simultaneously. The user selects the firmware path for that device. This is an important boundary because the hardware may contain multiple radio capabilities, but the supported product behavior is defined by the firmware Shelly actually ships. The ThreadLink release is therefore a deliberate mode choice rather than an invisible automatic conversion. A user who prefers the existing Wi-Fi behavior can keep the standard firmware on that device.

The Update Is Free — But It Is Not Available Yet

ThreadLink was announced on September 3, 2026. Shelly says the firmware is planned for release in approximately three months. It will be free of charge for eligible Gen4 devices and available through the Shelly app and web interface. The company also describes it as opt-in. So the timeline is: announced at IFA → firmware still in the release pipeline → free opt-in update planned in about three months. That distinction matters because the feature is not something every Shelly Gen4 owner can install today. IFA visitors can see live demonstrations, but consumer availability follows later. The exact list of eligible Gen4 models should be taken from Shelly when the release arrives rather than guessed in advance.

Security Still Happens in Layers

ThreadLink does not replace the security models of the protocols running over it. Shelly says Thread mesh traffic is protected at the link layer with AES-CCM according to the Thread specification. Matter sessions add their own certificate-based end-to-end security through CASE. Cloud connections use TLS, as Shelly’s Wi-Fi products do. Those are separate layers serving different parts of the communication path. The announcement does not provide a basis to say ThreadLink is universally more secure than Wi-Fi. The useful point is narrower: moving the device onto Thread does not mean communication is being sent as unprotected plain traffic. Each layer continues to use the security mechanisms associated with that part of the stack.

What Happens When Wi-Fi Comes Back?

ThreadLink does not need to switch back to Wi-Fi simply because the Wi-Fi network is healthy again. If the device is running ThreadLink firmware, its intended network path remains Thread. A local automation can continue using the mesh. Cloud traffic can continue leaving through the Thread Border Router. Matter can continue operating over the same Thread link. The return of Wi-Fi mainly restores the wider home-network infrastructure that may sit on the other side of the Border Router or support other devices in the home. That is another reason the architecture should not be described as a Wi-Fi failover mode. ThreadLink is a separate networking choice, not a temporary emergency radio used only when Wi-Fi fails.

What ThreadLink Does — and What It Does Not Do

ThreadLink runs IP networking over the Thread radio of eligible Shelly Gen4 devices. It can expose devices through Matter. It can let Shelly devices communicate directly inside the Thread mesh. It can reach Shelly Cloud through a suitable Thread Border Router when external connectivity exists. Shelly says local device-to-device scenes, interlocks and automations can continue when the internet or Wi-Fi network is unavailable. It does not create internet access when the internet connection itself is down. It does not guarantee every device in a smart home will work during a Wi-Fi failure. It does not remove the need for a Thread Border Router when traffic needs to leave the mesh. It does not mean Matter and Thread are the same protocol. And the firmware is not generally available to customers yet.

Why This Matters Beyond Shelly

ThreadLink is a Shelly product decision, but the architectural idea is broader. Thread was built as an IP-based mesh, which means it can carry more than one application layer. Consumers usually encounter it through Matter because Matter has made Thread visible in mainstream smart-home products. Shelly is showing another way to use the same foundation. A vendor can keep Matter for interoperability while also running its own local device API and cloud path over the Thread network. That does not mean every Thread vendor will copy Shelly. It does show that the Thread radio can be treated as more than a hidden transport beneath Matter. For smart-home systems, that opens a design space where local control, ecosystem compatibility and cloud access share one low-power IP mesh.

The Bigger Change: Matter Is No Longer the Only Thing Using the Thread Radio

For many consumers, Thread has appeared mainly as the invisible network underneath Matter devices. ThreadLink pushes the radio into a broader role. Matter can use it. Shelly Cloud connectivity can use it through a Border Router. Shelly devices can use it to talk directly to one another. And when a local automation does not need Wi-Fi or the internet, the Thread mesh can keep carrying that automation on its own. That changes the question from: Does this smart-home device support Thread? to: What else can the device do over Thread? For Shelly, the answer is a full IP path that can serve standards-based smart-home control, cloud access and local peer-to-peer logic from the same radio. The headline feature is surviving a Wi-Fi outage. The deeper story is that ThreadLink treats Thread as the network itself.

Matter Gives Smart-Home Devices a Common Language

The smart home is built from many kinds of devices.

Lights. Locks. Sensors. Thermostats. Plugs. Cameras. Appliances. Speakers. Hubs.

Matter starts by giving compatible products a common application language.

The Connectivity Standards Alliance describes Matter as an IP-based connectivity standard designed to create a common foundation for smart-home devices and ecosystems. Instead of every platform needing a completely separate way to understand every product, Matter defines standardized device types, commands and data models.

That changes the architecture of the home.

A compatible light can expose brightness or color in a standardized way. A compatible lock can expose its lock state through the Matter model. A sensor can report supported information through the same broader standard.

Then Apple Home, Google Home, Alexa and other Matter-capable ecosystems can build their own experiences on top of that shared foundation.

The device remains its own product. The ecosystem remains its own platform. Matter sits between them and gives both sides a common language.

That is why Matter matters.

It turns interoperability from a collection of individual integrations into part of the standard itself.

Matter Runs on the Networks Homes Already Use

Matter does not need a completely new home network.

It is built around IP.

Compatible devices can use Wi-Fi, Ethernet or Thread underneath the Matter application layer. Bluetooth Low Energy is commonly used during commissioning so a phone or controller can help bring the device into the home.

This creates a useful separation.

Matter defines how compatible smart-home devices communicate at the application level. The transport underneath can match the kind of device being built.

A smart plug can use Wi-Fi. A wired bridge can use Ethernet. A low-power sensor can use Thread. Each device can use the networking technology that fits its role while still participating in the same Matter ecosystem.

Google and Apple both support this model in their smart-home platforms. Homes can mix Matter-over-Wi-Fi products with Matter-over-Thread products, while compatible hubs and Thread border routers connect those pieces into the wider home network.

That is an important part of Matter’s design.

The standard does not force every smart-home device into one radio.

It gives different networking technologies a shared application layer above them.

Setup Is Becoming More Consistent

The first place many users feel a smart-home standard is setup.

Matter standardizes important parts of that process.

Compatible devices can include QR codes or numeric setup codes. A supported app scans or enters the code, the device is commissioned into the home, and the controller learns what kind of Matter device it is and which standardized capabilities it exposes.

Apple and Google both provide Matter-aware onboarding inside their home platforms. The same basic idea can therefore appear across several ecosystems even when the visual design of each app is different.

Matter 1.6 expands this further with NFC commissioning.

The Connectivity Standards Alliance says supported implementations can use bidirectional NFC for the commissioning exchange. That creates new possibilities for devices such as in-wall switches, ceiling fixtures and other hardware that may be easier to provision before final installation.

The important change is repetition.

Each new Matter device does not need a completely new setup concept.

The user can begin to recognize the pattern: find the setup code, add the accessory, choose the home or room, then continue into the ecosystem they already use.

A common standard turns setup into part of the platform rather than a separate learning curve for every product.

Multi-Admin Lets One Device Participate in More Than One Ecosystem

A home rarely belongs to one person.

One person may prefer Apple Home. Another may use Google Home. A shared speaker may run Alexa. A tablet mounted on the wall may act as another controller.

Matter was designed with Multi-Admin so the same compatible device can be shared across more than one authorized ecosystem.

That changes the ownership model of the smart home.

The light, lock or sensor can remain one physical device while several platforms become authorized to control it through Matter.

This is useful because households do not have to organize every interaction around one interface.

A person can use Siri. Another can open Google Home. Another can use Alexa. The same Matter accessory can become part of each supported environment.

Matter 1.4 expanded this area through Enhanced Multi-Admin mechanisms, and Matter 1.6 adds Joint Fabric for scenarios where multiple authorized controllers can co-administer one shared Matter fabric.

The Connectivity Standards Alliance highlights uses such as multi-platform households, managed properties and construction handovers.

This is one of Matter’s deepest changes.

Interoperability becomes something the device can carry with it.

Local Control Becomes Part of the Standard Smart-Home Path

Matter is also built around local IP connectivity.

That gives compatible devices a standardized way to respond inside the home network for supported functions.

Google explicitly lists local control as one of the benefits of using Matter devices with a compatible Google Home hub. The idea is simple: common smart-home commands can move through the local Matter network between controller and device.

That can make the home feel more immediate.

A light command can stay close to the home. A sensor update can move through the local network. A controller can understand the standardized state of a compatible accessory without requiring a custom integration for every basic function.

This local path also fits naturally beside manufacturer services.

A product can expose standard Matter controls locally while its own app continues to provide branded experiences, firmware updates, advanced automation, remote services or other product-specific features.

That creates two useful layers.

Matter handles the shared smart-home language.

The manufacturer can continue building additional value around the product.

The result is a smart-home model where standardized control and product-specific innovation can exist together.

Matter 1.5 Expanded the Kind of Devices That Can Join

Matter is not standing still.

The standard has been expanding from the early categories into more complex parts of the home.

Matter 1.5, released in November 2025, added support for major new categories including cameras, closures and soil sensors, while also expanding energy-management capabilities.

That matters because the value of a smart-home standard grows as more of the home can participate in it.

Lights and plugs are useful. Locks and thermostats add another layer. Cameras, closures and richer energy features push the standard into parts of the home where devices carry more data and more complex behavior.

The camera category is especially significant because cameras are central to many connected homes. Bringing a standardized Matter model into that area gives ecosystems and manufacturers another common foundation to build on.

Closures extend the same idea to products such as shades, gates and related devices. Soil sensors bring Matter into connected gardening and outdoor automation.

Each new category increases the number of devices that can participate in the same interoperable architecture.

Matter is becoming less like a standard for a few smart accessories and more like a common layer for the home itself.

Matter 1.6 Pushes the Standard Toward Easier Coordination

Matter 1.6 arrived on June 17, 2026.

Its focus is especially interesting because it develops the experience around the devices, not only the list of device categories.

The Connectivity Standards Alliance highlights more intuitive commissioning, multi-ecosystem coordination, context-driven control and core capability reporting.

NFC commissioning gives compatible products another setup path.

Joint Fabric creates a new model for co-administered Matter environments. Context-driven control gives the ecosystem more structure for understanding how devices and environments relate. Capability reporting gives controllers clearer information about what a Matter device can expose through the standard.

These changes show the direction Matter is taking.

The first phase was about establishing a common language.

The next phase is about making that common language easier to deploy across larger homes, several ecosystems and more sophisticated device types.

That is how infrastructure matures.

The standard starts with connectivity. Then it improves setup. Then sharing. Then administration. Then richer information about what the devices can do.

Matter 1.6 is another step in that progression.

Apple, Google and Alexa Give Matter a Large Consumer Footprint

A standard becomes more useful when the platforms people already use support it.

Matter has that advantage.

Apple Home supports Matter accessories through the Home ecosystem. Google Home provides Matter setup and control through compatible hubs and controllers. Amazon provides Matter support through Alexa and offers developer tooling for manufacturers building Matter products.

That creates a large consumer footprint around the same standard.

A manufacturer can build a Matter-compatible product and target several major smart-home ecosystems through a common application model.

A user can choose a controller based on the experience they prefer while keeping compatible Matter devices inside the broader home architecture.

This is important because the smart home is becoming less about one hub sitting in the center of everything.

Phones, speakers, displays, routers and dedicated hubs can all become parts of the control layer.

Matter gives those platforms a common way to understand supported devices.

The ecosystem companies can still compete on interface, automation, assistants and services.

The device layer gains a shared foundation underneath them.

Matter Is Turning Compatibility Into Smart-Home Infrastructure

The most important thing Matter changes is the starting point.

A smart-home device no longer has to begin with the assumption that every ecosystem needs a completely separate language.

Matter gives compatible products a standardized model for setup, control, sharing and device capabilities. Wi-Fi, Ethernet and Thread provide the network beneath it. Apple Home, Google Home, Alexa and other ecosystems provide the user experience above it.

Then the standard keeps expanding.

Matter 1.5 added more device categories. Matter 1.6 expanded commissioning and multi-ecosystem coordination. Multi-Admin lets one accessory participate in several supported ecosystems. Joint Fabric opens another path for shared administration. Local control gives compatible devices a common path inside the home network.

Put those pieces together and the smart home starts to look different.

The light can be a Matter device first and still have a manufacturer identity. The lock can participate in several ecosystems. The sensor can use Thread. The plug can use Wi-Fi. The hub can connect those pieces into the same home.

That is what a real standard should do.

It should make the infrastructure quieter so the devices can become easier to use together.

Matter is moving the smart home in that direction.

That is the upgrade.