User blogs

Matter solved a real problem for the smart home industry — a single application-layer standard that lets devices from different manufacturers work together regardless of brand. But Matter itself doesn't dictate which radio technology carries its traffic. That decision — Thread or Wi-Fi SoCs— is left to the device manufacturer, and it's a more consequential choice than it might first appear.

It's worth being precise about what Matter actually is: an application-layer protocol that defines how smart home devices describe themselves and communicate, regardless of the underlying network. Matter runs over IP, which means it can travel over Thread's low-power mesh network, over Wi-Fi, or in some architectures, over Ethernet. BLE, meanwhile, handles Matter's device commissioning process in nearly all cases, regardless of which transport the device ultimately uses for ongoing operation.

This means the real design decision isn't "Matter or not" — it's which transport layer, Thread or Wi-Fi, actually fits the device.

Matter over Thread is a low-power, IPv6-based mesh networking protocol purpose-built for exactly this kind of application, and pairing it with Matter has become the default choice for a large share of battery-powered and always-on-but-low-power smart home accessories.

Mesh networking extends coverage without extra infrastructure. Every Thread device on the network can relay traffic for its neighbors, meaning a Thread mesh's effective coverage grows as more devices join it — a real advantage in larger homes where a single Wi-Fi router's range may not reach every room reliably.

Power efficiency suited to battery operation. Thread's low-power design makes it a strong fit for sensors, door/window contacts, smart locks, and other devices where multi-year battery life matters — a use case where Wi-Fi's power draw would be a poor fit.

Self-healing network resilience. If one device in a Thread mesh goes offline, traffic automatically reroutes through other nodes, which meaningfully improves reliability for larger smart home deployments compared to a hub-and-spoke architecture with a single point of failure.

The tradeoff: it requires a Thread Border Router. Thread traffic needs to reach the internet somehow, which requires a Thread Border Router (increasingly built into smart speakers, hubs, and some routers) bridging the Thread mesh to the rest of the home network. Without one already present, a Thread device is effectively isolated until that infrastructure exists.

Matter over Wi-Fi takes a more straightforward path — using the Wi-Fi infrastructure most homes already have, without requiring any additional border router hardware.

No additional infrastructure required. Since the vast majority of homes already have a Wi-Fi router, a Matter over Wi-Fi device can join the network directly, without depending on a Thread Border Router being present.

Bandwidth for anything beyond simple state changes. Devices with higher data needs — cameras, video doorbells, anything streaming meaningful data — are a natural fit for Wi-Fi's throughput, which Thread's low-power design doesn't provide.

The tradeoff: power consumption and single-point network dependency. Wi-Fi's higher power draw makes it a poor fit for battery-powered devices expected to run for years, and unlike Thread's mesh resilience, a Wi-Fi device's connectivity depends entirely on its direct link to the router.

The decision comes down to two questions about the specific device being designed:

Does it need to run on battery for an extended period? If yes, Thread is almost always the better fit — a battery-powered Wi-Fi Matter device will need significantly more frequent charging or battery replacement than a Thread equivalent doing the same job.

Does it need to move meaningful data, or just report state changes? A door sensor reporting open/closed, a smart plug reporting on/off, or a thermostat reporting temperature are all low-bandwidth use cases well suited to Thread. A camera or anything streaming continuous data needs Wi-Fi's throughput regardless of power considerations.

For mains-powered devices with low data needs — many smart plugs and in-wall switches, for instance — either transport can work reasonably well, and the choice often comes down to secondary factors: whether a Thread Border Router is reliably present in the target market, existing product platform decisions, and certification timeline considerations.

For SoC selection specifically, this transport decision has direct silicon implications. A Matter over Thread design needs a chip with a proper Thread/802.15.4 radio and sufficient processing headroom to run the Thread mesh stack alongside Matter — RISC-V-based dual-core architectures have become common here specifically to handle both workloads without compromising responsiveness. A Matter over Wi-Fi design instead needs a capable Wi-Fi radio, typically paired with BLE for commissioning, in a combo SoC architecture.

Increasingly, product lines that need to serve both use cases — a company building both battery-powered sensors and a mains-powered hub, for example — are standardizing on SoC platforms that support both Matter over Thread and Matter over Wi-Fi as separate product variants sharing a common development toolchain, rather than building each on entirely different silicon.

Neither transport is universally "better" — they're optimized for genuinely different device categories, and the smart home ecosystem needs both to function well as a whole. The practical exercise for any product team is mapping the specific device's power constraints and data needs against these two transport options early in the design process, rather than defaulting to whichever protocol the last product used.