直连设备还是网关子设备？从接入、成本到 App 与看板的选型指南

一台 DTU 的 RS485 接口下接了温湿度传感器、光照传感器和多路继电器。到了 ThingsCloud 中，这套现场设备应该显示为一台设备，还是显示为一个网关和多台子设备？

这不是单纯的接线或通信协议问题，而是一个设备模型如何划分的问题。选直连模式，多个现场单元的数据可以集中为主设备的属性；选网关与子设备模式，每个现场单元可以拥有独立的设备身份、属性、历史数据和应用入口。

两种方式都能完成接入。真正需要判断的是：项目今后希望按“整套系统”管理，还是按“每个现场设备”管理。

先把概念说清楚：区别在云端设备边界

在 ThingsCloud 中，设备类型的接入类型可以设置为直连设备、网关或网关子设备。如果现场设备需要通过 DTU、ZigBee 网关、LoRa 网关等硬件才能访问互联网，云端仍然有两种常见的组织思路。

直连模式：把网关及其下游作为一个整体

平台只创建一台主要设备。下游传感器、仪表和执行器的数据，通过不同属性集中到这台设备中。

例如，一台 DTU 下接 2 个温湿度传感器、1 个光照传感器和 1 个继电器控制器，可以在同一台设备中定义：

• greenhouse_1_temperature
• greenhouse_1_humidity
• greenhouse_2_temperature
• greenhouse_2_humidity
• light_intensity
• relay_1

这里的“直连”描述的是 ThingsCloud 中的设备接入模型。现场传感器并不一定真的能够独立访问互联网，它们仍可通过 DTU 或网关完成物理通信。

网关与子设备模式：为下游设备保留独立身份

平台把联网入口建成网关设备，再把温湿度传感器、光照传感器、继电器控制器分别建成网关子设备，并建立所属关系。子设备通过地址区分，例如 Modbus 从机地址、ZigBee 地址或 LoRaWAN 的 DevEUI。

这样，数据虽然仍经过同一个物理网关上传，但会进入不同的云端设备中。

可以用一句话概括：

直连模式把多个现场单元折叠成一台云端设备；网关子设备模式保留现场单元各自的云端身份。

推荐阅读： 如果准备实际创建网关类型、子设备类型，并为网关关联子设备和设置子设备地址，可以继续阅读 如何创建网关和子设备。

两种模式放在一起看

这个表不是在判断哪种模式更先进。直连模式减少实体数量，网关子设备模式换来更细的管理粒度，两者是在不同维度上做取舍。

RS485 主从站：同一条总线，两种管理方式

假设一台 4G DTU 通过 RS485 总线连接以下设备：

• 2 台温湿度传感器
• 1 台光照传感器
• 1 台多路继电器控制器

方案 A：DTU 作为一台直连设备

所有 Modbus 数据解析后，都成为 DTU 设备的属性。这种方式适合设备数量少、点位固定、整套系统一起使用的项目。

它的优势是设备数量少，任务、看板和 App 都可以围绕一台综合设备完成。但随着从机增多，属性标识符、寄存器配置和界面布局会越来越长。工程团队必须在一开始就建立清晰的命名规则，否则很容易出现“温度 1 到底属于哪个传感器”的问题。

方案 B：DTU 作为网关，从机作为子设备

DTU 绑定网关类型，温湿度传感器、光照传感器和继电器控制器分别创建为子设备。ThingsCloud 的 Modbus 云网关可以按从机地址转发 Modbus 数据，并把下发给子设备的数据经由 DTU 送到现场。

这种方式更接近真实资产结构。增加一台传感器时，可以创建新的子设备并设置从机地址；同类传感器可以复用设备类型、功能定义、任务和应用面板。代价是需要创建和维护更多设备实体。

推荐阅读： 想把两种方案都走一遍，可以先学习 RS485/Modbus 设备通过 DTU 透传接入 ThingsCloud，了解数据集中在 DTU 设备中的配置过程；再观看 Modbus 云网关实现从机变独立设备，对照学习如何把温湿度传感器和 IO 控制器拆成独立子设备。

ZigBee 或 LoRa：通信拓扑不替你决定设备模型

ZigBee、LoRa 和 BLE 设备通常需要通过网关接入互联网，但“物理上经过网关”并不等于“平台上必须拆成子设备”。

如果网关上报的是一个家庭、一个温室或一个机柜的综合状态，而且所有节点总是一起交付、一起授权、一起维护，可以将它们组织在一台设备下。自行开发的网关还可以把多个节点的属性合并到一条 JSON 属性上报消息中。

如果需要按传感器查看历史数据、单独分配给用户、区分告警、替换硬件或扩展数量，则更适合将节点建成独立子设备。ThingsCloud 的网关接入协议可以处理子设备上线、离线、属性上报和控制等通信；对于第三方 LoRaWAN 网关，也可以结合消息规则，按 DevEUI 将网关收到的数据转发给对应子设备。

