The smart-home market becomes much easier to understand when you stop treating “hub,” “Matter,” “Thread,” “Wi‑Fi,” “Zigbee,” and “works with” as interchangeable labels.

They are not.

A buyer can purchase a device that supports Matter but still need a compatible controller. A Thread device can need a Thread Border Router to reach the rest of an IP network. A bridge can expose older Zigbee or other devices into a newer ecosystem without changing the radio those devices use. A product can work locally for basic control yet rely on a vendor cloud for history, remote services, or advanced features.

The market is therefore not one protocol replacing all others. It is a stack of roles sold by different companies.

As of October 3, 2026, Matter 1.6 is the current announced Matter release from the Connectivity Standards Alliance. It launched on June 17, 2026 and focused on setup, multi-ecosystem management, context-driven control, and richer communication of device capabilities and operational information. That is useful progress, but it does not make every old device, every radio, or every vendor feature identical.

The map below separates the layers so a buyer can ask better questions.

Wrong approach: “If it says Matter, I do not need a hub”

This is the first vocabulary trap.

Matter is an application-layer interoperability standard. It defines a common way for supported device types and ecosystems to communicate about functions and state. It does not mean every device talks directly to every phone without infrastructure.

In a typical home, something still performs controller duties: commissioning devices, holding fabric credentials, sending commands, coordinating automations, or providing the user interface. That controller function may be embedded in a speaker, display, TV, router, dedicated hub, phone ecosystem, or another always-on product.

Better approach: ask which role the product performs

Instead of asking “Does this include a hub?”, ask:

  • Is this a Matter controller?
  • Is it a Thread Border Router?
  • Is it a bridge for another device network?
  • Is it only an app interface to a cloud service?
  • Can one physical product perform several of these roles?

A single box can perform multiple roles, which is why retail language gets confusing.

The buyer should document the function, not the marketing noun.

Wrong approach: “Thread is the same thing as Matter”

Thread and Matter solve different parts of the stack.

Thread Group describes Thread as an open, secure, low-power, IPv6-based mesh networking protocol for IoT devices. It is designed for many low-power devices, uses a mesh topology, and avoids a single point of failure inside the Thread network.

Matter can run over IP transports including Thread for low-power mesh devices and Wi‑Fi or Ethernet for other device classes.

A useful shorthand is:

Matter describes how compatible smart-home devices understand one another. Thread can be one of the networks carrying that IP communication.

That shorthand is simplified, but it is better than treating the names as substitutes.

Better approach: separate application standard from transport

When looking at a product box or spec sheet, identify two things:

  1. What application/ecosystem standard does it support?
  2. What network transport does the physical device use?

For example, two Matter products can both participate in a Matter ecosystem while one uses Wi‑Fi and another uses Thread.

That difference can affect power use, network design, commissioning path, and whether a Border Router is needed.

Wrong approach: “A Thread Border Router is another proprietary gateway”

A Thread Border Router has a specific networking job: it connects a Thread network to adjacent IP networks.

Thread Group emphasizes that Thread is IP-based, and Border Routers extend connectivity between the Thread mesh and the broader IP infrastructure. This is different from a classic proprietary hub that translates every application command through a closed protocol.

Multiple Border Routers can exist in a home. In a well-designed Thread environment, the network should not depend on one special proprietary gateway as its only path.

Better approach: inventory Border Router availability before buying Thread devices

A household may already own compatible Border Router-capable infrastructure inside a smart speaker, home hub, router, or other platform device.

Before purchasing another box, ask:

  • Do I already have a Border Router supported by the ecosystem I plan to use?
  • Is it always powered and located well enough for the home?
  • Does the platform expose useful Thread network diagnostics?
  • If I add a second ecosystem, will the commissioning and credential-sharing experience be straightforward?
  • What happens to local control if internet service is unavailable?

Do not assume the presence of the Thread logo alone answers those questions.

Wrong approach: “Matter makes Zigbee, Z-Wave, and proprietary devices obsolete overnight”

Installed homes do not reset when a new standard arrives.

There are large numbers of existing sensors, bulbs, locks, switches, shades, thermostats, and security products using Zigbee, Z-Wave, Bluetooth, proprietary sub-GHz radios, or vendor-specific local networks.

A bridge can keep those devices on their existing radio while representing compatible functions into a Matter ecosystem.

This is one reason the hub market is not disappearing. Its role is changing.

Better approach: think in terms of translation and asset preservation

For an existing home, ask:

  • Which installed devices are still useful?
  • Which depend on a current vendor hub?
  • Can that hub or a replacement bridge expose them into the target ecosystem?
  • Which device features survive the bridge?
  • Which advanced or vendor-specific features remain available only in the original app?
  • What happens if the bridge is removed?

The right upgrade may be a bridge, not fifty replacement devices.

That can reduce cost and electronic waste, but it also creates another dependency that must be maintained.

Wrong approach: “If basic control is local, every feature is local”

A buyer presses a light button during an internet outage and concludes the system is fully local.

That test is useful but incomplete.

Different functions can take different paths:

  • local on/off control;
  • local automations;
  • remote access from outside the home;
  • camera history;
  • analytics;
  • voice services;
  • firmware delivery;
  • account management;
  • energy dashboards;
  • vendor-specific AI features.

