数据采集调试过程中的典型场景
在做物联网设备监控项目时，经常遇到传感器数据传不上来的情况。比如温度传感器明明正常工作，但后台一直显示离线。这时候就得一步步排查数据采集的每个环节，从硬件到软件，从协议到网络，任何一个细节出错都会导致整个流程卡住。
一个典型的调试场景是：现场设备已经部署，数据却断断续续，甚至完全丢失。这时候不能急着重装系统或者换设备，先理清楚数据采集的完整路径——传感器 → 采集模块 → 通信链路（如RS485、Wi-Fi）→ 数据解析服务 → 数据库存储。每一步都可能是故障点。
检查采集端硬件连接
最常见的问题是接线松动或电源不稳。比如用万用表测电压发现供电只有3.2V，而模块要求最低3.6V，这就可能导致间歇性重启。还有屏蔽线没接地，工业现场的电磁干扰让串口通信频繁出错。这类问题在车间环境特别常见，换个屏蔽层完好的线缆立马恢复正常。
验证通信协议是否匹配
调试Modbus RTU时，主从设备的波特率、校验位必须一致。曾经有个项目，采集器设置的是无校验，但从设备设成了偶校验，结果读回来的数据全是乱码。用串口调试工具抓包一看，帧格式对不上。改完参数后数据立刻通了。这种低级错误其实很普遍，特别是在多厂家设备混搭的场景下。
如果使用自定义协议，建议在采集程序里加上原始数据打印功能：
printf("收到原始数据: %02X %02X %02X %02X\n", buf[0], buf[1], buf[2], buf[3]);这样能快速判断是数据本身有问题，还是后续解析出了错。
模拟数据源辅助测试
当现场不具备真实采集条件时，可以用虚拟数据源代替。比如写个脚本模拟传感器输出：
import random
import time
while True:
print(f"{{'temp': round(random.uniform(20, 30), 2), 'time': time.time()}}")
time.sleep(1)把这段输出重定向给采集程序，就能在没有硬件的情况下测试解析逻辑和网络传输是否正常。这种方法在开发阶段特别实用，省去反复插拔设备的时间。
日志记录要具体到字段
很多采集程序只记录“数据接收失败”，这种日志毫无意义。应该记录更详细的信息，比如时间戳、设备ID、错误类型、尝试次数。例如：
[2024-05-12 14:23:11] DEV001 接收超时，已重试3次，丢弃本次采集有了这样的日志，回溯问题时一眼就能看出是某个设备长期不稳定，还是某一时间段整体通信异常。
网络传输中的隐蔽问题
用MQTT上传数据时，看似连接正常，但Broker设置了ACL权限控制，某些Topic被拒绝订阅。现象就是数据发出去了，但后端收不到。这时候要用mosquitto_sub命令手动监听Topic：
mosquitto_sub -h broker.example.com -t 'sensors/temp/+' -v如果命令行能收到数据，说明问题出在后端服务没正确订阅；如果命令行也收不到，那就是发布端或Broker配置有问题。
时间同步不可忽视
多个采集节点之间时间不同步，会导致数据分析时出现顺序错乱。比如A设备记录的时间比实际快了5分钟，和其他设备联动分析时就会误判事件因果关系。在调试阶段就要确保所有设备开启NTP同步，或者至少记录UTC时间。
有时候客户为了省事直接关防火墙，结果一段时间后被攻击，采集服务瘫痪。正确的做法是在路由器上只开放必要的端口，比如只允许采集服务器IP访问502端口（Modbus），而不是整个网段都能连。