直接从事这个项目的朋友应该都有同感：以太网温湿度采集通讯本身不难，难的是现场环境永远不像测试台上那么干净。部署环境里的交换机重启、光电转换器松动、DHCP地址漂移、上位机主动断开连接，随便一个意外就能让设备陷入“数据只采不发”的尴尬状态。而一旦断线期间持续采集的数据没有妥善保存，后续补传就成了无源之水。这篇文章把我做这套以太网温湿度采集通讯系统时，围绕多协议对接、断线重连、断点续传三个核心机制的设计思路、实现细节和现场踩坑记录完整整理出来，给正在做类似环境监测终端或数据采集网关的朋友一份可参考的实战笔记。
1. 需求驱动下的整体架构设计
1.1 项目背景与数据链路
实际业务场景很常规：车间/库房/机房部署若干温湿度采集节点，通过以太网接入现场局域网，数据最终汇入上位监控软件或云平台。采集节点需要同时满足至少两类协议需求——一类是工业现场常见的Modbus TCP轮询，另一类是HTTP或MQTT主动上报，方便对接不同厂家的平台软件。
数据链路分为三段：传感器采集层（SHT30/HTU21等）、主控处理层（MCU或边缘网关）、网络传输层（以太网+应用协议栈）。远端上位机或云平台通过以太网向下发起请求或接收上报。设计的关键不在“采集”这个动作本身，而在于传输链路出现异常时，整个系统如何做到自我恢复、数据不丢。
1.2 三个核心需求的优先级排序
把需求排优先级，是决定后续设计边界的第一步。多协议支持是功能层面的硬指标，部署现场用什么平台是用户说的算，不能替用户做选择。断线重连是“可用性”指标，设备掉线后如果不能自动恢复，维护人员就得反复跑现场重新上电，这在生产环境无法接受。断点续传则是“完整性”指标，断线期间的数据如果不能找回，监控报表就会出现空洞。
三者的关联关系可以这样理解：断线重连保证链路“尽快回来”，断点续传保证链路断开期间的数据“不白采”，多协议则保证“接得上”。这意味着断点续传的数据缓存区设计、重连后的状态恢复流程，都会直接影响到系统整体可靠性，必须从方案设计阶段就一起考虑，而不是拆成三个孤立模块堆在一起。
2. 通讯协议选型与多协议共存方案
2.1 主流协议的取舍
做协议选型时，我先约束了项目边界：设备是嵌入式资源受限环境，不能无限堆协议栈。最终选定三条主线——Modbus TCP、HTTP POST、MQTT协议。
Modbus TCP是工业现场的基础选项。这个人机接口简单，寄存器读写操作清晰，不少组态软件和PLC都原生支持，是做工业设备绕不开的协议。HTTP POST适合对接自定义平台或Web服务端，实现起来最直接，但需要处理HTTP头、响应状态码，数据丢失后还要靠上层机制保证可靠性。MQTT则是物联网平台的宠儿，发布订阅模型天然适合传感器周期上报，QoS级别还能提供消息层面的可靠投递。
实际项目里硬件以Cortex-M4/M7为主，主频和Flash容量尚可，移植lwIP协议栈后在3个协议之间做动态调度并没有资源瓶颈。但如果你的方案里用的是低端MCU，我建议精简协议数量，优先保留Modbus TCP，再把HTTP或MQTT二选一即可。
| 协议 | 连接模型 | 数据格式 | 典型场景 | 可靠性机制 |
|---|---|---|---|---|
| Modbus TCP | 请求/响应 | 寄存器值 | 组态软件、PLC | 应用层轮询+超时重读 |
| HTTP POST | 请求/响应 | JSON/XML | Web平台对接 | TCP保证传输，业务层补偿 |
| MQTT | 发布/订阅 | 二进制/JSON | 物联网云平台 | QoS 0/1/2，Broker缓存 |
2.2 协议帧格式与寄存器映射设计
Modbus TCP的帧结构不算复杂，但细节容易出错。事务标识符（Transaction ID）、协议标识符（Protocol ID=0）、长度字段、单元标识符，然后紧跟功能码和数据区。事务ID在高并发场景下尤其值得注意，要保证请求和响应对应关系唯一，否则设备同时处理多个上位机连接时，响应错配会造成数据错乱。
寄存器映射表是Modbus的“翻译字典”，必须在设计阶段就固定下来。我的映射方案：40001温度值（带符号整数，单位0.1℃）、40002湿度值（无符号整数，单位0.1%RH）、40003设备状态字（bit0在线标志，bit1缓存区剩余比例）、40004累计掉线次数。状态字的增加非常必要，这样上位机不仅能读到温湿度值，还能诊断设备当前的通信健康状况。
对于HTTP和MQTT，上报的JSON payload设计为可配置的键值模板，例如温度字段字段名可由配置项指定。前期就考虑“平台动态适配”，后期现场改对接时就能减少固件改动次数。
2.3 多协议共存的架构思路
多协议共存不能简单粗暴地把三套处理逻辑平铺在主流程里。我采用的是协议接入层→统一数据管理层→采集控制层的三层结构。接入层分别处理Modbus请求帧解析、HTTP报文解析、MQTT消息回调，把不同来源的请求统一封装为内部数据结构。这样处理有三个明显好处：采集模块只跟标准结构体打交道，不受上游协议类型变化影响；新增协议只需要实现接入层适配器，不用动核心代码；Modbus轮询和MQTT订阅可以同时工作，不影响采集周期的确定性。
3. 断线重连机制的设计与落地
3.1 断线检测：不能只靠TCP KeepAlive
TCP协议栈自带的KeepAlive机制默认探测周期是2小时，这在工业现场根本不适用。设备掉线半小时，上位机还显示在线，这就是典型的保活失败。我的做法是应用层心跳与链路层检测双管齐下。
应用层心跳：设备作为TCP服务端时，由设备每隔5秒主动向已连接的上位机发送心跳报文（可设置）。若上位机连续3次未回应，即判定该连接已断开。心跳间隔和失败次数的关联计算需要考虑网络抖动，例如5秒间隔下选择3次连续超时判定，即最慢15秒内可完成一次“掉线判决”。同时心跳也承担“链路探活”功能，避免设备长时间无业务报文时连接被中转设备回收。
针对Modbus TCP场景，设备作为服务端，无法主动向上位机发心跳（Modbus协议本身限制了主从模式）。此时用“空闲时长检测法”兜底：如果服务端超过30秒没收到任何有效Modbus请求，就可以主动断开该连接并进入监听状态。同时设备作为客户端主动连接远程平台时，应用层心跳就很有用，可以在同一套代码里都实现，按角色启用。
3.2 指数退避与重连状态机
断线之后立即重连是最常见的坑。现场若出现大面积掉电，几十台设备同时恢复上电并尝试连接服务器，很容易把服务器端口资源打满，这就叫重连风暴。解决方案是随机化+指数退避。
具体的重连间隔设计：首次重连延迟1秒，之后每次翻倍：2秒、4秒、8秒、16秒，封顶30秒。每次重连前加上一个0到3000毫秒的随机抖动，避免多设备同步重连。连续重连失败次数达到设定值（比如20次）后，自检网络配置并维持最小频率（每60秒一次）继续尝试，防止设备在网络瘫痪期间反复空转损耗Flash寿命。
重连逻辑我强烈推荐用状态机来表达，它比简单的if/else嵌套清晰太多，读代码的人一眼能看到当前处于哪个阶段：
- DISCONNECTED：未连接或连接已断开，启动退避计时器
- CONNECTING：TCP连接建立中，等待SYN/ACK结果
- RECONNECTING：重连等待计时阶段，退避间隔累加
- CONNECTED：连接保持，正常收发数据
3.3 重连成功后的状态恢复
重连成功后，后面的动作比TCP握手本身更重要。如果用Modbus TCP，服务端需要等待客户端重新轮询，但寄存器里的“掉线计数器”和“缓存区状态”必须在上位机下一次读取时正确返回。如果用MQTT或HTTP客户端，设备连接成功后需要自动补报一条“设备上线通知”，包含设备ID、上次离线时间戳、缓存区剩余空间，让平台侧第一时间感知设备回来了。
设备IP变化是重连时容易被忽略的隐患。如果设备通过DHCP获取地址，掉线重连后可能拿到不同的IP，导致上位机配置的旧IP失效。我的方案是双重保障：优先用静态IP部署，避免地址漂移；如果必须DHCP，设备每次成功联网后主动向上位机或平台进行一次“地址通报”（HTTP上报或MQTT遗嘱消息更新）。现场调试的时候就能靠这个机制少跑很多冤枉路。
4. 断点续传机制的设计与实现
4.1 本地缓存容量与存储介质选择
断点续传的前提是“断线期间数据被可靠保存”。第一个问题是存哪里。温湿度采集频率一般是30秒到5分钟一档，假设30秒采样一次、每帧数据16字节，一小时的缓存量是1.92KB。如果目标是覆盖24小时断网场景，需要至少46KB可用缓存空间，再加上索引和磨损均衡开销，64KB起步。
实际数据帧格式需要考虑时间戳（上电时间计数或RTC时间）、温度原始值、湿度原始值、帧序号。RTC配合时间戳在补传时能标明数据真实发生时刻，否则补传的数据只能按到达时间入库，分析序列就会变形。
存储介质选择：成本敏感方案用板载Flash，SPI接口、容量2MB到16MB，写入速度尚可，适合大量采样场景。高性价比方案加外置SD卡，容量大、数据管理灵活，但要注意掉电拔卡和FATFS掉电损坏的问题。我目前的做法是板载Flash环形缓存区，满则覆盖最旧数据，确保缓存区永远保留最近N小时数据。
4.2 数据帧结构与续传流程
数据帧序号是续传流程的核心锚点。每个采集记录分配一个16位递增序号，上位机通过序号连续性就能知道断了多少数据、缺了哪一段。序号溢出时做回绕处理（超过65535后从0继续），上位机按两段区间拼接即可。
续传流程可以这样设计：
- 设备断线恢复连接后，先补报离线时长和起始序号、结束序号
- 平台响应“请求补传”指令，设备将缓存区中指定序号范围的数据按批次发送
- 每批次16帧数据，帧尾带CRC校验，平台解析后返回该批次最后序号，作为确认
- 设备收到确认后发送下一批次；若超时未确认则重发本批次
- 所有数据传完后，设备发送“续传完成”标志，平台按时间戳将数据合并入库
这套方案兼顾了可靠性和实现复杂度，比TCP层的“无脑重发”高明在可控：只要平台侧确认到某个序号，设备就可以释放那段缓存。
4.3 数据去重与顺序恢复
补传过程中最常见的异常是“确认报文丢失”。设备把第N批数据发过去了，平台也收到并入库，但确认报文在网络里丢了，设备就会重发这批数据。平台侧如果不做去重，数据库里就会插进重复记录。所以平台入库必须用“设备ID+序号”作为唯一键去重。
顺序恢复依靠时间戳而非到达时间，这一点容易忽略。到达时间只能说明“补传发生在什么时候”，不能说明“数据是什么时候采集的”。我建议平台入库时统一采用设备RTC时间戳映射的UTC时间，如果设备没装RTC，就用“上电累计秒数+设备上次校准时间”反推，但这通常不如RTC雅观。
另外，缓存区写满变成覆盖模式后，旧数据被覆盖，新数据继续写入。续传时完整状态信息里必须包含“覆盖标志”，提示平台“前面的索引已被覆盖”，否则平台按顺序等待缺失帧时，永远等不到那些已经不存在的帧，补传就会卡死。
5. 常见问题排查与实测定量分析
5.1 现场通讯问题的快速定位速查表
| 现象 | 可能原因 | 排查动作 | 解决建议 |
|---|---|---|---|
| 设备显示连接成功但数据不更新 | 上位机连接数与设备资源限制冲突 | 抓包看TCP建连和轮询请求帧 | 确认设备连接数上限，调整上位机参数 |
| 间歇性断线，恢复时间不确定 | 交换机STP收敛或端口协商不稳定 | 检查交换机日志与端口统计 | 固定传输速率/关闭端口协商，部署时避开STP |
| DHCP导致IP漂移，重连后平台找不到设备 | 地址分配变化，未同步平台配置 | 查看设备获取到的IP和平台连接记录 | 静态IP部署或联网后主动地址通报 |
| 补传数据有缺口，某些序号永远缺失 | 缓存区覆盖或存储介质异常 | 读取Flash日志索引，检查覆盖标志 | 增加缓存容量，降低采集频率峰值 |
| 多台设备同时重连导致平台卡顿 | 重连风暴，重试间隔无随机化 | 观察平台连接数峰值突刺 | 启用随机抖动+指数退避策略 |
5.2 我在实际项目里的避坑心得
MQTT QoS等级的选择，实测下来不要盲目追求QoS 2。QoS 2要求两阶段握手，设备本地网络差的时候重传状态维护占用资源明显偏高。我推荐QoS 1配合本地缓存补传来兜底，这在嵌入式设备上是效果最好、实现最轻的方案。
重连次数的记录频次要控制。有些修改日志每Flash可擦写寿命约10万次，如果每掉线一次就写一条日志，寿命很快耗尽。掉了线可以不写Flash，只维护内存计数器和上次掉电时刻，真正需要持久化的时候才写。
测试断线重连不能只靠拔网线。拔网线只验证了“链路断开”这一种情况，协议栈内部的socket异常、服务器的半开连接、NAT超时回收这些情况必须在部署环境里模拟才更接近现场。我后来专门做了一套状态注入测试脚本，用测试平台开着不同断网时长、不同频率来验证设备恢复时间，才真正把重连机制的可靠性逼出来。
5.3 可靠性与性能的折中思考
偏执地提升某个单项指标是没有意义的，比如把重连间隔调得非常短、把缓存容量无限加大，都会带来副作用。重连间隔过短会造成网络拥塞，缓存容量过大会增加Flash磨损。设计过程中掌握好“够用就好、留有余地”的度，根据实际项目的数据频率、断网容忍时长、平台处理能力来定参数，是最务实的路径。我这套系统在200个节点的中等规模部署中采用上述设计，长期运行稳定，设备掉线率控制在可接受范围，数据完整性接近99.9%。
这个项目做完后，我又把框架抽出来复用到配电房监测、冷链仓储环境保障等场景，只要调整传感器类型和协议适配层，核心的断线重连与断点续传机制可以直接复用，节省的二次开发时间相当可观。
