返回博客列表
Matter

Matter 1.6 正式发布:从设备互联到生命周期管理,模组厂商与 OEM 需要关注哪些变化?

Matter 1.6 正式发布,重点不再只是设备互联,而是进一步增强设备配置、多生态协同、安全管理以及生命周期运营能力。本文分析 Matter 1.6 中 NFC-Based Commissioning、Joint Fabric、设备能力表达、安全事件历史等关键变化,以及这些更新对模组厂商和 OEM 产品设计、量产部署和长期运营的影响。

产品线
IoT 安全 
专题
Matter 生态
发布时间
2026-08-07
阅读时间
15
分钟阅读

Matter 1.6 为什么值得关注?

随着智能家居、智能楼宇以及物联网设备规模持续增长,行业关注点正在从“设备能否连接”逐渐转向“设备如何被高效部署、安全管理以及长期运营”。

近日,连接标准联盟(Connectivity Standards Alliance,CSA)正式发布 Matter 1.6。相比此前版本,Matter 1.6 的重点并不是增加大量新的设备类别,而是围绕设备配置体验、多生态协同管理、设备能力表达、设备自主协同、安全事件管理以及设备身份维护等方向进行了增强。

对于普通消费者而言,这些变化可能不会立即体现在产品功能上;但对于芯片厂商、无线模组厂商、方案商以及 OEM 企业而言,Matter 1.6 的更新将直接影响产品定义、硬件设计、SDK 开发、设备认证以及量产部署流程。

如果说 Matter 早期版本主要解决的是“不同品牌设备如何连接和互通”,那么 Matter 1.6 正进一步解决“设备如何被配置、管理、维护以及持续保证安全可信”。

从产业链角度来看,Matter 正逐渐从一个设备互联协议,演变为支撑智能设备全生命周期管理的重要技术基础。

基于 NFC 的设备配网(NFC-Based Commissioning):从安装后配置走向预配置部署

Matter 1.6 增强了基于 NFC 的设备配网能力(NFC-Based Commissioning),进一步扩展了设备初始化和部署方式。相比此前基于二维码(QR Code)或手动输入码(Manual Code)的方式,Matter 1.6 的重要变化在于,NFC 不只是承载设备配置信息的辅助方式,而能够支持更完整的配网流程。

在 Matter 1.4.1 中,NFC 已支持携带配网引导信息(Onboarding Payload),但仍需要依赖 Bluetooth LE 完成后续配网流程。Matter 1.6 进一步增强 NFC 配网能力,使设备能够通过近场通信完成更完整的初始化流程。

这一能力最大的产业价值在于:对支持 NFC-Based Commissioning 的设备,可以在设备安装前甚至主电源接入前完成初始化。

例如:

  • 智能灯泡可以在出厂、仓储或安装前完成预配置,到现场后直接安装使用;
  • 墙壁开关可以在接入市电之前完成设备初始化;
  • 酒店、公寓、智能楼宇等大型项目可以批量完成设备配置,提高部署效率。

相比传统二维码方式,NFC 还可以解决一些长期维护场景中的问题。例如,吸顶灯、墙壁开关、智能门锁等设备安装完成后,二维码可能位于设备背面或安装位置不可访问。当用户更换网络或重新配置设备时,通过 NFC 可以降低拆卸设备的需求。

对于模组厂商而言,NFC-Based Commissioning 不只是增加 NFC 接口支持,而需要结合 Matter 配网流程、安全通信以及设备身份管理能力进行设计,包括:

  • NFC 接口支持;
  • 安全数据交换;
  • 配网引导信息保护;
  • 设备凭证安全存储。

对于 OEM 而言,该能力将推动智能硬件部署模式从“现场安装后配网”向“生产预配置、现场快速部署”转变,更适用于智能楼宇、酒店、公寓以及大规模商业物联网场景。

联合 Fabric(Joint Fabric):推动智能设备多生态协同管理

传统 Multi-Admin 场景下,一个设备可能需要维护多个 Fabric 关系,不同生态分别建立授权关系,这会增加设备侧 Fabric 表、凭证以及访问控制信息的管理压力。

Matter 1.6 引入联合 Fabric(Joint Fabric)机制,进一步扩展 Matter 的多管理员能力(Multi-Admin),使多个经过授权的 Controller 能够基于同一个 Fabric 协同访问和管理设备。过去,智能设备更多采用单一生态控制模式。例如,用户购买智能设备后,通过某个平台 App 进行控制。除了提升多生态协同能力外,Joint Fabric 对设备端资源管理也具有重要意义。

