Files
qipai/docs/devlogs/2026-06-22-M06-C-协议适配与消息幂等.md
T
2026-08-10 16:28:11 +08:00

2.9 KiB
Raw Blame History

M06-C 协议适配器和消息幂等

  • 日期:2026-06-22
  • 起始 commitc96045f
  • 工程 commite795cdb
  • ENGINEERING_DELTA=YES
  • 子阶段状态:M06-C-R1 DONE;实物行为仍为 M06-G 外部阻塞

工程增量

  • 实现 MqttTransportJilianControlBoxAdapterJilianSub1GLockAdapterJilianSmartSocketAdapter
  • 严格保留 ConctolPowerCrldoorCrlLEDPlayTTSCtrlDevice 等厂商拼写。
  • Zod 校验控制箱读取/控电/门锁/TTS/LED/任务、Sub-1G 配对控制、插座读取/开关/本地任务。
  • 建立 13 位命令 ID、命令持久化、发布状态、ACK/失败/超时状态推进。
  • MQTT 消费校验 Topic、DeviceID 和 JSON;原始/标准化 payload 分开保存。
  • QoS 1 重复消息只增加接收次数,不重复推进命令或设备状态。
  • 非法 Topic、未知设备、非法 JSON/字段进入可去重死信表,消费循环不崩溃。

验证

  • Windows npm testscripts/dev/windows/test-all.ps1:退出码 0。
  • WSL MySQL 8.4.9 原生临时副本:up → verify → down → up → verify 通过。
  • 迁移语句:up 102、verify 74、down 96。
  • 实测同一 ACK 投递两次:事件行 1 条、receive_count=2、命令只推进一次至 ACKED
  • 非法 Topic 实测进入 qipai_iot_dead_letters
  • 工程 commit 已 pushHEAD == origin/main == e795cdb6935568611a5d27d78991bf9e7ee2f7df

M06-C-R1 协议纠偏(2026-08-10

  • 工程 commitdabc656
  • PlayTTS 由友好 DTO 生成精确 vol/firstPlay/loop/speaker/style/speed/intona/id,并按原件范围校验。
  • AddDevice 只发送 time;首个无 subtype/subID 的 ACK 不提前结束配对,最终包才 ACK 并固化父子拓扑。
  • CtrlDevice 强制 subtype=14/15,凭据使用 value;密码为连续 6 位分组、卡号为连续 8 位十六进制分组,清空全部和恢复出厂均有平台超管二次确认。
  • 上行按命令判别结果;未知结果落 UNKNOWN_VENDOR_RESULT、失败命令、协议告警和死信,不崩溃、不误 ACK。
  • record 与命令凭据在命令、事件、死信持久化前哈希/脱敏;magstate/taskfinish/Poweron/connected 保持事件语义。
  • /devicewill/{DeviceID} 接受原始 close 并更新离线,不进入 JSON 解析死信。
  • Windows 后端全量 npm test 通过;WSL MySQL 8.4.10 原生副本完成 144 up、124 verify、140 down 的 up → verify → down → up → verify,并实测上述命令状态、配对、脱敏、事件和遗嘱落库。
  • 工程提交已 pushHEAD == origin/main == dabc656f6319235f1f35106da493d24ced37d19a

资料边界

V5.6 已记录并固化两份厂商协议原件的审计差异,资料缺失不再构成外部阻塞。当前未具备的是实物、生产 DeviceID、MQTT 账号/ACL 和现场配线,继续登记在 M06-G。

后续

执行游标进入 M06-E-R1:智慧插座 Wire schema、标准化状态、保护事件和数据库告警纠偏。