TCP以太网温湿度传感器：原理、优势与工程应用详解

前阵子一个做机房动环的朋友问我：现场原来一直用RS485加Modbus RTU的温湿度传感器，为什么新出的项目图纸里全换成了带TCP以太网接口的型号，价格还贵一截。这个问题我琢磨了很久，也踩过不少坑，今天就专门聊聊TCP协议以太网温湿度传感器，以及它为什么在工业项目里越来越常见。

先说个结论：这类传感器测的还是温度、湿度，传感器本身并没有多神秘，真正的分水岭在“数据怎么从现场传到系统里”。如果你搞过几个几十个点的环境监测项目，应该能明显感受到，通讯方式决定了整个项目的施工方式、调试方式、后期排障方式。这篇文章打算把这套东西从原理到实操掰开揉碎讲清楚，适合做工业自动化集成、数据中心动环、洁净车间、仓库冷链、实验室监控的工程师看看。

1. 温湿度传感器通讯方案的底层差异：为什么不用RS485和4-20mA

1.1 从DHT11到工业级网络传感器，差的不是“准不准”

很多刚入行的朋友一听到温湿度传感器，脑子里跳出来的是Arduino套件里那种DHT11。DHT11确实便宜，几块钱一颗，数据手册里写着精度“±5%RH、±2℃”，实际用过的都知道，这玩意只能算“有信号”，不能算“测量”。而且它走的是单总线协议，只能由单片机直接读，没法长距离接，也没法组网，实验课玩玩可以，放到工业现场完全站不住脚。

工业项目里用的网络温湿度传感器，本体通常是一个带壁挂或管道安装外壳的探头，里面是进口的数字温湿度芯片，比如SHT30、SHT40这类，加上一个带网络协议栈的处理器。注意，现在很多低成本以太网传感器用的协议栈芯片是W5500这类硬件方案，原理就是MCU通过SPI把数据丢给W5500，由这块芯片自动完成TCP/IP报文封装，MCU只需要解析业务帧就够了。这样做的好处是方案成熟、成本低、稳定，不用自己啃协议栈底层的细节。

所以网络传感器和DHT11的差距，不在于“哪家测得更准”，而在于它自带完整的网络通讯能力，插一根网线就能接入现有的以太网络，被上位机、组态软件、云平台直接访问。

顺便说一句，现在以太网技术本身已经发展到25G、40G，车载以太网也在汽车行业大量上车，甚至还有专门做FPGA三速以太网、PHY测试的玩家。但工业温湿度监测这种低频小数据量场景，根本不需要跑满带宽，我们需要的是以太网带来的组网能力和标准化传输机制，这件事普通百兆交换机就完全够用。

1.2 RS485轮询模式在大型系统中的瓶颈

传统RS485方案在工业现场确实皮实，两线差分信号抗干扰能力强，一两百米距离轻轻松松。它的问题是半双工、主从轮询。什么意思？RS485总线上挂的所有设备都是“哑巴”，只能等主站点名，主站问一句，设备答一句，谁抢话谁出错。当现场传感器数量少，比如十几台以内，轮询一遍的周期还能接受；一旦点数到了三五十个，轮询周期就非常难受。

我算过一笔账，假设每台设备响应需要50毫秒，这是比较理想的Modbus RTU响应时间，再加上主站等待时间、总线上半双工切换的间隔，一台一台轮询，50台设备一轮下来就是2.5秒以上。要是其中某台设备响应慢甚至超时，整个周期还会被拉得更长。对于监控大屏上“每5秒刷新一次”的需求，勉强能跑，但要是系统里同时还有几百个点位、几十类不同协议设备，调试起来真的会崩溃。

RS485还有一个很现实的问题：布线必须手拉手菊花链，也就是从主机出来一根线，串到设备1，再从设备1串到设备2，不能随便分叉。现场施工的时候，设备分布往往不在一条直线上，绕来绕去的线非常难看，而且任何一个中间节点断线，它后面所有设备全部失联。这种“串联”的物理结构，天然没有以太网星型网络舒服。

1.3 TCP和UDP，为什么工业现场几乎只看TCP

要么不联网，一旦走IP网络，就得在TCP和UDP之间做选择。UDP的优点是开销小、速度快，发出去不管，没有确认和重传机制。但这种“发出去不管”的脾气，放在温湿度监控上是不行的。想象一下，机房温度已经30℃了，高温告警数据在网络上丢了一个包，监控中心完全不知道，这是不可接受的。

