工业以太网温湿度传感器：从TCP协议原理到Modbus TCP实战解析

1. 为什么工业项目里，“以太网温湿度传感器”总跟TCP协议绑在一起

在工业现场摸爬滚打的工程师，几乎都遇到过这样的对话：甲方开口就要“以太网温湿度传感器”，收到货物一看，厂家却默认按Modbus RTU配了个RS485转以太网模块；另一边的仪表柜里，PLC以太网口明明闲着，却非要走一条串口线到中控室。这背后其实藏着一个很实际的问题：我们说的“以太网温湿度传感器”，到底是把TCP/IP协议栈做进了设备里，还是仅仅给RS485设备套了一个网口壳子？搞清楚这件事，才知道为什么工业项目更倾向于选择真正基于TCP协议的一体化以太网传感器。

工业项目的选型逻辑跟消费类产品完全不一样。消费场景里，一个DHT11温湿度模块加一块STM32开发板，三五块钱成本就能把温湿度读出来，显示在屏幕上，做做室内环境监测绰绰有余。但到了工业现场，面对的是几十米甚至上百米的布线距离、变频器和大电机带来的电磁干扰、高温高湿粉尘环境，以及“数据必须进DCS/SCADA系统”的硬性要求。这时候，传感器本身准不准只是基础题，怎么把数据稳定、实时、可追溯地送到上位机，才是工业项目里真正值钱的部分。

TCP协议在这里扮演的角色，比很多人想象中更重要。它负责建立一条可靠的端到端数据通道，把温湿度数据封装成报文，经过以太网帧传输到PLC、触摸屏、工控机或者云端。和RS485的半双工轮询相比，TCP以太网方案天然具备全双工通信能力、更高的带宽余量、更灵活的组网拓扑，以及几乎不受限制的从站数量。再加上现代工业组态软件和PLC对TCP/IP生态的支持已经非常成熟，一个设备是否原生支持TCP协议，直接决定了它在工业项目的集成成本是高是低。

所以这篇内容，我想把“以太网温湿度传感器为什么在工业项目里更常用”这件事拆开讲透。不吹技术玄学，就从现场真实遇到的问题出发：硬件链路怎么搭、Modbus TCP为什么成了事实标准、接入PLC和触摸屏时有哪些坑、Wireshark抓包怎么看，以及选型时哪些参数容易被忽悠。希望你看完以后，能从“会接线的工程师”变成“真正懂这套通信体系的人”。

1.1 从布线方式看本质：以太网解决的不只是“能传数据”

先厘清一个概念：以太网（Ethernet）是物理层和数据链路层的标准，TCP是传输层协议，两者结合构成了我们常说的“以太网TCP/IP通信”。工业现场说的“以太网温湿度传感器”，核心特征就是设备内置了完整的TCP/IP协议栈，可以直接作为一个网络节点接入交换机，通过IP地址寻址、通过TCP端口建立连接，而不是依赖某个外部的串口服务器做协议转换。

从布线角度看，RS485总线需要手拉手串接，A/B两根线不能接反，终端电阻要匹配，波特率、数据位、校验位必须全链路一致。这种方案在点数少、距离短、现场电磁环境好的情况下没有任何问题。但一旦传感器数量超过十几台，或者分布在车间不同角落，RS485的痛点就出来了：轮询周期随节点数量线性增长，一个节点通信故障可能导致整个总线阻塞，排查时还得一台台断开找问题。

而以太网温湿度传感器走的是星型拓扑，每台设备一根网线接到交换机，IP地址独立，通信互不依赖。某个传感器掉线，交换机会上报端口状态，上位机巡检时也能针对单个IP做超时判断，不会拖累其他设备。更重要的是，现在工业现场普遍部署了企业级或者车间级的网络基础设施，一台支持TCP的温湿度传感器，可以直接复用这套网络，不必为几路温湿度数据单独拉一根RS485线到中控室。

当然，以太网方案也有自己的前提条件：现场需要具备网络环境，或者愿意为此敷设网线、布置工业交换机。对新建项目来说，这个成本通常很低；对老旧项目改造，则需要评估网络覆盖和布线路线。但从长期维护的角度看，以太网设备的替换、扩展、诊断都要比串口设备轻松得多。

1.2 消费级DHT11和工业级TCP传感器的本质差距

每次有人拿DHT11说事，我都觉得哭笑不得。DHT11是一款非常优秀的民用级温湿度芯片，价格便宜，单总线通信，Arduino玩家几乎人手一块。但把它放到工业场景里，至少有三个过不去的坎。

