How Thread Is Rewiring the Smart Home

Imagine... you're at your local Best Buy looking to buy lights that you can control with your phone or some sort of automation switch. You are faced with a wall of boxes covered in "Works with..." stickers — Google, Alexa, Apple, and who knows what else. The headache is real. You have some that work only with Google and Alexa, some that work with Apple, some that require a properietary hub, etc. It is a confusing mess. And at the end of the day, people resort to Wi-Fi ones which please do not get me started on the issues with those.

I am a big fan of Zigbee. I have reliably used it for free to control smart home devices like lights, plugs, and controllers. Zigbee, unlike, Wi-Fi, is its own protocol. It is able to communicate to other Zigbee devices without the internet. Allowing me to not pollute my Wi-Fi network with a bunch of smart home devices that may be insecure and take up bandwidth. Not to mention that it is so reliable that I almost never have issues with it (looking at you super expensive Wi-Fi enabled LIFX bulb that never worked).

While I have so many great experiences with Zigbee, I also have quite a few gripes with it that make it very hard to be optimistic about the future of the protocol. Mainly, the fact that it is a standard, but the implementation is not. You can buy a light-bulb that contains the Zigbee protocol, but it does not mean that it will necessarily work with all Zigbee hubs (the device that controls and automates Zigbee devices). Kind of weird when you think about it. Remember, the Zigbee protocol is designed for smart devices to communicate with each other over short ranges using low-power. There are multiple companies part of CSA that have the authorization to use the Zigbee protocol. So why does it not always interoperate?

What is Zigbee?

Zigbee is not just a protocol/language—it is a fullstack communication system: a network, an addressing system, a command format, and a routing protocol all rolled into one system.

Phew. That is a lot of tech jargon 😮‍💨. Let us break it down:

Zigbee Networking Basics

Zigbee uses a custom protocol stack. For addressing, devices (lights, locks, etc.) on a Zigbee network have:

• • A 64-bit IEEE address (sort of like a MAC address).
• • A 16-bit short address that is assigned by the Zigbee hub.

Devices form a mesh network, where routers (usually always-on devices like bulbs or plugs) help relay traffic between end devices (like sensors or remotes) and the hub.

Zigbee Mesh

Zigbee's mesh is built on its own proprietary routing protocol layered on top of the 802.15.4 radio standard. A Zigbee network requires a hub (or technically called a coordinator ☝️🤓 ) which:

• • Forms and maintains the network.
• • Assigns short addresses to new devices.
• • Acts as the root of the mesh.

There are also the routers which are always-on devices like bulbs and plugs and there are end devices (typically battery powered sensors) that cannot relay traffic.

But Zigbee mesh has drawbacks:

• • The hub/coordinator is a single point of failure.
• • Routing decisions are not IP-based.
• • Devices from different manufacturers may not route traffic through each other correctly.
• • Network topology is often statically assigned making recovery often slow or manual.

Zigbee's Application Layer: Clusters, Commands, and Attributes

Zigbee defines its entire communication stack — from the physical radio layer up to the application layer. At the application layer, Zigbee uses a standard called the Zigbee Cluster Library (ZCL). This library organizes device functionality into clusters, which are essentially groups of related commands and attributes.

Think of a cluster as a category of functionality — like turning a device on or off, or controlling its brightness.

For example:

• • Cluster 0x0006 = On/Off (used to turn devices on or off)
• • Cluster 0x0008 = Level Control (used to dim or brighten lights)

Each cluster contains:

• • Commands – Actions a device can perform (like "On", "Off", "Toggle").
• • Attributes – Values that represent the current state of the device (like "is the light currently on?").

So when you send a command to a Zigbee device, you're basically telling it: “Use this cluster to perform this command or report this attribute.”

Example: Sending a Zigbee Command

In a real-world command flow, this is how it would look:

Why Zigbee Struggles with Interoperability

Pretty straight forward, right? So why is Zigbee not interoperable? For many reasons, but here are a few:

1. The Standard Says What Is Possible, but Not Always What Is Required: The Zigbee specification allows too much flexibility in the 'standard'. Zigbee specification allows manufacturers to choose which clusters and commands they want to implement, customize behavior or timings, and create proprietary extensions. Just because two devices support cluster 0x0006 (on/off) it does not mean that:

   • • They handle pairing the same way.
   • • They report statuses identically.
   • • They handle errors, retries, or timing consistently.

2. Vendor Lock-In by Design: Vendors often use custom clusters or attributes not in ZCL. Vendors also customize their own pairing and commissioning steps, and tweak retry behavior/timeouts/command sequences. This very anti-consumer approach gives vendors like Xiaomi and Philips more control and locks users into their own ecosystem.

