智能家居市场一旦把“Hub、中枢、Matter、Thread、Wi‑Fi、Zigbee、Works with”这些词拆开，立刻就容易理解很多。

它们不是一回事。

一台设备支持Matter，不代表它可以不经过任何控制器就直接和所有手机通信；一台Thread终端可能仍需要Thread Border Router才能接入家庭其他IP网络；一个Bridge可以让原来的Zigbee设备继续使用原来的无线协议，同时把一部分功能暴露给新的Matter生态；有些设备基础控制可以在本地继续运行，但历史记录、远程服务或高级功能仍依赖厂商云。

所以，今天的市场并不是“一个新协议把所有旧协议一次性替掉”。

它更像一套由不同公司出售、组合在一起的角色栈。

截至2026年10月3日，Connectivity Standards Alliance公开发布的当前Matter版本已经到 Matter 1.6。该版本于2026年6月17日发布，重点不是大规模增加新设备类别，而是改善设置、多生态系统设备管理、情境化控制，以及设备能力、运行状态和安全信息的表达。这些进展有价值，但并不代表旧设备、旧无线协议和各家厂商独有功能从此完全一样。

下面直接把整条链路拆开。

错误做法：“写了Matter，就等于完全不需要中枢”

这是最常见的名词陷阱。

Matter本质上是应用层互操作标准。它让被支持的设备类别和生态系统，可以用共同的方式表达功能和状态。

但这不等于每个设备都直接和手机“裸连”。

实际家庭里，仍然会有某个设备承担Controller职责：给设备配网、管理凭证、下发命令、执行或协调自动化、提供用户界面。这个功能可能藏在智能音箱、屏幕、电视、路由器、专用Hub、平台设备或其他常开设备里。

更好的做法：不要问“有没有Hub”，而要问“它承担什么角色”

采购时逐项问：

  • 它是不是 Matter Controller？
  • 它是不是 Thread Border Router？
  • 它是不是给其他网络做 Bridge？
  • 它只是连接某个云服务的App入口吗？
  • 一台硬件能不能同时承担以上多个角色？

一台设备经常身兼多职，所以零售页面才会越来越难看懂。

买家应该记“功能角色”，不要只记营销名称。

错误做法：“Thread就是Matter”

Thread和Matter解决的是不同层的问题。

Thread Group把Thread定义为面向IoT的开放、安全、低功耗、基于IPv6的Mesh网络协议。它适合大量低功耗设备，采用Mesh拓扑，并强调网络不依赖单一节点才能继续工作。

Matter则可以运行在IP网络之上。对于低功耗Mesh设备，Thread是常见传输路径；其他设备可以使用Wi‑Fi或Ethernet。

可以用一句简化但实用的话理解：

Matter更接近“设备之间用什么共同语言理解功能”；Thread更接近“其中一部分低功耗设备如何把这些IP通信传过去”。

更好的做法：把“应用标准”和“网络传输”分开核对

看任何产品页，都分别找两个答案：

  1. 它支持什么应用/生态标准？
  2. 物理设备通过什么网络通信？

两台设备都可以支持Matter，但一台走Wi‑Fi，另一台走Thread。

这会影响功耗、网络布局、安装方式，以及是否需要Border Router。

错误做法：“Thread Border Router就是又一个私有网关”

Thread Border Router的工作非常具体：把Thread网络连接到相邻的IP网络。

Thread本身是IP体系。Border Router负责把Thread Mesh和家庭更广泛的IP基础设施连接起来，这和过去那种“所有命令都必须经过某个封闭厂商网关翻译”的逻辑并不完全一样。

一个家庭还可以存在多个Border Router。理想的Thread网络不应该因为某一个“唯一私有盒子”离线就彻底失去所有路径。

更好的做法：买Thread设备前先盘点家里已有的Border Router

很多家庭其实已经在智能音箱、家庭中枢、路由器或平台设备里拥有这项能力。