第一是供电与信号完整性。DHT11依赖单片机直接读取时序信号，线一长、环境一乱，波形畸变就会导致误码。工业级以太网传感器内部有独立的信号调理电路，传感头采集到的微弱阻容变化经过ADC转换、滤波、温度补偿后，才会被封装进协议报文。传感器到处理器之间的信号路径完全在屏蔽外壳内部，不受外部干扰。

第二是数据接口的统一性。DHT11吐出的是原始脉冲时序，需要单片机用专用代码去解析；而工业级TCP传感器对外提供的是标准的Modbus TCP寄存器，上位机只要按照寄存器地址去读，拿到什么值、单位是什么、小数点几位，都是约定好的。同样是读一个温湿度，前者是“手工解码脉冲”，后者是“打开网页看数据”，集成难度天差地别。

第三是标定和溯源。工业项目对温湿度数据往往有精度要求，比如±0.3℃、±2%RH，还要提供校准证书和年漂移指标。DHT11的精度等级和长期稳定性完全达不到这个要求。工业级传感器出厂前都会做多点标定，把校准系数写进设备固件，有些高端型号还支持现场二次校准。这些“看不见的功夫”，恰恰是工业项目敢把它接入质量体系的底气。

2. 拆解一台TCP温湿度传感器的内部链路：从探头到协议栈

理解一台TCP协议的以太网温湿度传感器，不需要把它当成黑盒子。从传感头到网络接口，中间其实只有四个环节：敏感元件与信号调理、MCU与数据计算、以太网控制器与TCP/IP协议栈、接口变压器与物理层收发器。把这四个环节搞清楚，很多调试问题就能迎刃而解。

2.1 传感与变送：模拟量是怎么变成数字量的

工业温湿度传感器的探头，常见的有两大类：一类是湿敏电容加铂电阻或热敏电阻，另一类是集成式数字温湿度芯片（比如SHT30、SHT35这类）。前者响应速度慢一些，但长期稳定性好、量程宽，适合高温高湿或者低温低湿的极端场合；后者线性度和一致性更好，标定也容易，是当前中高端工业传感器的常见选择。

不管是哪种探头，信号进入MCU之前都要经过调理电路。湿敏电容的容值变化量非常微小，需要利用振荡电路把它转换成频率或脉宽信号，再或者通过电容数字转换器直接读取出容值。温度部分如果用的是铂电阻PT100/PT1000，则需要恒流源激励再经过差分放大，消除引线电阻带来的误差。这些模拟前端的设计质量，很大程度上决定了传感器最终的测量精度，比后端用什么协议重要得多。

MCU拿到原始ADC值之后，并不是直接封包上传。它内部会跑一个温湿度补偿算法，因为湿度传感器的读数对温度非常敏感，温度变化1℃，湿度示值可能漂移0.5%RH以上。所以你会看到很多传感器说明书上标注的是“25℃下的精度”，实际上在更高温度下，精度会按曲线变化。MCU把这些补偿逻辑全部做掉，上位机拿到的才是一个经过修正的、可用的温湿度数值。

2.2 MCU与以太网控制器：TCP协议栈到底跑在哪里

“TCP协议栈跑在哪里”这个问题，直接决定了传感器的成本、功耗和稳定性。目前工业以太网传感器里，大致有四种实现方案。

• MCU内部集成以太网MAC，外挂PHY芯片：比如STM32F407、STM32H743这类自带MAC的芯片，搭配LAN8720A或者DP83848等PHY芯片。这是目前最常见的方案，因为协议栈可以借助LWIP等开源TCP/IP栈跑在MCU内部，灵活性高，成本适中，代码可控性强。
• MCU集成MAC+PHY，不需要外部PHY：比如Microchip的LAN9250系列或者某些工业级MCU，外围元件更少，但可选择性也少，通常绑定特定芯片平台。
• 内置TCP/IP硬件协议栈的以太网控制芯片：典型代表是WIZnet的W5500。这颗芯片把TCP/IP协议栈（TCP、UDP、ICMP、IGMP等）全部做在硬件里，MCU只负责通过SPI接口传输数据。好处是MCU负载极低、协议栈稳定不易出bug，坏处是灵活性受限，但做传感器这种数据量很小、连接数也不多的场景，反而特别合适。
• SoC跑Linux或RTOS，以太网作为标准网络接口：比如全志、瑞芯微的工业级核心板加一个传感器模组，这种做法适合需要本地存储、网页配置、MQTT上报等复杂功能的高端设备。

我拆过不少国产工业温湿度传感器，很多用的是W5500方案。原因不难理解：传感器上报数据量很小，几秒采一次，几十个字节的Modbus TCP报文，W5500的8个Socket完全够用，不占用主控MCU资源，而且协议栈由硬件保证，稳定性比裸机跑LWIP省心得多。

