1. 主干道和胡同的区别：为什么现场总线正在被以太网替换
先从一个实际项目说起。去年做某药厂洁净车间的环境监控改造，业主方在技术要求里写了一条：所有温湿度采集点必须走TCP/IP以太网接口，不支持串口方案。当时现场有48个RS485接线的温湿度探头，如果只改表计接线方式，工作量倒还可控，但他们同时要求数据直接进MES系统，而且上位机要用OPC UA统一采集。我到现场看完之后就明白了，继续用RS485不是不能做，但要做协议转换、串口服务器、网关这一大堆中间层，链路一旦长了，调试周期和故障点都压不住。那一次的项目经历，让我彻底理解了工业领域里"以太网温湿度传感器"本质上不是换个网口的事，而是整个数据链路的设计思路换了。
这几年我们在工业项目里见到的温湿度传感器，形态上仍然是小变送器加探头，但通信接口正在明显从RS485/Modbus RTU转向以太网/TCP。背后原因，是工厂的信息化架构从三层往扁平化走：底层的PLC、DCS，中间层的SCADA、MES，再到上层的数据库和云平台，大家越来越希望"一条线捅到底"。而TCP/IP协议栈天然就是为这种端到端通信设计的，设备接上交换机就能跑，不用像RS485那样考虑谁是主机、谁是从机、谁先发谁后收。
不过也要说清楚，RS485并没有死，在短距离、点对点、设备数量固定的场景里它仍然便宜可靠。只是当你的测点数量上到几十上百个，数据刷新频率要求1秒以内，并且需要跨车间、跨厂区汇总时，RS485轮询模式的短板就很明显了。
为了讲清楚这个换道逻辑，我先把RS485方案在工业现场的真实痛点列出来，再对比以太网方案到底解决了什么。这块我觉得是很多选型人员没有细想过的地方。
1.1 RS485总线方案的天花板在哪
RS485本身只是物理层标准，工业上跑得最多的应用层协议是Modbus RTU。它最大的特征是"一问一答"：主机轮流问每个从机，从机收到指令后应答。听起来没什么问题，但一算账就露馅了。
假设一根总线上挂了32个温湿度探头，波特率设为9600bps时，单条Modbus RTU报文——8字节地址功能码加数据、2字节CRC16——通常在8到20字节之间。一个完整查询加应答周期约20到40毫秒。32个从机轮询一圈就是0.7到1.3秒，这还只是理想情况。如果中间有任何一个从机响应超时，主机还要等超时时间，通常200毫秒以上，轮询周期直接爆炸。想提高刷新速度？把波特率提到115200bps可以，但RS485在高速率下传输距离急剧缩短，超过200米就需要加中继器，布线复杂度和成本全上来了。
另一个麻烦是拓扑结构。RS485本质上是一条总线，虽然支持手拉手串联，但实际工程里最容易出问题的地方恰恰是接线端子松动、节点位置偏移导致的反射。每加一个新测点，都要把总线断开重新串进去，这对不停产的改造项目来说很难操作。更别说还要考虑终端电阻、偏置电阻、共模干扰，现场调试排查一套流程下来，没有半天时间搞不定。
还有一层是数据接入上层系统的代价。RS485信号要先经过串口服务器或协议网关转成TCP/IP才能进上位机软件。有些网关只支持特定品牌的协议，Modbus RTU转Modbus TCP还得做报文映射表，本来很简单一个温湿度读数，经过中间层后出了任何问题，厂商之间互相推诿就够喝一壶的。"为什么工业项目更常用以太网"，根本原因不是性能指标好看，而是链路简单、责任边界清晰。
1.2 以太网方案解决的是效率问题，不只是速率问题
以太网温湿度传感器走的是TCP/IP协议栈，物理层是10/100Mbps以太网，速率本身就不是一个量级上的问题。但我觉得普通人容易误解的一点是：TCP方案最大的价值不是"传得快"，而是"并发和全双工"。
在RS485总线里，物理上同一时刻只能有一个设备发言，这是半双工和轮询机制决定的。以太网交换机每个端口都是独立冲突域，所有传感器可以同时往服务器上报数据，不需要排队等着被问。比如60个传感器每10秒上报一次数据，如果走TCP主动上传模式，服务器只需要维持60个TCP连接，每个连接的数据帧独立到达，完全不存在"查完1号才能问2号"的等待。这个能力对实时监控系统来说意义重大。
另外，TCP是有连接、面向字节流的可靠传输协议。三次握手建立了会话，每个数据包都有序列号和确认机制，丢了会重传，乱序会重组。这在工业环境里对应的是：你的温湿度记录不会因为某个瞬间的网络抖动就丢一个包。对生产温控来说，丢一段0.5秒的数据可能导致批次追溯记录不完整，这在医药、食品行业审计时是致命的。所以凡是强调数据完整性的项目，TCP几乎成了硬指标。
从成本角度看，以太网温湿度传感器单个价格通常比RS485同等精度型号贵30%到100%，很多采购第一次看到报价单会犹豫。但算上省掉的串口服务器、网关、中继器、专用线缆以及它们对应的调试人力，在一个中等规模的测点项目里总成本反而更低。而且现在工业以太网交换机的价格已经跌到很亲民的水平，PoE交换机还能顺带给传感器供电，布线更省。
2. 拆开一台以太网温湿度传感器，看看TCP是怎么落地在里面的
有了宏观概念，我们拆开设备看硬核部分。温湿度传感器要做成以太网接口，不是简单加一个网口座子就行，它内部需要一个完整的嵌入式网络方案。目前市面上常见的架构有三类。
第一类是MCU加外部以太网控制芯片，典型组合是STM32配W5500或者CH395。STM32通过SPI接口读写W5500内部寄存器，由W5500完成MAC和PHY层的处理，开发者只需要在MCU里跑TCP/IP协议栈的应用层部分。W5500内部集成了全硬件TCP/IP协议栈，TCP的连接管理、重传、分片全由硬件完成，MCU这边只管收发数据缓冲区，编程门槛很低。很多国产温湿度变送器选的就是这条路线，因为整体BOM成本可以压得很低，代码量也少。
第二类是MCU内置以太网MAC加外部PHY芯片，比如STM32F4/F7系列本身带MAC控制器，外部再接一个PHY芯片如LAN8720A或者DP83848，然后跑LwIP纯软件协议栈。这种方案灵活性高，但调试难度明显上升：PHY芯片的寄存器配置、RMII接口时序、LwIP的内存池配置、网卡驱动中断优先级，哪一环没弄好都会出现"时通时不通"的玄学故障。我看到过不少小厂的产品在这上面翻车，表现为设备上电后得等十几秒才能ping通，或者长时间运行后TCP连接死掉。
第三类是高集成度方案，直接用带网口的单片机模组，比如乐鑫ESP32或瑞萨RA系列加内置PHY。这类芯片跑TCP协议栈非常方便，甚至可以直接上Wi-Fi或者以太网二合一模组。但工业现场对芯片的工作温度范围、抗干扰能力要求比较高，消费级Wi-Fi芯片在高温高湿车间里经常掉线，所以正规工业产品反而少用这种方案。
不管内部是哪一种架构，对外表现出来的功能是一致的：传感器把温湿度数据封装成TCP报文，发给服务器的指定端口。为了兼容工业软件生态，大多数产品会选择把应用层协议做成Modbus TCP。Modbus TCP本质上就是把Modbus RTU的报文去掉CRC16，加上MBAP报文头，然后塞进TCP的有效载荷里，占用502端口。也就是说，SCADA系统里原来写好的Modbus驱动几乎不用改，只要把连接方式从串口改成以太网就能读数据。
2.1 温湿度探头信号是怎么变成IP包的
从探头到IP数据包，完整链路是这样的。传感器探头（常见的有SHT30、SHT31、SHT35、AM2301B等）输出的是数字信号，走I2C或单总线协议。以SHT30为例，它是一个I2C接口的数字温湿度传感器，内置校准过的CMOS芯片，温度精度能达到±0.3℃，湿度精度±2%RH。MCU周期性通过I2C读取探头寄存器里的温湿度原始值，然后做换算和温度补偿，得到工程单位的数据。
接着MCU把温湿度值填写到Modbus TCP报文的数据字段里，调用协议栈的发送接口。如果是W5500方案，MCU要先把报文写到W5500的发送缓冲区，然后触发发送命令，W5500硬件自动完成TCP分段、加IP头和MAC头、计算校验和，最后通过RMII接口把数据流给到PHY芯片。PHY芯片负责把数字信号调制成双绞线上的差分电平信号，经过网口变压器和RJ45座子送到交换机。
这一整条链路里，温湿度采样的过程和网络发送的过程是异步的。采样靠定时器中断或RTC唤醒，发送靠TCP协议栈的事件驱动。好的设计会把采样周期和上报周期解耦：比如每2秒采样一次并缓存在内存里，每10秒把最近5个平均值打包上报一次。这样做的目的是减轻网络负载，也避免服务器端频繁处理小包导致CPU空转。很多刚入行的工程师不理解为什么读到的数据和传感器实际值有偏差，其实就是没搞明白上报周期和采样周期的区别。
2.2 TCP的可靠性靠的是"确认、重传、序号"三件套
TCP和UDP最本质的区别是它有状态。UDP把数据报扔到网络上就不管了，TCP却要维护连接状态、接收窗口、拥塞窗口、序列号等一堆信息。在温湿度传感器这种低速率应用里，我们最需要的是TCP的确认重传机制，保证服务器一定收到数据。
具体来说，传感器每发送一个TCP数据段，服务器收到后会回复一个ACK确认包。这个ACK里带着期望收到的下一个字节序号。如果传感器在超时时间内没收到ACK，它就会重发这一段数据。连续多次超时后，TCP会逐步降低发送速率，避免网络拥塞进一步恶化。
这套机制在RS485串口世界里是没有的。Modbus RTU靠CRC校验保证不传错，但CRC只能发现错误，发现之后怎么办？协议层面没有重传策略，丢了就丢了，下一轮轮询再读一次。对温湿度这种缓变量来说，丢个几秒数据看不出问题，但在恒温恒湿机房或者锂电池化成车间里，温度短时间越限可能直接影响产品良率，这就要求每一次越限告警都必须可靠到达。
当然，TCP的可靠性也带来了一个小问题：实时性不如UDP。因为确认重传会消耗时间，如果网络质量不好，数据到达时间会有抖动。但对温湿度监控来说，秒级甚至分钟级的数据交付完全够用，TCP这点延迟根本无感。所以"TCP协议以太网温湿度传感器"在工业项目里成为主流，本质上是牺牲了一点实时性换来了可靠性和可集成性，这笔账是划算的。
2.3 Modbus TCP和Modbus RTU的报文差异
如果你用过Modbus RTU再切到Modbus TCP，会发现地址映射几乎是透明的。两者的区别主要在报文格式上。
Modbus RTU报文格式是：从站地址(1字节) + 功能码(1字节) + 数据(N字节) + CRC16(2字节)。
Modbus TCP报文格式是：MBAP报文头(7字节) + 功能码(1字节) + 数据(N字节)。MBAP头包括事务处理标识符(2字节)、协议标识符(2字节，固定为0)、长度(2字节)、单元标识符(1字节，替代原来的从站地址)。
举个例子，读温湿度寄存器，一般用功能码0x03（读保持寄存器），起始地址和数据长度由厂商定义。假设温度存在寄存器地址0x0001，湿度在0x0002，那么Modbus TCP请求报文大概是：
00 01 00 00 00 06 FF 03 00 01 00 02- 00 01：事务标识符，每次请求递增
- 00 00：协议标识符，Modbus协议固定为0
- 00 06：后续字节长度
- FF：单元标识符，相当于原来RTU里的从站地址，以太网环境一般填FF或1
- 03：功能码，读保持寄存器
- 00 01：起始地址
- 00 02：寄存器数量
从这条报文就能看出，只要是按标准实现的设备，上位机不用关心传感器是RS485还是以太网，它发的都是同样的功能码和数据格式。这就是工业软件生态能平滑过渡的根本原因。
3. 别把DHT11那类模块和工业级温湿度传感器混为一谈
市面上有很多开发板配套的温湿度模块，DHT11、DHT22、AM2301，价格从几块钱到十几块钱不等。网上搜"以太网温湿度传感器"的人有不少是从单片机开发转过来，很容易把这类模块和工业变送器摆在一起比。先说结论：不能比，也不该比。
DHT11这类传感器本质上是把温湿度感湿元件和一个8位MCU封装在一起，用单总线协议输出数据。它的优势是便宜、接口简单、随便一个GPIO加延时函数就能读。但它的数据可靠性很成问题。首先采样精度低，DHT11温度精度±2℃，湿度精度±5%RH，这个精度做定性判断还行，做工艺控制和合规审计完全不够。其次单总线协议对时序要求极其苛刻，MCU在读数据时要精确控制电平持续时间，稍微受到中断干扰或者线缆过长，读出来的就是一串乱码。最后，DHT11的校准数据是出厂一次性烧录的，没有可追溯性证书，也无法二次校准。
相比之下，工业级温湿度传感器（不管RS485还是以太网）在设计上考虑的纬度完全不同：
第一是传感器探头的精度和长期稳定性。SHT30、SHT31、SHT35这些贴片探头出厂前都会做单独校准，校准数据存在芯片内部，而且标称漂移量有明确指标。SHT35的湿度精度能达到±1.5%RH，这在医药仓库里是硬指标。
第二是信号链路的鲁棒性。工业变送器内部有MCU做滤波、线性化、温漂补偿，外部走的是成熟的数字通信协议，不存在DHT11那种靠GPIO读取脉冲宽度来解码数据的脆弱方案。即使探头和变送器主机分离（外置探头），中间线缆也做了屏蔽处理。
第三是可靠性设计。工业以太网温湿度传感器的电源输入端有防反接、防浪涌电路，RS485接口有隔离，以太网口有网络变压器隔离。工作温度范围一般是-40℃到+85℃，而DHT11出厂只有0到50℃。你把它放到冷库或者高温烘房，数据根本不可信。
3.1 DHT11在ST/单片机项目里的定位
说到热门搜索词里有"stm32 车载以太网"和"dht11温湿度传感器stm32f1"，这类内容大多来自大学生课程设计和创客项目。用STM32F103读DHT11，把数据通过串口打印或者TFT屏显示，这是一个很好的GPIO和定时器入门练习。但要注意，这类练习的思维方式和工业产品设计是两条路线。DHT11的输出时序以微秒为精度，而MCU主频、中断优先级、编译器优化级别都可能影响读取结果。我见过有些代码为了稳定读DHT11，不得不关闭全局中断，这在实时性要求高的系统里是不可接受的。
简单说，DHT11适合做原型验证和教学，它能帮你快速理解传感器数据的读取和处理流程。但如果你要把采集到的温湿度数据用于正式项目——不管是产线监控还是节能管理——我都会强烈建议换用SHT30或者更高端的探头，配合以太网或者至少RS485的数字通信方式。数据可信度决定了整个系统的价值，不能为了省几十块钱把一个月的生产数据质量搭进去。
3.2 工业探头的标定与更换逻辑
工业温湿度传感器还有一个容易被忽视的点：标定。计量法规要求用于环境监测的数据，传感器要定期送检并出具校准报告。工业级探头一般设计成可插拔式，比如变送器主体保持不动，只更换探头部分，换完在变送器里做一下偏置校准就能继续使用。而一体式DHT11模块如果精度漂了，除了整体换掉没有别的办法。
在以太网传感器的实际项目里，标定还有一个便利性优势：通过Modbus TCP或厂家私有协议，可以在线写入校准偏置，不必像RS485那样接USB转串口线跑到机柜旁边去调。尤其是一些安装在吊顶、夹层、室外立杆上的测点，位置往往很刁钻，能通过网络远程校准，运维成本能省下一大截。
4. 选型部署里的硬核细节：从供电方式到TCP粘包
接下来这部分是本文的干货重点。以太网温湿度传感器看着原理简单，真正部署到项目里，各种细节处理不当会让系统三天两头出问题。我按从硬件选型到网络配置到软件排障的顺序梳理一遍。
4.1 供电、探头形态与环境防护选择
以太网温湿度传感器常见的供电方式有两种：DC电源适配器单独供电，PoE供电。
DC供电就是每个传感器配一个12V或24V电源适配器，或者从现场的直流电源箱拉线。好处是传感器本体成本稍低，坏处是每个测点要多布置一根电源线，而且电源适配器质量参差不齐，劣质电源的纹波会干扰传感器读数。如果现场已经规划了弱电井和UPS电源，这种方案也可以接受。
PoE供电（Power over Ethernet）是我个人更推荐的方案，前提是现场有条件使用PoE交换机。PoE用同一根网线同时传输数据和直流电，传感器只需要接一根网线到交换机，数量多的时候集中供电，停电后靠UPS统一续航，布线和维护都更清爽。PoE供电标准有802.3af（最大15.4W）和802.3at（PoE+，最大30W）两种，温湿度传感器功耗通常在1到3W之间，802.3af就完全够用。
探头形态上，一体式探头适合安装在墙面或吊顶下方，环境温湿度变化均匀的地方；分体式探头适合管道安装、壁挂式机柜内部或者需要快速响应的小空间。分体式探头线缆长度一般在1到3米，选型时要确认探头工作温度范围是否覆盖实际环境，有些耐高温探头可以做到-40℃到+125℃。
环境防护等级是经常被忽略的一个维度。洁净车间的墙面传感器一般有IP54就够了，但如果你要把传感器放到户外或者有冲洗作业的食品车间，至少得是IP65以上，并且传感器外壳要有防水接头。此外，腐蚀性气体、粉尘环境要考虑探头保护罩，避免传感器感湿元件被污染后读数长时间偏高。
4.2 IP地址规划与交换机网络隔离
以太网设备第一件事就是分IP地址。工业项目里常见的问题有两种：一是所有设备都开启DHCP自动获取，交换机上级的DHCP服务器一旦出问题，整个网络里的传感器全部失联；二是人为分配静态IP却又没有规划表，新加的传感器和现有设备冲突，大量掉线。
我的经验是，固定测点类设备全部使用静态IP，并且按站点编址。比如A车间传感器网段是192.168.20.0/24，B车间是192.168.30.0/24，预留地址段和网关地址后，传感器从.10开始递增，留出.1到.9给网络设备。如果测点数量多，建议做一个IP地址登记表，把MAC地址、IP、安装位置、序列号全部对应记录好。这个表在后续排查定位时能帮你省出几小时。
网络层面，工业以太网温湿度传感器建议单独划分VLAN，和办公网络、视频监控网络隔离。原因很简单：传感器报文少、规律性强，单独VLAN可以避免广播风暴和ARP欺骗的影响。如果担心安全问题，还可以在交换机端口上做MAC地址绑定，防止有人随意接到网络里仿冒设备。
4.3 抓包与排障：Wireshark看什么
部署调试阶段，Wireshark是最好用的工具。接在传感器和交换机之间的镜像口或者直接用笔记本接到汇聚交换机镜像端口，然后过滤传感器的IP地址和TCP端口，就能看到完整的通信过程。
第一件事是确认三次握手是否正常。过滤器输入tcp.port == 502或者传感器上报端口，正常情况下应该看到SYN、SYN-ACK、ACK三个包。如果只有SYN没有SYN-ACK，说明对端服务没起来或者防火墙拦了端口。如果有SYN-ACK但最终握手失败，多半是本地防火墙或者网络地址转换的问题。
第二件事是看数据上报的规律性。正常工作时，每过一段固定时间就有一条数据包。如果发现时间间隔忽长忽短，甚至出现大量TCP Retransmission重传包，说明网络链路质量有问题，可能是网线过长、接头氧化、交换机端口协商失败。此时查看物理层状态，确认网卡和交换机端口都是100M Full Duplex，而不是Half Duplex，全双工不匹配会造成大量冲突丢包。
第三件事是观察应用层报文内容。Modbus TCP的报文长度和寄存器值应该符合厂商协议文档，如果你在Wireshark里看到功能码不对或者寄存器地址和文档对不上，先怀疑固件版本不匹配，再从配置页面确认设备型号和固件版本。很多传感器厂家的固件升级日志会写"修正了寄存器地址偏移"，这类问题本质上是代码缺陷，但通过抓包能很快定位到是协议解析问题还是网络传输问题。
4.4 TCP粘包、拆包与上位机的处理
TCP是字节流协议，什么叫字节流？就是说底层收到的是一串连续字节，没有天然的消息边界。上层发的两个温湿度数据报可能在接收方看来被合并成了一个TCP段，也可能一个数据报被拆成了两个TCP段。这就是TCP粘包和拆包问题。
很多初学网络编程的工程师在写服务器端接收程序时会遇到一个现象：明明传感器设置的10秒上报一次，但服务器收到的数据有时候两个包连着到，有时候一个包等了20秒才到。原因就是TCP的Nagle算法和接收延迟ACK机制在起作用。Nagle算法会把多个小数据包合并发送以减少网络开销，而接收端的延迟ACK又让确认包晚一点发，两边一配合，小包的实时性就会受影响。
解决粘包和拆包，应用层协议必须定义消息边界。Modbus TCP的做法是MBAP头里有一个长度字段，指明后面还有多少个字节。接收方先读7字节的MBAP头，解析出长度字段，再按照这个长度读取后续数据。如果应用层协议没有长度字段，那就需要用特殊分隔符或者固定长度帧。上位机如果按这种方式处理，无论TCP底层怎么粘包拆包，应用层数据都能正确解析。这个原理同样适用于其他TCP设备接入物联网平台，凡是走TCP协议接入的设备，平台接入端都必须做帧完整解析，这是基本功。
4.5 和PLC对接：博途TSEND_C的BUSY问题
热搜词里有一个很具体的问题："博图s7-1500 tsend_c tcp协议发送数据太慢，总是busy"。这个我调过不少，值得单独说一下。S7-1500通过TCP协议发送自定义数据，常用指令是TSEND_C（FB65），它把连接建立和发送封装在一个功能块里。很多工程师第一次用，REQ引脚保持常TRUE，结果发现指令一直报BUSY，甚至把CPU通讯资源占满。
原因很简单：TSEND_C在REQ为TRUE时执行发送，点火后如果不复位，功能块就一直处于忙碌状态，不会处理下一次发送。正确做法是给REQ一个上升沿，发送完成（DONE为TRUE）后立刻复位，下次需要发送时再给一个上升沿。另外LEN引脚要填实际数据长度，如果填写0或者比有效数据大，也会出现发送不符合预期的情况。这个问题的经验和TCP原理是相通的：可靠传输需要明确的会话管理和状态控制，不能一把梭。
5. 项目落地后的两条腿：断线重连与长期数据管理
设备装完、通信调通，很多人以为项目就结束了。实际上，工业以太网温湿度传感器项目里，长期运行阶段的稳定性和数据管理策略，才是区分运维水平的关键。
5.1 断线重连与数据补传策略
TCP连接在运行期间一定会遇到断网、交换机重启、光纤抖动等事件。传感器侧需要设计自动重连机制，否则断一次网就老老实实停在原地等人工重启，这在现场运维是灾难。
常见的实现思路是：传感器在TCP连接异常断开后，每5到10秒尝试重连一次，连续重连失败N次后降低频率，避免频繁的SYN请求占用带宽和交换机CPU。重连成功后，补传断线期间缓存的数据。缓存的数据量取决于传感器存储空间，低端设备可能只能存几十条，好一点的可以存几千条。这个能力在合规性审计时尤其重要，温度越限记录一条都不能少。
服务器端的设计同样要注意：监听Socket要设置超时，长时间没有数据的客户端可以主动断开；客户端重连后要能重新注册；数据库写入要做好幂等处理，重复的数据包不能导致记录翻倍。
5.2 从测点到系统：数据上云前的"翻译"问题
工业现场的以太网温湿度传感器，最终数据一般会汇聚到三处：SCADA系统、本地数据库、云平台。每一处对接都要注意数据语义的映射。Modbus TCP读到的是原始寄存器值，有些传感器直接输出实际温度值（例如25.3代表25.3℃），有些则是放大10倍的整数（253代表25.3℃），上位机配置不当会把253℃当成实际温度，这属于低级但常见的错误。
另外，很多云平台接入协议走MQTT，而传感器只有Modbus TCP，中间需要一个边缘网关做协议转换。网关的采集周期、断线缓存、上行周期都要仔细配置，否则云平台上的曲线会出现"阶梯状"，没有人愿意看这种数据。我们做过一轮优化后，把边缘网关的采集周期从60秒改成5秒，上行周期保持60秒，云端曲线立刻平滑了很多，而且网关负载和流量都没有明显上升。这类调优靠的是对业务需求的理解，不是简简单单套个模板就完事。
6. 什么情况下你可以说"我们系统是可靠的"
最后想聊聊界定的尺度。很多人觉得只要传感器上了以太网，TCP协议本身就保证可靠了，这个理解不准确。TCP只保证传输过程的可靠——数据要么送达且有序，要么触发连接断开，它不保证设备本身的采样精度，也不保证整体系统的业务可靠。一个完整的可靠体系由四层组成：
- 传感器层：探头精度、采样周期、内部滤波、固件稳定性
- 网络层：以太网链路质量、交换机冗余、VLAN隔离、供电可靠性
- 平台层：TCP长连接管理、断线重连、数据幂等处理
- 业务层：告警规则、数据存储与审计、可视化与报表
四层各司其职，只有每一层都设计到位，才能在三年五年后回头看时，发现这套环境监测系统依然在稳定运行，而不是每个季度都要去现场处理一遍掉线或误报。
我现在的选型习惯是：在预算允许的前提下，优先选使用成熟以太网控制芯片方案、支持Modbus TCP和主动上报双模式、内置断线缓存、带PoE功能的以太网温湿度传感器。现场布线优先考虑PoE交换机加单根网线的方式，IP规划在项目动工前就做好，然后花一小段时间用Wireshark抓包确认设备通信符合预期。这些动作并不能让项目变得多炫酷，但能把后续运维的"惊心动魄"提前消解掉大半。
再补一个实际经验：安装传感器时，和装修、电气专业约好，网线必须做永久性标签，线缆中间不允许有非标接头。遇到过太多次"测点离线"最后查出来是天花板上有人用网线对接端子续了一段，氧化后时通时断。这种问题Wireshark抓包只能看到TCP重传增多，真正定位还是要靠物理链路逐段排查。所以，不要在小细节上节省人力，工业系统的可靠性往往就是由这些不起眼的约束堆出来的。
