以太网温湿度传感器与Modbus TCP：工业环境监控的优选方案

1. 先搞清楚：以太网温湿度传感器到底是什么

说实话，第一次听到"TCP协议以太网温湿度传感器"这个名字的人，多半会愣一下：一个测温度湿度的传感器，怎么还跟网络协议扯上关系了？

简单说，这就是一个自带网口的温湿度探头。你可以把它理解成一台微型小电脑，内置了温湿度采集电路和一个以太网接口，通电以后直接插网线就能接入局域网。它采集到的温度、湿度数据，通过TCP/IP协议打包，以标准的工业通信协议（绝大多数是Modbus TCP）发送给上位机、PLC、触摸屏或者数据采集服务器。整个过程不需要额外的串口转换器，也不需要RS485总线，网络通到哪里，数据就能到哪里。

我用过不少类型的传感器，从最早的模拟量输出（4-20mA、0-10V），到后来的RS485+Modbus RTU，再到现在的以太网口传感器。回头来看，以太网温湿度传感器之所以在工业项目里越来越常见，核心就一句话：

它把"数据采集"和"网络传输"这两件事直接合并了，省掉了中间一堆协议转换和设备调试的麻烦。

如果你正在给机房、仓库、冷库、配电房、养殖场或者洁净车间做环境监控，或者是搞物联网数据采集的工程师，这篇文章会帮你看明白：为什么工业项目里大家宁可多花几十块钱选以太网口的温湿度传感器，也不用传统的串口方案；以及拿到设备之后，从接线到读数据的完整实操流程，还有我踩过的坑。

先说结论：选型这件事，没有绝对的最好，只有最合适的场景。但工业项目里，以太网温湿度传感器确实在大多数场景下占据了明显优势。

2. 为什么工业项目更爱用它：四种方案横评

2.1 传统方案与以太网方案的底层差异

工业环境监控的传感器输出方式，市面上主流的就这几种：

• 模拟量输出：4-20mA电流环或者0-10V电压信号，配AI模块（模拟量输入模块）采集。
• RS485总线 + Modbus RTU协议：传感器并接在总线上，通过轮询方式读取。
• 以太网接口 + Modbus TCP协议：传感器直连交换机，通过网络读取。
• 无线方案：LoRa、NB-IoT、4G DTU等，适合无可布线条件或远距离场景。

前两种是很多老工程师的习惯方案，尤其是RS485+Modbus RTU，在工业现场统治了二十多年。它稳定、抗干扰、成本低，一条双绞线可以挂几十个设备。但它的短板也非常明显。

2.2 RS485方案的真实痛点

带过现场的人深有体会：RS485总线看着简单，实际调试起来相当考验耐心。

第一，布线有讲究。手拉手串联，不允许星型连接，A/B线不能接反，终端电阻要按需匹配。现场电工师傅要是不熟悉这套规矩，很容易给你接成一团乱麻。

第二，轮询效率低。RS485是半双工通信，主站一次只能问一个从站，问完一个再问下一个。如果你有几十个传感器，一个轮询周期可能就是好几秒。数据量一大，实时性就吃紧。

第三，需要额外的转换设备。PLC要接RS485总线，往往得配通信扩展模块或者专用的协议转换网关。PC上位机要用USB转485的线。这些额外的设备，每一样都是成本，每一样都是潜在的故障点。

第四，传输距离和速率受限。RS485在9600bps下理论上能到1200米，但实际项目里受线缆质量、干扰、节点数量影响很大。而且它的物理层决定了它抗雷击和浪涌能力有限，户外场景还要加防雷器。

2.3 以太网方案的三个关键优势

以太网温湿度传感器能解决上面大部分问题：

组网方式灵活。以太网是星型拓扑，交换机一拖几十台设备轻轻松松。线缆用超五类或六类网线，布线规范和网络施工完全一致，电工师傅也好上手。

通信效率高。全双工通信，百兆网络跑Modbus TCP，单条请求的响应时间在毫秒级。即使挂几十个传感器，轮询一圈也就是几百毫秒的事情，实时性比RS485高一个量级。