TCP协议有三次握手、确认应答、超时重传、滑动窗口这些机制。我把TCP理解成快递签收：寄出后必须有人签收，没签收就重新送。对传感器来说，报文从设备到上位机、从上位机到设备，都能确认“对方收到了”，数据可靠性有明确保证。

代价是TCP协议栈开销比UDP大，吞吐量有所下降，但对温湿度这么小的数据量来说，完全可以忽略。所以工业现场的传感器通讯，几乎九成以上都在用TCP，而不是UDP。这也是为什么标题里专门强调“TCP协议以太网温湿度传感器”，根子上要的就是这份可靠。

2. 工业项目选TCP以太网传感器的四个决定性理由

2.1 布线灵活，现场施工省一大截

前面提到RS485要手拉手，4-20mA模拟量更是“一个信号一对线”。一个4-20mA温湿度传感器，如果同时输出温度和湿度两个信号，要么用两线制变送器接两台采样设备，要么用一个多通道采集模块，反正线材和接线端子都不少。上了规模之后，系统柜里的接线端子排密密麻麻，查故障时拿万用表一根根对线，能把人逼疯。

以太网方案就简单了。传感器是RJ45接口，直接插到交换机上，整个网络是星型结构，想在哪里加设备，拉一根网线到最近的交换机端口即可。用工业交换机做汇聚，一根光纤或者一根千兆主干线就能把几十台设备的数据带回中控室。现场施工的人最喜欢这种方案，因为不用算总线的距离、不用画复杂的极性图，也不会因为“这条总线最后一个设备的终端电阻忘了拨”导致整条链路通信异常。

而且现在不少网络温湿度传感器支持PoE供电，也就是一根网线同时传数据和供电，传感器不需要再拉一根220V或24V电源线，这对吊顶里、夹层里的安装场景来说，省掉的施工成本非常可观。

2.2 数据不占PLC资源，直接对系统软件

以前很多环境监控点位是挂在PLC的AI模块或者串口模块上的，一个温度点占一个模拟量通道，组态的时候还得在PLC里做工程量转换、滤波、越限判断。一旦点位多了，PLC的程序越来越臃肿，扫描周期被拉长，而且扩展AI模块的成本并不低。

TCP以太网传感器走的是另一条路：它直接对上位机、组态软件、数据库、云平台对话，完全绕开PLC。传感器的数据通过网络传递给监控软件，软件自己完成解析、存储、报警；需要对第三方系统联动时，再由上位机决定是否下发给PLC执行。这样PLC只管现场逻辑控制，环境监测自成一套独立系统，两边互不干扰，检修也不会影响生产逻辑。

对系统集成商来说，这套架构还有个大好处：可交付性强。客户需要的不光是能在现场触摸屏上看几个数，还要有数据报表、历史曲线、短信或者微信报警。这些功能，以太网传感器直接对接软件平台就能实现，比从PLC里一点一点抠数据再存数据库，效率高太多了。

2.3 多客户端并发，调试、数采、上云可以同时做

这是TCP方案一个很隐蔽但极其好用的优点。RS485是一主多从，整个总线只能有一个主站，调试电脑把总线占住之后，HMI和监控平台都只能靠边站。而TCP协议天然支持多客户端连接同一个服务器端口的场景——只要传感器作为TCP Server端，它就可以同时被多个Client连接访问。

实际项目里我经常这么干：一台传感器还在现场调试，上位机软件连着一个连接、笔记本电脑开着Socket调试工具又连一个、HMI触摸屏也来读数据，三个客户端同时连着互不影响，随时可以“挤进去看一眼”当前的数据。这种并发访问能力，对调试和排障的价值是实打实的。

另外，现在很多项目要做“边缘采集+云上展示”，传感器数据通过本地上位机采集后，再转发到云平台或者园区物联网平台。如果传感器支持Modbus TCP，中间还能加网关把Modbus TCP转成MQTT等协议上云。有以太网口，意味着你有无数种后续玩法，不会被物理总线限制死。

2.4 有线网络比无线更稳，温湿度也不怕干扰

有人会问，现在无线传感器那么多，LoRa、NB-IoT、WiFi都有，为什么还要拉网线。我的看法是：看场景。温湿度传感器在车间、仓库、机房、实验室里用量很大，很多点位就在头顶上、墙面、空调出风口附近，这些地方布一根超五类网线难度并不大。有线以太网的稳定性和可靠性，在工业环境里依然是最高的。

