在物联网项目中，网关通常负责汇聚现场设备数据，再通过 MQTT 等协议上报到平台。真正影响项目交付效率的，往往不是"能否收到数据"，而是平台收到数据之后，能否稳定完成解析、分流和存储，并把这些数据继续用于告警、状态判断和自动化处理。
传统非模块化平台在接入物联网关时，常见问题是设备数据输出格式不统一。每接入一种新设备，开发人员都要针对设备协议和数据格式编写解析脚本与业务逻辑。设备规模扩大后，系统集成、测试验证和后期维护都会受到影响，设备选型也容易被现有平台的适配能力限制。
在这类场景中，ThingsBoard PE 的思路是把设备接入、数据处理和遥测存储拆成可配置、可编排的模块。平台通过 Device Profile（设备配置） 统一管理设备接入特性，再通过 Rule Chain（规则链） 可视化编排业务逻辑，把原本写在业务系统里的数据处理逻辑前移到 IoT 平台层。新增设备时，更多工作集中在配置模板和规则连线上，而不是反复修改底层代码。
| 维度 | 传统非模块化平台 | ThingsBoard PE |
|---|---|---|
| 接入方式 | 以代码开发为主 | 配置化、低代码 |
| 扩展能力 | 较弱 | 较强 |
| 维护成本 | 较高 | 相对可控 |
| 设备规模增长影响 | 复杂度明显增加 | 扩展复杂度更易控制 |
下面以物联网关通过 MQTT 上报遥测数据为例，梳理 ThingsBoard PE 中从规则链、设备配置、设备创建到数据存储的完整配置流程。
一、创建规则链
Rule Chain 用于承接设备上报后的数据处理流程。网关数据进入 ThingsBoard PE 后，可以在规则链中完成清洗、过滤、计算、分发和存储等操作，再为告警触发、状态判断和自动化处理提供标准化的数据入口。
1. Entity Type Filter：实体类型过滤
Entity Type Filter 用于限定后续规则节点只处理指定实体类型的消息。例如，当某段处理逻辑只适用于设备消息时，可以在该逻辑前加入实体类型过滤节点，让设备、资产、客户等不同实体类型进入不同路径，避免异常来源的消息被误处理。
2. Message Type Switch：消息类型切换
Message Type Switch 会根据消息类型把数据分发到不同的下游路径，无需额外编写代码。ThingsBoard 的标准消息类型会映射为可读的连接标签，例如 POST_TELEMETRY_REQUEST 对应 Post telemetry。配置规则链时，可以根据遥测数据、属性更新、RPC 调用、生命周期事件等不同类型，分别连接后续处理节点。自定义或未知消息类型则可以通过 Other 分支处理。
3. Script：脚本转换
Script 是规则引擎中较灵活的转换节点，可用于重塑消息内容、修改消息类型、重写元数据，或把一条传入消息拆分为多条传出消息。脚本可使用 TBEL 或 JavaScript 编写，适合处理网关上报字段转换、单位换算、字段补充和消息分发等场景。
4. Save Time Series：保存遥测数据
当消息类型为 POST_TELEMETRY_REQUEST 时，可以通过 Save Time Series 节点将设备遥测数据写入 ThingsBoard PE 的时间序列存储。本文示例环境中，遥测数据最终存储在 PostgreSQL 中。
该节点还可以配置数据保存时间（TTL）、时间戳确定方式，并在特定情况下进行去重或跳过写入，从而减少无效数据写入和数据库负载。
二、创建设备配置
设备接入前，需要先通过 Device Profile（设备配置） 定义设备类型及其接入方式。Device Profile 可以统一管理设备使用的规则链、传输协议、能力模型和相关接入参数，让同类设备复用同一套配置。
这样配置后，平台不必为每台设备重复维护完整规则。只要设备属于同一类型，就可以关联同一个 Device Profile，后续接入、扩展和维护也更容易保持一致。
三、创建设备并配置网关连接
完成规则链和设备配置后，需要在 ThingsBoard PE 中创建具体设备，并让现场物理设备或网关与平台中的设备对象建立对应关系。这个过程主要包括设备实体创建、访问凭证配置和网关 MQTT 参数配置。
1. Device：创建设备实体
在 ThingsBoard PE 中创建对应的 Device 对象，用于表示现场真实设备或网关设备。创建设备时通常需要填写或关联以下信息：
- Device Name（设备名称）
- Device Profile（设备类型）
- Device Label（设备标签）
其中，Device Profile 决定该设备后续使用哪套接入与规则处理配置。
2. Device Credentials：配置设备访问凭证
设备需要通过访问凭证向 ThingsBoard PE 进行身份认证。访问凭证可以由平台随机生成，也可以根据项目规范自行编辑。
在 MQTT 接入场景中，设备访问凭证通常会作为网关连接 ThingsBoard PE 的认证信息使用。配置完成后，需要妥善记录凭证，并同步到网关侧。
3. 配置网关 MQTT 参数
在网关侧配置 MQTT 连接参数时，需要把 ThingsBoard PE 的服务地址、端口、访问凭证和遥测上报主题填写到对应位置。示例配置如下：
| 参数 | 说明 | 示例 |
|---|---|---|
| Broker 地址 | ThingsBoard 服务器 IP 或域名 | 192.168.1.100 |
| 端口 | MQTT 通信端口 | 1883 |
| 协议 | MQTT 传输协议 | MQTT TCP |
| Client ID / 认证字段 | 按网关字段定义填写设备访问凭证或对应认证信息 | TP-HLH0001 |
| 主题 | ThingsBoard MQTT 设备上传遥测数据的固定主题 | v1/devices/me/telemetry |
完成以上配置后，网关即可通过 MQTT 向 ThingsBoard PE 上报遥测数据。
四、查看遥测数据与存储结果
网关开始上报数据后，可以在设备详情页查看遥测状态和遥测数据。配置正确时，设备上报的数据会进入规则链，并通过 Save Time Series 节点写入时间序列存储。
设备遥测状态示例：
设备遥测数据示例：
本文示例环境中，时间序列数据在 PostgreSQL 中的存储格式如下：
小结
通过 ThingsBoard PE 接入物联网关 MQTT 数据时，可以按以下顺序完成配置：
- 创建 Rule Chain，定义数据过滤、分流、转换和存储逻辑。
- 创建 Device Profile，统一管理同类设备的接入方式和规则链。
- 创建设备实体，并配置 Device Credentials。
- 在网关侧填写 MQTT Broker、端口、访问凭证和遥测主题。
- 上报数据后，在设备遥测页面和时间序列存储中验证结果。
相比将解析逻辑全部写入业务系统，基于 Device Profile 和 Rule Chain 的配置方式更适合设备类型持续增加、数据处理规则需要持续迭代的物联网项目。它能把设备接入和业务逻辑解耦，让后续扩展、维护和问题定位更清晰。