海量数据并发能力。TCP协议天然支持多客户端同时连接。也就是说，一个传感器的数据，可以同时被PLC读取、被上位机软件读取、被MES系统读取，互不干扰。而RS485要搞多主机访问，那就复杂了。

加一个更实际的场景。现在的工业项目，环境数据往往要传给云端或者工厂的MES系统。以太网温湿度传感器接上交换机，数据直接就能往上层送。而RS485方案，你还得配一个工业网关，把Modbus RTU转换成Modbus TCP或者MQTT才能上云。网关选型、配置、维护，又是一堆事情。

2.4 工业场景为什么默认选Modbus TCP

提到以太网温湿度传感器，就绕不开Modbus TCP协议。工业现场默认它作为以太网通信协议，不是为了追新，而是它太适合工业场景了。

Modbus TCP本质上是Modbus RTU协议跑在TCP/IP网络上。它的帧结构相比RTU没有复杂校验，因为TCP/IP自带差错控制。它的端口固定为502，功能码和寄存器地址映射和RTU基本保持一致。这意味着：

• PLC柜子里不需要额外配置，很多中大型PLC（西门子S7-1200/1500、三菱FX5U、欧姆龙NX系列）本身就内置以太网口并且支持Modbus TCP通信。
• 上位机组态软件（组态王、WinCC、LabVIEW）自带Modbus TCP驱动，配置一下IP和寄存器地址就能读。
• 如果你会写代码，一个Python脚本就能轻松读出数据，接入自己的系统。

简单来说，Modbus TCP就是工业设备之间约定的"普通话"。对于温湿度传感器这种只需要周期性上报几个数据的简单设备来说，Modbus TCP足够简单、足够稳定、足够通用。

2.5 使用以太网传感器的代价

不能只说优点，也得客观说说代价。

成本方面：同样精度的温湿度传感器，RS485版本可能一百多块，以太网版本要贵几十到一百来块。如果传感器数量多，这个成本差异会放大。

供电方面：很多以太网温湿度传感器不支持PoE（以太网供电），需要单独供电。这就意味着现场除了网线，还得拉一根电源线。不过现在市面上也有支持PoE供电的型号，一根网线搞定电源和数据，布线省很多事，选型的时候注意看清楚参数。

IP地址管理：每个传感器都是一个独立的网络设备，需要占用一个IP。设备多了，IP规划要做好，不然容易冲突或者混乱。好在现在大多数传感器支持DHCP，也支持通过工具软件批量修改IP，管理起来比想象中轻松。

所以，项目里如果传感器数量不多（比如不到100个）、有现成的网络设施，选以太网方案是很划算的。如果传感器数量特别大（几百上千个）且全部集中在几个狭窄的采集点，RS485总线也仍然有自己的优势。这个后面再展开。

3. 协议细节拆解：Modbus TCP报文到底长什么样

3.1 MBAP报文头和PDU结构

很多做应用层的工程师，对Modbus协议的理解停留在"会用工具读取"的程度。但如果出了问题，不懂协议就抓瞎。

Modbus TCP的报文结构分为两部分：MBAP报文头（7字节）和PDU（协议数据单元）。

MBAP头一共7个字节，包含四个字段：

字段	长度	说明
Transaction Identifier（事务标识符）	2字节	用来匹配请求和响应，每次请求递增
Protocol Identifier（协议标识符）	2字节	Modbus协议固定为0x0000
Length（长度）	2字节	后面PDU加Unit ID的总字节数
Unit Identifier（单元标识符）	1字节	相当于RTU模式下的从站地址，TCP模式下默认填0xFF或0x01

PDU就是功能码加数据部分。对于温湿度传感器这种数据采集类设备，最常用的功能码有两个：

• 0x03：读保持寄存器（Read Holding Registers）
• 0x04：读输入寄存器（Read Input Registers）

温湿度传感器通常把采集到的数据放在输入寄存器或者保持寄存器里面，具体用哪个，还得看厂家的说明书。有的厂家两个都支持，有的只支持其中一个。

3.2 温湿度数据存储格式与字节序

