企业官网建设流程全解析

connectedhomeip ESP32 平台 Matter OTA 实战：OTA 镜像生成、Requestor/Provider 配置与加密、Delta 升级

【免费下载链接】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

本篇以 docs/platforms/esp32/ota.md 为核心，系统讲解 Matter (formerly Project CHIP) 在 ESP32 平台上完成整机 OTA 升级的全链路做法：如何生成带 Matter 头的 OTA 镜像、如何在 ESP32 应用上使能 OTA Requestor 并接入 OTA Provider，以及如何完成加密 OTA 与 Delta OTA。读完后，你可以独立完成从密钥生成、镜像加密/打差、添加 OTA 头到设备端查询下载、应用重启的完整升级验证，并能对照 OTA 助手实现 理解设备端的初始化与下载链路。

一、整体角色与升级链路

Matter OTA（Software Update 框架）在设备端分为两个角色：

• OTA Provider（OTA 提供方）：负责存储并提供 OTA 镜像。仓库中提供独立的 Provider 示例（早期文档中路径为ota-provider-app，当前仓库已归并到 OTA Provider 示例目录，并附有 使用说明）；
• OTA Requestor（OTA 请求方）：运行在待升级设备（如 ESP32 应用）上，负责向 Provider 查询、下载镜像、校验并应用。ESP32 示例（all-clusters-app、lighting-app、ota-requestor-app 等）通过 ESP-IDF Kconfig 选项CONFIG_ENABLE_OTA_REQUESTOR使能该能力。

一次典型的升级流程是：设备入网（commissioning）→ Requestor 向 Provider 查询（QueryImage）→ 下载镜像 → 发送 ApplyUpdateRequest 应用镜像 → 设备重启生效。以下各节按“生成镜像 → 使能设备 → 部署 Provider → 触发查询”的顺序展开，全部步骤与 官方 ESP32 OTA 文档 保持一致，并补充了仓库内的源码佐证。

二、生成 Matter OTA 镜像

2.1 通过构建配置直接生成

最简便的方式是在 ESP32 工程构建时使能CONFIG_CHIP_OTA_IMAGE_BUILD配置项。构建完成后，build目录下会生成名为<project name>-ota.bin的 OTA 镜像，该镜像可直接用于 OTA Provider 应用。

需要注意软件版本号的正确设置：使用CONFIG_DEVICE_SOFTWARE_VERSION与CONFIG_DEVICE_SOFTWARE_VERSION_NUMBER配置项设置软件版本。OTA 协议依赖SoftwareVersion比较来判定是否有可用更新，若版本号设置错误，Requestor 可能拒绝下载相同或更低版本。

2.2 使用 ota_image_tool.py 脚本生成

Matter OTA 镜像也可以不依赖整机构建，通过 ota_image_tool.py 脚本为任意应用二进制文件追加 Matter OTA 头（vendor-id、product-id、software-version 及数字签名/摘要信息）。后文的加密 OTA 与 Delta OTA 流程中均会用到它的create子命令，示例形如：

src/app/ota_image_tool.py create --vendor-id 0xFFF1 --product-id 0x8000 \ --version 2 --version-str "v2.0" -da sha256 \ lighting-app-encrypted.bin lighting-app-encrypted-ota.bin

其中-da sha256指定使用 SHA-256 作为镜像的摘要算法（delta 模式下 Requestor 端依赖摘要校验差分包）。

三、使能 OTA Requestor（ESP32 设备端）

3.1 配置与构建

• 确保CONFIG_ENABLE_OTA_REQUESTOR配置项已使能，即可启用 OTA Requestor 功能；
• 按文档说明，目前 all-clusters-app、lighting-app 与 ota-requestor-app 支持 OTA Requestor；其中 ESP32 版 ota-requestor 示例位于 examples/ota-requestor-app/esp32，其构建基线可参考同目录的 sdkconfig 默认配置；
• 构建并烧录任一支持的应用，然后完成配网（commissioning）。

3.2 源码层面的初始化链路

从源码结构看，使能该配置后，设备端的 OTA 能力集中在 examples/platform/esp32/ota/ 目录中实现：

• CommonDeviceCallbacks.cpp 中，设备事件回调在收到kDnssdInitialized（mDNS/DNS-SD 初始化完成）事件时，在#if CONFIG_ENABLE_OTA_REQUESTOR保护下调用OTAHelpers::Instance().InitOTARequestor()，也就是说 OTA Requestor 的初始化时机与网络栈就绪绑定；
• OTAHelper.cpp 的InitOTARequestor()负责装配整套 Requestor 组件：DefaultOTARequestor（协议核心）、DefaultOTARequestorStorage（基于持久化存储的属性存储）、ExtendedOTARequestorDriver的自定义派生类CustomOTARequestorDriver（用户层/同意策略）、BDXDownloader（下载器）与OTAImageProcessorImpl（镜像处理器）。下载器通过SetImageProcessorDelegate()与镜像处理器挂接，gImageProcessor又通过SetOTADownloader()反向持有下载器句柄。

