一、现场那句话：连接成功，平台没数
这句话这大半年被问得最多，客户描述时几乎一字不差：设备屏幕上的联网图标是绿的，日志里还在滚动“发送成功”，可登录平台一查，最近一条数据停在三天前。先把结论放在最前面：多数情况不是传不上去，而是传上去的报文没被平台认下来。
TCP 连接成功只说明网络通路是通的。数据能不能进库，取决于 HJ212 报文里的 MN、ST、CN、DataTime、Flag 这几项能不能和平台侧配置一一对上。所以排查不要从天线和信号格数开始，从设备日志里“有没有平台回执”开始。有回执，问题在数据本身；连回执都没有，才轮到查链路。
二、HJ212 这条链路上都有什么
一台 HJ212数采仪干的活其实只有三件：从仪表取数、按协议打包、发出去等回话。三件事对应四层，任何一层出问题，现场看到的现象都一样——平台没数。
协议层：报文能不能被解析
HJ212 是文本协议，每个字段都有明确含义，错一个字符就可能整包被丢。
- QN：14 位时间戳（yyyyMMddHHmmss）。少一位、时区算错、设备时钟跑偏，平台按格式校验直接拒收。
- ST：系统编码，由平台分配给这个企业。ST 对不上，报文会被归到“未知企业”，日志里能看到回应，库里却没有。
- MN：设备唯一编号。这是现场最常出错的一项，同型号设备出厂配置雷同，装第二台时忘了改。
- CN：命令码。实时数据上传常见 2011，分钟、小时、日数据分别落在 2000–2999、3000–3999、4000–5999 这几个段里；平台向下提取时常用 1011、1012、1013、1014。设备发的 CN 不在平台模板里，平台按未定义命令处理。
- PW：访问密码，要和平台开户时登记的一致。
- Flag：数据段标志位，各平台按位解析，值不对会被判成无效包。
- CP=&&…&&：数据段，带 4 位十六进制 CRC 校验，从 ## 起算到 && 结束（含）。校验差一位，整包丢弃，而且不少设备不会把它记成错误。
- 数据段内部：a34013-Rtd 这类编码对应因子，后面的 Flag 为 N 表示该条数据无效（仪表故障、校准中等）。
网络层：报文出不出得去
- 平台域名解析失败，或平台侧换了 IP 而设备还配着旧地址。
- 端口被园区防火墙封了，不少园区只放行 80、443，其它端口一律不通。
- 长连接被 NAT 或防火墙的空闲超时回收，设备以为还连着，实际已经掉了。
- 4G 弱网下频繁重连，重连期间产生的数据有没有缓存、会不会补传，看设备设置。
- 用 APN 专网的现场，DNS 常常解析不了公网域名，得直接填 IP。
- 一次性补传大量历史数据时报文变大，触发 MTU 分片，分片丢失的表现是“补传几十条只进去几条”。
设备层：数采得对不对
- 串口参数和仪表不一致（波特率、数据位、停止位、校验位），或 RS485 的 A/B 接反，轮询全部超时，采到的是空值。
- 仪表站号（地址）填错，总线上没人应答。
- 设备时间没同步，DataTime 落后几小时，平台按时间去重或判超时，数据被静默丢弃。
- 多台上位机挂在同一条 485 总线上互相抢占，表现为时好时坏。
- 存储写满，历史数据补传卡在队头。
平台层：收进去了但没留下
- 设备没审核、没入库，报文能收但只落到临时表。
- 协议模板选错版本，字段映射对不上。
- 有效数据规则：一个小时内分钟数据缺得太多，这个小时直接判无效，平台上看就是“没数”。
- 同一个 MN 有两台设备在线，后上线的把先上线的顶掉，两台互相顶，表现为间歇性断线。
- 平台按 DataTime 去重，重复上报被丢掉，设备侧却显示每次都成功。
三、为什么先查回执，后查网络
一次完整上报是“发—收—回—确认”四步，任何一步断，现场看到的现象都一样。但“有没有回执”这一条能把整条链路一刀切成两半：有回执，说明域名、端口、平台监听都正常，问题只在报文内容和平台规则；没回执，才轮到查网络。
这个顺序还有成本上的考虑。看日志只要一根串口线或远程登录，十分钟能出结论；改 MN 要协调平台重新登记，查端口要跑现场，动网络要过园区 IT。先把十分钟能做完的事做完，能省掉大半冤枉路。
顺序是：看回执 → 核对 MN、ST、PW → 探域名和端口 → 查设备时间与采集 → 最后才动平台配置。
四、每一步怎么判断、怎么处置
| 现象 | 判断 | 动作 |
|---|---|---|
| 日志里只有发送记录，没有任何回应 | 链路不通或对端没在监听 | 先探平台 IP 和端口，再抓包看有没有 RST；不通就找园区 IT 开端口 |
| 有回应，但回应是错误包或空包 | 报文被解析了，但内容不合法 | 逐项比对 ST、MN、PW 和平台开户信息，确认 CN 在平台模板里 |
| 回执正常，平台查不到数据 | 平台侧字段映射或有效数据规则 | 让平台查这个 MN 的入库日志，看是丢弃还是未映射 |
| 换一台设备用同一 MN 就正常 | 原设备配置或固件问题 | 导出两台配置逐项比对，重点看协议版本和心跳设置 |
| 白天正常，夜里断，早上自己恢复 | 长连接被 NAT 空闲回收 | 缩短心跳间隔，让它小于防火墙的空闲超时 |
| 只有个别因子缺，其它都有 | 对应通道没采到，或数据被标了 N | 查该因子对应的仪表和通道，确认是否处于校准、故障状态 |
| 补传很慢，几十条只进去几条 | 大包分片或平台限流 | 改成分包补传、错峰补传，观察单包大小 |
| 时间戳和平台时间差几小时 | 设备时钟没同步 | 开 NTP 或让平台下发对时，校完再看是否恢复 |
五、三个最容易踩的坑
坑一：把“连接成功”当成“数据已送达”
屏幕上的“已连接”只代表 TCP 三次握手完成。报文有没有被应用层接收、有没有被解析、有没有入库，是三件不同的事。不少现场就在这一步下了错误结论，然后开始换卡、换天线、换流量，钱花了问题还在。判断标准只有一个：日志里有没有针对这条 CN 的回应。
坑二：看见 Flag=N 就以为数据丢了
数据段里每个因子后面都跟着一个 Flag，N 表示这条数据无效——仪表在校准、在维护、故障中都会标 N。这是正常的业务标记，不是传输故障。真正要查的是“为什么一直是 N”，而不是“为什么平台没显示”。反过来，有些平台会把标 N 的数据整条过滤，这时现象和“没传上去”完全一样，非常容易误判。
坑三：两台设备用同一个 MN，互相顶号
这个坑最隐蔽。同型号设备出厂配置接近，第二台装上去只改了 IP 没改 MN，两台用同一个编号连同一个平台。平台一般按 MN 维持单会话，后连上的把先连上的踢掉，两台设备不停重连、不停互踢，现场看到的是“时好时坏、一天断十几次”。凡是遇到间歇性掉线，先把全厂设备的 MN 列一遍去重。我们在给客户调试 PS-S01 时也把这步写进了交付清单——上线前核编号，比事后查三天划算。
六、几个被反复问到的问题
“我这个情况到底要不要传？”
先看你所在的行业和排口类型是不是在要求联网的范围内，再看当地平台有没有给你开户、发 MN。开户了、发了编号，就是要传；只是内部看数、没进平台名单的，先把采集做准，别急着接。
“我这边显示发送成功，平台说没收到，到底是谁的问题？”
看“发送成功”是哪种成功。只发出去没收到回应，是链路问题；收到回应但平台没入库，是字段或规则问题。把设备日志里那条原始报文和平台的入库记录对着看，十分钟能定位，比两边互相推快得多。
“换一家平台，设备要不要重新配？”
要。MN、ST、PW、平台地址端口、命令码段、心跳间隔基本都得重配一遍，协议版本也可能不一样。换之前把旧配置导出一份存着，出问题还能回退。
“4G 信号满格，为什么还是三天两头掉线？”
信号强度只说明无线侧。掉线更多是长连接被回收、基站切换、APN 侧路由变化。看日志里掉线的时间点有没有规律：整点掉、每隔固定时长掉，八成是心跳间隔大于空闲超时。
最后一句：HJ212数采仪的排查靠的不是猜，是日志。原始报文、回执、时间戳三样凑齐，剩下的都是比对工作。设备侧把日志留全、留够天数，比任何自动诊断都实在。