协议简述补充解析

来源：仓库根目录 协议简述.docx，已归档到 docs/protocols/协议简述.docx。

本文只记录该补充文档的可读内容和与当前实现的差异判断。原 DOCX 内容较短，主要描述 FFE1 数据通信服务下的控制/状态特征，以及一组 33 字节控制参数。

原文抽取

UUID	名称	说明
`FFE1`	数据通信服务	控制指令
`FFE4`	设备状态及 ADC 值	数据上报

UUID	名称	属性	说明
`FFE1`	`Command`	`Write+Read`	下发控制指令
`FFE4`	`Status`	`Read + Notify`	数据上报

注意：补充文档将 FFE1 同时写作“数据通信服务”和 Command 特征 UUID；这与当前代码中的 FFE1 服务、FFE4 命令特征、FFE5 状态特征不一致，需硬件侧确认最终 UUID 分配。

当前小程序 BLE 实现位于 miniprogram/services/ble/。它采用的是帧协议：

0xAA 0x55 | length | type | payload | XOR checksum

并且 setParams() 当前下发的 payload 是：

region_mask | wavelength | brightness | duration_ms(4B) | mode | seq

补充文档描述的 Command 更像“裸 33 字节参数块”，没有出现 0xAA 0x55 帧头、命令 type、seq、ACK 或 region_mask。当前因赶进度先以该 33 字节协议为准，旧帧协议暂作为历史兼容代码保留。

主要差异如下：

项目	当前代码/文档	补充文档	影响
命令写入格式	帧格式 `0xAA55 + length + type + payload + checksum`	33 字节参数块	需要确认设备固件实际接收哪一种格式
数据通信 UUID	`FFE1` 服务，`FFE4` 命令，`FFE5` 状态	`FFE1` 服务/Command，`FFE4` Status	UUID 表存在冲突，需要硬件确认
治疗参数模型	区域 mask + 单一波长 + 全局亮度	IO1-IO5 各自四种灯光强度 + 电流增益	当前 UI/协议无法表达每个 IO 的独立参数
时间字段	`duration_ms` 4 字节大端毫秒	保持时间 2 字节	时间单位、范围、字节序均需确认
状态上报	当前解析 14 字节状态	仅说明“设备状态及 ADC 值”	需要补齐 Status 字节表，尤其 ADC 字段
校验	当前 XOR 覆盖帧头/长度/type/payload	Byte33 为异或校验	需确认 Byte33 是否 XOR Byte1-Byte32

优先级从高到低：

FFE1、FFE4、FFE5 的最终含义：哪个是服务 UUID，哪个是 Command characteristic，哪个是 Status characteristic。
Command 写入时是否仍需要 0xAA 0x55 帧封装，还是直接写 33 字节参数块。
Byte33 XOR 校验范围：是否对 Byte1-Byte32 做 XOR，初始值是否为 0x00。
Byte31-Byte32 保持时间的单位：秒、100ms、分钟，或其他单位；以及字节序是否为高字节在前。
IO1-IO5 与面部区域/灯板通道的对应关系。
红灯、红外、紫外、暖黄光强的取值范围和含义：是否为 PWM、百分比、DAC 值，范围是 0-100 还是 0-255。
电流增益高/低字节的取值范围、字节序和单位。
Status/ADC 数据上报的完整字节布局：状态码、电量、温度、ADC 通道数、每通道字节序和单位。
是否存在开始、停止、查询状态、绑定等命令字；如果没有，33 字节写入是否同时承担“设置参数并启动”的语义。
是否需要 ACK/NACK；如果有，ACK 格式和错误码表是什么。