Joint Fabric 通过共享 Fabric 架构,让多个经过授权的 Controller 基于同一 Fabric 协同管理设备,从而减少传统 Multi-Admin 模式下多个 Fabric 并存带来的凭证和资源管理压力。对于设备而言,加入 Joint Fabric 只占用一个 Fabric 容量,因此设备仍可以保留加入传统生态 Fabric 的空间。

对于芯片和模组厂商而言,这意味着 Matter 支持不仅需要关注协议功能是否实现,还需要评估:

  • Fabric 表容量;
  • 凭证存储空间;
  • 安全存储资源;
  • SDK 对多管理员场景的支持能力。

尤其对于资源受限 MCU 平台,Fabric 资源设计可能影响产品是否能够支持更复杂的商业部署场景。

但在商业应用场景中,一台设备往往需要多个角色参与管理。例如,在智能酒店中,房间内的灯光、空调和门锁设备既需要满足住客日常使用需求,也需要支持酒店后台统一管理,同时物业维护人员还需要在授权情况下进行设备维护。传统方式下,不同系统之间可能需要分别绑定设备,管理复杂度较高。Joint Fabric 提供了一种更加标准化的协同管理方式,使多个授权控制方能够共享设备访问能力。

对于模组厂商而言,需要关注 Matter SDK 对 Joint Fabric 场景的支持,包括 Fabric 凭证(Fabric Credential)管理、凭证安全存储、多管理员关系维护以及授权变化处理。对于 OEM 而言,设备管理逻辑需要从“谁可以控制设备”,升级为“谁可以在什么时间、以什么权限管理设备”。例如,酒店可以拥有长期设备管理权限,住客入住期间获得临时控制权限,维修人员获得限定时间的维护权限。当用户离店后,相关访问权限可以根据业务策略进行调整。这意味着 OEM 不仅需要关注设备连接能力,也需要考虑设备授权生命周期和后续运营管理能力。

温控器建议(Thermostat Suggestions):设备从执行命令走向自主决策

Matter 1.6 针对恒温器设备引入建议机制(Thermostat Suggestions),改变了传统“控制端发送指令,设备直接执行”的模式。

这些建议通常与恒温器支持的预设模式(preset)关联,并且恒温器可以结合用户偏好、当前环境以及已有操作决定是否执行。例如,在智能能源管理场景中,电力服务商可能希望用户在用电高峰期间降低空调负载。传统方式可能直接修改温度设置,而基于 Matter 1.6 的方式,恒温器可以根据用户是否允许节能策略、当前室内环境以及近期操作行为,判断是否接受该调整建议。

对于恒温器和 HVAC 厂商而言,需要关注设备逻辑和应用层对建议机制的支持。这也体现了 Matter 未来的发展方向:设备不仅执行控制命令,也能够结合自身状态参与智能协作。

设备功能和通信限制(Device Capability and Limits Communication):让设备准确表达自身能力

Matter 1.6 增强设备能力与限制描述机制,使设备能够更加准确地向控制端传递自身支持的功能以及限制条件。过去,生态平台通常根据设备类别判断功能。例如,同样是智能灯产品,不同型号可能具备完全不同的能力。有的型号支持开关、亮度调节和色温调节,而有的型号只支持基础开关功能。如果平台仅根据“智能灯”这一类别判断,就可能无法准确展示设备实际能力。

通过设备能力与限制描述机制,设备可以向控制端表达自身支持的功能和限制条件,使生态平台能够提供更准确的控制体验。

对于模组厂商而言,需要保证 Matter 数据模型和 SDK 能够灵活表达不同产品能力。对于 OEM 而言,该能力可以降低不同型号产品接入生态平台时的适配成本,使生态平台能够根据设备实际能力提供对应控制体验。

安全传感器事件历史记录(Security Sensor Event History):增强安全设备事件追踪能力

Matter 1.6 增强安全设备事件历史的标准化表达能力,使生态平台能够访问设备支持范围内的历史事件信息,让生态系统不仅可以获取设备当前状态,也能够了解过去发生过什么。过去,安全设备更多关注实时状态,例如门窗当前是否关闭、是否检测到移动或者是否处于报警状态。但在实际应用中,用户和管理平台往往还需要了解设备历史变化情况。

例如,智能门窗传感器过去只能告诉系统“当前门窗处于关闭状态”,而通过事件历史能力,设备能够以标准化方式向生态系统提供更丰富的安全事件信息,使平台不仅能够了解当前状态,也能够结合历史事件进行分析和管理。当用户发现异常情况时,可以通过历史记录判断是否存在异常访问。

