现场那句原话
“数采仪屏幕上显示连接成功，心跳也在发，江苏这边平台上就是查不到数据，是不是设备有问题？”这是我们在江苏几个化工园区、印染厂现场最常听到的一句描述。
结论先给：连接成功只说明 TCP 通了、心跳有回应，不代表数据能入库。这类情况里，多数不是设备坏，而是 MN（设备唯一编号）、ST（系统编码）与平台备案不一致，或者现场机只发了心跳、压根没发上传包。
四层拆开看原因
协议层
- MN 与平台侧备案的编号差一位、大小写不同，包发上去直接被丢弃。
- ST 系统编码填错，平台按系统类型分流，进了错误的库。
- 命令码用错：平台下发走 1000–1999 段（取数、校时一类，例如 1014），现场机主动上传应走 2000–2999 段；只发 9011 心跳不发 2xxx，平台当然没数据。
- CP 数据段字段缺失或因子编码与平台因子表不一致，成了“有包无值”。
- 校验和算错：从 && 到 ## 之间按 ASCII 累加、模 256、取反加一，两位十六进制，算错平台整包丢弃。
- QN 请求编码重复，平台按 QN 去重，重复包不认。
网络层
- 能 ping 通、能建链，但端口填的不是当地下发的接入端口。
- 现场用 4G 路由，白天正常、夜间断链，补传没开。
- 防火墙只放行了心跳短包，长报文被截断。
设备层
- 数采仪与仪表之间的采集参数没配对，模拟量没换算成工程量。
- 只开了实时上传，历史/分钟数据补传未启用。
- 内置时钟漂移，DataTime 与平台差太多被判无效。
平台层
- 企业信息尚未通过审核，端口通了但不入库。
- 因子表更新后设备侧没同步。
- 平台回执超时，设备重发多次后被限流。
排查顺序：为什么先抓报文
顺序本身就是知识。先抓包再看配置，是因为报文能一次性告诉你“有没有发、发了什么、平台认没认”；反过来先改参数，等于盲调。
- 第一步，看设备发送日志里有没有 2xxx 包——确认是“没发”还是“发了不认”。
- 第二步，比对 MN、ST、PW 与平台备案——这是最高频的错。
- 第三步，看 CP 数据段和校验和——确认报文体本身合法。
- 第四步，才查网络与端口——前三个都对了，网络问题才浮出来。
- 第五步，找平台侧看回执与入库记录。
每一步怎么判断、怎么处置
- 只有 9011 心跳、没有 2xxx：判断为上传通道未启用或上传周期设成了很长。动作：打开实时与分钟上传，观察 5 分钟内是否出现上传包。
- 有包、平台无记录：多为 MN/ST 不符。动作：拿平台下发的接入参数逐位核对，不要照抄旧台账。
- 有包、平台回执报错：看回执码与报文体。动作：优先查因子编码与 DataTime 格式（yyyyMMddHHmmss）。
- 包体被丢弃、日志显示发送成功：查校验和。动作：手工算一次，与日志里的两位十六进制比对。
- 断链后无补传：判断为补传未开。动作：启用历史数据补传，按平台支持的时间窗回补。
三个容易踩的坑
- 把心跳成功当联网成功。心跳只是链路保活，跟数据入库是两码事。
- 拿测试编号直接上生产。调试时用的临时 MN 忘了改回来，平台侧一直按无效设备处理。
- 只看设备日志、不看平台回执。设备日志写“发送成功”只代表字节发出去了，不代表平台收下并入库。
我们做江苏环保数采仪这几年，遇到的上传异常里，真正需要换硬件的比例并不高，多数是参数、命令码和因子表这三件事没对齐。先抓一次报文，往往比在机柜前站一下午有用。
FAQ
我这个情况到底要不要传？
看当地下发的接入要求。已经纳入联网范围、平台侧也建了档案的，就得按要求传，别自己判断“数据不稳定先不传”。
平台说没收到，我这边日志明明显示成功了，听谁的？
看报文和平台回执。日志的“成功”只是发送动作完成，有没有入库以平台回执为准。
换台数采仪是不是就好了？
先别换。MN、ST、命令码、因子编码四项没核对完就换设备，大概率还是同样的现象。
断网那几天的数据，平台还认吗？
多数平台支持补传，但有时间窗限制。先确认平台支持的时间范围，再在数采仪上启用历史补传。