温湿度数据存在寄存器里，不是简单地把温度值直接放进去，而是经过了一次换算。

常见的有两种情况：

一是整数放大存储。比如温度实际是25.6℃，寄存器里存的是256。也就是说真实值 = 寄存器值 / 10。湿度同理，实际湿度65.2%RH，寄存器存652。这是最常见的格式，因为温湿度传感器精度通常是小数点后一位，整数线性放大刚好能表达。

二是原始ADC值转换。部分高端传感器需要在程序里做线性换算，公式一般是资料里给的，比如温度 = 寄存器值 × 0.01 - 40。这种情况多见于带了SHT30、SHT35、DHT21等数字温湿度芯片的高端变送器。

还有一个很多人会踩坑的点——字节序。Modbus寄存器是16位的，高字节在前低字节在后（大端模式）。大多数传感器按这个顺序存储温度值，但也有一些厂家的设备是小端存储。读取出来的数值明显不对的时候，第一件事就是检查字节序。

以温度25.6℃为例，寄存器十六进制应该是0x0100。如果你读出来0x0001，那就是字节序反了，需要在程序里做一个字节交换。

3.3 用Wireshark抓包看一次完整的请求响应

理论讲多了有点抽象，我直接贴一次实测的抓包数据。

请求报文（主机发往传感器，IP 192.168.1.100 → 192.168.1.200，端口502）：

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

拆开看：

• 00 01：事务标识符，第1次请求
• 00 00：协议标识符，Modbus协议
• 00 06：后续还有6个字节
• 01：单元标识符，设备地址1
• 03：功能码，读保持寄存器
• 00 00：起始寄存器地址，从0x0000开始读
• 00 02：读取2个寄存器，正好对应温度和湿度

响应报文（传感器返回）：

00 01 00 00 00 07 01 03 04 01 00 02 8C

• 00 01：事务标识符，和请求对应
• 00 00：协议标识符
• 00 07：后续有7个字节
• 01：单元标识符
• 03：功能码
• 04：后面有4字节数据
• 01 00：第一个寄存器值，十进制256，对应温度25.6℃
• 02 8C：第二个寄存器值，十进制652，对应湿度65.2%RH

如果在Wireshark里看到完整的有来有回，说明物理链路、IP配置、TCP连接都是好的。如果只有请求没有响应，问题就在传感器侧或者网络路径上。

3.4 几个常见寄存器的坑

第一个坑：寄存器地址偏移。Modbus协议里，保持寄存器的地址范围是40001-49999，输入寄存器是30001-39999。但TCP报文里，起始地址是从0开始的。也就是说"40001"在报文里写的是"00 00"，"40002"写的是"00 01"。有些厂家说明书直接写"温度寄存器地址为40001"，如果你把这个当成报文里的起始地址去读，那读出来的可能是错的。实际操作中，要看说明书里给的是协议层地址还是数据模型地址，自己心里要清楚差了一个1的偏移。

第二个坑：温湿度数据中可能穿插状态寄存器。有些传感器寄存器映射表里，01是温度，02是湿度，03是报警状态，04是设备地址。如果你一次性读4个寄存器，就要留意哪些是你要的，哪些不是。别把状态值当成湿度来判断，不然一个报警位就能让你的监控曲线出现一个"假湿度"尖峰。

第三个坑：负温度怎么表示。冬天冷库里面零下20度是常态。寄存器是16位有符号数还是无符号数，直接决定了读出来的对不对。如果是无符号数存储，+65535-20=65515，按无符号读会读出一个巨大的数值。有些传感器厂家把负温度做了偏移处理，比如实际值+1000=寄存器值，这样-20℃就存成980。读之前仔细看说明书的数据格式定义，这是必须养成的习惯。

4. 实操：从开箱到数据入库的全过程

4.1 选型时重点看的参数

设备到手前，先给选型划个重点。以太网温湿度传感器厂家和型号不少，我总结几个挑选时必须确认的参数：