3. Hubs Implement Their Own Compatibility Layers: Even if two Zigbee devices follow the same standard, the Zigbee hub would still need to understand the device's fingerprint (identity and capabilities). If the Zigbee hub cannot recognize the device, it will not map commands properly.

4. Inconsistent or Minimal Certification Requirements: Devices can be "Zigbee-certified" but only support the bare minimum to pass. And the certifications given by the CSA may not actually even test real-world interoperability with other brands. In fact, some manufacturers even skip full certification entirely and implement Zigbee, but do not test or fully align with the CSA. They might not get the official Zigbee badging, but they can still sell the Zigbee-enabled product.

So what is next for smart homes? Enter Thread 🎆, a protocol designed to fix what Zigbee could not.

What is Thread?

Thread is also low-powered like Zigbee, but it is an IP-based wireless mesh network protocol. In its purpose, it is like Zigbee, but communicates like the internet does.

How Thread Communicates

Devices in the Thread mesh network communicate using IPv6 addresses over 6LoWPAN which is a lightweight IP over low-power radio. Every device (lightbulb, lock, switch, etc.) is part of a mesh network, and can route messages. There is a Thread Border Router that bridges Thread to the rest of your home network. In contrast to Zigbee's cluster/command frames to a 16-bit address like 0x1234, you're sending real IP packets to an IPv6 address — which is super exciting because... drum roll please 🥁... vendors can use standard tools, protocols, and security layers that are so widely used today in the internet already.

I know what you might be thinking: "Gee, this still looks complicating like Zigbee." And that is fair. But here is the key difference; in comparison to the Zigbee diagram, that the "Turn On" command is no longer a Zigbee-specific frame. It is a standard IP packet, with a Matter payload inside — just like a web service. This allows devices to use existing IP infrastructure and security models, instead of trying to reinvent the wheel like Zigbee did. Cool stuff.

Thread Mesh

Okay now here is the cool difference between good ole' Zigbee and the new and improved Thread!

Thread also uses 802.15.4 radios.... but wait! The entire stack is IP-based, and it uses modern mesh routing protocols like IPv6 and 6LoWPAN with routing based on link-state techniques. Cool, right??? 🤯

The key advantages of Thread mesh are:

• • No single point of failure; meaning, every router is equal (No coordinator, but there is still a hub)
• • Mesh routing is self-healing and dynamically managed
• • Devices use standard IPv6 addresses and can communicate directly
• • Thread Border Routers automatically connect the mesh to your home network
• • Fully open standard

What is Matter?

Matter is the application-layer protocol that runs on top of Thread (or Wi-Fi). It's a universal smart home standard that defines how devices pair, talk, and behave — with strict certification and security baked in. Thread handles the networking; Matter defines the language.

How Thread Ensures Compliance (with Matter)

This is interesting because unlike Zigbee, Thread works with an application layer protocol called Matter. And Matter is essentially a protocol, data model, and a strict certification process. It defines how smart home devices communicate: how to pair, send commands, report state, error handling, all that good stuff developers have to implement. To become Matter-certified, a device must pass rigorous testing, including:

• • Network Compliance (Thread, Wi-Fi, or ethernet)
• • Behavioral Compliance (Does it follow the command spec?)
• • Security Testing (E2E encryption, standard cryptographic keys, etc.)

Platfrom Agnostic

As mentioned, Zigbee lacks mandatory standard following. Thread + Matter aim to fix this by being platform agnostic by design. With Matter, the goal is to be able to walk into a store and buy a Matter certified smart home product and pair it with any platform (Apple, Google, Samsung, etc.).

This cross-platform promise is one of Matter’s most ambitious goals, and it's being backed by the biggest names in tech.

Why Thread is the Future (with Matter)

Zigbee was an incredible step forward — it gave us mesh networking, reliable local control, and freedom from Wi-Fi congestion. But it also brought headaches: inconsistent compatibility, vendor lock-in, and a frustrating lack of true interoperability.

Thread and Matter aren’t just incremental upgrades — they represent a new foundation for the smart home. With Thread’s IP-based, self-healing mesh and Matter’s strict, open, cross-platform device standard, we finally have the ingredients for a smart home that’s platform free.

It’s still early — not every device supports Thread or Matter yet. But the direction is clear: the future of smart homes is going to be a whole lot less painful for developers and consumers.

So if you’re starting from scratch or looking to future-proof your setup, look for devices that are Matter-certified and Thread-compatible. Because the smart home you build today should still work tomorrow — no matter which app or platform you use to control it.