无限回声：一个状态镜像中的去重键缺失 Bug

背景

作者 Spencer Kittleson 在为新居搭建智能家居系统时，使用了 Tasmota 固件和 MQTT 协议将两个 Martin Jerry 品牌的智能开关配置为“虚拟三位开关”（Virtual 3-way switch）。这种配置的目标是：无论拨动哪一个开关，另一个开关的状态都会同步跟随，从而实现从不同位置控制同一盏灯的效果。

这套系统在正常运行数月后，经历了一次全屋断电重启。重启后，两个开关陷入了死循环：它们互相发送状态更新指令，导致继电器在黑暗中以极快的频率反复开合，发出类似“机枪”的咔哒声。作者通过查看日志，发现这是一个典型的“无限回声”（Infinite Echo）现象——设备应用了接收到的状态变更，却未更新用于抑制自身回声的去重键（Dedup Key），导致系统不断放大信号而非趋于稳定。

核心内容

1. 初始设计与“回声守卫”的失效

作者最初的实现逻辑非常直观：当开关 A 的状态改变时，发布 A 的新状态给开关 B，反之亦然。为了抑制回声，作者设计了一个基于变量 VAR1 的“回声守卫”机制。

核心规则逻辑如下：

Rule1 ON Power1#State!=%var1% DO Backlog VAR1 %value%; Publish cmnd/<peer>/Power %value% ENDON

理论逻辑：

1. 将上次执行操作的值存储在 VAR1 中。
2. 仅当 Power1#State（当前物理状态）与 VAR1 不同时，才发布命令给对端设备。
3. 对端设备接收命令并改变状态后，其状态变化会触发本地规则，但由于状态值与 VAR1 匹配（或预期匹配），规则不应触发，从而形成“单向一跳，随后安静”的效果。

这个设计在正常手动操作下运行良好，具有无需 IF 语句的优雅性，但在断电重启后彻底失效。

2. 故障排查：从猜测到日志实证

断电后，两个开关开始互相“ ping-pong ”。作者首先怀疑是经典的启动竞态条件（Boot Race）：两个设备同时启动，VAR1 为空，导致在启动窗口期内无法抑制回声。

作者尝试添加了一个“启动稳定守卫”：

Rule2 ON System#Boot DO Backlog Rule1 0; RuleTimer2 10 ENDON ON Rules#Timer=2 DO Rule1 1 ENDON

即在启动后禁用镜像规则 10 秒，然后再启用。然而，再次断电后，循环依旧存在。

此时，作者停止了理论猜测，转而通过 Tasmota 的 Web 控制台接口实时抓取日志，并手动触发开关以复现问题。日志揭示了两个关键事实：

1. 代码未生效：作者以为已经部署了“物理按键触发”的修复补丁，但日志显示两个开关仍在运行原始的 Power1#State 回声规则。这提醒开发者：调试前必须验证实际运行的代码，而非假设运行的代码。
2. 根本原因：回声守卫从未真正打破循环。日志显示，对端发来的镜像命令直接写入 cmnd/<me>/Power，这确实翻转了继电器，但从未更新接收方设备的 VAR1。
   • 结果：传入的值总是与本地陈旧的 VAR1 不同。
   • 后果：规则持续触发，发布命令，两个开关陷入相反相位，无限驱动彼此。
   • 结论：该守卫仅对单一、隔离的本地切换有效，在持续的往返通信中毫无作用。去抖（Debounce）也无济于事，它只会让失控的循环变慢，而不会修复状态追踪 Bug。

3. 硬件限制：Tuya 设备的特殊性

作者曾考虑仅响应物理按键按下事件，因为 MQTT 驱动的继电器变化不应生成按钮事件，从而在结构上避免循环。然而，日志显示其中一个开关是 Tuya 设备，其 ESP 芯片通过串口与 Tuya MCU 通信。

日志显示：

TYA: RX Relay-1 --> MCU State: Off

在该硬件架构中，不存在独立的 Button1#State。物理按键按下和远程命令导致的继电器变化，都作为相同的 TuyaReceived dpId 1 事件返回。两者在软件层面无法区分。因此，“仅响应物理按键”的方案在该硬件上不可行。

4. 最终修复：更新去重键

一旦理解了机制，修复方案变得极其简洁。核心思路是：不要让对端直接写入 Power 命令，而是发送一个事件，接收方先更新 VAR1，再操作继电器。

修复后的规则：

Rule1 ON Power1#State!=%var1% DO Backlog VAR1 %value%; Publish cmnd/<peer>/Event SYNC=%value% ENDON
ON Event#SYNC DO Backlog VAR1 %value%; Power1 %value% ENDON

工作原理：

1. 当 SYNC 事件到达时，处理程序首先设置 VAR1 = value。
2. 然后设置继电器 Power1。
3. 此时产生的 Power1#State 等于 VAR1，因此发布规则检测到无变化，保持静默。
4. 回声在恰好一跳后死亡。

部署注意事项：在启用规则前，必须确保两个继电器的物理状态一致，并将 VAR1 初始化为匹配值。否则，设备醒来时会状态不一致，并在启用规则瞬间为了收敛状态而再次冲突。

5. 验证

作者对修复方案进行了压力测试：一个开关快速切换六次，两个控制台同时记录。结果显示，接收方每次都执行 EVENT#SYNC -> Power1，且从未触发自身的 POWER1#STATE...Publish。回声路径在结构上已死亡，停止操作后系统立即恢复安静。

关键要点

• 验证实际运行代码：在调试之前，务必确认设备上运行的是你认为是的代码，而不是旧版本或错误的版本。
• 日志优于理论：十分钟的实时日志观察胜过一小时的竞态条件猜测。日志直接揭示了根因和未知的硬件约束。
• 去抖不是万能药：去抖只能掩盖时序问题，无法解决状态追踪 Bug。如果循环是由状态不一致引起的，减慢速度只会让问题以更“礼貌”的方式持续存在。
• 最小正确修复：最简洁的修复方案通常出现在真正理解机制之后。之前的尝试（如启动守卫）只是临时修补。
• 通用 Bug 模式：任何节点在应用传入变更但未更新用于识别自身回声的去重键时，都会导致双向镜像变成信号放大器。这种现象不仅存在于智能家居开关，也常见于 CRDT 合并错误、Webhook 重试风暴和事件溯源反馈循环中。修复原则始终一致：在应用效果之前，先更新去重键。

意义与影响

这篇文章不仅是一个智能家居故障排除案例，更是一个关于分布式系统状态一致性和事件处理模式的深刻教训。

1. 状态镜像的陷阱：在构建任何镜像或同步系统时，必须明确区分“数据变更”和“元数据更新”。如果接收方应用了数据变更但未更新用于去重的元数据（如版本号、哈希值或状态变量），系统将陷入无限循环。
2. 硬件抽象层的局限性：在物联网开发中，不同厂商的硬件抽象层（如 Tuya MCU 与原生 ESP 逻辑）可能导致事件语义的模糊。开发者不能假设软件逻辑能完美映射到硬件行为，必须深入理解底层通信协议。
3. 调试方法论：作者展示了从“假设-修补”到“观察-理解-修复”的科学调试过程。强调实证数据（日志）在解决复杂并发和状态问题中的核心价值。
4. 系统设计的鲁棒性：简单的状态同步逻辑在边界条件（如断电重启、网络延迟、硬件限制）下极易崩溃。设计时应考虑“启动收敛”和“状态初始化”的一致性，避免依赖瞬态的时序假设。