结论：网络没有断，问题出在 1014 上传没走通
客户的原话是：「数采仪界面上显示连接成功，平台那边一条数据都没有。」这类情况在我们的现场和远程支持中出现得最多，九成以上不是因为网络不通。HJ212-2025 沿用的仍是「## + 四位数据段长度 + 数据段 + 四位 CRC 校验 + 回车换行」这套报文框架，链路通不通由心跳决定，数据有没有由上传命令决定，这两件事在现场经常被当成一件。所以第一步不能重启设备，要先把报文抓出来看。
「连接成功」只能证明心跳正常
现场机按周期发一条 CN=1000 的心跳，平台回一条应答，界面上的灯就绿了。它只说明三件事：TCP 能通、MN 设备编号平台认得出、PW 访问密码对得上。它证明不了数据已经写进数据库。实时数据走 CN=1014，平台回 CN=9014；分钟、小时、日数据走 2000–2999 这个上传区间；平台下发的提取类命令走 3000 段，3020 就属于这一类。心跳通、1014 不通，界面照样是绿的，这是最常见的误导现象。
协议层：报文组装得对不对
- MN 与平台备案的设备编号差一个字符，平台能应答心跳却把数据丢进未匹配队列。
- PW 访问密码改了但只改了一边，表现为能连上、上传被拒。
- CP 数据段里 DataTime 格式或时区不对，平台按无效数据处理。
- 实时数据段写成 Hour 段，接收口径对不上。
- 数据段长度字段与实际内容差一位，CRC 校验通过但平台解析直接报错。
- 因子上传编码与平台配置的因子表不一致，值传上去了却落不到对应污染物。
网络层：通了但没有稳定地通
- 平台侧 IP 白名单没加现场出口，会出现连上后很快被断开。
- 现场走 NAT 或 4G 路由，链路空闲后被回收，形成半开连接，设备以为在线，报文发不出去。
- 心跳间隔超过平台设定的超时阈值，平台主动踢，设备端重连前的那段时间是空窗。
设备层：采不到，也就传不上去
- 串口参数与仪表不一致，波特率、数据位、校验位任一不对都读回空值。
- 设备时间漂移，QN 时间戳跳到过去或未来，平台判定数据超期。
- 补传队列写满后新数据直接丢弃，表现为时有时无。
平台层：数据到了，但没落库
- 新增因子在平台侧没有审核通过，数据被挂在待处理区。
- Flag 标志位与平台的脏数据处理规则冲突，正常数据被标成异常。
- 3020 这类历史补传请求平台侧未开权限，补传数据静默失败。
排查顺序：为什么必须先抓包
顺序本身就是知识，原则是按证据链从外往里走：先抓一条完整报文，再看有没有应答，再看网络，最后才动设备。原因是报文是唯一客观证据，抓一次就能把协议层和设备层的问题排除一大半；而先拆串口、先换模块，是最容易把现场搞乱、又最不容易留下结论的动作。
- 抓到完整 1014 且 CRC 正确，说明采集和组包都没问题，视线转到平台侧和网络侧。
- 只有心跳没有 1014，说明上传任务根本没触发，回到设备层查采集和数据调度。
- 有 1014 但没有 9014 应答，说明平台没回执，现场机会重发，队列堆积后表现为断断续续。
- 平台能查到记录但数值为空，说明 CP 里的数据段内容或因子编码对不上，问题在协议层与平台层的交界。
三个最容易踩的坑
第一个是把心跳在线当成数据链路正常。绿灯只代表 TCP 和身份校验通过，数据有没有落库必须去平台查记录，不能看设备界面。
第二个是只改平台因子编码、不改 CP 里的编码。两边必须是同一套编码，改一边等于没改，而且这种错最难发现，因为报文结构完全正确。
第三个是把时间不同步当成丢包。设备时间差十几分钟，平台按超期丢弃，运维看到的现象是数据断层，容易误判为网络抖动，反复重启路由而不去校时。
常见问题
问：我这个情况到底要不要传？
只要属于联网范围的排口，实时数据就要传，且 HJ212-2025 对接时平台一般要求先有心跳再有数据，先确认链路再确认内容。
问：设备上显示在线，是不是就说明平台收到数据了？
不是。在线只看心跳，收到数据要看平台的历史数据列表里有没有对应时间段的记录。
问：为什么白天好好的，晚上就断了？
多半是夜间链路空闲被回收，或平台侧的超时阈值比现场心跳间隔短，调一次心跳周期往往就能看出来。
问：补传一直不成功，是不是设备坏了？
先别换设备。查平台有没有给补传命令开权限，再查补传队列是否已满，这两项占了我们遇到的大多数。