设计决策与故障经验
| 决策 | 原因 | 当前影响 |
|---|---|---|
| MQTT客户端订阅业务消息,HTTP回调仅认证授权 | 分清设备消息与连接授权;避免Broker数据库强耦合 | 更换Broker仍需适配其回调与ACL,不能声称已验证RMQTT |
| 复用BLE Core和官方Security 2 | 连接生命周期与应用协议分离,减少自研加密维护 | Core不是账号认领协议;端点发现、MTU与加密消息边界仍需应用处理 |
| 接受票据后释放BLE | ESP32 BLE/Security2与TLS共存造成内存峰值,曾导致WiFi成功后云端超时 | 手机转HTTP等待;未接受票据不应提前释放本次认领状态 |
| prepare/ready/commit/active持久屏障 | 消息重复、断电与账号变化需要可恢复边界 | 新epoch不能从普通消息创建,清理失败不可先ACTIVE |
| 执行前持久保留occurrence | 掉电后无法知道硬件动作是否已完成 | 宁可漏一次也不自动重放,不承诺物理恰好一次 |
| 定时编辑换新ID | 旧ID执行水位不能同时代表新任务 | 同ID改义云端/固件拒绝,纯启停保留水位 |
| 查询关联观察状态 | 迟到旧快照曾把已应用的新配置误判冲突 | 并发更新后旧查询不能写状态,真实回退仍由匹配查询处理 |
| 产品恢复目标参与归属清理 | 通用规则清了但独立继电器NVS曾恢复旧ON | 清理回调在持久屏障内严格提交OFF目标 |
| OSS客户端直连下载 | 服务器转发大工厂镜像放大延迟和流量 | 后端只授权签名,客户端验证哈希;不能靠公共桶解决 |
失败经验应体现在明确排障动作中:iOS缺claim先核对真实特征与缓存;WiFi常亮后认领超时查TLS、订阅与归属;OTA已回滚查新应用启动校验,不反复盲目升级;配置等待查原msgId与观察状态,而非调大所有超时。详见故障排查。
原始阶段设计与构建记录保留在归档,其中旧Topic、旧网络和兼容方案不作为现行配置。