参数	怎么选	原因
温度量程	根据应用场景	-40~80℃覆盖绝大部分工业场景，冷库要选-40~60℃或更宽的
温度精度	一般±0.3~0.5℃够用	要求更高就选±0.1℃的探头，但价格成倍涨
湿度精度	±3%RH是及格线	±2%RH属于较好水平，特别精密的才需要±1%RH
供电方式	DC 12-24V居多	有些支持PoE，布线更方便
防护等级	IP65以上	在潮湿、粉尘环境很有必要
通信协议	确认支持Modbus TCP Server	大多数支持，少数只支持私有TCP协议，要避开
探头类型	一体式还是分体式	高温管道场景必须分体式，探头远离电路板

一个冷门的坑：有些传感器的"以太网接口"只是让Modbus RTU数据跑在TCP里，但并不完全符合标准Modbus TCP的寄存器映射。使用前最好先抓包确认一下，不然程序写好了才发现协议不标准，返工成本就高了。

4.2 接线和IP配置的现场操作

拿到设备之后，现场操作分三步。

第一步：接线。绝大多数以太网温湿度传感器供电是DC 12-24V，网线插到交换机上。Power和Link指示灯亮了，说明供电和网络都正常。这里有件事要说一下，就是有些工业现场对网线的线序要求很严格。传感器到交换机这一段，如果距离短（小于50米），用成品超五类网线就够。但如果走桥架或者穿管，建议六类纯铜网线，抗拉强度和抗干扰性能都更好。

第二步：规划IP。工业项目里，我习惯把传感器单独规划一个网段，比如192.168.1.200到192.168.1.250，和PLC的IP段分开。不是说不能同段，而是分开管理起来更清晰，排查故障时一眼就能看出哪些IP是传感器、哪些是PLC。

传感器出厂IP一般是192.168.1.200之类的固定地址。如果你手头用的是笔记本电脑，先把电脑的IP改成和传感器同网段（比如192.168.1.100），再打开浏览器访问传感器的内置Web配置页面，或者用厂家提供的配置工具扫描局域网里的设备，就能找到它。

第三步：修改IP和基本参数。在配置页面里，把IP改成规划好的地址，子网掩码设成255.255.255.0，网关看现场网络情况，如果不需要跨网段就填0.0.0.0或网关地址都行。另外，一些传感器可以设置上报间隔、报警上下限、Modbus从站地址等，按需修改。

这里有个细节：改完IP以后，原先连接设备的TCP连接会立即断开，如果配置页面没有自动跳转，需要你把电脑IP再改成新网段，重新连接。

4.3 用Modbus Poll验证通信

电脑上打开Modbus Poll（Windows上最常用的Modbus调试工具），新建连接，选择Modbus TCP/IP模式，填传感器的IP地址和端口502，从站地址填1或者0xFF（取决于设备说明书），功能码选03或04（和寄存器类型对应），起始地址填0，数量填2，然后轮询。

正常情况下，几毫秒内就能在界面上看到温度、湿度的寄存器值。

如果显示超时，按下面的顺序排查：

• ping一下传感器IP，ping不通说明链路问题，查网线、交换机、IP配置。
• ping通了但Modbus报文无响应，用Wireshark抓包，看请求是否发出、是否有响应。只有请求没有响应，说明传感器侧通信模块或者寄存器地址有问题。
• 有响应但数据明显不对，检查功能码、起始地址、从站地址、字节序。

4.4 用Python实现批量读取和存储

调通了Modbus Poll，接下来就是把数据接到自己的系统里。这里我用Python示例写一下，方便大家直接抄作业。

先安装依赖库：

pip install pymodbus

然后写一个简单的读取脚本：

import time from pymodbus.client import ModbusTcpClient SENSOR_IP = "192.168.1.200" SENSOR_PORT = 502 UNIT_ID = 1 def read_temp_humidity(client): # 读取保持寄存器，起始地址0，读2个寄存器 result = client.read_holding_registers(address=0, count=2, slave=UNIT_ID) if result.isError(): print("读取失败:", result) return None, None # 注意字节序和放大倍数按说明书调整 temperature = result.registers[0] / 10.0 humidity = result.registers[1] / 10.0 return temperature, humidity def main(): client = ModbusTcpClient(SENSOR_IP, port=SENSOR_PORT, timeout=3) connected = client.connect() if not connected: print("无法连接到传感器") return print("连接成功，开始轮询...") try: while True: temp, humi = read_temp_humidity(client) print(f"温度: {temp:.1f} ℃, 湿度: {humi:.1f} %RH") time.sleep(5) except KeyboardInterrupt: print("退出") finally: client.close() if __name__ == "__main__": main()