所以，协议决定数据如何到达平台，设备模型决定数据到达后归属于谁。

推荐阅读： LoRaWAN 项目可参考 星纵 LoRaWAN UG65 网关使用消息规则转发数据到子设备，教程完整演示了如何根据 devEUI 把网关消息路由到对应子设备；Zigbee 项目可参考 米家、飞利浦、宜家 Zigbee 设备接入 ThingsCloud，了解 Zigbee2MQTT 网关、子设备地址和数据转发的配置过程。

从用户使用角度看：能否一眼找到要管理的对象

最终用户通常不关心 DTU、Topic 或从机地址。他们关心的是“3 号温室温度是否正常”“哪块电表异常”“哪个继电器需要打开”。

直连模式把整套设备呈现为一个入口，适合以下情况：

• 用户购买和使用的是一套完整产品
• 所有数据点由同一角色管理
• 用户更希望打开一个页面看到全部状态
• 下游单元没有独立资产编号或维护流程

网关子设备模式更适合以下情况：

• 每个传感器、仪表或控制器都是可单独识别的资产。
• 不同设备需要关联给不同用户或部门。
• 运维人员需要按设备筛选在线、活跃和告警状态。
• 设备会单独替换、扩容或调拨。

一个实用判断是：如果现场人员日常会说“更换 2 号电表”或“把 5 号传感器交给 A 班组”，它通常就值得在平台上成为独立设备。

推荐阅读： 当独立子设备数量增加后，可以通过 设备组管理海量设备，按区域、客户、产品类型或运维责任组织设备，减少列表变长带来的管理压力。

从工程角度看：简单接入和长期维护不是同一件事

直连模式的初始接入往往更直接。网关只需把解析后的数据放入主设备属性，不必维护云端子设备映射。但工程复杂度并没有消失，而是转移到了属性命名、解析逻辑和综合界面中。

当下游单元变多时，需要提前处理这些问题：

• 属性标识符如何编码区域、设备类型和序号。
• 同类设备替换后，原属性和历史数据如何延续。
• 某个从机离线时，如何区别于整台网关离线。
• 不同型号的寄存器或数据格式如何在同一设备类型中共存。
• 综合设备的规则、任务和界面修改是否会影响其他点位。

网关子设备模式增加了地址映射、子设备创建和关联工作，但把故障域和配置边界拆开了。不同型号可以使用不同设备类型；规则、任务、告警和面板可以按类型复用；新增设备也不必持续扩充一张巨大的属性表。

对自行开发的网关，还要比较固件职责。直连模式通常由网关负责把各节点数据规范化并合并上报；子设备模式则要保留节点标识，并按网关协议或项目规则把消息路由到正确的子设备。前者协议负担小，后者更利于平台侧管理。

从平台资源角度看：设备数一定不同，消息量要具体分析

设备数

ThingsCloud 中的直连设备、网关和网关子设备都是独立实体，都会占用项目设备数量。因此，同一现场采用网关子设备模式时，通常会比只创建一台直连设备占用更多设备数。

例如，1 台 DTU 下有 10 台从机：

• 直连模式通常占用 1 个设备。
• 网关子设备模式通常占用 11 个设备，即 1 个网关和 10 个子设备。

项目设计阶段应把未来扩容数量算进去，而不是只按首批点位估算。

消息量

消息量不能只根据设备数判断。ThingsCloud 按设备与平台之间传输的消息统计；一条属性上报消息可以同时包含多个属性值，仍然算一条消息。

对于自行开发的 MQTT 网关，直连模式可以把多个下游节点的数据合并到一次属性上报中，因此有机会减少消息量。网关子设备模式通常需要保留数据归属，消息如何拆分取决于网关协议实现、上报周期和转发规则。

对于 RS485/Modbus 透传项目，如果寄存器范围、轮询周期和查询任务不变，是否拆成子设备通常不会自动改变现场需要完成的 Modbus 查询与回复次数。真正影响消息量的是：是否增加了任务、是否缩短轮询周期、寄存器能否批量读取，以及解析或转发过程中是否生成了额外消息。

因此，比较资源用量时应采用同一采集策略做小规模验证，并在项目概要和设备详情中查看消息统计，不要用“设备数翻倍，所以消息量也翻倍”这样的简单公式。

从 App 搭建角度看：一个综合面板，还是多个专用面板

ThingsCloud 的 ThingsX 设备面板由设备类型决定。同一设备类型下的设备可以复用同一套面板，面板组件再关联该类型中定义的属性。

