“数采仪上显示连接成功，平台那边一条数据都没有。”华东一个面源治理项目的运维工程师这么描述。站设在农田退水口，太阳能供电、4G 上传，人到了现场，屏幕上的状态灯是绿的。
先说结论：这类故障里最常见的原因在平台侧，不在现场——设备的 MN 没在农业面源污染治理平台建档，或者建档了但没绑点位，报文到了平台被直接丢弃。TCP 建链是通的，所以现场看到的是“连接成功”。先别急着换卡、换天线、换数采仪。
连接成功说的是链路，不是数据入库
HJ212 的流程分两段。第一段是建链：设备发 CN=9011 请求连接，平台回 9012 确认；之后靠 9013 心跳、9014 心跳应答保活。第二段才是数据：CN=2011 实时数据、2051 小时数据、2061 日数据，报文体里带 MN、PW、ST=32、Flag 和 CP=...DataTime=...因子编码=值。
前一段通了，只证明 4G 卡能上网、平台端口开着。建链成功和数据入库之间，还隔着 MN 校验、因子字典、时间窗口、校验和四道关。
四层原因，从平台往下捋
平台层
- MN 未建档：设备用的是自编编号，平台按站点表比对，匹配不上直接丢包，也不回错误。
- 建档了但没绑点位，或绑到了别的行政区，数据落在空站点下。
- 进了审核池：面源平台对超标值、负值、突变值默认标为疑义数据，前台不展示，看着就像没传。
- 因子字典缺项：农田退水站常见的流量、雨量、液位，很多平台用自定义编码，不在字典里时整条报文解析失败。
协议层
- DataTime 必须是 14 位 yyyyMMddHHmmss，写成 12 位或带分隔符，平台解析不动。
- Flag 位用错：分钟数据 Flag=4、小时 Flag=2、日数据 Flag=1，混着发容易被判为重复或非法。
- 校验和算错：报文头 ## 后四位是数据段累加和取低 16 位的十六进制，多一个分号、少一个 && 就过不去，平台静默丢弃。
- CP 段里字段之间用分号、因子之间用逗号，用反了同样解析失败。
网络层
- 4G 私网 NAT 老化，连接挂着但发不出去，设备日志里有 9013、没有 9014。
- 心跳间隔长于运营商保活时间，建议收到 60 到 120 秒。
- 定向卡只放通了特定 IP 和端口。
设备层
- 传感器无输出，数采仪照发，但值全是 0 或 -9999，被判无效。
- 太阳能欠压，发一条就重启，时间回到出厂默认。
- 本地缓存满，2051 补传队列被覆盖，历史数据补不回来。
排查顺序：先平台，再报文，再心跳，最后才去现场
顺序本身就是效率。现场跑一趟成本最高，而“连接成功”已经排掉了物理链路，所以第一步应该坐在电脑前查平台有没有收到这个 MN 的任何报文；第二步抓设备原始报文，核对因子编码、DataTime 和校验和；第三步看心跳往返；实在不行再去现场量电压、查传感器。
每步的判断标准和处置
- 平台查不到该 MN 的任何报文 → 建档或绑定问题 → 补建档，逐个字符核对 MN 的大小写和位数。
- 有报文但数据表为空 → 因子编码或校验和 → 拿原始报文对平台字典，重算累加和。
- 数据入库但前端不显示 → 审核标记 → 去疑义数据列表看阈值设置。
- 日志有 9013 无 9014 → 链路保活 → 缩短心跳、开 TCP KeepAlive。
- DataTime 与实际差十分钟以上 → 校时 → 平台下发校时命令（1000–1999 段）或换 RTC 电池。
三个容易误判的坑
- 看见“连接成功”就派人去换卡换天线。链路通不代表业务通，白跑一趟的情况很多。
- 拿一台能正常上报的表去替换，结果还是没数据。因为病根在 MN 和因子字典，不在设备。
- 把补传当实时。缓存里堆了几千条 2051，一连上就猛发，平台限流去重，看着像“时有时无”，其实一直在补历史。
FAQ
我这个站到底要不要用平台给的 MN？我自己编的行不行？
不行。MN 是平台认设备的唯一凭据，自编的进不了站点表，报文照发、数据照丢。要自编也得先在平台上登记一致。
平台上能看到连接记录，就是没数据，是不是数采仪坏了？
先别怀疑设备。连接记录只能说明 9011、9012 走通了，重点查 MN 是否绑定、因子编码在不在字典里。
下大雨那几天数据特别少，是设备被淹了吗？
面源站多是降雨触发采样，雨量大时供电紧张、信号也差，先看设备日志里的掉电记录和心跳中断时间，再判断是不是硬件问题。
换了一块新数采仪，数据还是上不去，是不是新设备也是坏的？
两块表同时坏的概率很低。更可能是新表沿用了旧配置里的 MN 或者因子编码，把旧问题一起搬过去了。