Matter Fabric Synchronization 实战指南基于 connectedhomeip 的跨 Fabric 设备同步【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeipFabric Synchronization织物同步是 Matter 协议中让不同生态系统Ecosystem之间无需逐一人工配网即可共享设备的能力。本文以 connectedhomeip 仓库中的 fabric_synchronization_guide 为核心结合 fabric-sync 示例应用 的源码与构建脚本完整讲解 Fabric-Admin / Fabric-Bridge 示例的构建、双机部署、反向配网、设备同步与移除的端到端流程帮助你快速搭建并验证跨 Fabric 的设备同步演示环境。图为两个 Fabric Synchronizing AdministratorE1 / E2分别运行 Fabric-Admin 与 Fabric-Bridge-App通过同步流程共享开关与灯光等终端设备的架构示意来源docs/guides/images/matter_fabric_synchronization.png。Fabric Synchronization 核心概念Fabric Synchronization 定义了一套机制让多个生态系统/控制器之间相互通信从而简化终端设备从一条 Fabric 到另一条 Fabric 的配网过程——用户无需对每一台终端设备重复执行配网操作。在 connectedhomeip 中该特性的示例应用位于 examples/fabric-sync其中包含两个核心角色Fabric-Admin管理员实现 Fabric Administrator 角色负责与对端的 Fabric-Bridge 通信推动 Fabric Synchronization 流程。其实现位于 examples/fabric-sync/admin内部包含FabricAdmin、PairingManager、DeviceManager、DeviceSynchronization、BridgeSubscription、CommissionerControl、FabricSyncGetter、IcdManager、StayActiveSender、UniqueIdGetter等组件模块。Fabric-Bridge桥接器实现 Aggregator聚合器设备类型满足 Fabric Synchronization 条件通过**动态端点Dynamic Endpoints**演示端到端的设备同步。其实现位于 examples/fabric-sync/bridge包括Bridge、FabricBridge、CommissionerControlDelegate等。关键约束与特性Fabric-Admin 与 Fabric-Bridge-App 必须运行在同一台物理设备上两者通过 RPC 方式互相通信。Fabric Synchronization 可以从任意一侧发起发起方共享自身设备的一方担任Commissioner角色接收方接收被共享设备的一方担任Commissionee角色。这种双向灵活性使得同步过程顺畅高效。构建示例应用构建 Linux 主机版在当前仓库根目录执行要求 Linux 主机环境官方文档注明已在 Ubuntu 22.04 LTS (aarch64) 上测试source scripts/activate.sh ./scripts/build/build_examples.py --target linux-x64-fabric-sync-no-ble build构建产物fabric-sync即为集成了 Fabric-Admin 与 Fabric-Bridge 的单一可执行文件。构建 Raspberry Pi 4RP4版RP4 为 aarch64 架构官方推荐在 Docker 交叉编译环境中构建。先拉取交叉编译镜像并进入容器docker pull ghcr.io/project-chip/chip-build-crosscompile:211 docker run -it -v ~/connectedhomeip:/var/connectedhomeip ghcr.io/project-chip/chip-build-crosscompile:211 /bin/bash进入容器后在挂载的源码目录内执行cd /var/connectedhomeip git config --global --add safe.directory /var/connectedhomeip ./scripts/run_in_build_env.sh \ ./scripts/build/build_examples.py \ --target linux-arm64-fabric-sync-no-ble-clang \ build构建完成后将二进制传输到 RP4 设备上scp ./fabric-sync ubuntuxxx.xxx.xxx.xxx:/home/ubuntu说明原指南中引用的./examples/fabric-admin/scripts/run_fabric_sync.sh与examples/fabric-admin、examples/fabric-bridge-app目录在当前仓库快照中并不存在Fabric Sync 示例已统一收敛为 examples/fabric-sync 目录下的单一fabric-sync可执行文件可直接运行无需额外脚本包装。引导 Fabric Sync 演示环境在 Linux 上引导两个生态系统演示需要两台 Linux 机器分别代表Ecosystem 1E1与Ecosystem 2E2。在两台机器上分别启动fabric-syncsudo rm -rf /tmp/chip_* # 清理旧的 KVS / 状态文件 cd ~/connectedhomeip/ out/debug/fabric-sync原指南中在 E1、E2 上分别执行./examples/fabric-admin/scripts/run_fabric_sync.sh来启动同步脚本在当前仓库中该脚本已被直接运行fabric-sync可执行文件的方式取代。应用启动后会初始化两部分bridge::BridgeInit()初始化桥接端Aggregator 设备admin::FabricAdmin::Instance().Init()初始化管理端并将日志重定向写入/tmp/fabric_sync.log参见 examples/fabric-sync/main.cpp 中的ApplicationInit()。在 RP4 上引导分别 SSH 登录两台 RP4代表 E1 与 E2然后运行之前 scp 过去的二进制ssh ubuntuxxx.xxx.xxx.xxx # Password: password ./fabric-sync两台机器的引导步骤完全一致区别仅在于它们各自的 IP 与端口参数会在后续命令中作为对端地址使用。运行 Fabric Sync 演示第 1 步Fabric Sync Setup互相配网Fabric Sync Setup 的目标是让两个支持 Fabric Synchronization 的生态系统把对方的 Fabric Bridge 节点配网进自己私有的 Fabric。在E1 的 Fabric-Admin 控制台中将 E1 的本地桥接器以节点 ID 1 加入本地 Fabricfabricsync add-local-bridge 1将 E2 的桥接器以节点 ID 2 配入 E1参数依次为 setup PIN 码、E2 Fabric-Bridge 的 IP 与端口fabricsync add-bridge 2 setup-pin-code e2-fabric-bridge-ip e2-fabric-bridge-port该命令会触发**反向配网Reverse Commissioning**流程。数秒后E1 控制台应看到如下消息表示 E1 的本地桥接到已在 E2 的 Endpoint 2 上成功配网 A new device is added on Endpoint 2.注意只需将本地桥接器加入对端生态系统即可触发 Fabric Sync Setup。上例中该流程由 E1 发出的add-bridge命令发起对端E2是否把本地桥接器加入 E1 是可选的。在示例应用的交互 shell 中对应命令为app add-bridge完整用法参见 examples/fabric-sync/shell/ShellCommands.cppapp add-bridge node-id setup-pin-code device-remote-ip device-remote-port第 2 步将 Light 示例配到 E2由于 Fabric-Bridge 本身也是一个 Matter Server如果它与 Light 示例运行在同一台机器上会发生端口/服务冲突。因此Light 示例必须运行在与 Fabric-Admin / Fabric-Bridge 不同的物理机器上再通过 Fabric-Admin 在源端将其配网。规避同机冲突的变通方案若必须在同一台机器上运行多个 Matter Server可以为每个应用分配不同的端口与唯一的 Key-Value StoreKVS路径。示例以独立 discriminator / passcode、端口与 KVS 启动 Light App./out/linux-x64-light-clang/chip-lighting-app --discriminator 3843 --passcode 20202023 --secured-device-port 5543 --unsecured-commissioner-port 5553 --KVS /tmp/chip_kvs_lighting_app各参数含义参数值示例说明--discriminator3843设备发现标识符用于配网时定位目标设备--passcode20202023配网使用的 Setup PIN 码--secured-device-port5543设备监听安全消息的 UDP 端口--unsecured-commissioner-port5553监听未加密 commissioner 消息的 UDP 端口--KVS/tmp/chip_kvs_lighting_app该应用的持久化 Key-Value Store 路径必须与其它应用唯一区分接着在 Fabric-Admin 控制台使用 payload 配 Light 示例为节点 ID 3pairing already-discovered 3 20202021 ip 5543设备成功加入后E2 侧会看到新分配的节点 ID New device with Node ID: 0x3 has been successfully added.同时当新设备从 E1 被添加到 E2 时你也会收到通知 A new device is added on Endpoint 3.第 3 步将 Light 示例同步回 E1Light 示例在 E2 配网成功后即可使用 E2 上新分配的动态端点 ID将该设备同步到 E1fabricsync sync-device endpointid对应 shell 命令为app sync-device endpointid见 examples/fabric-sync/shell/ShellCommands.cpp其背后由DeviceSynchronization模块驱动将源端生态系统中已配网的动态端点设备镜像到目标生态系统。同步完成后可以在两个生态系统中分别开关灯验证状态同步从 E1 控制node-id为 E1 视角下的节点 IDonoff on node-id 1 onoff off node-id 1从 E2 控制使用 E2 分配的节点 IDonoff on node-id 1 onoff off node-id 1第 4 步从生态系统中移除 Light 示例解除配网即可将该设备从生态系统中移除pairing unpair node-id对应 shell 命令为app remove-device node-id。配接并同步商用 WiFi 开关除 Light 示例外还可以演示将 WiFi 商用开关同步到另一个生态系统。配接开关到 Fabric-Source在 Fabric-Source 控制台使用设备的 payload 配网支持 WiFi 配网模式参数为节点 ID、SSID、密码与 payloadpairing code-wifi node-id ssid passwd payload将开关同步到 E1开关在 E2 配网成功后使用 E2 上新分配的动态端点 ID 将其同步到 E1fabricsync sync-device endpointid开关控制与 Light 相同从 E1 / E2 两侧均可执行onoff on node-id 1 onoff off node-id 1移除开关pairing unpair node-id底层实现要点动态端点机制Fabric Synchronization 依赖动态端点实现运行时增减设备。由于 SDK 中端点通常由 .zap 文件静态定义为支持动态端点ZCL 属性存储机制需要额外保留NUM_DYNAMIC_ENDPOINTS个端点的空间。仓库提供了一组宏来声明动态属性、动态集群与动态端点详见 examples/fabric-sync/README.md属性列表DECLARE_DYNAMIC_ATTRIBUTE_LIST_BEGIN / DECLARE_DYNAMIC_ATTRIBUTE / DECLARE_DYNAMIC_ATTRIBUTE_LIST_END集群列表DECLARE_DYNAMIC_CLUSTER_LIST_BEGIN / DECLARE_DYNAMIC_CLUSTER / DECLARE_DYNAMIC_CLUSTER_LIST_END端点声明DECLARE_DYNAMIC_ENDPOINT(endpointName, clusterList)所有动态属性都被标记为MATTER_ATTRIBUTE_FLAG_EXTERNAL_STORAGE其读写必须由应用通过emberAfExternalAttributeReadCallback/emberAfExternalAttributeWriteCallback回调处理。管理端组件协作从源码结构看examples/fabric-sync/admin 中各模块分工明确FabricAdmin管理员主入口持有并协调各子管理器PairingManager负责设备配网add-device/pair-device与桥接器配网add-bridgeDeviceManager维护本地已配网设备的节点 ID 与动态端点映射DeviceSynchronization实现sync-device将设备同步到对端生态系统BridgeSubscription/DeviceSubscription订阅对端桥接器/设备状态变化CommissionerControl利用 Matter Commissioner Control 相关机制完成反向配网StayActiveSender/IcdManager面向 ICD间歇性连接设备的保活与同步支持。Shell 命令注册所有同步命令通过 examples/fabric-sync/shell 目录下的命令类AddBridgeCommand、AddDeviceCommand、PairDeviceCommand、RemoveBridgeCommand、RemoveDeviceCommand、SyncDeviceCommand注册到 CHIP Shellmain中通过Shell::RegisterCommands()挂载见 examples/fabric-sync/main.cpp。常见问题与注意事项同机冲突Fabric-Bridge 本身是 Matter Server与其它 Matter 示例共机运行会产生冲突。要么将终端示例放到独立物理机要么用不同的端口 唯一 KVS 路径规避如上文 Light 启动命令所示。KVS 唯一性多应用共机时--KVS路径必须各不相同否则持久化状态互相覆盖。脚本路径差异旧指南中的run_fabric_sync.sh脚本在当前仓库中已不存在直接运行构建出的fabric-sync可执行文件即可达到同样的引导效果。动态端点 IDsync-device必须使用目标生态系统中实际分配的动态端点 ID配网日志中的 A new device is added on Endpoint N 即为该 ID 的来源。通过上述步骤你可以在两台 Linux 主机或 RP4上完整复现 Matter 跨 Fabric 设备同步从双向桥接配网、反向配网到终端设备跨生态系统的共享、控制与移除并可直接阅读 examples/fabric-sync 与 fabric_synchronization_guide 两个文档交叉验证细节。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考