此外，OTAHelper.cpp 还注册了 shell 调试命令OTARequestor，提供三个子命令，便于在设备串口控制台直接观察/干预升级行为：

userConsentState <granted/denied/deferred> # 设置 QueryImage 的用户同意状态 requestorCanConsent <true/false> # 设置 Requestor 是否“可同意” PeriodicQueryTimeout <seconds> # 设置周期性查询 Provider 的超时（秒）

这对应ExtendedOTARequestorDriver的CanConsent()机制：CustomOTARequestorDriver::CanConsent()优先读取 shell 设置值，未设置时回落到基类默认实现，从而可在调试阶段模拟用户同意/拒绝升级的场景。

四、部署 OTA Provider

为任意一个 OTA Provider 应用完成构建、入网，并安装合适的访问控制列表（Access Control List），使 Requestor 所在 Fabric 的设备允许向该 Provider 发起 OTA 集群请求。文档给出的 Provider 选项为：

• Linux OTA Provider（对应当前仓库 OTA Provider 示例，Linux 构建入口 providers/README.md）；
• ESP32 OTA Provider（同目录，面向 ESP32 目标构建）。

Provider 与 Requestor 必须处于同一 Fabric（或访问控制允许跨 Fabric 的策略内）才能完成查询与传输。

五、触发 OTA 镜像查询

5.1 通过设备控制台操作

配网成功后，先读取 Requestor 的default-otaproviders属性，确认 Provider 是否已在列表中：

./out/debug/chip-tool otasoftwareupdaterequestor read default-otaproviders <REQUESTOR NODE ID> 0

若列表中没有目标 Provider，则写入default-otaproviders（JSON 数组，每项含fabricIndex、providerNodeID、endpoint）：

./out/debug/chip-tool otasoftwareupdaterequestor write default-otaproviders '[{"fabricIndex": 1, "providerNodeID": <PROVIDER_NODE_ID_1>, "endpoint": 0}, {"fabricIndex": 1, "providerNodeID": <PROVIDER_NODE_ID_2>, "endpoint": 0}]' <REQUESTOR NODE ID> 0

随后在 Requestor 设备控制台上按回车并输入查询命令：

>matter ota query

传输完成后，OTA Requestor 会向 OTA Provider 发送ApplyUpdateRequest命令请求应用镜像；OTA 镜像应用成功后设备会自动重启。

5.2 通过 chip-tool 直接触发

无需设备端交互时，可以直接用 chip-tool 向 Requestor 发送“Provider 已就绪”的公告（AnnounceOTAProvider），Requestor 收到该命令后会自动发起 OTA 镜像查询：

./out/debug/chip-tool otasoftwareupdaterequestor announce-otaprovider <PROVIDER NODE ID> 0 0 0 <REQUESTOR NODE ID> 0

两种方式的区别在于触发主体：前者是设备本地主动查询（适合验证默认 Provider 列表配置），后者是由控制器侧公告 Provider 存在（更接近生产环境由云端/网关触发升级的模式）。

六、加密 OTA（Encrypted OTA）

ESP32 支持传输加密的 OTA 镜像。当前应用镜像可基于RSA-3072 密钥对进行加解密：Provider 下发密文镜像，设备端用私钥解密后再进入常规校验/应用流程。

6.1 固件侧改动

使能 OTA Requestor 与加密 OTA 两个配置项：

CONFIG_ENABLE_OTA_REQUESTOR=y CONFIG_ENABLE_ENCRYPTED_OTA=y

应用需要把密钥对提供给 OTA 镜像处理器，调用InitEncryptedOTA()API 完成解密初始化。这一点在仓库源码中有直接体现：OTAHelper.cpp 在#if CONFIG_ENABLE_ENCRYPTED_OTA下将编译期内嵌的esp_image_encryption_key.pem私钥（通过汇编符号_binary_esp_image_encryption_key_pem_start/_end从二进制段读取为CharSpan）传给gImageProcessor.InitEncryptedOTA(sOTADecryptionKey)。源码中明确警告：该“把私钥嵌入固件”的写法仅用于测试，不可直接用于生产场景。

6.2 生成加密 OTA 镜像的步骤

1. 生成或复用 RSA-3072 密钥对：

   openssl genrsa -out esp_image_encryption_key.pem 3072

   从密钥对中提取公钥：

   openssl rsa -in esp_image_encryption_key.pem -pubout -out esp_image_encryption_public_key.pem

2. 使用 ESP 官方 idf-extra-components 组件中的esp_enc_img_gen.py脚本加密应用二进制（注意：该脚本位于 ESP 组件仓库，不在本仓库内）。用公钥加密 OTA 镜像：

   python3 esp_enc_img_gen.py encrypt lighting-app.bin esp_image_encryption_public_key.pem lighting-app-encrypted.bin

   可选地，也可以在构建流程中使用 CMake 函数create_esp_enc_img()自动加密，仓库中 lighting-app/esp32/main/CMakeLists.txt 即为现成示例：

   create_esp_enc_img(${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}.bin ${project_dir}/esp_image_encryption_public_key.pem ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}-encrypted.bin app)

