一、先确认：数据从哪里出来？

仪表、传感器、PLC都可能提供现场数据，但接入方式并不相同。

有些传感器输出4—20mA电流或0—10V电压，需要通过匹配的采集模块或PLC，将信号转换成数字数据。有些仪表带有RS485接口，可以通过它支持的通信协议读取数值。如果数据已经进入PLC，也可以从PLC开放的接口和协议中读取所需点位。

因此，选联网设备之前，先确认三件事：设备提供什么信号、有什么接口、支持什么协议。

本文中的温度仪表已经具备数字通信能力，可以由支持Modbus RTU采集的网关读取，不需要再把温度转换成模拟量采一次。

二、接上线，为什么还读不到温度？

RS485解决的是通信信号传输问题，Modbus RTU规定的是数据如何请求和回应。接好线以后，采集端还需要知道“找谁读、读哪里、怎么解释”。

首先，双方的波特率、校验方式等通信参数需要匹配。其次，需要设置仪表的设备地址，以及温度对应的寄存器地址和数据类型。

读取到数字后，也不一定能直接当作温度使用。

例如，假设某台仪表定义寄存器值253表示25.3℃，采集端就需要按规定比例换算。如果漏掉这一步，平台可能显示253℃，通信虽然成功，数据却解释错了。

联网前，先在采集端确认数值正确，是很重要的一步。设备地址、寄存器和换算规则，都应以对应型号的实际定义为准。

现场数据读取正确后，还需要一条通向平台的网络路径。

网关可以根据现场条件，通过以太网、Wi-Fi或蜂窝网络连接远端服务。网络解决“数据怎么到达”，上传协议和消息格式则决定“双方怎么交换数据”。

一种常见做法是：采集网关读取Modbus数据，将温度与设备标识、测点名称等信息组织成消息，再通过MQTT发送到MQTT服务器。服务器接收消息后，转发给订阅对应主题的应用。

这里容易混淆的是设备分工。DTU、串口服务器、采集网关的功能可能不同，不能只看名称。

只支持透传的设备，主要负责把原始数据传到另一端，读取指令和数据解析可以由远端软件完成。具备主动采集、解析和MQTT上传能力的网关，则可以在现场完成这些工作。具体采用哪种方式，要看设备功能与平台要求。

数据到达MQTT服务器，还没有完成整个应用过程。

平台应用需要识别消息来自哪台设备、对应哪个测点，以及数值采用什么单位，再将数据保存、展示。手机或电脑打开的页面，查看的是应用处理后的结果。

如果希望温度超过阈值时提醒，还需要配置告警规则：多少度触发、持续多久触发、通知发给谁。

这些是平台应用承担的任务，MQTT本身负责消息传递，不会自动生成温度曲线或判断温度异常。网络中断后的补传，也需要设备或系统具备相应的缓存和恢复机制。

一套温度监测方案是否完整，可以沿着数据路径检查：

现场有没有正确读到温度？消息有没有成功送达？平台有没有正确识别和展示？

如果平台没有数据，就从采集结果、网络连接、上传配置和平台接收逐段排查。如果平台有数据但数值不对，则重点检查寄存器、数据类型、换算比例及平台解析规则。

仪表上的温度能够出现在手机上，是因为现场设备、采集与通信设备、服务器和平台应用共同完成了这条路径。理解每一段的职责，才能知道方案缺什么，也才能在出现问题时找到排查方向。