先问：

  • 我现在计划使用的生态里，是否已经有兼容Border Router？
  • 这个设备是否一直通电，放置位置是否合理？
  • 平台能不能提供有用的Thread网络诊断？
  • 如果以后增加第二个生态，配网和凭证共享是否方便？
  • 互联网断掉时，本地控制会剩下什么？

不要因为包装上有Thread标志，就默认所有问题都解决了。

错误做法：“Matter一来，Zigbee、Z-Wave和私有协议马上淘汰”

真实家庭不会因为一个新标准发布，就把已经安装的设备全部清零。

市场上已经存在大量Zigbee、Z-Wave、Bluetooth、Sub-GHz私有协议以及厂商自建本地网络的传感器、灯、锁、开关、窗帘、温控和安防设备。

Bridge可以让这些旧设备继续使用原本的无线协议，同时把被支持的功能映射到Matter生态。

这也是为什么“Hub市场”不会简单消失。

它的角色正在变化。

更好的做法：把Bridge理解成“翻译+保护已有资产”

老房子升级时先问：

  • 哪些已经安装的设备仍然好用？
  • 哪些依赖当前厂商Hub？
  • 当前Hub或新的Bridge能否把它们接到目标生态？
  • 哪些能力可以被桥接？
  • 哪些高级能力仍然只能在原厂App里使用？
  • Bridge一旦移除，会失去什么？

正确升级方案可能只是换一个可靠Bridge，而不是把五十个还能工作的终端全换掉。

这能减少成本和电子浪费，但也意味着多了一个需要维护的依赖点。

错误做法：“基础控制能离线，就代表所有功能都本地化”

有人断掉互联网，发现灯还能开关，于是得出结论：“这套系统完全本地。”

这个测试有意义，但并不完整。

不同功能可能走完全不同的路径：

  • 本地开关；
  • 本地自动化；
  • 外网远程控制；
  • 摄像头历史；
  • 数据分析；
  • 语音服务；
  • 固件更新；
  • 账号管理；
  • 能耗看板；
  • 厂商独有AI能力。

一套系统完全可能保留关键本地控制，同时高级能力仍需要云。

更好的做法：把重要功能逐项画依赖

买生态之前至少做一张这样的表：

功能 本地控制器 是否需要互联网 是否依赖厂商云 中断后损失什么
基础灯光控制 视架构而定 通常不一定 可能不需要 App路径可能变化
外网远程控制 通常需要网关/控制器 是 视平台而定 无法远程
历史记录 视平台而定 经常需要 经常需要 历史/看板消失
本地自动化 取决于控制器 不一定 各家不同 规则可能继续或停止
固件更新 设备/平台决定 通常需要 平台/厂商 无法及时更新
语音助手 平台决定 经常需要 经常需要 语音不可用

真正答案必须看具体产品。也正因为如此，架构图比Logo更重要。

从卖方看，一台“简单设备”背后至少可能有五类公司

消费者只看到一个传感器或开关，但商业链路远不止一个品牌。

1. 芯片与无线方案商

提供支持Wi‑Fi、Thread、Bluetooth、Zigbee或多协议的芯片、模组与参考设计。

2. 终端制造商

真正生产锁、传感器、温控器、灯泡、插座、窗帘或家电，并实现对应软件和安全能力。

3. 标准与认证组织

例如Connectivity Standards Alliance和Thread Group，负责标准、认证、互操作测试和生态推动。

4. 生态与平台公司

提供Controller、App、语音入口、自动化、账号体系，有时也提供Border Router能力。

5. 集成商、零售商、安装商和服务商

决定哪些组合真正被卖出去、装进家庭、长期维护和替换。

用户买的是一件产品，背后的服务链可能很长。

Matter 1.6改变了体验，但没有取消“核对角色”这一步

2026年6月17日发布的Matter 1.6，是理解当前市场的一个重要时间点。

CSA将1.6描述为聚焦功能改进的版本，而不是大幅扩展设备类别。它加入或强化了基于NFC的配网方式、多生态设备管理协作、更加情境化的控制，以及设备能力、运行状态和安全信息在不同生态间的表达。

