结论先给：链路通不等于数据通
PS-S01环保数采仪显示「已连接」、平台侧一条数据都收不到，最常见的四个原因，按现场出现频率排：一是TCP长连接已经变成半开状态，设备侧socket还挂着ESTABLISHED，其实对端早就释放了；二是MN、ST、PW这三个身份参数跟平台台账对不上，报文发到了，平台认不出是谁，或者直接丢弃；三是数据时间戳不落在平台要统计的时间区间里；四是上报命令码、数据标记位跟平台要求不一致。这四类问题重启设备基本解决不了，先抓一次报文比拔电有用得多。
客户的原话：连上了，就是没数据
一位运维工程师的描述是这样的：「PS-S01环保数采仪上显示连接正常，平台那边一条数据都没有，平台值班的还打电话来说我们站掉线了。」这句话里已经藏了矛盾——设备认为自己在线，平台认为设备掉线。两边的「在线」判据根本不是一回事：设备看的是TCP三次握手成没成，平台看的是有没有按时收到合法报文。
所以这类故障不要笼统问「为什么连不上」，要拆成三个更小的问题：报文到底发出去了吗？平台收到了吗？平台为什么没用？三个问题各对应一层原因，排查顺序也由此确定。
原因分四层看
协议层：报文格式和身份字段
按HJ 212-2017，一帧完整报文是「##」加4位数据段长度、数据段、4位CRC校验码、再以「&&」结尾。数据段里是QN、ST、CN、PW、MN、Flag、CP这些字段。这一层出问题，典型现象是「平台有连接、有流量，但没有有效数据」。
- MN设备唯一标识跟平台登记的不一致，多一位少一位平台都不认。很多现场是换主板或者恢复出厂设置后，MN被重置成了默认值。
- ST系统编码填错，数据虽然收下了却挂不到对应排口的点位上，平台界面上就是空的。
- PW访问密码被平台侧改过，设备还用旧密码，表现是每条报文都有应答，但应答里带错误码。
- CN命令码与平台要求的上报方式不一致。1011和2011对应实时数据，1012和2012对应分钟数据，1013和2013对应小时数据。只收小时数据的平台，设备配成只发分钟数据，平台那边看起来就是没数据。
- Flag标志位是4位数字，依次表示是否分包、是否加密、是否带时间戳、是否带数据区。分包上传时PN分包号错序，平台组包失败。
- 数据区里的PolId编码、单位、小数位与平台点位配置不一致；DataTime不是14位时间格式，或者时区写错。
- CRC16校验算错，或者数据段长度字段填的不是实际长度（4位不足要补零），平台连解析这一步都过不去。
网络层：TCP长连接最容易骗人
- 4G上网卡或专线防火墙的NAT会话表有老化时间，映射被回收后设备侧不发FIN，socket状态仍是ESTABLISHED。这就是半开连接，设备「以为」连着，实际发出去的数据石沉大海。
- 平台侧做了负载均衡或集群，会话在节点切换时被打断，设备端感知不到。
- 防火墙策略调整、端口变更，或者运营商侧对空闲长连接的回收。
- 现场交换机端口协商异常、偶发丢包，容易被误当成「设备不稳定」。
设备层：采不到、存不下、发不出
- 下挂仪表485线松了、地址冲突、量程配错，数采仪采到的是无效值，按规则不上传。
- 本地缓存写满、上报队列积压，积压到上限后按策略丢弃最早的数据。
- 时钟没有同步，设备时间比标准时间快几分钟，整点数据落到区间之外。
- 上报周期配错，比如平台要求5分钟一次，设备配成了60分钟。
平台层：收下了但不用
- 该排口还挂在调试状态，数据不入库。
- 平台侧点位信息变更后没有同步到设备。
- 平台升级或维护窗口，接口字段长度、必填项发生变化。
排查顺序本身就是知识
顺序不能乱，理由只有一个：抓包和日志是一次性证据，重启和改配置会把证据毁掉。
- 第一步，在数采仪的通信日志里调出最近半小时的收发报文。有发送记录、没有应答记录，说明报文出去了但平台没回，问题在网络层或平台层。
- 第二步，日志看不出结果，就在数采仪所接的交换机上做端口镜像，用抓包工具过滤平台端口，看有没有以「##」开头的TCP载荷。
- 第三步，从同一网段的电脑直接连平台IP和端口。能连上说明网络路径是好的，问题出在设备那条长连接本身，也就是半开连接。
- 第四步，确认报文到了平台，再去看报文内容：MN、ST、PW、CN、DataTime、Flag，逐项对着平台台账比。
- 第五步，前面都排除了，才去动平台侧配置，最后才是重启设备。
每一步的判断标准和处置动作
| 现象 | 判断 | 动作 |
|---|---|---|
| 设备日志有发送记录、无应答记录 | 报文出得去、回不来，卡在网络或平台 | 测平台端口连通性，查防火墙策略，看设备socket是否已处于半开 |
| 抓包看到「##」开头的载荷，平台侧无入库 | 报文到了，内容不被接受 | 比对MN、ST、PW与平台台账，确认排口是否处于调试状态 |
| 平台有应答但错误码非0 | 报文格式或权限被拒 | 查PW、CN、数据段关键字拼写、CRC校验结果 |
| 设备日志完全没有发送记录，本地却有数据 | 上报队列卡住或采集无效 | 查下挂仪表485通信、量程、上报周期设置 |
| 平台收到数据但时间对不上 | DataTime与平台统计区间错位 | 校对设备时钟，检查时区与14位时间格式 |
| 平台显示数据状态异常 | 数据标记位是F、D、M而不是N | 检查仪表故障状态与维护、停运标记设置 |
| 同网段电脑能连平台，设备连不上 | 设备侧长连接已失效 | 开启TCP keepalive或缩短心跳间隔，必要时主动重连 |
三个最容易踩的坑
坑一：把TCP连接成功当成上传成功
面板上的「在线」只代表链路层握手成功，跟报文有没有被平台接收是两件事。判断上传是否正常，唯一可靠依据是平台侧有没有按时返回9011应答，而不是看指示灯颜色。
坑二：看到本地历史数据完整，就认定设备没问题
本地存储和上报队列是两条独立的路。本地存得满满当当，队列里可能早就卡死或者因为重发次数耗尽被丢弃。数采仪本地有数据，恰恰说明采集没问题、问题出在上报环节。
坑三：一上来就重启设备
重启会让半开连接、队列积压这些证据全部消失，看起来好了，过几天原样复发。现场常见的「重启能好两天」就是半开连接被重新握手的典型表现，不是设备硬件故障。
FAQ
问：我这台数采仪本地存了几万条历史数据，重新连上之后会不会自动补传？
要看补传配置。多数数采仪支持断点续传，但补传范围受本地缓存容量和补传开关控制，超期或者超量的部分不会补。另外补传报文里的QN和DataTime要保持原始时间，否则平台会当成新数据入库，反而造成时间重复。建议先确认平台的补传窗口要求，再决定补传策略。
问：平台说我们掉线，可设备上明明显示在线，我该信谁？
以平台为准。平台判在线看的是规定时间内有没有收到合法报文，设备判在线只看TCP握手。两边不一致，基本就是半开连接或者报文被拒，按上面的表格往下排。
问：MN能不能随便改？改了平台那边要不要同步？
不能随便改。MN是设备在平台上的身份证，改完必须让平台同步台账，否则报文全成了陌生设备的报文。改动前先跟平台确认编码规则，最好在停机窗口操作。
问：抓包我不会，有没有更简单的办法判断数据到底发没发出去？
先看数采仪自带的通信日志，里面通常记录了每一帧发出报文和平台应答。日志里只有发送、没有应答，说明问题在链路上；有应答但错误码非0，说明问题在字段上。这一步不需要任何额外工具，是最省事的初判手段。