Matter, Thread, Zigbee, Wi-Fi: which protocols keep a smart home local

The protocol a device speaks decides more about your smart home than the brand on the box. It sets whether the device can be controlled from inside your network, how far its radio reaches, how much power it draws, and how much of its behaviour depends on a vendor’s servers.

Four protocols cover most of what you can buy today: Wi-Fi, Zigbee, Thread, and Matter. They are not interchangeable, and they do not sit at the same layer. Wi-Fi, Zigbee, and Thread are ways for a device to talk on a network. Matter is a common application language that runs on top of some of them. Understanding that difference is the first step to buying for local control instead of against it.

A protocol is not a privacy promise

Before comparing them, one caveat carries through every section: a protocol that supports local control does not guarantee it. The radio standard sets what is possible; the vendor’s implementation decides what actually happens.

A Wi-Fi plug can run entirely through a vendor cloud even though Wi-Fi itself is local. A Zigbee device controlled through a vendor hub can still route decisions through that vendor’s app. Matter is designed around “reliable and responsive local connectivity,” per the Connectivity Standards Alliance, but a Matter device can still expose fewer features locally than it does through its own cloud app.

So read the sections below as “what this protocol makes possible,” then verify each specific device against it.

Wi-Fi: everywhere, but power-hungry and often cloud-tied

Wi-Fi is IP-based and connects devices directly to your router, so no extra hub is required. That convenience is why so many budget devices use it.

The trade-offs are real. Wi-Fi radios draw more power, which makes them a poor fit for battery sensors and door locks meant to last months on a coin cell. A home with dozens of Wi-Fi devices also loads the same network your phones and laptops use. And because each device reaches the internet on its own, many vendors build their products to check in with a cloud account by default, even for basic on/off control.

Wi-Fi can absolutely be local: a controller on the same network can talk to a Wi-Fi device directly. But with Wi-Fi devices, cloud dependence is the most common default to watch for.

Zigbee: a mature low-power mesh, behind a coordinator

Zigbee is a low-power mesh protocol. The Connectivity Standards Alliance describes it as a “proven, self-healing mesh” with a “self-organizing, self-healing mesh topology” that is “scalable to thousands of nodes,” and notes it is “optimized for low power consumption to extend battery life,” with a PHY that “supports both 2.4 and Sub-GHz bands.”

Mesh matters for coverage. Mains-powered Zigbee devices (bulbs, plugs) relay traffic for battery devices (sensors, buttons), so the network’s reach grows as you add devices rather than depending on a single radio.

Zigbee is not IP-based. Devices do not get their own internet address; they talk to a coordinator, and that coordinator connects to your controller. This is the practical key to local Zigbee: if your coordinator is a local controller (rather than a vendor’s cloud hub), control stays inside your home. The protocol is local by nature, but the coordinator you choose decides whether that locality is preserved.

Thread: a low-power mesh that speaks IP

Thread is the newer low-power mesh, and its defining difference from Zigbee is that it is IP-based. The Thread Group describes Thread as “based on the power-efficient IEEE 802.15.4 MAC/PHY,” running an “open IPv6 based protocol” with a “low energy footprint” and “built-in security.”

Because Thread devices carry IPv6 addresses, they can be addressed individually on the network, much like any other IP device, while still drawing little power. Thread supports “device-to-device and device-to-cloud connections” — note the order: device-to-device first, with cloud as an option rather than a requirement.

Thread needs a Thread Border Router to bridge its low-power mesh to your regular home network. Many people already own one inside a smart speaker or hub; a local controller can also act as one. As with Zigbee’s coordinator, the border router is where local-versus-cloud is decided in practice.

Matter: a shared language, not a new radio

Matter is the layer that ties the others together. It is an IP-based application standard, governed by the Connectivity Standards Alliance, that, in the Alliance’s words, “will run on Wi-Fi and Thread network layers and will use Bluetooth Low Energy for commissioning.”

That sentence is the whole model in miniature:

• Matter does not replace Wi-Fi or Thread; it runs on them.
• Bluetooth LE is used only for the initial setup (commissioning), not for everyday control.
• Because Matter is IP-based and emphasises local connectivity, a Matter device should be controllable on the local network by any Matter controller — not just the vendor’s app.

The promise is cross-brand local control: one device, multiple controllers, no single vendor required. The caveat from the first section still applies — a device can be “Matter” yet expose its richest features only through its own app — so Matter narrows the cloud-dependence risk without erasing the need to check each product.

How to choose for a local-first home

Translate the protocols into buying rules:

• Prefer Thread or Zigbee for battery devices. Both are low-power meshes built for sensors, buttons, and locks. Wi-Fi is the wrong tool for anything running on a small battery.
• Treat the coordinator or border router as the decision point. Zigbee’s coordinator and Thread’s border router are where “local” is kept or lost. A local controller acting in that role keeps control inside the home.
• Favour Matter when you want cross-brand local control, but verify which features a specific device actually exposes over Matter before relying on it.
• Be most skeptical of Wi-Fi devices. They can be local, but cloud-by-default is the common pattern — check before buying.
• Match the radio to the controller you already chose. The protocol question only pays off if your controller runs automations locally; otherwise even a perfect Thread device still depends on someone else’s server.

No single protocol is “the private one.” The combination that keeps a home local is a low-power mesh for the small devices, a local controller acting as the coordinator or border router, and a habit of checking each device against what its protocol actually allows.