对于模组厂商而言,需要关注设备事件历史信息的采集、管理以及 SDK 对相关数据模型的支持。对于 OEM 而言,该能力可以帮助安全设备从状态反馈设备进一步发展为具备事件追踪能力的智能终端。

未安装的烟雾和一氧化碳报警器(Unmounted State for Smoke and CO Alarms):提升安全设备状态透明度

Matter 1.6 针对烟雾报警器和一氧化碳报警器增加了未安装状态表达能力,使设备能够向生态系统报告自身是否处于有效安装状态。在实际使用过程中,安全设备可能仍然保持联网状态,但已经从安装位置移除,例如更换电池、装修改造或者临时维护。如果系统无法识别这种情况,可能会误认为设备仍然处于正常保护状态。

通过新的状态表达能力,报警器可以向生态系统报告当前是否处于有效安装状态。例如,用户拆下烟雾报警器进行维护后,智能家居系统可以识别设备当前处于未安装状态,并提醒用户重新安装,而不是继续认为设备能够正常提供安全保护。

该能力主要面向安全设备厂商,但也体现了 Matter 对设备实际运行状态表达能力的进一步提升。

分区证书吊销列表(Partitioned Certificate Revocation Lists):Matter 安全基础设施持续演进

值得注意的是,Matter 1.6 延续了此前版本在设备身份管理方面的演进方向。Matter 1.4.2 已基于 CRL 支持引入分区证书吊销列表机制,在传统 CRL 基础上,将撤销信息划分为更小、可独立更新的分区,以提升大规模设备环境下安全基础设施的扩展能力。

对于智能楼宇、酒店、公寓以及商业物联网等大规模部署场景,设备身份管理不再只是生产阶段的一次性流程,而需要覆盖设备整个生命周期,包括设备认证、凭证管理、安全更新以及撤销状态维护。

对于模组厂商而言,需要关注安全存储、证书生命周期管理以及 SDK 对相关安全机制的支持;对于 OEM 而言,需要建立覆盖生产、部署和运营阶段的设备身份管理体系。

Matter 1.6 对产业链意味着什么?

从产业链视角来看,Matter 1.6 的核心价值并不是简单增加设备类型,而是在设备生命周期关键环节进行增强。

  • 基于 NFC 的设备配网(NFC-Based Commissioning)提升设备初始化和部署体验,使设备配置流程更加适应实际安装环境;
  • 联合 Fabric(Joint Fabric)扩展多管理员协同管理能力,使 Matter 设备能够适应家庭之外更多商业应用场景;
  • 温控器建议(Thermostat Suggestions)推动设备从被动执行控制命令,向基于场景理解的主动控制决策演进;
  • 设备功能和通信限制(Device Capability and Limits Communication)提升设备能力表达准确性,降低生态兼容成本;
  • 安全传感器事件历史记录(Security Sensor Event History)增强安全设备事件追踪能力,提高设备状态可追溯性;
  • 未安装的烟雾和一氧化碳报警器能力提升安全设备状态透明度;
  • Matter 1.6 与此前版本安全机制形成连续演进,结合此前版本的安全机制,为大规模 Matter 设备长期运营提供基础支撑。

对于模组厂商和 OEM 来说,Matter 1.6 带来的最大变化,是产品开发逻辑正在从“支持 Matter 协议”转向“构建完整设备生命周期能力”。未来智能硬件竞争不仅体现在连接能力和协议兼容性,更体现在设备部署效率、生态协同能力、安全管理以及长期运营能力。

此外,Matter 1.6 也进一步推动设备感知能力和基于环境状态的智能交互能力发展,使智能设备能够结合环境状态参与更智能的协作,为未来环境感知型智能设备提供基础。

Matter 正从单纯设备互操作协议,向覆盖设备配置、安全身份和跨生态管理能力的基础标准演进。对于芯片、模组以及智能硬件企业而言,提前布局 Matter 1.6 相关能力,将有助于提升产品在智能家居、智能楼宇以及商业物联网场景中的适配能力和部署价值。

参考资料

Matter 1.6 版本实现了更直观的设置、多生态系统体验和情境驱动控制

Snowball 团队
团队成员
LinkedIn
Snowball Technology 成立于 2013 年,致力于通过可信、面向未来的安全基础设施,推动行业实现可扩展且可持续的发展。公司的核心团队来自 NXP 安全服务部门,在设备安全领域拥有十余年的深厚经验。目前,Snowball Technology 拥有超过 100 名员工,其中三分之二以上为研发人员。公司已通过 ISO 9001、ISO 14001 和 ISO 27001 等国际标准认证。