2.3 Modbus TCP：为什么它成了工业设备的“普通话”

讨论TCP温湿度传感器，绕不开Modbus TCP。它是Modbus协议族在以太网TCP/IP上的映射，端口号502，报文结构比Modbus RTU简洁不少：去掉了CRC校验和从站地址，取而代之的是MBAP报文头（事务处理标识符、协议标识符、长度、单元标识符）。单元标识符一般填1或者0xFF，用于兼容串口网关转发场景。

为什么工业现场这么认Modbus TCP？两句话：一是施耐德当年开放了Modbus协议，厂商实现成本低；二是PLC、DCS、组态软件对它的支持是“开箱即用”的，不需要额外授权或者专用驱动。

举一个实际应用中的寄存器读取例子。某型号温湿度传感器定义寄存器地址，以W5500为例，温度保持寄存器在40001（即0x0000偏移），湿度在40002（0x0001偏移），浮点数模式下可能占用连续4个寄存器。上位机要读温度和湿度，只要发一条Modbus TCP请求：

00 01 00 00 00 06 FF 03 00 00 00 02

事务标识符=0x0001，协议标识符=0x0000，长度=0x0006，单元标识符=0xFF，功能码=0x03（读保持寄存器），起始地址=0x0000，寄存器数量=0x0002。传感器响应报文返回4个字节的寄存器数据，上位机按精度定义解释成实际温湿度。整个过程就这么简单直接。

有很多读者私信问我：为什么不用更“先进”的协议？比如OPC UA、MQTT、Profibus DP或者EtherNet/IP。实话讲，这些协议各有优势，OPC UA语义建模强，MQTT适合云上集成，EtherNet/IP在AB PLC生态里集成度更高。但Modbus TCP最大的优势是“下限低、上限够用”：一个没有专业软件工程师的中小工厂，维护师傅拿一个网口调试工具就能读传感器数据。传感器厂家不用为不同品牌PLC维护多套协议栈，PLC和组态软件厂家也不用把所有传感器厂商的驱动写一遍。标准化和生态优势，比技术先进更值钱。

2.4 TCP重传、KeepAlive与工业场景的边界

TCP是一种面向连接的可靠传输协议，它通过确认应答、超时重传、滑动窗口等机制保证数据可靠送达。这套机制在以太网这种相对稳定的链路上表现得非常好，但也不是万能的，工业场景里有两个典型问题需要提前想清楚。

一个是半开连接。传感器或者上位机突然断电、网线被拔掉、交换机端口故障，TCP连接的对端可能不会立刻感知，因为FIN或RST报文根本没机会发出来。于是你会看到，连接状态还显示ESTABLISHED，但数据已经发不过去了。解决这个问题，一是靠TCP KeepAlive机制，默认情况下Linux的KeepAlive探测包间隔是2小时，对工业设备来说太长，应用层可以做更短周期的应用心跳，比如每5秒或者10秒发一个空读请求，超时未响应就主动断开重连；二是传感器厂家在设计固件时，给TCP Socket设置合理的接收超时时间，当对端多轮无响应时，主动关闭Socket并重新监听。

另一个是数据实时性与“可靠”的矛盾。TCP为保证可靠性，如果发生丢包或者拥塞，会主动降低发送速率并重传，这在大量文件传输时是好消息，但对温湿度这种周期性小数据不是问题。实际上温度变化本身是慢变量，几秒钟的延迟完全不影响控制逻辑。真正需要注意的是，不要在一条TCP连接上既跑高频率的采集数据，又跑需要严格时序的配置文件读写，避免两者因为重传机制互相拖累。

3. 那些让RS485“翻车”的现场场景，为什么到了以太网这里就顺了

我不是RS485的反对者，直到今天，RS485在短距离、少节点、低成本工业现场依然是极其优秀的总线方案。但必须承认，当项目规模变大、环境变恶劣、系统集成度变高以后，RS485的很多固有短板会逐渐暴露，而以太网TCP方案恰好把这些短板全部补上了。

3.1 轮询延迟与从站地址冲突：多节点采集的真实体验

RS485总线是半双工、主从模式的，也就是说所有通信都要等主站逐个点名，从站才能答话。假设总线上挂了20台温湿度传感器，每台传感器响应时间50ms，单纯轮询一圈就需要1秒，算上切换、广播、等待超时等额外开销，实际周期可能到2到3秒。如果还有风机、水泵、电表等其他485设备混在一条总线上，轮询周期会被拉得更长。对空调自控或者环境监测系统来说，传感器超过10台，你就会明显感觉到数据刷新有“卡顿感”。

