Every Shelly relay in my walls has a radio it is not using. The Gen4 chip speaks Wi-Fi, Bluetooth and IEEE 802.15.4, the low-power radio underneath both Zigbee and Thread. Out of the box, mine run on Wi-Fi. Shelly has let you flip Gen4 devices to Zigbee for a while, but Thread, the thing my Home Assistant box has been ready for since I set up the ZBT-2 as a border router, was never an option.
On September 3, just before IFA, Shelly announced it is changing that. The firmware is called ThreadLink, and it is more ambitious than I expected. I have read the press release several times now. What I keep coming back to is not a Shelly feature. It is one setting on my own border router.
What ThreadLink actually is
Most Thread devices use Thread for exactly one thing: Matter. If a vendor wants anything beyond what Matter covers (their app, their cloud, energy history, their own scripting), that traffic usually goes over a second radio, which in practice means Wi-Fi.
ThreadLink takes a different approach. Thread is already an IPv6 network, so Shelly runs a full IP stack over it: 6LoWPAN, UDP, and TCP for larger transfers like configuration and updates. Three things then ride on the same mesh at once:
- Matter, for Home Assistant, Apple Home, Google Home, Alexa and SmartThings.
- The Shelly RPC API, device to device. Scenes and interlocks run peer to peer inside the mesh, and Shelly says they keep working if the internet or the whole Wi-Fi network goes down.
- Shelly Cloud, reached through the border router using NAT64, which translates the mesh’s IPv6 traffic to the IPv4 internet. No Wi-Fi credentials are stored on the device at all.
The fine print matters. It is a separate, opt-in firmware, and you choose per device whether it runs the normal Wi-Fi firmware or ThreadLink. It is not both at once, the same either/or deal as the Gen4 Zigbee mode. It will be free, delivered through the Shelly app and web interface, and Shelly puts it roughly three months out from the September 3 announcement. So think December, give or take. Shelly has not published which Gen4 models are eligible. The press release also promises a “dedicated module” that brings ThreadLink devices into Home Assistant with the full Shelly feature set, beyond what Matter exposes, with no details yet on what that module is.
Somebody got there first, from a van
What makes this announcement interesting is what came before it. Back in May, a developer publishing as Automatous released open-source Matter-over-Thread firmware for the Shelly 1 Gen4, later also the 1 Mini Gen4. The README says it was written from inside an old camper van. It reconfigures the ESP32-C6’s 802.15.4 radio for Thread and turns the relay into a plain Matter device: no Shelly app, no cloud, no Wi-Fi. Matter Alpha covered it at the time, and the project’s own README links a Shelly subreddit thread whose moderator credited it with a noticeable spike in Thread feature requests to Shelly.
I never flashed it, and the project is very upfront about why most people should think twice. Flashing voids the warranty and removes the factory keys that enable Shelly Cloud and official OTA updates. The quick web-UI install can’t back up the stock firmware, so treat it as one-way. It also runs on Espressif’s test credentials, so it isn’t a certified Matter product. For a relay switching a ceiling light, some people will happily take that deal. For a relay buried in a wall box behind plaster, I didn’t want to.
I can’t prove the community project caused ThreadLink, and I won’t pretend to. But the order of events is worth noticing. The README still says Shelly “currently has no plans for Thread”, and that line has aged fast. I would like to think the two versions can coexist: a certified, supported path from the vendor, and a minimal, Matter-only one from the community for people who want nothing else on the device.
The cloud switch lives on my border router
This is the part I didn’t expect. With Wi-Fi Shellys, keeping the cloud out takes deliberate effort. You disable the cloud connection per device, and if you’re thorough you block the devices’ outbound traffic at the firewall, and you hope a firmware update doesn’t quietly turn anything back on. I’ve been doing some version of that for years.
With ThreadLink, the device reaches Shelly Cloud through NAT64 on the border router. My border router is Home Assistant’s own OpenThread Border Router add-on running on the ZBT-2. That add-on has a NAT64 option, and it is off by default. Mine is off, because nothing on my mesh has ever needed to reach an IPv4 address on the internet.
If I understand the design correctly, and I will test this rather than assume it, that means a ThreadLink relay on my mesh simply has no path to Shelly Cloud. I wouldn’t need a per-device toggle or a firewall rule, because the network it lives on can’t reach the IPv4 internet. Matter to Home Assistant would still work, and so would device-to-device scenes inside the mesh, because none of that leaves the house. For a local-first setup, that is a better default than anything I’ve had with Wi-Fi relays: local is what you get unless you choose otherwise, instead of something you have to switch on per device.
The flip side is equally clear: people on Apple, Google or Amazon border routers don’t control NAT64 the same way, so for them cloud access will likely just work. That is fine. It is their house.
What I’d lose, and what I don’t know yet
My Wi-Fi Shellys do more than switch. They can speak MQTT, they have a local web UI I can open from my laptop, and a couple of them act as Bluetooth gateways for BLU sensors. The press release confirms the RPC API over Thread and firmware transfers over TCP. It says nothing about MQTT, the web UI, on-device scripts, or whether a ThreadLink relay can still relay BLU sensor advertisements. Until the eligible models and a changelog show up, I’m treating every one of those as unknown.
There’s also a concentration problem I’d be walking into. Today, if my Home Assistant box dies, my Wi-Fi relays keep working locally and I can still reach them. On ThreadLink, they’d depend on the Thread mesh, and my mesh has exactly one border router. Scenes inside the mesh would survive, and Shelly is right that this is more resilient than cloud-dependent logic. But reaching those relays from anything outside the mesh would go through a single USB stick on a single mini PC. A second border router has been on my “someday” list. ThreadLink would move it up.
And one question for the Home Assistant side: will the “dedicated module” be an extension of the existing Shelly integration, or something separate? The current Shelly integration is local push and excellent, and its docs say nothing about Thread. If ThreadLink devices show up as Matter entities with a Shelly-flavoured layer on top, that’s fine. If it means a second integration for the same physical device, I’ll want to see how the two coexist before I convert anything important.
My plan for December
- Buy nothing now. Nobody knows which models are eligible, so buying a Gen4 relay today because of ThreadLink is buying a promise. If you need a relay anyway, Gen4 is still a reasonable pick, just not for this reason.
- Pick one low-stakes relay. When the firmware ships, it goes on the hallway light, not anything wired to heating or a door.
- Test the NAT64 theory. With NAT64 off, confirm the relay commissions over Matter, works in Home Assistant, and makes no attempt to reach Shelly Cloud that gets anywhere. Then flip NAT64 on briefly and see what changes.
- Pull the plug on purpose. Stop the Home Assistant box and check which scenes still run inside the mesh, the same way I tested my backups by wiping the box.
I have been cautious about Shelly this year. The 2.0.0 security cleanup was overdue, and I rolled it out one relay at a time. ThreadLink is the first Shelly announcement in a while that I’m actually excited about. The main reason isn’t Shelly’s cloud or its app. It’s that, on my network, the design seems to make the local-only setup the default. I’ll report back when there’s firmware to flash instead of a press release to read.
Leave a Reply