“数采仪屏幕显示连接成功，污染源自动监控平台V5.0上就是没数据，曲线是平的。”这是运维工程师最常发来的一句话。结论先给：绝大多数情况不属于网络不通，而是TCP通道建起来了、HJ 212报文没被平台认下来，问题集中在MN/ST与平台档案不一致、Flag状态位被置为无效、DataTime不落在允许时段这三处；其次才是长连接假在线，心跳没有应答。
一、别被“连接成功”骗了：连上不等于传上去
数采仪上的“连接成功”只代表TCP三次握手完成。HJ 212 是应用层协议，真正的通是：设备发出带QN、ST、CN、PW、MN、CP的报文，做CRC校验，以&&…##封装，平台回一条应答。只握手不交互，就是典型的“假在线”，看着灯是绿的，数据一条没进库。
二、四层拆开看，先定位责任层
协议层
- 命令码发错：实时数据2011、分钟数据2051、小时数据2061、历史补传3020，平台V5.0对不同数据类型走哪个CN有要求，编码不对会被静默丢弃，日志里连报错都不给。
- MN（设备唯一标识）与平台接入码不一致，或ST系统编码与排口绑定关系对不上，报文收到了却挂不到排口上。
- CRC算错，或Flag标志位被置成维护、校准，数据被平台判为无效。
- PW密码与平台下发的接入密码不符，部分平台只回错误应答不落库。
网络层
- 端口方向性不通、NAT表项老化、APN专网未开通、防火墙只放行单向SYN。
设备层
- 时钟偏差、因子与量程配置为空、串口波特率与仪表不一致、本地存储满导致补传队列堵死。
平台层
- 接入码未审核、排口未绑定、时段策略限制、平台版本升级后字段校验变严，多出必填项。
三、顺序为什么是“平台→设备→网络→协议字段”
平台侧报文日志是唯一的客观证据。先看平台收没收到，一次就能分清是“没发出去”还是“发了不认”。没收到，才回头查网络和设备；收到了但报表空白，直接奔协议字段，不必再去折腾网线和交换机。这个顺序本身就是经验，反过来做，往往在网线上耗掉半天。
四、每一步的判断标准
- 现象：平台日志里连这个MN都搜不到。判断：报文没到平台。动作：看设备发送日志，确认目标IP和端口，检查心跳是否有应答。
- 现象：日志能看到报文，但解析失败或提示校验错。判断：封装或CRC问题。动作：比对&&…##收尾与两位十六进制CRC，核对PW。
- 现象：报文解析正常，曲线仍是空的。判断：MN/ST绑定错或Flag无效。动作：核对平台档案，查Flag位，查DataTime是否落在允许区间，超前时间会被直接丢弃。
- 现象：白天正常、夜间断。判断：长连接被NAT老化，心跳间隔大于设备超时设置。动作：缩短心跳周期，打开断线重连。
五、三个最容易误判的坑
- 看到“连接成功”就断定网络没问题。半开连接下TCP还在，应用层已经死了，实际心跳无应答。
- 把Flag置为维护、校准当成故障。数据其实上去了，平台按无效处理，报表自然空白。
- 发现时钟不对就随手改时间。改完DataTime跳到未来，平台丢弃，补传也跟着乱序。正确做法是先停传、校准、再走历史补传。
六、客户常问的四个问题
“我这个情况到底要不要传？”
有排口、有联网验收要求的必须传；只做内部看板另说。传上去的数据要和验收档案对得上。
“平台说连上了，为什么报表还是空的？”
先查MN与排口绑定，再查Flag位和DataTime时段，九成在这两处。
“换了一台数采仪，数据全跑到别的排口去了”
MN沿用了旧值，平台按MN归档。换机必须重新核对接入码。
“补传一直不动”
看补传的起止时间和条数上限，本地存储满了要先清队列再补。
把平台日志当第一现场，按层收口，比一台台换设备快得多。