以太网TCP方案则没有这个问题。每台传感器就是一个独立的TCP服务器，上位机可以同时建立多条TCP连接并行读取，或者用多线程并发轮询，理论上20台传感器的刷新周期和1台几乎一样，瓶颈只在上位机的处理能力和交换机的背板带宽。Modbus TCP的本地网络带宽是100Mbps，这意味着即便你在1秒内把所有传感器的所有寄存器都读一遍，也只占了可怜的一点带宽。

地址冲突的问题就更直接了。RS485靠Modbus地址区分设备，设备安装完成后如果地址写重了，会造成总线冲突和数据错乱，必须逐台断电、拨码、重新上电排查，非常痛苦。以太网设备用IP地址寻址，只要交换机端口和IP规划不冲突，两个设备之间就不会互相干扰。就算两台设备IP配重了，交换机端口指示灯和ARP表也能帮你快速定位是哪一台。

3.2 干扰、隔离与接地：为什么双绞线上容易丢数据

工业现场的电磁环境有多恶劣，跑过现场调试的人都懂。变频器一启动，附近没屏蔽的双绞线上就能感应出几十伏的共模干扰。RS485是差分信号，抗共模干扰能力不错，但它的共模电压范围有极限，一旦超过收发器允许范围，轻则通信误码，重则烧毁接口芯片。

以太网的物理层也使用差分信号（100BASE-TX用的是两对双绞线），但它有两个RS485不具备的优势。第一，以太网变压器（网络隔离变压器）提供了电气隔离，能阻断低频地环流，把设备之间可能存在的电位差挡在链路之外，这和RS485接口上外挂隔离模块的效果类似，但成本更低、体积更小。第二，以太网交换机本身对信号做了整形和转发，信号经过一级交换机后重新定时、重新放大，不像RS485总线那样所有节点共享一段物理链路，一个节点的阻抗异常就可能导致整条总线的信号质量恶化。

当然，这不代表以太网可以无视干扰。工业现场要求网线至少是超五类屏蔽双绞线（SFTP）或六类，并且屏蔽层要做单端接地；网线不要跟动力电缆同管敷设，至少保持30cm的距离；交换机要选用工业级宽温和冗余电源。这些施工规范落实到位，TCP链路的长期丢包率可以做到非常低的水平。

3.3 拓扑扩展与系统集成：从“手拉手”到“星型网络”的认知升级

RS485总线的拓扑是“手拉手”，所有设备挂在一根主干上，支线长度有严格限制（一般不超过1米）。这种结构决定了它很难覆盖空间分散的大型厂区。而以太网的星型拓扑几乎可以无限扩展，一个车间一台交换机，交换机之间用光纤或者千兆铜缆互联。传感器接在二级、三级交换机上，对上位机来说只是不同IP地址而已，逻辑上没有任何区别。

系统集成层面的差异更是明显。现在的工业项目，普遍要求温湿度数据不仅进PLC，还要进数据库、上云平台，方便做能耗分析、合规审计、设备联动。基于TCP的Modbus协议，可以非常方便地被Python脚本、Node-RED流、SCADA节点甚至Edge网关直接读取。很多边缘计算网关原生支持Modbus TCP采集，只需要把传感器的IP和寄存器地址填进去，几分钟就能把温湿度数据推送到MQTT Broker。RS485设备想上云，就得先经过串口服务器、DTU或者协议转换网关，链路长了一截，故障点也跟着多了一截。

4. 实战接入：Modbus TCP温湿度传感器与PLC/触摸屏的联调过程

写再多理论，不如给出一套能跑通的接入过程。我以最常见的两种上位设备为例：西门子S7-1500PLC和昆仑通态触摸屏，演示如何把一台Modbus TCP温湿度传感器的数据读进来。选择这两种设备，是因为它们在项目里出现频率非常高，而且踩坑点也很有代表性。

4.1 硬件连接与IP规划：先把网络层打扎实

拿到一台TCP温湿度传感器，第一件事不是连PLC，而是先把它通过网线接到电脑上，用厂家提供的调试软件或者直接用Modbus Poll工具，确认设备能正常响应。很多初学者一上来就把它接到PLC网络里，一旦IP规划有问题，PLC和传感器之间根本没法建立连接，排查难度还会叠加设备本身的配置问题。

IP规划有一套成熟的做法，建议按这样做：

• 先确定PLC的IP地址，比如S7-1500设置成192.168.1.10，子网掩码255.255.255.0。
• 温湿度传感器改成同网段的独立IP，比如192.168.1.21，确保不跟PLC、触摸屏、上位机冲突。
• 如果有多台传感器，建议用IP段分区：设备1用192.168.1.21、设备2用192.168.1.22，以此类推，避免随意设置。
• 子网掩码统一用255.255.255.0，不要轻易用非标准掩码，否则不同设备可能互相不可达。