采用直连模式时，用户在 App 中进入一台设备，就能看到整套系统的温度、湿度、光照和继电器控制。它适合家庭环境控制器、温室控制箱、机柜监控器等“整机产品”。需要注意的是，属性过多时，面板会变长，权限和交互也较难按下游单元拆分。

采用网关子设备模式时，温湿度传感器、电表和继电器控制器可以分别拥有适合自己的设备面板。用户关联设备时，也能按实际需要获得某一台或某一类设备。它更适合设备运营、分户管理和多角色协作，但 App 的设备列表会出现更多条目，需要配合清晰的名称和分组规则。

选择时可以问一句：用户希望先进入“某个站点”，还是先找到“某台设备”？前者偏向直连综合面板，后者偏向独立子设备。

推荐阅读： 为 Modbus 子设备生成 App 界面 展示了温湿度传感器和 IO 控制器拆成独立设备后，如何继续为不同类型的子设备制作对应的 App 面板。

从看板搭建角度看：属性集中更快，设备独立更容易扩展

ThingsCloud 看板的数据源可以绑定设备及其属性，也可以使用设备组统计、设备列表和设备跟随模式。

直连模式下，同一站点的数据集中在一台设备中。制作单站点总览时，组件选择这台设备的不同属性即可，绑定路径短，适合固定点位的小型看板。

网关子设备模式下，可以把多台同类设备加入设备组，在列表中选择设备，再让历史曲线、仪表盘、告警和控制组件跟随当前设备。需要横向比较多台电表、按区域筛选传感器或在设备扩容后继续复用看板时，这种结构通常更自然。

但“拆得越细越好”同样不成立。如果一块 8 路 IO 控制板在业务上始终作为一个整体，就没有必要把每一路 DI、DO 都拆成独立设备。设备应对应可管理的资产或产品，而不是对应每一个数据点。

推荐阅读： 如果准备搭建“左侧选择设备、右侧查看详情”的多设备看板，可以继续阅读 可视化看板：跟随设备组件，了解设备列表、历史曲线、仪表盘、告警和控制组件如何随当前设备切换。

一个更稳妥的折中：按资产分层，不按协议机械拆分

很多项目适合采用分层模型：

• DTU 或网关保留自身的连接状态、信号质量和运行信息。
• 需要独立运维的电表、传感器和控制器建成子设备。
• 同一控制器内部紧密关联的多路输入输出保留为该设备的多个属性。
• 只用于辅助判断、没有独立生命周期的低价值点位，可按项目需要并入上级设备。

这种做法既保留网关层的通信视角，也避免把每一个采集点都变成设备。设备边界最终应与资产边界、责任边界和用户操作边界尽量一致。

选型前，用这 8 个问题快速判断

1. 下游单元是否有独立的设备名称、编号或二维码？
2. 是否需要把不同下游单元关联给不同用户？
3. 是否需要分别查看在线状态、告警、历史数据和消息日志？
4. 下游设备是否会单独新增、替换、停用或调拨？
5. 同类子设备的功能定义、规则、任务和 App 面板是否可以复用？
6. 用户习惯按整套系统操作，还是按单台资产操作？
7. 当前套餐和扩容计划能否覆盖独立子设备带来的设备数量？
8. 网关固件或平台规则能否稳定识别并路由子设备地址？

如果前 5 个问题多数回答“是”，通常更适合网关子设备模式。如果项目是一套固定功能的整机，所有点位共同交付、共同授权、共同维护，则直连模式往往更简洁。

建议先用一个最小现场验证

设备模型一旦进入正式运营，就会影响设备身份、功能定义、任务、告警、App 面板和看板数据源。后期从“属性集中”改成“独立子设备”，不仅是修改一个接入类型，还需要重新评估应用绑定和历史数据的处理方式。

因此，在批量部署前，建议选取 1 台网关和 2 至 3 台典型下游设备，分别验证：

• 上报、下发和离线判断是否符合预期
• 设备数量与日消息量是否在预算内
• 运维人员能否快速定位故障设备
• App 设备列表和面板是否容易使用
• 看板是否方便扩展到更多同类设备

用真实操作走一遍，通常比只看架构图更容易做出正确选择。

小结

直连模式和网关子设备模式的核心差异，不在于数据能不能上云，而在于平台把谁当作一台设备。

直连模式适合把固定、紧密关联的现场单元作为一套产品管理，设备数少，综合界面集中，也有机会通过属性合并减少消息。网关子设备模式适合保留真实资产边界，让每台传感器、仪表和控制器能够独立配置、授权、运维和展示，但会占用更多设备数，也需要维护子设备映射。

最实用的原则是：按未来需要独立管理的对象划分设备，而不是只按当前接线方式划分设备。

相关文档：

• 设备类型基础：设备接入类型
• 如何创建网关和子设备
• Modbus 云网关
• 设备消息与使用统计
• App 设备面板
• 可视化看板