无线方案主要的坑在于频段拥挤和穿透衰减。工厂里2.4GHz频段里蓝牙、WiFi、无线键鼠、微波炉都在挤，信号干扰难以避免；现场有很多金属设备、钢板隔断，无线信号穿墙之后强度掉得很厉害，数据总是时断时续，巡检的人跑断腿也找不出原因。ZigBee、LoRa这类低速无线虽然功耗低、穿墙好一些，但还是需要额外的网关设备把无线转成以太网，系统多了一层，维护量也就上来了。

另外温湿度探头本身是个低频缓变信号，我们真正需要的不是“无线”这种自由，而是“稳定不丢数”。所以在相对固定、有网线条件的环境里，我几乎都会优先考虑有线以太网方案。

3. TCP通讯原理、报文解析与Wireshark验证

3.1 先理解Server和Client模式再接线

拿到一个TCP以太网温湿度传感器，第一件事不是急着接线，而是确认它工作在什么模式。市面上的传感器一般有两种工作方式：

第一种是TCP Server模式，也就是传感器在网络上监听一个固定的端口，比如8000、5000之类的。上位机、组态软件、调试工具作为TCP Client主动去连接它。这个模式最常用，因为服务器端的IP和端口是固定的，客户端随时可以发起连接，调试方便，多客户端并发也容易实现。

第二种是TCP Client模式，传感器主动向指定IP和端口发起连接。这种模式适合传感器主动上报数据，比如定时往监控平台推送温度，平台不需要去遍历所有设备。但要注意，这种模式下如果平台还没启动，传感器可能一直连接不上，需要配置重连间隔。

我建议采购之前一定问清楚传感器支不支持“同时作为TCP Server并且允许多个Client连接”，有些便宜货只能支持一个客户端，调试时自己电脑一连，触摸屏就断了，很被动。还有一点，尽量选支持静态IP的传感器，不要用DHCP自动获取IP。原因很简单：现场交换机未必有DHCP服务器，就算有，断电重启后IP可能变了，上位机找不到设备，“续订失败”之类的坑我踩过不止一次。静态IP加上自己规划的地址表，一劳永逸。

3.2 报文解析：从hex里把温度和湿度算出来

传感器把温湿度数据发给上位机，不是直接发“23.5℃”这个字符串，而是按厂商协议拼成十六进制报文。不同厂家协议格式千差万别，但套路都差不多：帧头、地址、功能码、数据长度、数据区、校验位。

举个例子，某款传感器的查询命令长得像Modbus风格：

发送读取命令： 01 03 00 00 00 02 C4 0B

传感器返回：

响应帧： 01 03 04 00 BE 02 21 5A 7B

这帧怎么解析？01是设备地址，03是功能码，04是后面数据区的字节数。数据区是四个字节：00 BE和02 21。厂家手册会告诉你，温度是两个字节的短整型，高字节在前低字节在后，原始值除以10就是摄氏度。于是温度值是0x00BE，转换成十进制是190，除以10就是19.0℃。湿度值是0x0221，十进制是545，除以10就是54.5%RH。

千万别小看这一步，很多新手在这里翻车。最容易错的是字节序。有的传感器是低字节在前，有的高字节在前；有的数据排列顺序是“温度在前湿度在后”，有的反过来；还有的是无符号整数，有的用带符号整数表示负温度。不要想当然，必须以手册为准。最稳妥的办法是拿一个已知温湿度的环境，用Socket调试工具主动读一帧，对照手册逐字节分析，再写进程序里。比如0xFF38这种高位是1的数据，如果按无符号算出来是65336，实际可能是带符号的-200，也就是-20.0℃，这两种处理方式结果天差地别。

3.3 Wireshark抓包确认通讯状态

报文解析逻辑写好了，设备还是“没反应”，这时候别瞎猜，直接上Wireshark抓包。抓包工具看网络通信，就像万用表量电压一样，是排障的基本功。

Wireshark用法很简单。选择连接传感器的那块网卡，抓包前在过滤栏输入类似这样的条件：

tcp.port == 8000 && ip.addr == 192.168.10.50

然后让上位机连接传感器，发一次查询命令。回来看抓到的包：正常情况下应该先看到三条握手包，也就是SYN、SYN-ACK、ACK，这代表TCP三次握手成功；然后是应用数据包，负载长度也就是我们发出去的查询命令；接着传感器回一帧响应数据，负载长度和返回帧完全一致。

