ESP32基于AsyncMQTT与ArduinoJSON的配置更新循环卡死问题排查

关于逻辑表达式的有效性分析 #

表达式rtcConfig.time > 0 && rtcConfig.time == (uint64_t)jsonConfig["time"]存在多个潜在失效场景：

1. JSON类型不匹配：若Broker下发的time是字符串类型（如"1690000000"）而非数字类型，ArduinoJson解析后强制转换为uint64_t会得到0，直接导致等式不成立。
2. 符号扩展异常：如果JSON中的time被错误存储为带符号32位整数（数值超过2^31-1时），强制转uint64_t会触发符号扩展，生成错误的数值。
3. RTC存储位翻转：ESP32的RTC RAM虽支持断电保留，但长期运行可能受电磁干扰出现位翻转，篡改rtcConfig.time的数值，导致与JSON中的值不匹配。
4. JSON解析失败：若payload存在格式错误（如time字段缺失、格式非法），jsonConfig["time"]会返回默认值0，同样让等式不成立。

建议优化后的校验逻辑：

// 先校验字段存在且类型匹配
if (jsonConfig.containsKey("time") && jsonConfig["time"].is<uint64_t>()) {
  uint64_t receivedTime = jsonConfig["time"].as<uint64_t>();
  bool isUpToDate = (rtcConfig.time > 0) && (rtcConfig.time == receivedTime);
}

无USB调试下验证JSON的time属性 #

可通过以下远程方式实现验证：

• 新增MQTT调试主题：修改设备逻辑，接收到配置后立即向esp/debug/<MAC_ADDRESS>主题发布{"received_time": [数值]}，通过订阅该主题或查看Broker日志直接获取接收值。
• 本地存储关键数据：将每次接收到的time值写入SPIFFS（注意限制写入频率，避免存储磨损），后续可通过OTA升级时读取历史值分析。
• 故障触发临时上报：当检测到连续3次isConfigUpToDate()返回false时，暂停快速重启逻辑，每隔30秒向MQTT上报当前rtcConfig.time和接收的time值，直到手动触发重启。
• 远程日志转发：将ESP32的运行日志（如JSON解析结果、rtcConfig值）通过MQTT发送到专属日志主题，替代USB串口调试，用log_i等ESP-IDF日志函数捕获关键信息后转发。

整体排查步骤 #

1. Broker端payload校验：检查Mosquitto日志中下发的esp/config/<MAC_ADDRESS>主题内容，确认time字段为uint64类型数字，无格式错误。
2. RTC存储可靠性监控：设备正常运行时，定期上报rtcConfig.time到MQTT，观察长期运行中数值是否出现异常波动。
3. 增加异常分支处理：当isConfigUpToDate()返回false时，先上报关键数据再延迟5分钟重启，避免快速耗尽电池。
4. JSON结构校验：反序列化后添加字段存在性、类型校验，校验失败则丢弃配置，避免无效写入RTC。

内容的提问来源于stack exchange，提问作者Lecram