“数采仪显示连接成功，平台就是没数据。”这是华东某化工园区一位运维工程师的原话。面板灯是绿的，网络能ping通，平台侧却调不出这一时段的曲线。
先说结论：这类故障九成出在HJ212协议这一层，不是网络。报文里的字段没对上（MN、PW、CN），平台应答的QN没被设备正确匹配，或者Flag没置应答位导致设备“发完就当成功”——真正需要换设备的比例很低。
一、链路通，不等于数据通
HJ212跑在TCP之上，设备侧显示的“连接成功”只说明三次握手完成。数据要进平台，还得过三关：报文拼装正确、CRC校验通过、平台按MN和QN正确入库。任意一关没过，设备界面照样显示已连接。
二、按平台、协议、网络、设备四层拆开看
- 平台层：MN没在平台注册，或注册在别的企业名下；数据段字段名与平台配置不一致；平台按QN去重，把重复包丢了。
- 协议层：QN不是YYYYMMDDHHMMSSXXX格式；CN用了平台不认识的编码；Flag未置应答位；CRC算错；数据段长度（4位十进制）与实际长度不符。数据类命令集中在2000–2999这一段，2051、2061这类编码一旦和平台约定不一致，就会出现“收到了但解析不出来”。
- 网络层：长连接被中间设备空闲断开后没有自动重连；心跳（1011）间隔过长；NAT会话老化；上报端口受限。
- 设备层：采集周期与上报周期不匹配；设备时钟漂移导致QN乱序；数据源本身没出数。
三、排查顺序本身就是知识
不要一上来就重启设备。顺序应该是：平台有没有收到 → 报文对不对 → 链路稳不稳 → 设备有没有数。理由很简单，前三步都是改配置，几分钟的事；跳过它们直接动硬件，代价是几小时和一次停机。
- 第一步，看平台。现象是平台无数据。判断标准：平台是否收到过该MN的任何报文，登录1000、心跳1011也算。动作：让平台侧导出原始报文日志。
- 第二步，看报文。现象是平台收到但解析失败或丢弃。判断：逐项核对QN、CN、MN、PW、Flag、CRC和数据段长度。动作：用模拟工具发一条最小报文验证。
- 第三步，看链路。现象是报文时断时续。判断：心跳是否按周期收发，断线后是否自动重连。动作：抓包看TCP重连和报文序号。
- 第四步，看设备。现象是字段齐全但数值为空或时间错乱。判断：设备时钟、采集周期、数据源状态。动作：校时并调整上报周期。
四、三个最容易误判的坑
- 把“TCP连接成功”当成联网成功。数采仪连上平台只是第一步，协议层没有应答才是常态。判断依据要看平台有没有回包，不要看面板灯。
- 只看发送记录，不看QN匹配。断线重传时同一条数据可能发两次，平台按QN去重，现场以为“发了就是收了”，最后发现缺了半小时数据。
- MN或PW沿用旧配置。换现场、换站点时没重新申请MN，数据挂到了别的企业名下；或者PW改了平台没同步，登录直接失败，可设备侧仍然显示已连接。
五、FAQ
- 问：数采仪显示连接成功，平台就是没数据，是不是设备坏了？答：先别换设备。让平台导出原始报文日志，看有没有收到过这个MN的任何包。能收到说明设备在发，问题在字段；一个包都没有，再回头查链路。
- 问：现场能ping通平台，为什么数据还传不上去？答：ping只验证网络可达。HJ212走长连接和协议应答，端口被封、NAT老化、心跳超时都会让包发不出去，但ping照样通。
- 问：平台说数据重复或者时间对不上，是谁的问题？答：多数是QN重复或设备时钟漂移。校时后观察一个完整上报周期，再看平台的去重规则是不是按QN来做。
- 问：HJ212要不要升级到新版本？答：看平台侧要求。版本不一致时，先确认平台认哪个版本的CN编码和字段名，再决定改设备配置还是改平台解析。