对买家而言，这不意味着“永远等最新版本”。

更实际的是：

  • 核对你真正购买的商品实现了哪个Matter版本和哪些功能；
  • 核对你使用的生态是否真正暴露这些能力；
  • 核对认证针对的是不是你手里这台设备/固件；
  • 不要假设标准发布以后，所有旧设备会自动获得同样能力。

标准升级速度和终端固件、零售库存速度并不一致。

买新Hub之前，先把家庭现有架构画出来

真正有用的市场地图，不是从“买什么品类”开始，而是从家庭现状开始。

写下：

**生态：**家庭真正长期使用哪些App、语音和平台？

**常开基础设施：**哪些音箱、屏幕、路由器、Hub、Bridge一直通电？

**无线协议：**现有设备分别用Wi‑Fi、Thread、Zigbee、Z-Wave、Bluetooth还是私有网络？

**关键自动化：**哪些规则在断网时也必须继续？

**远程要求：**哪些设备必须在外面也能控制？

**旧资产：**哪些设备更换成本高、施工麻烦，不值得重买？

**支持寿命：**哪些Hub或Bridge还在持续获得安全更新？

画清楚以后，新Hub就变成“补架构缺口”，而不是“再收藏一个盒子”。

三种真实购买情景

情景A：新公寓，设备很少

家庭没有历史包袱，只准备装灯、传感器、门锁和温控。

更简单的方案可能是：先确定一个主要生态，保证它拥有Matter Controller和需要的Thread Border Router角色，再购买兼容、认证明确的设备。

在真正需要之前，多加一个传统Hub未必产生价值。

情景B：已经有大量Zigbee设备的家庭

几十个传感器和灯仍然好用。

仅仅为了“全部Matter化”就一次性替换，成本很高，也未必改善体验。

一个可靠Bridge如果能够把主要能力暴露给新生态，可以保护原来的投入。重点是提前确认：哪些能力能映射，哪些功能仍然留在原厂App。

情景C：更看重隐私和断网韧性的家庭

用户要求灯光、传感器、温控等关键自动化在互联网故障时仍能运行。

采购重点就必须变成依赖关系：自动化到底在哪个Controller执行、哪些功能一定要云、有没有合适的本地接口、账号或云故障以后基础控制是否保留。

一个协议Logo无法替代这些答案。

卖家最应该停止的几种过度承诺

市场越复杂，模糊宣传越伤信任。

尤其避免：

  • 只写“无需Hub”，却不解释仍然需要哪个Controller或Border Router；
  • 写“离线可用”，实际只有开关功能离线；
  • 写“支持Matter”，却不说明具体功能和固件；
  • 写“未来可用十年”，却没有支持周期；
  • 写“一个App控制全部”，但高级功能仍然必须回原厂App。

越精确的兼容性说明，越能减少售后和退货。

买家五分钟协议测试

购买前回答七个问题：

  1. 终端本身使用什么无线协议？
  2. 是否支持Matter，具体暴露哪些功能？
  3. 哪台设备承担Matter Controller？
  4. 如果使用Thread，Thread Border Router在哪里？
  5. 是否有Bridge在翻译旧网络？
  6. 哪些关键功能依赖互联网或厂商云？
  7. 厂商停止支持以后，哪些本地功能还在？

商品页如果无法让你回答这些问题，就把这种不确定性直接算进成本。

用一句话总结这个市场

智能家居Hub市场没有消失，而是在被拆成更清楚的角色：

Controller、Border Router、Bridge、无线网络、应用标准、云服务和用户界面。

Matter和Thread正在减少一部分互操作摩擦，尤其是在厂商认真实现标准的情况下，但它们不会取消系统架构。

真正理解这些角色的买家，可以少买不必要的盒子、保留更多已有设备，也更容易问清可靠性、隐私、支持寿命和长期成本。

这才是当前“中枢与协议”真正值得看的市场地图。

资料来源

相关阅读