These Smart-Home Automations Can Keep Running When Wi-Fi Goes Down — Here’s What Shelly ThreadLink Changes

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.

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 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.

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 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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.