3、ThingsBoard核心概念：租户、客户、设备、资产、仪表板、规则链、实体关系
好，咱们今天来聊聊 ThingsBoard 里最核心的几个概念。说实话，我刚接触 ThingsBoard 那会儿，也被这些名词绕得有点晕。租户、客户、设备、资产……它们到底是个什么关系？
别急，我带你一个一个捋清楚。搞懂了这些，你后面做项目会顺手很多。
3.1 租户（Tenant）—— 系统的“房东”
租户，你可以把它理解成整个系统的“房东”或“大管家”。在 ThingsBoard 里，租户是一个独立的逻辑单元。每个租户拥有自己的设备、用户、仪表板、规则链等一切资源。
为什么要有租户？
说白了，就是为了多租户隔离。你想想看，如果你做一个物联网平台，卖给 A 公司和 B 公司。A 公司的设备数据，B 公司肯定不能看到吧？租户就是干这个的。
核心要点：
- 每个租户是独立的“王国”
- 租户之间数据完全隔离
- 一个 ThingsBoard 实例可以管理多个租户
- 租户可以创建客户、设备、资产等
我在项目中遇到过一种情况：客户要求把不同工厂的数据分开管理。我当时就用了多租户架构，每个工厂一个租户。嗯，这样权限和数据隔离就都搞定了。
3.2 客户（Customer）—— 租户的“房客”
客户是租户下面的概念。一个租户可以有多个客户。客户通常代表最终使用系统的企业或个人。
租户和客户的区别是什么？
我打个比方你就明白了：
- 租户：是平台的运营方，比如一个物联网 SaaS 服务商
- 客户：是租户的客户，比如买了这个 SaaS 服务的工厂老板
客户能看到什么？只能看到租户分配给他们的设备和仪表板。客户之间也是隔离的，互相看不见。
我的经验：
在实际项目中，我习惯把客户权限收得比较紧。只给客户看他们自己的设备数据，别让他们看到系统配置。这样安全，也省得客户乱改东西。
3.3 设备（Device）—— 物联网的“主角”
设备，这个不用我多说了吧？就是那些传感器、控制器、网关等硬件。在 ThingsBoard 里，设备是最核心的实体。
每个设备有一个唯一的名称，还有访问令牌（Access Token）或证书。设备通过 MQTT、HTTP 或 CoAP 上报数据。
设备的关键属性：
| 属性 | 说明 |
|---|---|
| 设备名称 | 唯一标识，比如 "temperature_sensor_01" |
| 设备类型 | 自定义，比如 "温度传感器"、"电表" |
| 凭证 | 访问令牌、X.509 证书或用户名密码 |
| 客户端属性 | 设备上报的属性，比如固件版本 |
| 服务端属性 | 平台设置的属性，比如安装位置 |
我记得有一次，客户问：“我能不能给设备加个备注？”当然可以。设备属性就是干这个的。你可以在服务端属性里加一个 "location" 字段，写上“3号车间东墙”。
3.4 资产（Asset）—— 设备的“容器”
资产这个概念，很多人一开始会忽略。但我觉得它特别有用。
资产是什么？资产是设备的逻辑分组或容器。比如：
- 一个工厂是一个资产
- 一条生产线是一个资产
- 一个楼宇是一个资产
资产本身不产生数据，但它可以关联多个设备。你想想看，如果你有 50 个温度传感器分布在 5 个车间里。没有资产的话，你怎么快速找到“3号车间”的所有传感器？
资产 vs 设备：
- 设备：产生数据，是数据源
- 资产：组织设备，是逻辑容器
- 一个资产可以包含多个设备
- 一个设备可以属于多个资产（通过关系）
我个人习惯，在项目一开始就规划好资产结构。比如：
工厂（资产）
├── 1号车间（资产）
│ ├── 温度传感器01（设备）
│ ├── 温度传感器02（设备）
│ └── 电表01（设备）
└── 2号车间（资产）
├── 温度传感器03（设备）
└── 电表02（设备）这样后面做仪表板、写规则链，都方便很多。
3.5 仪表板（Dashboard）—— 数据的“展示窗口”
仪表板，就是 ThingsBoard 里的可视化界面。你可以把设备数据用图表、表格、地图等形式展示出来。
仪表板的特点：
- 支持拖拽式布局
- 可以绑定设备、资产的数据
- 支持多种组件：折线图、柱状图、表格、地图、控件等
- 可以设置权限：谁可以看，谁可以编辑
我做过一个项目，客户要求实时显示 200 个电表的功率数据。仪表板里用了一个表格组件，配合自动刷新，效果还不错。不过要注意，数据量大的时候，别把刷新间隔设得太短，不然服务器扛不住。
避坑指南：
我曾经犯过一个错误：在仪表板里绑定了太多实时数据，结果页面加载慢得要命。后来我学乖了，能用聚合数据就用聚合数据，别一股脑全拉下来。
3.6 规则链（Rule Chain）—— 系统的“大脑”
规则链，是 ThingsBoard 里最强大的功能之一。它负责处理设备上报的数据，做过滤、转换、存储、告警等操作。
你可以把规则链想象成一个流水线：
- 设备数据进来（消息入站）
- 经过各种节点处理（过滤、转换、丰富）
- 最终输出到目标（数据库、仪表板、外部系统）
常见的规则链节点：
| 节点类型 | 作用 |
|---|---|
| 过滤器 | 判断数据是否满足条件，比如温度 > 50 |
| 转换器 | 修改数据格式，比如把摄氏度转成华氏度 |
| 动作节点 | 执行操作，比如保存到数据库、发送告警 |
| 外部节点 | 调用 REST API、发送邮件、写入 Kafka |
嗯，这里要注意：规则链的执行顺序很重要。我见过有人把过滤节点放在最后，结果数据都处理完了才过滤，白白浪费性能。
3.7 实体关系（Entity Relations）—— 把一切“串起来”
最后，咱们聊聊实体关系。这是 ThingsBoard 里比较抽象，但极其重要的概念。
实体关系，说白了就是给各种实体（设备、资产、租户、客户等）之间建立联系。比如：
- 设备 A “属于” 资产 B
- 资产 B “包含” 设备 C
- 设备 D “维护” 客户 E
关系类型：
- 从（From）：关系的起点
- 到（To）：关系的终点
- 类型（Type）：关系的名称，比如 "Contains"、"Manages"、"Uses"
举个例子：
// 创建一个关系：资产 "Factory_01" 包含 设备 "Sensor_01"
{
"from": { "id": "资产ID", "entityType": "ASSET" },
"to": { "id": "设备ID", "entityType": "DEVICE" },
"type": "Contains"
}有了实体关系，你就可以做很多高级操作。比如：
- 查询某个资产下的所有设备
- 找到某个设备所属的资产
- 遍历整个资产树
我的建议：
在项目初期，花点时间设计好实体关系。别等到设备上线了，才发现关系乱成一团。我习惯用 "Contains" 表示包含关系，"Manages" 表示管理关系。保持关系类型简单统一，后面维护起来轻松很多。
3.8 它们之间的关系——一张图看懂
说了这么多，咱们来总结一下：
- 租户：系统的顶层容器，拥有所有资源
- 客户：租户的客户，只能看到被分配的资源
- 设备：数据生产者，是物联网的核心
- 资产：设备的逻辑容器，用于组织管理
- 仪表板：数据的可视化展示
- 规则链：数据的处理引擎
- 实体关系：把以上所有实体连接起来的“纽带”
你想想看，没有实体关系的话，设备就是孤立的，资产就是空壳子。有了关系，整个系统才活起来。
好了，这一章的内容就到这儿。下一章咱们会深入讲讲设备接入的具体流程，特别是 Modbus 协议怎么在 ThingsBoard 里配置。到时候见。