如果要同时采集多台设备，不要用单线程逐个串行读，用多线程或者异步协程效率高很多。Modbus TCP的请求是同步阻塞的，串行读10台设备耗时就是10次网络往返时间加起来。改成异步后，10台设备可能一秒内全部读完，实时性提升明显。

4.5 用Python和开源工具实现批量采集

除了Modbus Poll，还有很多好用的工业数据采集工具值得推荐。我在实际项目里最常用的是Node-RED（一个可视化流编排工具），它自带Modbus节点，拖拽几下就能完成数据采集、清洗、入库、告警的流程。特别适合快速搭建环境监控的原型系统。

举一个实际例子：机房里有5台以太网温湿度传感器，我用Node-RED搭了一个采集流，每个传感器一个Modbus节点，5秒轮询一次，数据直接写入时序数据库InfluxDB，再用Grafana做可视化大屏。整个流程从搭框架到上线，用了不到半天时间。如果这些传感器是RS485接口的，光是把5条485总线接到工控机上就要多花不少功夫。

4.6 接入PLC的配置方法

工业项目里，数据最终要送到PLC里去参与逻辑控制的，这个场景也很多。

以西门子S7-1200/1500为例，你不需要写ST语言，直接用PLC内置的Modbus TCP客户端指令就行。

在博途（TIA Portal）里，调用MB_CLIENT功能块，配置好如下参数：

• DISCONNECT：0表示保持连接
• CONNECT：填一个TCON_IP_v4类型的连接描述，包含PLC的IP、传感器IP、本地端口、远程端口502
• MB_MODE：0代表读
• MB_DATA_ADDR：填40001（对应报文里的起始地址0）
• MB_DATA_LEN：填2
• MB_DATA_PTR：指向一个存放读取结果的Data Block
• MB_DATA_LEN：数据长度

轮询周期一般设置1-5秒，足够监控用了。

有一点要注意：S7-1500的TSEND_C指令（对第三方TCP设备做原始套接字通信时用的比较多）如果频繁发送且上位机处理不及时，会出现busy状态。遇到这种情况，通常是连接没有处理好，需要在上位机侧确认每个TCPConnection实例是独立的，或者增大发送缓冲。如果你不打算自己解析协议，直接用MB_CLIENT就好，它内部已经把TCP连接生命周期管理好了。

顺带提一个踩过的坑：S7-1200/1500的PLC通过Modbus TCP读取第三方寄存器时，有些厂家的传感器对连续读取长度有限制，一次最多读2个或4个寄存器。如果你一次读8个寄存器超时，就改小一次读的长度，分多次读。

5. 常见问题与排查技巧实录

5.1 网络通了但Modbus报超时

这个现象很常见：ping传感器能通，但Modbus Poll读取超时。我遇到过的原因有几种：

TCP 502端口被占用。传感器到上位机这条链路中间有个交换机或者路由器做了端口限制，502端口不通。排查方法是用telnet命令：

telnet 192.168.1.200 502

如果提示连接失败，说明502端口没有通，查交换机的端口策略或防火墙规则。这里补充一句，工控网段里面这类问题通常不是故意拦截，而是网络工程师在配置交换机时只放行了特定端口，需要联系网络管理员放通502端口。

Modbus从站地址不对。Modbus Poll里的Unit ID填1读不到，试试填0xFF。很多TCP传感器默认从站地址是0xFF而非1。

传感器只能接受单客户端连接。有些低端传感器固件只允许一个TCP客户端保持连接，Modbus Poll占着连接不放，你程序里再连就连不上。这是固件限制，没有太好的办法，只能保证同一时间只有一个客户端在轮询。

5.2 读取的数值是千位级的大数