连接方式分两种。如果传感器直连PLC的以太网口，那就是点对点连接，用一台网线即可，注意带PoE供电的传感器可能需要通过交换机供电，不允许直接把PoE电源器的输出插到PLC网口上。如果现场还有很多其他网络设备，建议统一接到工业交换机里，PLC、触摸屏、传感器各占一个端口，这是最规范的组网方式。

连接完成后，在电脑上先ping一下传感器IP，确认网络通畅后再进入PLC编程。这一步虽然基础，但能省掉后面一大半的通信故障排查时间。

4.2 PLC侧程序设计：以S7-1500“TSEND_C总是BUSY”为例

西门子S7-1500访问Modbus TCP有两种常用方法：一种是用现成的MB_CLIENT功能块，它把Modbus TCP客户端逻辑封装好了，简单粗暴，适合直接读寄存器；另一种是用TSEND_C/TRCV_C自己拼TCP报文，灵活度高，适合跟不带Modbus协议的设备通信。温湿度传感器走Modbus TCP的时候，首选MB_CLIENT。

以博途TIA Portal环境为例，具体步骤如下。

1. 在程序块中调用MB_CLIENT功能块，给它分配一个背景数据块。REQ引脚连接一个脉冲信号（比如定时器M0.5，每2秒触发一次）。
2. CONNECT引脚需要填入一个TCON_IP_v4结构体。在这个结构体里把InterfaceId填PLC网卡硬件标识符，ID填连接号（例如1），ActiveEstablished填TRUE表示主动建连，RemoteAddress填传感器IP地址（例如192.168.1.21），RemotePort填502。
3. DATA_ADDR引脚填寄存器地址。MB_CLIENT的DATA_ADDR跟Modbus实际地址有一个映射关系：如果是保持寄存器40001，DATA_ADDR填“16#40001”；如果是保持寄存器40001，功能码会自动识别。很多工程师卡在这里，因为填了“0”或者“1”，读出来的数据全是0或者错误。
4. DATA_LEN填数据长度，一般温度占1个字，湿度占1个字，填2就够。
5. DATA_PTR指向一个接收数据缓冲区，比如数组或Struct，MB_CLIENT会把读回来的数据放进去。
6. 调用MB_CLIENT后，检查STATUS引脚返回值。STATUS=0表示通信成功，非0则需要查MB_CLIENT错误代码表。

再来说TSEND_C“总是BUSY”的问题。这个情况很多用西门子PLC直接拼报文的人遇到过：第一次触发TSEND_C发送数据，之后无论怎么给REQ引脚送上升沿，TSEND_C都返回BUSY（状态码16#7002），或者发送永远不完成。

我排查过类似的案例，原因通常出在“连接没有正确建立”或者“LEN参数与实际发送长度不匹配”。TSEND_C是一个非阻塞功能块，它发送完成后需要等到DONE引脚出现一次上升沿，才能再次接收新的触发。如果上一次发送还没完成，你又给了新的上升沿，它会直接BUSY。解决思路：

• 确认TCON连接成功。用“TPCON”先建立连接，等STATUS返回0之后，再允许调用TSEND_C。
• TSEND_C的LEN参数必须与实际要发送的数据长度严格一致。Modbus TCP请求报文长度是12个字节，LEN就填12；如果填16，发送缓冲区会多出4个无效字节，传感器收到后可能当成错误请求，不回响应。
• 发送完成判断不要用REQ下降沿，而要用DONE或ERROR引脚。把DONE引脚接到一个置位线圈，用于触发下一次发送；或者用定时器控制发送周期，确保上一次已经完成。

这种“TSEND_C总是BUSY”的问题，本质上是把面向连接的TCP通信当成了无连接的串口发送来用，忽略了TCP连接的建立、保持和关闭机制。理解了这一点，以后再遇到类似问题，你就能举一反三。

4.3 触摸屏侧配置：昆仑通态与FX5UJ的以太网自由协议通信

昆仑通态（MCGS）触摸屏在国产中小项目中占有率很高，它的TCP自由协议功能特别实用。所谓“TCP自由协议”就是触摸屏直接以TCP客户端身份，向目标设备的IP和端口发送自定义报文，不需要依赖特定的PLC驱动。

以昆仑通态触摸屏读取温湿度传感器为例，配置思路是：