Wireshark里可以直接看到数据包里的十六进制字节内容。把“Data”字段展开，就能看到传感器返回的一串hex，我通常是直接复制出来，和自己解析程序的输出结果对一遍。如果发现抓到的数据和理论值对得上，程序却解析不对，那问题一定出在代码的字节序或数据类型上；如果抓包都看不到传感器的回包，那就得回头查网络通不通、端口对不对、防火墙有没有拦。

4. 与PLC、组态软件对接的几种典型玩法

4.1 昆仑通态MCGS走TCP自由协议

组态软件是工业项目里最常见的上位机形式，其中昆仑通态的MCGS因为成本低、上手快，在中小项目里用得非常多。它和TCP以太网传感器对接，很多场景靠的不是标准的Modbus驱动，而是走“TCP自由协议”。

什么是自由协议？就是组态软件不预设报文格式，允许你用脚本自己组一个HEX字符串发出去，再把收到的HEX字符串按字节解析成需要的数值。对传感器厂商来说，这是一条很友好的路，因为国产传感器常常用自定义的TCP报文，未必严格按Modbus标准来。

用MCGS对接TCP传感器，我的经验是先在PC上用Socket调试助手把报文彻底调通。确认好“发什么命令、回什么数据、回包的哪个字节是温度、哪个字节是湿度”，再去组态软件里写脚本。不要在组态里一点一点猜报文格式，那样调试效率极低。脚本里做两件事：建立连接、定时发送查询命令；接收返回数据后，把指定字节截出来做进制转换。转换后的工程值存到组态变量里，就能显示在画面上、存进历史库了。

4.2 威纶通HMI通过以太网接三菱FX5U，再顺便读传感器

威纶通MT系列触摸屏本身自带以太网口，它和三菱FX5U PLC走以太网通讯是典型的自带功能，在EasyBuilder Pro软件里选对PLC型号和驱动，填上PLC的IP地址就行，用的是三菱的MC协议。如果不清楚怎么配，最简单的方法是先给PLC和HMI配同一个网段的IP，然后在HMI的系统参数里新建三菱FX5U以太网设备，填IP和端口号，正常情况下连接状态会变成正常。

有意思的是，HMI除了能和PLC通讯，它的宏指令里一般也支持Socket操作。也就是说，我们可以把HMI当作一个TCP客户端，同时去连接网络温湿度传感器，读取数据后再写入HMI的LW内部寄存器，显示在画面上。这样一台触摸屏就同时扮演了两个角色：PLC的人机界面、环境监测的上位机。

这种玩法很实用，因为很多小型设备客户的预算有限，不想单独上一台工控机和组态软件。动动HMI的宏指令，就能给设备加上温湿度显示和报警功能，交付效果比在PLC程序里读模拟量再送HMI显示要清爽得多。

当然，宏指令Socket编程对现场工程师来说有一定门槛，但如果只是想读取数据，思路其实很简单：连接、发查询命令、延时等待、接收数据、解析字节。做好数据重连机制，掉线自动重连。

4.3 博图S7-1500用TSEND_C太慢、总是BUSY？先搞清楚非阻塞

再聊一个PLC和TCP通讯的高频问题。有些项目把网络温湿度传感器当成一个小服务器，让S7-1500通过TSEND_C把采集到的数据主动发送到服务器端。不少人在博图里这样写过，然后发现：TSEND_C调用起来感觉很迟钝，连续发数据的时候，BUSY总是TRUE，数据发不出去，网上搜“TSEND_C发送数据太慢”能搜到一堆抱怨。

问题的根子在于TSEND_C是非阻塞指令。意思是调用它只是“交出发送请求”，真正的数据发送过程在后台执行，可能跨多个PLC扫描周期。如果你在每个扫描周期里都把REQ输入置为TRUE，或者用同一个背景DB连续触发多次发送任务，那么上一次任务没有完成之前，新任务根本无法启动，BUSY就一直在TRUE，给人一种“卡死”的错觉。

正确做法是给REQ加一个上升沿脉冲触发，发送完成后再复位。用结构化控制语言写出来大致是这样：

// 简化示意：上升沿触发TSEND_C sendPulse := (startSend AND NOT prevStartSend); prevStartSend := startSend; IF sendPulse THEN "TSEND_C_DB".REQ := TRUE; END_IF; IF "TSEND_C_DB".DONE OR "TSEND_C_DB".ERROR THEN "TSEND_C_DB".REQ := FALSE; END_IF;

