很多工业现场并不缺设备，缺的是把这些设备清晰、稳定、低成本地组织起来的方式。
RS485/Modbus 是工业现场最常见的通信组合。一台 DTU 接入 ThingsCloud，下面挂 5 个、10 个甚至几十个 Modbus 从机设备：温湿度传感器、电表、水表、IO 控制器、压力变送器、液位计。这种架构便宜、稳定、易施工，也是很多项目最实际的选择。
但问题也很快出现：如果所有从机数据都进入 DTU 这一个设备，平台上看到的就是一堆属性混在一起。看板不好做，告警不好分，客户 App 也很难按真实设备管理。
Modbus 云网关解决的正是这个问题：DTU 仍然做透传，ThingsCloud 在云端按 Modbus 从机地址，把每个从机映射为独立设备。
一、什么时候需要 Modbus 云网关
如果你的现场是下面这种结构，就很适合使用 Modbus 云网关：
Modbus 从机 1 ┐
Modbus 从机 2 ├─ RS485 总线 ─ DTU ─ 4G/WiFi/以太网 ─ ThingsCloud
Modbus 从机 3 ┘
不使用云网关时
所有从机数据都进入 DTU 设备的属性里。
这种方式适合从机数量少、业务简单的场景。例如只有 1 个温湿度传感器，只需要在看板上展示两个属性。
使用云网关后
每个 Modbus 从机都可以在 ThingsCloud 中成为独立设备。
这样做的好处很明显：
- 每个从机有独立设备详情页。
- 每个从机可以绑定自己的设备类型和功能定义。
- 告警规则、任务、看板、ThingsX App 可以直接按子设备配置。
- 后期增加传感器时，不需要改 DTU 程序。
- 设备资产结构更接近真实现场，客户更容易理解。
二、Modbus 云网关和网关 MQTT 协议有什么区别
很多用户会问：既然 ThingsCloud 有网关 MQTT 协议，为什么还需要 Modbus 云网关？
| 方案 | 适合对象 | 是否需要网关开发 | 典型场景 |
|---|---|---|---|
| 网关 MQTT 协议 | 自研网关、可编程边缘网关 | 需要适配协议 | Zigbee 网关、LoRa 网关、自研工业网关 |
| Modbus 云网关 | 通用透传 DTU + Modbus 从机 | 不需要 DTU 适配开发 | RS485 传感器、电表、水表、IO 控制器 |
如果你使用的是通用 DTU，它只负责把串口 Modbus 报文透传到云端，那么 Modbus 云网关更合适。它把复杂的子设备识别、地址映射和报文转发放在 ThingsCloud 云端完成。
三、配置步骤：从 DTU 到独立子设备
下面以“一台 DTU 下挂一个温湿度传感器和一个 IO 控制器”为例，梳理完整配置流程。
步骤 1：把 DTU 设备类型设置为网关
为 DTU 绑定一个接入类型为 网关 的设备类型，并将网关接入协议选择为 Modbus RTU 云网关。
这一步的意义是告诉 ThingsCloud：这台设备不是普通直连设备，它下面会挂接多个 Modbus 从机。
步骤 2：创建子设备
为每一个真实的 Modbus 从机，在 ThingsCloud 中创建一个独立设备。例如：
| 物理设备 | 云端设备 |
|---|---|
| 1 号温湿度传感器 | 温湿度传感器 1 |
| 2 号 IO 控制器 | IO 控制器 1 |
| 3 号电表 | 电表 1 |
然后进入 DTU 网关设备的 子设备 列表，把这些设备添加到网关下面。
步骤 3：设置 Modbus 从机地址
为每个子设备设置对应的 Modbus 从机地址。这个地址必须和物理设备上的站号一致。
例如：
| 子设备 | Modbus 从机地址 |
|---|---|
| 温湿度传感器 1 | 1 |
| IO 控制器 1 | 2 |
| 电表 1 | 3 |
ThingsCloud 后续会根据这个地址，把 DTU 上报的 Modbus 回复报文转发到正确的子设备。
四、为子设备配置任务和解析
云网关配置完成后，关键变化是：任务和解析都应配置在子设备上，而不是配置在 DTU 上。
1. 为子设备配置 Modbus 任务
如果需要定时读取温湿度、电表、电流、电压等数据，可以直接在子设备下创建任务。配置方法和普通 Modbus 设备类似，但要开启 使用子设备地址。
这样平台下发查询指令时，会自动使用子设备上配置的从机地址，无需为每个设备复制一份规则。
2. 为子设备配置 Modbus 解析
解析有两种常见方式。
方式一：使用 Modbus 智能解析
在子设备所属的设备类型中配置 Modbus 寄存器。适合寄存器规则明确、希望少写代码的场景。
方式二：使用消息规则的 Modbus RTU 解析
在子设备所属的设备类型下，创建自定义数据上报规则，使用 Modbus RTU 解析操作，并开启 使用子设备地址。
完成后，子设备就会像直连设备一样显示属性、历史数据和消息日志。
五、一个真实项目里的配置思路
假设一个水处理项目中有：
- 1 台 4G DTU。
- 3 台压力变送器。
- 2 台液位计。
- 1 台电磁流量计。
- 1 个 4 路继电器控制箱。
推荐这样建模：
| 设备 | ThingsCloud 设备类型 | 是否作为子设备 |
|---|---|---|
| 4G DTU | Modbus 云网关设备类型 | 网关 |
| 压力变送器 | 压力传感器设备类型 | 是 |
| 液位计 | 液位传感器设备类型 | 是 |
| 电磁流量计 | 流量计设备类型 | 是 |
| 继电器控制箱 | IO 控制器设备类型 | 是 |
这样看板可以按真实设备组织，告警可以直接绑定“压力变送器 1”，自动化也可以写成：
- 压力变送器 1 压力超过 0.6 MPa：关闭进水阀。
- 液位计 1 液位低于 20%：停止水泵。
- 流量计累计流量异常：通知运维人员检查管路。
客户在 ThingsX App 中看到的也是一个个真实设备，而不是一个属性很多、难以理解的 DTU。
六、常见问题和避坑建议
1. 子设备地址必须唯一
同一个 DTU 网关下，子设备地址不能重复。两个从机都设置为地址 1，会导致平台无法正确判断报文属于哪台设备。
2. 波特率、校验位、数据位要一致
RS485 总线上的 DTU 和所有从机必须使用一致的串口参数，例如：
- 波特率：9600。
- 数据位：8。
- 校验位：None。
- 停止位：1。
如果某个设备出厂默认波特率不同，建议先用串口工具或平台任务修改后再接入总线。
3. 不要把所有寄存器都读一遍
很多 Modbus 设备手册里有大量寄存器，但业务真正需要的可能只有几个。读取过多寄存器会增加总线负载，也会拉长轮询周期。
建议先定义核心属性：
- 温湿度：温度、湿度。
- 压力：压力。
- 液位：液位或液位百分比。
- 电表：电压、电流、功率、总电量。
4. 轮询周期要和业务匹配
不是所有数据都需要每秒读取。
| 数据类型 | 建议周期 |
|---|---|
| 温湿度 | 1-5 分钟 |
| 液位 | 30 秒-5 分钟 |
| 压力 | 5-30 秒 |
| 电表能耗 | 1-15 分钟 |
| 控制状态 | 按需读取或控制后读取 |
如果总线上设备多，轮询周期要留出足够间隔，避免多个任务互相拥堵。
5. 先调通一个，再复制到一组
项目实施时，不建议一次性把所有设备都加上。更稳妥的步骤是：
- 只接一个从机。
- 确认 DTU 能连上 ThingsCloud。
- 确认任务能下发。
- 确认 Modbus 回复能解析成属性。
- 再逐个增加子设备。
这样排查问题更快，也更容易判断是总线、地址、规则还是设备本身的问题。
七、为什么这对项目交付很重要
Modbus 云网关的价值不只是“技术上能转发报文”，而是让设备资产和业务界面保持一致。
对工程团队来说，它减少了重复配置和 DTU 定制开发；对运维团队来说，它让告警、历史数据、任务和看板都能按真实设备管理；对客户来说，它让系统更容易理解和使用。
当一个项目从 5 台设备增长到 500 台设备时，这种清晰的设备模型会变得非常关键。
结语
如果现场已经大量使用 RS485/Modbus 设备，不必为了“上云”推倒重来。通过通用 DTU + ThingsCloud Modbus 云网关，可以在保留现场成熟架构的同时，让每个从机设备在云端拥有独立身份。
这是一种非常务实的工业物联网接入方式：硬件改动少、实施成本低、设备结构清晰、后续应用扩展方便。
相关文档可参考：
关于 ThingsCloud
ThingsCloud 是新一代物联网设备统一接入平台，帮助企业在极短的时间内搭建个性化的物联网平台和应用，并适应不断变化的发展需求。目前广泛应用于制造、电力、能源、环境、农业、楼宇、家居、教育、交通、物流、自动化等领域。
ThingsCloud 可接入各类网关，传感器、执行器、控制器、通信模组、智能硬件等，实现数据采集、远程控制，数据分析、告警通知、智能联动。还可以零代码生成项目应用 SaaS 和用户应用 App，并开放 API 和实时消息，便于业务系统集成和扩展开发。
通过使用 ThingsCloud，企业可以大大缩短搭建物联网系统的时间，节省软件开发费用，降低定制开发的风险，快速落地数字化和智能化项目。我们的客户遍布各行业，包括中国石化、中国铁塔、中国燃气、吉林大学、北控水务、ACE、中国民航大学、西安交通大学、精量电子、大秦铁路、宁波水利局等。
