什么是物联网遥测？让现场数据真正可见、可查、可用

一台水泵装在几十公里外，今天运行了吗？冷库昨晚的温度有没有超过范围？电表的读数是在稳定增长，还是突然出现了异常？

这些问题，靠偶尔去现场看一眼很难回答。遥测做的事情很朴素：把现场正在发生的事，持续、可信地带回到你能看见和处理的地方。

遥测：持续知道现场发生了什么

遥测（Telemetry）指的是从远端采集设备或环境的测量数据，并传回系统进行查看、存储和处理。

温度、压力、液位、电流、累计电量、设备电池电量、信号强度，都是典型的遥测数据。它们有一个共同点：不是只在某个瞬间有用，而是需要随着时间持续记录，才能看出现场的真实状态和变化趋势。

很多项目一开始会把遥测理解成“设备上报一个数值”。这只是第一步。真正有用的遥测，至少要回答 3 个问题：现在是多少、过去怎样变化、出现异常时谁来处理。

遥测、遥信、遥控，别混在一起

它们经常出现在同一个项目中，但解决的问题不同：

实际项目里，这几件事常常连在一起：先通过遥测发现温度持续升高，再产生告警，最后由人员或系统决定是否启动风机。遥测是这条链路的起点，但不必一开始就把每个项目都做成自动控制项目。

哪些数据值得纳入遥测

一个实用的判断方法是：这项数据能不能帮助你少跑一次现场、少错过一次异常，或更快做出一次判断？如果可以，它就值得进入遥测清单。

通常可以从 3 类数据开始：

• 业务状态：温湿度、液位、流量、压力、累计电量、产量等，直接说明现场业务是否正常
• 设备健康：在线状态、电池电量、信号强度、运行时长、故障码等，帮助判断设备本身是否可靠
• 判断上下文：设备位置、设备型号、安装区域、工作模式和阈值等，让同一个数值放回正确的业务环境中理解

例如，冷库温度是核心业务状态；网关信号强度和设备在线状态则决定这条温度数据是否仍然可信。两者一起看，才不会把“没有新数据”误判为“温度一直正常”。

遥测在项目里，通常用来解决这些事

环境和仓储：少靠人工巡检

冷库、机房、大棚和仓库常常需要持续关注温湿度、二氧化碳、门磁或液位。遥测让管理人员先看到趋势和异常，再决定是否需要到现场处理，而不是按固定频率盲目巡检。

能源和水务：从读表变成看趋势

智能电表、水表、流量计会持续产生读数。把读数按时间保存下来后，才能看出日用量、峰值、异常突增和不同区域之间的差异。累计值适合做周期统计，瞬时功率、流量和压力则更适合观察波动。

设备运维：不只看“在线”

设备在线只表示它与平台仍有连接，不代表运行一定正常。再加上电流、温度、运行时长、故障码或电池电量等遥测指标，运维人员才能更早发现“还在线，但状态已经不对”的设备。

分散站点：让每个现场都有同一套语言

当设备分布在多个园区、门店或客户现场时，统一的遥测指标能把原本分散的情况放到同一张看板和同一套告警规则中。项目人员不必先理解每个现场的原始报文，先看统一的温度、液位、能耗和告警状态即可。

在 ThingsCloud 中，把遥测做成一条可用链路

遥测不是某一个单独的功能，而是一条连续的工作流。以一个安装了温湿度传感器、电表和网关的站点为例，可以这样理解：

1. 采集数据：设备可以通过 MQTT、HTTP、TCP 等方式主动上报。对于使用 RS485 和 Modbus 的仪表，也可以由 DTU 或网关按任务定时查询。
2. 整理成属性：把原始报文映射为温度、湿度、电量、信号强度等设备属性。这样不同型号的设备，也能用统一名称和单位来使用数据。
3. 同时保留现在和过去：属性当前值回答“现在怎么样”；属性历史数据保留为时间序列，回答“什么时候开始变化、变化了多少”。
4. 让数据看得见：在 ThingsCloud 可视化看板中，可将属性、设备状态、告警和历史数据绑定到仪表盘、趋势图、统计图或设备列表。
5. 让异常找得到人：告警规则可以根据设备属性变化或设备离线触发检查，并通过邮件、短信、电话、企业微信、钉钉、飞书或 Webhook 等方式通知相关人员。

如果一个 DTU 下接有多台 Modbus 从机，还可以按从机地址把数据归到独立子设备中。这样，后续查看历史曲线、配置告警和比较不同站点时，数据不会都挤在网关设备下面。

做遥测前，先把这 5 件事说清楚

1. 测什么：从“能产生动作”的指标开始

不要因为设备能采集 30 个寄存器，就一次性全部上报。先列出哪些数据会影响巡检、告警、运营统计或维护决策，再逐步补充。每多采一个点位，都会增加设备消息、存储、看板和维护成本。

2. 多久采一次：看变化速度，也看可接受的发现延迟

没有所有项目通用的上报间隔。温度、液位这类缓慢变化的数据，通常可以按分钟级或更长间隔采集；快速变化且会影响安全或控制的指标，则需要更短的采样与上报周期。

先反过来问：异常发生后，最晚多久必须被发现？再结合网络条件、设备功耗、总设备数和消息量限制，确定采集与上报策略。对变化不频繁的数据，也可以考虑“定时上报 + 变化触发”的组合。

3. 数据怎样命名：单位、精度和含义要统一

同一个项目里，不要让一台设备用 temp 表示温度，另一台用 t1，还混用 ℃、℉ 或不同的小数精度。给属性建立清晰的名称、标识符、数据类型和单位，后续做看板、告警和跨设备比较会轻松很多。

ThingsCloud 的功能定义可以预先约定设备属性、事件和命令，并对属性的数据类型进行校验。对同一类设备，优先复用一套定义，而不是每接一台设备就重新起名。

4. 把“数据异常”和“设备没数据”分别处理

温度超过上限，是数据异常；长时间没有新的温度数据，是采集链路或设备状态异常。两者的处理人、紧急程度和告警规则可能完全不同。

在告警设计中，除了数值阈值，也要考虑设备离线或属性长时间未更新的情况。对于容易在临界值附近波动的数据，可使用重复次数和持续时间，减少偶发波动带来的频繁通知。

5. 让每条告警都有去处

“报警了”并不等于“问题被处理了”。上线前至少明确：谁接收通知、收到后先看哪个数据、需要联系谁、恢复后是否需要留痕。

通知方式也要贴合现场。值班人员需要即时响应时，可以选择合适的即时通知渠道；需要对接已有运维系统时，可以使用 Webhook。对大量设备，还应设置合理的通知次数上限，避免一处故障刷屏掩盖其他问题。

一个遥测项目的最小闭环

如果准备从零开始，不必先做复杂大屏或预测模型。先完成下面这条最小链路：

做到这里，遥测已经能服务日常运营。后续再按业务需要增加跨站点对比、能耗统计、报表导出、自动化联动或对接外部系统，成本和方向都会更清楚。

数据能被看见，才有机会被用好

遥测的价值不在于云端多了一串数字，而在于现场状态不再只能靠猜、靠电话问、靠临时跑一趟。选对指标、设好节奏、保留历史、及时通知，再给运维人员一个顺手的看板，数据就能真正进入项目的日常工作。

如果你正在规划设备接入，也可以继续阅读：深入理解设备属性，看这一篇就明白！ 、设备历史数据分析，学会这几招就够用了 和 Modbus 项目交付前必须完成的 10 项检查 。