刚接触Modbus的新手最容易懵的场景：温度读出来是65516这样的数，或者湿度读数在几千甚至几万。

原因九成是数据格式不匹配。先从最基础的查起：

• 寄存器是16位有符号还是无符号。
• 温度是否带符号位，负温怎么编码。
• 寄存器值需要除以10还是除以100，还是原始ADC值需要做线性换算。
• 厂家是把温度和湿度各放一个寄存器，还是把温度低字节和状态位合在一起。

一般厂家说明书里有"寄存器定义表"，专栏一列是寄存器地址，二列是数据类型，三列是换算公式。对着表，一条一条核对你的代码。

5.3 多台传感器轮询耗时太长

有朋友问我，30台以太网温湿度传感器，用PLC的MB_CLIENT一块轮询一遍要10秒，实时性太差怎么办。

这里有两个层面的优化思路。

协议层面，检查是不是每个传感器都建立了独立的TCP连接。Modbus TCP握手开销高，频繁建立连接很浪费时间。如果PLC的MB_CLIENT能支持连接保持，就把连接一直保活，不要每轮询一次就断开重连。

算法层面，如果传感器固件支持，可以修改数据上报模式。有些传感器支持主动推送模式，服务器端不需要轮询，传感器自己按间隔推送数据。这个模式更适合大量传感器的场景，但要确认固件支持。

软件层面，如果数据最终要交给上位机做展示和报警，可以考虑用独立的数据采集网关来轮询传感器，再把数据通过OPC UA或者MQTT传给上位机和PLC。PLC不必自己一个个去问，它能省出通信资源去跑核心逻辑。

5.4 Windows电脑突然没有以太网选项

排查时偶尔会遇到这种情况：设备管理器里有网卡，网络适配器也正常，但网络连接设置里根本没有"以太网"图标。

大概率是网卡驱动被Windows更新搞挂了。处理办法是按Win+X，打开设备管理器，找到网络适配器，看看有没有带黄色感叹号的设备。有感叹号就先卸载再重新扫描硬件，让系统重新装驱动。还不行就去网卡厂商官网下载对应型号的驱动，手动安装。实在不行，在设备管理器里禁用再启用网卡，很多时候也能救回来。

5.5 如何提高现场调试效率

最后分享几个实用心得：

把传感器IP规划做成一个Excel表，贴在控制柜门上。项目上线后维护人员最缺的就是这种基础文档。

固件版本和寄存器定义说明书，一定要存档。有一次我们项目里传感器厂家升级了固件，寄存器地址整体偏移了一位，我们按旧文档对接，整整排查了一天才发现问题。

批量采购的传感器，到货后先抽两台做网络吞吐和长时间稳定性测试，跑个48小时看看数据有没有丢包、断连的情况，比等装到现场再出问题要主动得多。

以太网温湿度传感器的本地通信，无论协议如何分层，最终走的都是TCP/IP这一个底层通道。把TCP/IP这一层打通了，一通则百通，Modbus TCP只是这个通道上跑得最勤快的一个应用。

6. 写在最后的一点经验

用了几年下来，我的体会是：以太网温湿度传感器不是万能的，但它在"需要接入网络、需要多设备协同、需要远程监控"的工业场景里，确实是最省心的方案。

有些项目因为传感器点位分散、布线困难，选了无线方案，后期发现功耗、信号干扰、电池更换都是长期麻烦；有些项目坚持用RS485，维护成本也不低。以太网方案最大的优势在于"基础设施复用"——工厂里本来就有交换机、有网线、有人会排查网络故障，传感器只是网络上的一个小节点，不需要学习新的总线知识。

最后说一个更实用的小建议：如果你在项目里打算用多个以太网传感器，前期就统一好型号和固件版本，组建一个小型的吞吐测试环境，把Modbus TCP的寄存器映射表核对一遍。这一步能帮你在项目后期省下大量时间。

这个内容如果要继续延伸，可以往两个方向走：一个是传感器报警联动（比如湿度过高自动开启除湿机），另一个是多点位数据的空间分布可视化。不过这都是后话了，先把传感器数据稳定地读上来，才是环境监控项目的开始。