The worst way to buy a smart-home hub is to start with the word “hub.” The label is used for several different jobs: an ecosystem controller, a Thread Border Router, a radio bridge, an automation engine, a local storage device, or simply a speaker/display that happens to contain some of those functions.

The safer buying question is: which network and control jobs does this home actually need, and which device is responsible for each job?

That matters even more in 2026 because Matter has continued to evolve. The Connectivity Standards Alliance released Matter 1.6 on June 17, 2026. The release focused on setup, multi-ecosystem management, contextual control, and richer capability/state information rather than simply adding more device categories. Buyers should therefore compare the capabilities of the products and ecosystems they can actually purchase today, not assume that the latest specification instantly appears in every installed device.

Here are the five questions to answer before spending money.

1. Do you need an ecosystem controller, a radio bridge, or a Thread Border Router?

These jobs overlap in product marketing but are technically different.

Matter controller: commissions and controls Matter devices inside an ecosystem. A phone app, smart speaker, display, or dedicated hub may play this role.

Thread Border Router: connects a Thread mesh to the home's broader IP network. Thread Group describes a Border Router as the bridge between the Thread network and other IP networks; unlike an application-layer gateway, it routes IP traffic rather than translating the smart-home application itself.

Protocol bridge: translates devices from one ecosystem or radio/application protocol into another representation. A bridge may expose legacy lights, sensors, or locks into a Matter ecosystem while the end devices themselves are not native Matter-over-Thread devices.

Automation hub: runs rules, scenes, schedules, or local logic. It may also contain radios and controller functions, but automation is a separate job.

The key purchasing mistake is assuming one box performs all four jobs just because the packaging says “hub.”

2. What transports do your actual devices use?

Matter is an application-layer interoperability standard. It does not replace Wi-Fi, Ethernet, or Thread as network transports.

A practical home can contain:

  • Matter over Wi-Fi devices;
  • Matter over Thread devices;
  • older Zigbee or Z-Wave devices through a bridge/hub;
  • Bluetooth used for commissioning or vendor-specific functions;
  • proprietary cloud-connected devices that are not Matter devices at all.

So inventory first, buy second.

Create a simple table:

Device Current protocol/transport Must keep? Local control needed? Ecosystem target
Door lock Thread yes yes Apple + Google
Existing bulbs Zigbee via bridge yes preferred Apple
Camera Wi-Fi/vendor cloud yes mixed vendor app
New sensor Matter over Thread no yes multi-admin

Once the device inventory is visible, the hub decision usually becomes smaller.

3. Do you actually need Thread?

If you plan to buy Matter-over-Thread devices, you need access to a Thread Border Router somewhere in the home. That router may already exist inside a compatible smart speaker, display, router, or hub. Buying another box without checking existing infrastructure can be unnecessary.

Thread has useful properties for low-power mesh devices. It is IP-based and is designed so multiple Border Routers can coexist. Thread Group notes that multiple Border Routers can improve resilience because the network does not have to depend on a single application-layer gateway.

But Thread is not automatically the right answer for every device. High-bandwidth cameras usually remain Wi-Fi/Ethernet territory. Existing Zigbee devices do not become Thread devices because a Matter controller is added. A hub purchase should solve a real transport gap, not satisfy a buzzword checklist.

4. How much do you care about local operation when the internet is down?

“Works locally” is not one binary feature.

Ask vendors to separate at least five functions:

  1. device-to-device control on the LAN;
  2. automation rules stored locally;
  3. remote access from outside the home;
  4. notifications/push services;
  5. vendor account, history, video, or analytics services.

A Matter light may still respond locally while a vendor-specific history screen is unavailable. A hub may run local scenes but require the cloud for voice assistants or remote notifications. A camera may remain connected on Wi-Fi yet lose its cloud recording service.

Buyers should test the failure mode they care about. Disconnect the WAN during setup or ask for explicit documentation. Do not infer “local” from a Matter logo alone.

5. What happens when you use more than one ecosystem?

One of Matter's important design goals is interoperability across ecosystems, and Matter 1.6 continues to improve multi-ecosystem experiences. But multi-admin does not mean every ecosystem exposes every feature identically.

Before buying, check:

  • which functions are available in each ecosystem;
  • whether automations have to be rebuilt separately;
  • which ecosystem owns household/user permissions;
  • how scenes, rooms, names, and favorites synchronize—or do not;
  • whether firmware updates require the vendor app;
  • whether advanced device features exist only in the manufacturer's app.

The base device may be interoperable while the richer feature layer remains ecosystem-specific.

Compare support life, security, and recoverability—not just radios

A hub can solve today's compatibility problem and still become tomorrow's weakest link if the vendor stops updating it, the account cannot be transferred cleanly, or critical automations cannot be exported.

Before buying, check four lifecycle questions:

  • Is there a published security-update or support policy for the product line?
  • Can the device be factory-reset and transferred without leaving the previous household's access behind?
  • Are automations, device lists, or configuration exportable or at least easy to recreate?
  • If the vendor account or cloud service disappears, which local functions remain usable?

Matter certification or protocol support does not answer those questions by itself. Interoperability at the application layer is useful, but the hub is still a maintained software product with firmware, accounts, radios, storage, and vendor-specific features.

For a buyer, recoverability is part of compatibility. A system that takes six hours to rebuild after a failed hub may be a worse choice than one with fewer features but a documented backup, replacement, or migration path.

A decision tree for three common homes

Home A: mostly Wi-Fi devices, one ecosystem, few automations

You may not need a dedicated hub at all. If your preferred ecosystem controller already exists on a phone, speaker, or display, adding hardware can create more administration without solving a real problem.

Buy a hub only if you need a missing radio, local automation, better reliability, or Thread support for planned devices.

Home B: many low-power sensors/locks plus multiple ecosystems

This is where Thread Border Router availability and Matter controller compatibility matter. Prefer infrastructure that supports more than one Border Router and document which device performs each controller role.

Avoid concentrating every critical function in one box if a failure would disable access, lighting, and automation simultaneously.

Home C: large installed base of Zigbee/Z-Wave or proprietary devices

Do not replace working devices just to make the diagram look modern. A bridge strategy may be more economical.

The purchasing question becomes: how well does the bridge expose the functions you actually use? Basic on/off or sensor states may transfer cleanly while advanced vendor features do not.

What changed in 2026—and what did not

Matter 1.6 is real and current as of June 17, 2026. CSA describes improvements around NFC-based commissioning, ecosystem coordination, contextual control, and richer communication of capabilities and states. That is useful progress.

What has not changed is the need to verify implementation. A specification release is not the same thing as a firmware update on the device in your hand. Product support depends on manufacturer timelines, chipset capability, ecosystem certification, and software rollout.

So the buyer's rule is simple: shop the implemented feature, not the specification headline.

The buying checklist

Before checkout, write down:

  • devices you already own and their protocols;
  • devices you plan to add in the next 12–24 months;
  • the ecosystem(s) you want to control them from;
  • whether Matter-over-Thread devices are planned;
  • which existing devices already provide Thread Border Router capability;
  • which automations must work without internet;
  • whether you need bridge support for legacy devices;
  • how firmware updates and backups work;
  • how household access is managed;
  • what remains functional if the vendor cloud, internet, or one hub is unavailable.

Then purchase the smallest set of infrastructure that closes those gaps.

A good hub architecture is not the one with the most logos. It is the one where every box has a known job, failure is understandable, legacy devices are not replaced unnecessarily, and future expansion does not require rebuilding the entire home.

Sources

Related Reading