2.9 KiB
2.9 KiB
M06-C 协议适配器和消息幂等
- 日期:2026-06-22
- 起始 commit:
c96045f - 工程 commit:
e795cdb - ENGINEERING_DELTA=YES
- 子阶段状态:M06-C-R1 DONE;实物行为仍为 M06-G 外部阻塞
工程增量
- 实现
MqttTransport、JilianControlBoxAdapter、JilianSub1GLockAdapter、JilianSmartSocketAdapter。 - 严格保留
ConctolPower、Crldoor、CrlLED、PlayTTS、CtrlDevice等厂商拼写。 - Zod 校验控制箱读取/控电/门锁/TTS/LED/任务、Sub-1G 配对控制、插座读取/开关/本地任务。
- 建立 13 位命令 ID、命令持久化、发布状态、ACK/失败/超时状态推进。
- MQTT 消费校验 Topic、DeviceID 和 JSON;原始/标准化 payload 分开保存。
- QoS 1 重复消息只增加接收次数,不重复推进命令或设备状态。
- 非法 Topic、未知设备、非法 JSON/字段进入可去重死信表,消费循环不崩溃。
验证
- Windows
npm test与scripts/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 已 push,
HEAD == origin/main == e795cdb6935568611a5d27d78991bf9e7ee2f7df。
M06-C-R1 协议纠偏(2026-08-10)
- 工程 commit:
dabc656 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,并实测上述命令状态、配对、脱敏、事件和遗嘱落库。 - 工程提交已 push,
HEAD == origin/main == dabc656f6319235f1f35106da493d24ced37d19a。
资料边界
V5.6 已记录并固化两份厂商协议原件的审计差异,资料缺失不再构成外部阻塞。当前未具备的是实物、生产 DeviceID、MQTT 账号/ACL 和现场配线,继续登记在 M06-G。
后续
执行游标进入 M06-E-R1:智慧插座 Wire schema、标准化状态、保护事件和数据库告警纠偏。