1. 在MCGS组态环境的设备窗口里，添加“TCP/IP设备”或者“自由口设备”驱动。不同版本的组态软件名称略有差异，但本质都一样。
2. 设置远程IP地址为传感器IP，远程端口为502。
3. 定义发送报文模板。报文模板就是Modbus TCP请求的十六进制字节串，对应上面提到的“00 01 00 00 00 06 FF 03 00 00 00 02”。注意事务处理标识符每次发送要变化，否则某些传感器会认为请求非法；MCGS的报文模板支持变量插入，可以把计数器变量嵌入到事务ID的位置。
4. 解析返回数据。MCGS收到传感器响应后，需要从回复报文的固定偏移位置截取温湿度数据，再通过数据处理函数转换成实际工程值。比如温度如果以0.1℃为单位存成一个有符号整数，就需要除以10。
5. 把解析结果存到实时数据库变量，关联到画面上的温度显示控件。

再提一嘴三菱FX5UJ与昆仑通态MT8072iE的以太网通讯。很多用户以为FX5UJ必须用三菱专用协议（MC协议）才能和触摸屏通信，其实FX5UJ也支持Socket通信，可以用TCP自由协议直接访问。但需要注意，FX5UJ的MELSEC通信端口是固定的，默认情况下没有开放TCP 502，需要用户在PLC程序里用“Socket通信功能”指令（如SP.SOCKSND、SP.SOCKSND）建立一个TCP服务器或者客户端，才能跟外部设备交换数据。对不熟悉三菱Socket指令的人来说，用MC协议更稳妥；如果非要走Modbus TCP，建议用FX5UJ自带的Modbus TCP功能指令库，官方有现成FB，移植过来改改寄存器地址就能用。

5. 用Wireshark直击温湿度上报：数据帧、TCP序号和抓包技巧

很多工程师做了好几年项目，还是不太敢用Wireshark，觉得那是网络工程师的专业工具。但实际上，学会了Wireshark，调试TCP类设备能少走一半弯路。一台传感器通信异常，你用厂家上位机软件看不到的信息——TCP握手有没有完成、重传有没有发生、数据包卡在哪个环节、报文内容到底对不对——在Wireshark里全部一目了然。

5.1 为什么现场调试必须学会抓包

我先讲一个真实的调试经历。有一回在客户现场，一台PLC读取温湿度传感器数据，偶尔读到巨大异常值，比如温度显示-86℃，湿度显示420%RH。乍一听像传感器坏了，换了一台新的，问题依旧。后来我把交换机的一个端口镜像到笔记本上，用Wireshark一抓，看到PLC发给传感器的请求报文中，寄存器地址和数量都对，但返回报文的长度和寄存器顺序跟传感器说明书不符。再仔细一看，原来上一手工程师在PLC程序里把DATA_ADDR填错了，读到的是传感器固件保留区的数据。这个问题如果靠肉眼去看PLC程序，可能一整天都找不出来；抓包一秒钟就真相大白。

Wireshark对TCP温湿度传感器调试的价值，主要体现在三个方面：

• 看连接建立：通过过滤“TCP三次握手”，确认客户端和服务器之间的SYN、SYN-ACK、ACK是否正常完成。
• 看数据交互：通过过滤Modbus TCP协议号502，逐条检查请求和响应报文的内容，确认寄存器地址、数据格式是否符合预期。
• 看异常性能：通过Wireshark的IO图形和统计功能，查看通信是否有大量重传、延迟抖动和零窗口，判断到底是网络问题还是设备处理能力问题。

5.2 从以太网帧到应用层数据：看懂那一串字节

在Wireshark里双击一个温湿度上报的数据包，你能看到完整的协议层级展开。很多嵌入式工程师对“以太网帧格式”这几个字很熟，但真正用Wireshark看数据包的时候，容易把每一层的含义弄混。这里把链路串一遍。

以太网帧（数据链路层）由目的MAC地址（6字节）、源MAC地址（6字节）、类型字段（2字节，IPv4对应0x0800）、数据部分（至少46字节）和帧校验序列FCS（4字节）组成。Wireshark抓包时会把前导码和FCS过滤掉，所以你看到的一般是从目的MAC开始的48位地址。

再往上是IP层（网络层），里面有源IP、目的IP、协议类型（TCP对应6）、TTL、标识符和分片偏移。对本地网络通信来说，TTL初始值一般是64或128，如果你看到TTL变成63甚至更低，说明数据包经过了多个三层设备，这可能暗示你的传感器和上位机不在同一个二层网络里。

然后是TCP层（传输层），包含源端口、目的端口、序列号、确认号、标志位和窗口大小。温湿度传感器的数据量很小，一般不会触发大窗口机制，但窗口突然为零，说明接收端应用程序处理不过来或者缓冲区已满，需要检查接收端是否有阻塞。