A product may keep essential local control while advanced features depend on cloud infrastructure.

Better approach: map each important feature to its dependency

Use a table like this before choosing an ecosystem:

Function Local controller Internet required? Vendor cloud? What fails if unavailable?
Basic light control maybe often no maybe no app/automation path may vary
Remote control away from home usually gateway/controller yes platform-dependent remote access
Device history platform-dependent often often history/dashboard
Local automation controller-dependent not necessarily varies automation may continue or stop
Firmware updates device/platform-dependent generally yes vendor/platform updates delayed
Voice assistant platform-dependent often often voice feature unavailable

The actual answer is product-specific. That is exactly why the map matters.

The seller side: five businesses can touch one “simple” device

From the seller’s perspective, the value chain may include:

1. Silicon and radio vendors

They provide chipsets and reference platforms supporting Wi‑Fi, Thread, Bluetooth, Zigbee, or multiple radios.

2. Device manufacturers

They build the lock, sensor, thermostat, bulb, plug, shade, or appliance and implement required software and security functions.

3. Standards and certification organizations

Organizations such as the Connectivity Standards Alliance and Thread Group maintain specifications, certification programs, and interoperability work.

4. Ecosystem/platform companies

They provide controllers, apps, voice interfaces, automations, account systems, and sometimes Border Router functionality.

5. Integrators, retailers, installers, and service companies

They decide which combinations are actually sold, installed, supported, and replaced in a real home.

A buyer sees one product. The service chain behind it can be much larger.

Matter 1.6 changes the experience, not the basic need to verify roles

The release of Matter 1.6 on June 17, 2026 is a useful marker for the current market.

The Connectivity Standards Alliance describes 1.6 as a focused feature release rather than a large expansion of device categories. It adds improvements such as NFC-based commissioning options, better coordination of device management across ecosystems, more context-aware control behavior, and improved communication of capabilities, states, and safety information.

For buyers, the lesson is not “wait for the latest number.”

It is:

  • check what Matter version and features the actual product has implemented;
  • check whether the ecosystem you use exposes those features;
  • check whether certification applies to the device/version being sold;
  • avoid assuming a standard release automatically upgrades every existing product.

Standards move faster than some product firmware and retail inventory.

How to map a home before buying another hub

A useful market map starts with the home, not with product categories.

Write down:

Ecosystems: Which apps or voice/platform ecosystems does the household actually use?

Always-on infrastructure: Which speakers, displays, routers, hubs, or bridges stay powered?

Radios: Which current devices use Wi‑Fi, Thread, Zigbee, Z-Wave, Bluetooth, or proprietary networks?

Critical automations: Which routines must keep working if the internet is down?

Remote requirements: Which devices must be controlled from outside the home?

Legacy assets: Which installed devices are expensive or difficult to replace?

Support horizon: Which hubs or bridges are still receiving updates?

Once this is visible, a new hub purchase becomes a gap-filling decision instead of a collection hobby.

Three buyer scenarios

Scenario A: a new apartment with a small number of devices

The buyer has no legacy network and wants lights, sensors, a lock, and a thermostat.

The simplest architecture may be to choose one primary ecosystem with a capable Matter controller and the needed Thread Border Router role, then buy certified devices that fit it. Adding a separate legacy hub before it is needed may create complexity without value.

Scenario B: an existing Zigbee-heavy home

The buyer already has dozens of functioning sensors and lights.

Replacing all of them merely to say “Matter” may be wasteful. A reliable bridge that exposes useful functions into the chosen ecosystem can preserve the installed base. The buyer should verify which device capabilities are bridged and which remain vendor-specific.

Scenario C: a privacy- and resilience-focused home

The buyer cares about local operation and wants critical lighting, sensors, and climate routines to survive internet failure.

The buying process should prioritize the local dependency map: which controller executes automations, which features require cloud access, whether local APIs exist where relevant, and how account/cloud failure affects basic control.

The protocol logo alone is not enough evidence.

What sellers should stop promising

The market becomes harder to trust when sellers oversimplify.

Avoid claims like:

  • “No hub required” without saying which controller or Border Router role is still needed;
  • “Works offline” when only basic control works offline;
  • “Works with Matter” without specifying the supported device functions and firmware;
  • “Future-proof” when support life and update policy are undefined;
  • “One app controls everything” when advanced features still require vendor apps.

Precise compatibility language is more valuable than broad slogans.

A buyer’s five-minute protocol test

Before spending money, answer these seven questions:

  1. What radio does the end device use?
  2. Does it support Matter, and which functions are exposed?
  3. What device acts as the Matter controller?
  4. If it uses Thread, where is the Thread Border Router?
  5. Is a bridge translating any legacy network?
  6. Which important functions depend on internet or vendor cloud?
  7. If the vendor ends support, what still works locally?

If a product listing does not let you answer those questions, treat the uncertainty as part of the cost.

The market in one sentence

The smart-home hub market is not vanishing. It is being decomposed into clearer roles: controller, Border Router, bridge, radio network, application standard, cloud service, and user interface.

Matter and Thread reduce some interoperability friction, especially when vendors implement them well, but they do not erase architecture.

The buyer who understands the roles can reuse more existing equipment, avoid unnecessary boxes, and ask much sharper questions about reliability, privacy, support, and cost.

That is the practical market map.

Sources

Related Reading