一、客户原话：数采仪显示连接成功，平台就是没数据
“数采仪显示连接成功，平台就是没数据，是不是设备坏了？”这是上周一位运维工程师在电话里的原话，现场在华东一家印染厂，设备面板上网灯是绿的，4G 信号满格，现场重启过两次，平台侧那个排口的数据一直是空的。
先说结论：最可能的原因不在网线，也不在主板上，而在身份字段和应答链条上。设备的 MN、ST、PW 三项与平台侧设备档案对不上，或者平台下发的指令（例如 1011 提取现场机时间、2011 提取污染物分钟数据）设备没有用同一个 Qn 正确应答，平台就认为这次会话没有完成，后续不再向这台设备要数据。TCP 通了、界面显示“连接成功”，但应用层一次有效交互都没走完。
HJ212数采仪面板上那个“连接成功”，只说明设备与平台服务器的 IP、端口之间完成了 TCP 三次握手。它不检查 HJ212 报文有没有被平台收下，也不检查平台有没有回包。这两件事在现场往往共用同一个指示灯，但在协议里隔着一整个应用层。
二、把“连接成功”拆成四层来看
协议层：包发出去了，平台有没有回
HJ212 的报文结构是固定的：包头 ##，紧跟 4 位数据段长度，然后是数据段，数据段以 && 结束，最后是 4 位十六进制的 CRC16 校验码。数据段里按顺序是 Qn、ST、CN、PW、MN、Flag、PNUM、PNO、CP。
这一层最容易出问题的地方有三个：一是 4 位长度字段与实际数据段字符数差一个，平台按长度截断后 CRC 对不上，整包丢弃；二是 CRC 计算范围不一致，有的固件从 ## 之后开始算，有的把 ## 也算了进去；三是 Qn 没有原值回填，平台下发时用的是自己的 14 位时间戳加 3 位流水号，设备应答时另起了一个新 Qn，平台那边按超时处理，登记为“无应答”。
还有 Flag 字段。7 位 Flag 标记的是数据段里带了哪几类数据，位与位之间有固定顺序。多填一位、少填一位，字段整体错位，平台解析出来是乱码，通常不会报错，只是在入库前被过滤掉。
网络层：能 ping 通，不等于会话一直活着
现场常见的几种情况：4G 定向卡没把平台 IP 加进白名单，出方向能通、回方向被拦；企业防火墙的 NAT 会话老化时间短于设备心跳间隔，链路被静默回收，而设备侧 socket 还挂在 ESTABLISHED 状态，自己以为连着；数据段比较长的时候遇到 MTU 分片，个别中间设备直接丢包。
这一层的特点是“时好时坏”。如果平台上的数据是规律性缺失，比如每小时整点那一包没有，或者每隔十几分钟断一次，先怀疑会话老化，而不是去换卡。
设备层：MN、ST、PW、DataTime 四个字段
这一层是故障密度最高的地方。MN 是设备唯一标识，规范里是 24 位，很多平台下发的却是一串短号，现场随手在尾部补空格或者补 0，补错了平台就认不出这台设备。ST 系统编码同样是 24 位，要与平台分配的保持一致。PW 是 6 位访问密码，密码不对时平台一般直接不回包，设备重发几次后挂起，界面上仍然显示连接正常。
DataTime 是数据段时间，属于 CP 内部字段。设备系统时间没有同步、比平台时间快或者慢了几分钟，平台按接收窗口做有效性判断时会把这一包判为无效数据。这种情况在换了主板、断过电、没配 NTP 的现场特别多。
平台层：命令码和档案
2000–2999 段是污染物数据，2011、2012 是分钟数据的提取与上传；3000 段是统计类数据，像 3020 这类命令码走的是另一条通道。如果平台只为这个排口开通了分钟数据接收，而设备配置的上报方式挂在统计类命令码上，就会出现“设备一直在发、平台一条不收”的现象。另外两种情况也很常见：平台侧设备档案处于待审核、未启用状态；同一个 MN 之前有一个没有释放的旧会话，设备重启后新连接被平台踢掉，表现就是设备在线、平台离线。
三、排查顺序：为什么先看应答，最后才看网线
顺序本身就是经验。判断先后不按“哪层重要”排，按“哪一步信息量最大、成本最低”排：
- 第一步看设备通信日志里有没有平台回来的包。这一步几十秒就能完成，而且结论是二值化的：有回包，网络层基本没问题，直接去查字段；没有回包，再去查身份和链路。很多现场跳过这一步，直接换卡换天线，一天就过去了。
- 第二步看回包里的 CN 和 Qn 是否与请求匹配。匹配说明交互成立，问题在数据段；不匹配说明设备固件的命令码映射有错，这时候改现场参数没有用。
- 第三步对时间。把设备时间、平台接收时间、DataTime 三个值并排看一眼。时间差超过平台的有效窗口，前面两步全部白做。
- 第四步才查网络稳定性。看缺失是否规律、是否集中在某个时段，再决定是调心跳间隔还是找网络侧改会话时长。
把网络放在最后，是因为一旦 TCP 显示连接成功，链路层的嫌疑就排到了后面；而把应答放在最前，是因为它能一次性把问题切成“没到平台”和“到了没被收”两半，后面所有的排查都只在一半的范围里做。
四、每一步的现象、判断和动作
| 现象 | 判断 | 动作 |
| 日志里只有 ## 开头的发送记录，没有接收记录 | 平台没回包，或回包到不了设备 | 用电脑 telnet 平台 IP 和端口，核对 MN、ST、PW 后再看平台侧该 MN 的登录记录 |
| 有回包，但 CN 与请求不一致，或 Qn 不是原值 | 协议层应答映射错，平台按超时登记 | 核对固件的命令码映射表，确认 Qn 原值回填 |
| 回包正常，平台仍查不到数据 | 数据段被解析后丢弃 | 抓包核对 4 位长度、Flag 位数、DataTime 格式和 CRC 计算范围 |
| 平台显示离线，设备显示在线 | 旧会话未释放，或 NAT 会话老化 | 缩短心跳间隔，查防火墙会话超时时间 |
| 数据规律性缺失，例如整点那包没有 | 上报周期与平台接收窗口没对齐 | 调整上报时刻，避开平台整点批量处理时段 |
| DataTime 与平台接收时间差几分钟以上 | 设备时钟未同步 | 配 NTP，先同步时间再补传 |
| 同一时段补传多次，平台只保留一条 | 平台按 DataTime 去重 | 补传前清空重复区间，按时间正序一次性补齐 |
五、三个最容易踩的坑
坑一：把“在线”当成“在传”
平台上的在线状态，取的是最近一次 TCP 连接或者最近一次心跳，不是最近一条有效数据。设备在线、数据为零，是完全自洽的状态。看到绿灯就排除设备侧，是现场最常见的误判起点。
坑二：抓包只看出包，不看回包，也不解 CRC
很多人抓到设备发出去的包，看到 ## 开头就断定“我们发出去了，是平台的事”。可平台只认 CRC 正确的包，CRC 错一个字符，平台侧看到的和没发是一样的。正确的做法是把回包一起抓，并且把 4 位 CRC 解出来比对，而不是只看报文长得像不像。
坑三：改完 MN、ST、PW 不重启、不重新登录
不少 HJ212数采仪的联网模块在启动时读取一次配置，参数保存成功但没重启，设备还拿着旧 MN 建链，平台侧看到的是另一台“陌生设备”，历史数据挂在原来的档案下。改完参数至少要让联网模块重新登录一次，并把平台侧旧会话释放掉。
六、客户最常问的四个问题
“我这个情况到底要不要传？”
判断依据不是设备指示灯，而是平台侧这台设备的档案是否启用、排口是否绑定。档案启用了，数据就必须按约定的命令码和时间间隔上传；档案没启用，传上去也会被丢弃。先让平台侧确认档案状态，再决定查不查设备。
“数采仪显示连接成功，平台没数据，是不是平台的问题？”
不能这么下结论。连接成功只覆盖到 TCP 层，往上还有报文、字段、档案三道关。按第三节的顺序走一遍，通常半小时内能把范围缩到一层。真到平台侧，也要拿得出回包记录和 Qn 对应关系，否则沟通没有落点。
“平台给我的 MN 只有十几位，设备要 24 位，怎么填？”
规范里 MN 是 24 位，不足的部分怎么补、补在哪一位，必须与平台确认，不要自己补空格。空格在报文里是有效字符，一旦补错，平台侧认的是另一台设备，排查时会往完全错误的方向走。
“补传历史数据，平台说重复，怎么办？”
先看平台是否按 DataTime 去重。如果去重，补传前要把已成功入库的时段清出来，只补缺口，并且按时间正序发送。一次性全量重推，除了触发去重，还容易把平台的接收队列堵住，反倒影响实时数据。