3. 为加密后的镜像追加 Matter OTA 头：

   src/app/ota_image_tool.py create --vendor-id 0xFFF1 --product-id 0x8000 \ --version 2 --version-str "v2.0" -da sha256 \ lighting-app-encrypted.bin lighting-app-encrypted-ota.bin

4. 将lighting-app-encrypted-ota.bin提供给 OTA Provider 应用即可分发。

设备端收到密文镜像后，由OTAImageProcessorImpl在InitEncryptedOTA()注入的私钥配合下完成解密，再按标准流程校验、写 Flash 并在 ApplyUpdate 后重启切换到新镜像。

七、Delta OTA（差分包升级）

Delta OTA 使用**压缩差分包（patch）**代替完整固件进行空中升级。相比全量包，差分包体积更小，可缩短下载时间与流量消耗；同时“补丁”无需额外存储分区，降低了 Flash 资源压力。

7.1 固件侧改动

使能 OTA Requestor 与 Delta OTA：

CONFIG_ENABLE_OTA_REQUESTOR=y CONFIG_ENABLE_DELTA_OTA=y

7.2 生成 Delta 升级镜像的步骤

1. 差分包生成基于 Python 3.6+ 的二进制差分编码，先安装detools：

   pip install detools>=0.49.0

2. 生成差分包。该脚本来自 ESP 组件管理器安装的espressif__esp_delta_ota组件（构建后位于工程的managed_components下，不在本仓库内）：

   python managed_components/espressif__esp_delta_ota/examples/https_delta_ota/tools/esp_delta_ota_patch_gen.py --chip <chip> --base_binary <base-binary> --new_binary <new-binary> --patch_file_name <patch-file-name.bin>

   其中--base_binary为设备当前运行的基线固件，--new_binary为待升级固件，--patch_file_name为输出的差分包文件名。

3. 为差分包追加 Matter OTA 头：

   src/app/ota_image_tool.py create --vendor-id 0xFFF1 --product-id 0x8000 --version 2 --version-str "v2.0" -da sha256 <patch-file-name.bin> lighting-app-delta-ota.bin

4. 将lighting-app-delta-ota.bin提供给 OTA Provider 应用。

设备端使能CONFIG_ENABLE_DELTA_OTA后，镜像处理器会将下载内容识别为差分包，在本地完成“基线 + 补丁”合成后写入 OTA 分区并切换，无需为完整新固件预留第二套空间。

八、加密 Delta OTA

加密 Delta OTA 是前两个特性的叠加：差分包先被 RSA-3072 加密，设备端解密后再进行差分解压与合成。

固件侧需要同时使能三个配置项：

CONFIG_ENABLE_OTA_REQUESTOR=y CONFIG_ENABLE_DELTA_OTA=y CONFIG_ENABLE_ENCRYPTED_OTA=y

镜像制作流程依次复用前述各节的步骤：

1. 按“加密 OTA”一节的步骤生成 RSA-3072 密钥对（openssl genrsa -out esp_image_encryption_key.pem 3072，并提取公钥），用于构建二进制；
2. 按“Delta OTA”一节的esp_delta_ota_patch_gen.py步骤生成差分包；
3. 用公钥对差分包执行加密（esp_enc_img_gen.py encrypt ...）；
4. 使用src/app/ota_image_tool.py create ...追加 Matter OTA 头后，交给 OTA Provider 分发。

九、实践要点与适用边界

• 适用平台：本指南针对 ESP32 平台（基于 ESP-IDF 构建），文档中的CONFIG_*均为 ESP-IDF Kconfig 配置项，可通过menuconfig、sdkconfig.defaults（如 ota-requestor-app/esp32/sdkconfig.defaults）或构建参数使能；
• 版本号一致性：CONFIG_DEVICE_SOFTWARE_VERSION/CONFIG_DEVICE_SOFTWARE_VERSION_NUMBER必须与 OTA 镜像头中的--version保持递增关系，否则 Requestor 的版本比较会导致更新被拒绝；
• 密钥管理：把私钥嵌入固件的做法（参见 OTAHelper.cpp 的注释与实现）源码中已明确标注仅为示例，生产环境应将私钥置于安全存储或安全元件中，避免随镜像泄露；
• 组件依赖：esp_enc_img_gen.py（加密）与esp_delta_ota_patch_gen.py（差分）均来自乐鑫idf-extra-components/组件管理器生态，构建前需确认相应组件已安装；
• 访问控制：Provider 与 Requestor 之间的 OTA 集群调用受 Fabric 访问控制约束，部署 Provider 时务必安装正确的 ACL，这是文档中明确要求的前置步骤。

按照以上流程，即可完成从镜像制作、设备使能、Provider 部署到触发升级的完整闭环，并可借助设备端OTARequestorshell 命令对同意策略与周期查询参数进行调试观测。

【免费下载链接】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