关键就一句话：同一个TSEND_C实例，前一个发送作业没结束，绝对不发起下一个。如果你有大量数据要连续发送，正确做法是建立发送缓冲区，一次只发一个数据包，等DONE标志出现后再发下一包。新版本的S7-1500其实还有TSEND_C的“并发发送”更优雅的库，但老项目里，把REQ触发逻辑改正确，问题就能解决大半。

5. 部署实操：IP规划、网络结构与问题排查

5.1 给传感器分配IP的几条规则

部署网络传感器的第一件事，不是接网线，而是做一张《现场设备IP地址规划表》。别嫌这步麻烦，等设备上了五六十台再回头整理，就会发现哪里都像有点问题，但哪里都查不清楚。

我常用的规划思路是：传感器网段统一用一个私网段，比如192.168.10.x，子网掩码255.255.255.0；网关指向现场的核心工业交换机或工业路由器；给每一台传感器分配一个唯一的静态IP，并且把标签打印出来贴在设备外壳上。标签内容包括IP地址、安装位置、物理点位编号。这个方法成本极低，但排障的时候能省下大量时间。

不建议给传感器开DHCP，除非整网有严格管理的DHCP服务。工业现场很多交换机默认不开DHCP服务，设备拿不到地址就一直用默认的厂商IP，多台设备同一个IP冲突起来，通讯就是一锅粥。有时候Windows更新之后，电脑网卡的IP被重置成自动获取了，调试工具就连不上设备了，查一下网卡的IP配置就能发现原因。在虚拟机里跑上位机也一样，VMware之类的虚拟机如果没设置桥接模式，虚拟网卡跟物理网卡之间等于没通，上位机自然找不到传感器。

5.2 工业交换机选型和网络拓扑

以太网传感器的性能上限很低，一个点位每秒可能才几百个字节，用百兆交换机绰绰有余。但工业场景不能只盯着带宽，环境适应性更关键。商业交换机在车间里，粉尘、温度、震动都可能引发端口闪断和死机；工业交换机的好处是宽温、导轨安装、无风扇设计，还存在断电重启快速恢复的能力，有些还支持环网冗余协议，比如ERPS、STP/RSTP。

如果项目点位很多，我习惯分层做：现场用24口的工业以太网交换机做接入层，传感器全部汇聚到接入交换机；接入层向上用千兆光纤或者六类网线接到中心机房的核心交换机；核心交换机再连接监控服务器、工程师站、数据中心动环监控平台。这样做的好处是，某台接入交换机故障，只影响它下面的一小块区域，而且整个网络拓扑清晰，排障范围能快速收缩。

网络拓扑上还要注意VLAN划分。环境监测设备和管理办公网混在同一个二层网段里，一旦办公网有人发广播风暴或者有病毒传播，传感器通讯也可能被波及。条件允许的话，把环境监测网单独划一个VLAN，通过三层交换机或路由与办公网隔离，传感器端口不做DHCP、不响应广播，安全性会好很多。

5.3 常见问题速查表

这些是我在项目现场反复遇到的坑，整理成一张速查表，给兄弟们参考：

还有一个容易忽略的细节：传感器的电源。很多以太网温湿度传感器是12V或24V直流供电，有些还支持PoE。如果采用本地直流供电，建议用带隔离的DC-DC电源，避免现场大功率设备启停时把电源拉偏。数据跳变、偶发断线这类问题，查到最后常常是供电质量问题，而不是网络问题。这个习惯我保持了好多年，帮我在项目现场少跑了很多冤枉路。

6. 最后一些小经验

做环境监测这些年，我最大的体会是：TCP以太网温湿度传感器真正解决的问题不是“度数准”，而是“数据通”。只用一台仪表看现场温湿度，用什么通讯方式都无所谓；一旦系统超过几十个点、要上组态、要接云平台、要远程报警，TCP方案的优势就会全面显现出来。

另外还有个小技巧，采购网络传感器的时候，不要只看参数表上写着“以太网接口”，一定要问清楚支持的是“标准Modbus TCP协议”还是“自定义TCP协议”。标准Modbus TCP意味着可以用组态软件现成的驱动直接对接，开发量很小；自定义TCP协议则需要写脚本解析，对接成本就上去了。很多传感器明明硬件能力很强，但因为协议不够“通用”，导致现场集成非常吃力。这是我踩过坑以后才明白的，写在这里给后面的人提个醒。