最后是Modbus TCP应用层，它挂在TCP载荷的最前面。MBAP头部前面已经讲过，功能码后面跟的是数据内容。比如读保持寄存器请求，功能码03，后面是起始地址和寄存器数量；应答报文功能码03，后面是字节数和寄存器值。如果你在Wireshark里看到的功能码是0x83或者0x01，那是Modbus异常响应，0x83表示“寄存器数量错误或地址越界”，0x01表示“非法功能码”，这时候就要回头检查传感器说明书和PLC配置了。

5.3 排查“TCP发送总是BUSY”问题的完整排查链路

前面提到西门子S7-1500用TSEND_C发送数据时出现BUSY问题。这里给一套标准的排查链路，你在现场也能照着走。

第一，抓包确认TSEND_C有没有真正发出数据。如果在Wireshark里看不到目的端口502的SYN包，说明TSEND_C根本没进入发送流程，问题多半在REQ触发逻辑或连接建立上。检查TSEND_C前面的调用条件是MODBUS请求的“使能”置位，确认你用的是沿触发而不是电平触发。

第二，如果看到了SYN包，但对方没有回SYN-ACK，说明传感器没在监听该端口。这时用网口调试助手直接连一下传感器的502端口，如果也连不上，可能是传感器本身的TCP服务没有启动，或者被防火墙拦截了。

第三，如果三次握手完成了，TSEND_C还是BUSY，那就要看TSEND_C的DONE信号有没有被正确复位。TSEND_C在发送完成后DONE会变成TRUE，但下一次调用前必须先清掉DONE，否则功能块会认为上一次发送尚未结束。很多工程师在程序里用了直接复位或者置位/复位的指令，DONE信号一直接通，TSEND_C就永远BUSY。

第四，如果发送完成DONE正常，但传感器一直不回响应，用Wireshark看请求报文内容。最常见的问题是把Modbus TCP请求报文的长度字段填错，或者寄存器地址高位低位颠倒了。Modbus TCP采用大端字节序，寄存器地址0x0000在报文里必须写成00 00，不能写成00 01，也别把高字节和低字节换过来。

6. 选型前必须想清楚的四件事：防护、供电、精度与协议兼容

如果你看完前面的内容，已经决定在项目里采用TCP协议的以太网温湿度传感器，那选型环节我建议再花点心思。市面上同类产品十几家在做，宣传参数看起来都差不多，实际上差距可能很大。结合我自己的项目经验，有四件事必须逐一确认，否则用起来全是坑。

6.1 防护等级与外壳材料比芯片更影响长期稳定性

工业传感器最怕的不是芯片坏，而是“环境把芯片周围的环境搞坏了”。温湿度传感器需要开孔保证空气流通，但开孔又会让水汽和粉尘进入内部。所以外壳的防护设计非常关键。IP65的外壳能防喷水、防粉尘进入；IP66还能防强力喷水。如果传感器安装在室外或者高湿车间，至少要求IP65以上，而且进线口要用防水格兰头固定网线。

另一个容易被忽略的指标是工作温度范围。传感器自身的电子元件工作温度范围窄，比如-10~50℃，到了北方冬天的室外或者南方夏天的室外，内部电气性能会劣化，测量数据也可能漂移。选型时要注意区分“探头测量范围”和“整机工作温度范围”，这两个概念经常被厂家混在一起标。如果是冷库、高温烘房这类极端场景，更要确认整机在目标温度下能够正常工作。

6.2 PoE供电与DC供电怎么选

TCP以太网传感器比RS485设备多一个网口，供电方式也有了新选择。主流的供电方式有三种：DC端子供电、PoE（以太网供电）供电、以及DC和PoE双供电。我的建议是：能选双供电优先选双供电，其次选PoE。

PoE的最大好处是一根网线解决通信和供电，布线成本低、现场整洁、维护也方便。但PoE有两个注意点：

• 标准兼容性：PoE有802.3af（15.4W）、802.3at（30W）、802.3bt（60/90W）几个标准，温湿度传感器功耗一般只有1~3W，802.3af就足够了。但很多工业交换机只提供802.3bt的PoE口，向下兼容一般没问题，个别老型号可能不兼容，需要提前确认。
• 网线质量：PoE供电对网线质量有要求。用劣质铜包铝网线，不仅供电距离会缩短，还可能因为线阻发热导致传输质量下降。工业场景建议使用至少超五类以上、纯铜线芯的屏蔽网线，PoE供电距离最长100米，实际上质量好的网线可以到120米，但别赌这个余量。

