用户-节点映射
说明
在 ESP RainMaker 中，Claiming 是节点首次连接 RainMaker 云后执行的第一步，随后进行用户-节点映射。
- Claiming 将设备注册到云端并分配一个唯一的节点 ID，但不会将设备关联到任何用户。
- 在对设备进行远程监控和控制前，必须首先将节点映射到用户，确保只有特定用户拥有其访问权限。
- 用户-节点映射过程只能通过 ESP RainMaker 手机应用或 CLI 执行，因为只有 ESP RainMaker 手机应用或 CLI 能够驱动将节点分配给用户的工作流。
ESP RainMaker 支持 两种用户-节点映射方法，可在编译时选择：
- 基于挑战-响应机制 (Challenge-Response) 的映射：一种较新且更安全的方法，推荐用于生产环境。可在 menuconfig 中通过
CONFIG_ESP_RMAKER_ENABLE_CHALLENGE_RESPONSE启用。 - 基于 MQTT 的映射：默认方法，使用共享密钥进行节点到云的 MQTT 通信。
基于挑战-响应机制的映射（推荐）
信息
该方法更加安全可靠，推荐在生产固件时使用，需要配合 ESP RainMaker iOS 应用 v3.4.0+ 或 Android 应用 v3.7.0+。
核心优势
- 安全性高：采用加密的挑战-响应机制，而非共享密钥
- 提前映射：映射操作在发送 Wi-Fi 凭证前完成，确保节点在连接网络前已添加至用户账号
- 无需联网：节点无需连接网络即可完成映射
- 流程简化：映射过程中无需节点与云端进行直接的 MQTT 通信
工作流程
- 发起映射：客户端通过安全的已登录会话，向 RainMaker 云端发起映射流程。
- 生成挑战：云端返回一个请求 ID (Request ID) 和一个加密挑战 (cryptographic challenge)。
- 转发挑战：客户端通过蓝牙 (BLE) 将该挑战发送至 ESP32 节点。
- 生成响应：ESP32 使用自身凭证生成挑战响应 (challenge-response)，并将其与节点 ID (Node ID) 一同返回给客户端。
- 验证操作：客户端将节点 ID、挑战响应及请求 ID 转发至云端。
- 状态确认：云端验证响应内容，并返回映射状态（成功/失败）。
前提条件
- 此方法需要确保 MQTT 凭证可用，所以使用此方法前，节点必须完成 Claiming 操作。
- 在私有部署场景中，节点凭证已预先烧录，此条件会自动满足。
基于 MQTT 的映射
工作流程
-
在 Wi-Fi 配置期间，客户端通过 BLE 将用户 ID 和随机生成的密钥发送到节点，节点随后将节点 ID 返回给客户端。
-
客户端通过安全的登录会话将节点 ID 和密钥发送到 RainMaker 云，RainMaker 云会返回一个请求 ID。
为什么客户端不直接将用户 ID 发送到 RainMaker 云？因为用户 ID 是从会话信息中由云提取的。由于请求发生在登录会话中，云已经检测到请求的发起方，从而避免额外的数据传输，降低了安全风险。
-
通过安全的 MQTT，节点还会发送节点 ID、用户 ID 和密钥到 RainMaker 云。
说明步骤 2 和步骤 3 顺序无强制要求，不会影响流程。
-
客户端使用请求 ID 查询 RainMaker 云以获取请求状态。根据请求状态，有三种可能的响应：
状态 描述 已确认 (Confirmed) 如果 RainMaker 云从客户端和节点接收到匹配的信息，则映射成功 超时 (Timed Out) 如果请求发出一分钟后仍未从另一端接收到匹配的信息，则触发超时 请求中 (Requested) 映射仍在进行中，需继续查看
适用场景对比
| 特性 | 挑战-响应 | MQTT |
|---|---|---|
| 安全机制 | 采用加密的挑战-响应机制，更高安全性 | 采用共享密钥，标准安全性 |
| 网络依赖 | 节点无需连接网络 | 节点需与云端建立 MQTT 连接 |
| 映射时机 | 发送 Wi-Fi 凭证前 | Wi-Fi 连接建立后 |
| 版本要求 | iOS v3.4.0+, Android v3.7.0+ | 任意版本 |
| 生产环境 | ✅ 推荐 | ✅ 支持 |
| 私有部署 | ✅ 具有预烧录凭证 | ✅ 兼容 |
| 配置难易 | 步骤更少，更简单 | 需节点与云端通信，相对复杂 |
推荐做法
对于新项目及生产环境部署，建议使用基于挑战-响应的映射。若需兼容任意版本的应用，或对基于 MQTT 的通信有特定需求，则可使用基于 MQTT 的映射。