DC供电相对简单，但要注意电压范围。工业现场传感器供电一般跟PLC共用24V开关电源，如果现场电压波动大，而传感器只支持12V供电，那就容易烧坏。选型时尽量选宽电压输入的，比如DC 9~30V或者DC 12~24V，对现场容错性更高。

6.3 精度与年漂移：不能只看出厂校准

温湿度传感器的精度指标，厂家喜欢用“±0.3℃、±2%RH”这种看起来很漂亮的数据吸引你。但几个问题必须问清楚：

• 这个精度是“在25℃、50%RH标定点”下的精度，还是“全量程范围内”的精度？后者如果还能做到±0.3℃，那才是真本事。
• 标定是出厂时逐台做，还是抽检做？逐台标定的传感器一致性更好，但价格也更贵。
• 年漂移是多少？工业项目通常要连续运行三五年，湿度传感器尤为关键，湿敏元件会随暴露在污染空气中时间增加而缓慢漂移。好一点的传感器年漂移低于0.5%RH/年，差的可能到1%RH/年以上。如果项目有环保、医药、电子半导体这类合规要求，还要确认传感器是否有校准证书出具能力，以及能否做现场二次校准。

6.4 协议兼容清单：别买回来才发现在组态软件里不认

最后这个问题最让人头痛。部分传感器厂家虽然标称“支持Modbus TCP”，但寄存器地址定义非常“随心所欲”：温度放在30001输入寄存器，湿度放在40001保持寄存器，还有一些状态位、报警位散落在各个位置。如果你的PLC和触摸屏对Modbus寄存器类型支持不够灵活，集成起来会非常痛苦。

选型时尽量让厂家提供以下资料：

• 完整的Modbus寄存器表，包括寄存器类型、地址、读写权限、数据类型、单位、缩放系数。
• 设备支持的TCP Socket数量。多台上位机同时连接时，如果设备Socket数不够，可能出现第二台上位机连不上的情况。W5500一般是8个，Linux方案可能64个以上。
• PLC和组态软件的兼容性测试证明，或者至少提供“已经与哪些主流组态软件联调成功”的案例列表。比如MCGS、WinCC、组态王、LabVIEW、Node-RED，这些生态里有没有现成驱动，决定了你项目后期要不要自己写脚本。

7. 围绕TCP温湿度传感器，我自己的几个经验心得

从最开始玩DHT11，到后来在车间里部署几十台工业级TCP温湿度传感器，我对这套东西的认知经历了一个变化过程。这里分享几个掏心窝子的经验，供大家参考。

第一个心得是：**TCP通信排障，永远从下往上查，不要跳过物理层直接看软件。**有一次传感器连接频繁断开，我查了半天PLC程序和Wireshark包，最后发现是现场用了普通非屏蔽网线，网线又跟变频器出线捆在一起，电磁干扰把协商速率打到了10Mbps还频繁掉线。换成屏蔽工业网线后问题彻底消失。物理层的问题不解决，上层协议做得再好也是白搭。

第二个心得是：**传感器厂家给的示例代码和配置工具可信，但也要存疑。**很多国产传感器附带的调试软件，其实只是把寄存器地址固定封装好了，没有把所有细节暴露出来。你在自己的PLC或者上位机里重新配置时，一定要按照厂商寄存器表自己算一遍地址，不要想当然地认为“40001就是第1个地址”。不少厂家的寄存器表从0开始编，导致TCP报文里的地址和PLC里的DATA_ADDR差了一个偏移，通信能通但读出的数据不对。

第三个心得是：**别为了“先进”盲目上云。**TCP以太网只是打通了传输链路，数据该进PLC就进PLC，该进SCADA就进SCADA，不要一上来就想着把温湿度数据推到云端App。工业现场最重要的是稳定可控，先把本地闭环跑通、跑稳，再考虑上云的事。云平台连接一旦出问题，反而会影响现场操作人员对系统的信任。

最后一个技巧是：**给每一个TCP传感器配一张“设备信息卡”。**卡片上记录设备IP、MAC地址、安装位置、Modbus寄存器地址、固件版本、校准日期，贴在设备外壳内侧或者机柜门上。看似简单，但在后期运维、故障排查、年度校准时，能帮你省下大量时间。尤其是做了网络扩容或者IP重新规划之后，这张卡就是你的救命稻草。

TCP协议的以太网温湿度传感器，在工业项目里越来越常见，绝不是因为“以太网听起来高大上”，而是它真正解决了多节点采集、远程集成、故障隔离、系统扩展等一连串实际问题。希望你看完这篇内容，能从“会用”变成“懂原理”，再遇到相关项目时，能根据自己的现场情况做出更准确的判断。