3. 仪表板基础概念:仪表板定义、仪表板状态、仪表板别名、仪表板权限模型
在深入 ThingsBoard 仪表板设计之前,必须理解四个核心基础概念:仪表板定义、仪表板状态、仪表板别名和仪表板权限模型。它们是构建任何复杂仪表板的基石,决定了数据如何被组织、导航、引用以及谁可以访问。
3.1 仪表板定义 (Dashboard Definition)
仪表板定义是 ThingsBoard 中一个仪表板的完整 JSON 描述。它包含了仪表板的所有配置信息,从布局、组件到数据源绑定,全部以结构化数据的形式存储。
核心要点: 仪表板定义是一个 JSON 对象,包含
title、configuration(含 widgets、layouts、states、aliases 等)、assignedCustomers 等顶层字段。理解其结构是进行高级定制和版本控制的前提。
仪表板定义的主要组成部分:
| 组成部分 | 说明 | 示例 |
|---|---|---|
| title | 仪表板的显示名称 | "生产车间实时监控" |
| configuration | 核心配置对象,包含布局、小部件、状态、别名等 | { "widgets": [...], "layouts": {...} } |
| assignedCustomers | 分配给特定客户的列表(用于多租户场景) | [ { "customerId": {...} } ] |
| image | 仪表板缩略图(Base64 编码) | "data:image/png;base64,..." |
| mobileHide | 是否在移动端隐藏 | false |
一个简化的仪表板定义 JSON 结构示例:
{
"title": "温度监控仪表板",
"configuration": {
"widgets": [
{
"id": "w1",
"type": "timeseries",
"config": {
"datasources": [
{
"type": "entity",
"name": "温度传感器",
"aliasName": "temp_sensor_alias"
}
]
}
}
],
"layouts": {
"main": {
"widgets": { "w1": { "sizeX": 6, "sizeY": 4, "col": 0, "row": 0 } }
}
},
"states": { "default": { "name": "主视图" } },
"aliases": { "temp_sensor_alias": { ... } }
},
"assignedCustomers": []
}
3.2 仪表板状态 (Dashboard State)
仪表板状态是 ThingsBoard 实现多页面导航和交互式钻取的核心机制。每个状态代表仪表板中的一个独立视图,可以拥有自己的一组小部件和布局。
设计技巧: 将仪表板状态视为“页面”。通过状态之间的切换(例如点击设备卡片进入详情页),可以构建从全局概览到局部细节的完整用户体验。
状态的关键属性:
- 状态 ID:状态的唯一标识符(如
default、device_detail)。 - 名称:状态的显示名称,用于面包屑导航或状态切换器。
- 根状态:仪表板加载时默认显示的状态,通常命名为
default。 - 父状态:允许定义状态层级,实现“返回上一级”功能。
- 布局:每个状态可以拥有独立的布局(如 main、right、bottom),控制小部件的位置。
状态之间的典型关系:
3.3 仪表板别名 (Dashboard Alias)
仪表板别名是 ThingsBoard 中一个强大的抽象层。它允许小部件的数据源不直接绑定到具体的设备或资产实体,而是绑定到一个逻辑名称(别名)。别名在运行时解析为实际的实体 ID。
常见误区: 初学者常将别名与实体名称混淆。别名是仪表板级别的配置,可以指向单个实体、实体组或通过过滤器动态解析的实体集合。修改别名解析逻辑无需更改小部件配置。
别名的类型与解析方式:
| 别名类型 | 解析方式 | 适用场景 |
|---|---|---|
| 单个实体 | 直接指定一个设备、资产或租户 | 固定设备监控(如“中央空调主机”) |
| 实体列表 | 指定多个实体 ID | 固定设备组(如“1号车间所有传感器”) |
| 实体名称过滤器 | 根据名称模式匹配(如 temp_*) |
动态发现设备(如所有以“temp_”开头的设备) |
| 实体类型过滤器 | 根据实体类型(如 DEVICE、ASSET)和关系 | 按类型分组(如“所有温度传感器”) |
| 状态实体 | 从仪表板状态参数中获取实体 ID | 状态间传递实体(如点击设备卡片进入详情) |
别名在仪表板定义中的位置:
{
"configuration": {
"aliases": {
"current_device": {
"alias": "当前选中设备",
"filter": {
"type": "entity_from_dashboard_state",
"entityType": "DEVICE",
"stateEntityParamName": "selectedDeviceId"
},
"resolveMultiple": false
},
"all_temp_sensors": {
"alias": "所有温度传感器",
"filter": {
"type": "entity_name",
"entityType": "DEVICE",
"namePattern": "temp_*"
},
"resolveMultiple": true
}
}
}
}
3.4 仪表板权限模型 (Dashboard Permission Model)
ThingsBoard 的权限模型基于角色和范围,控制谁可以查看、编辑或管理仪表板。理解权限模型对于多租户部署和团队协作至关重要。
关键原则: 权限是分层的。租户管理员拥有最高权限,可以创建和分配仪表板给客户。客户用户只能查看被分配且权限允许的仪表板。设备或资产本身不直接拥有仪表板权限。
权限模型的核心角色与能力:
| 角色 | 范围 | 仪表板操作能力 |
|---|---|---|
| 系统管理员 | 整个系统 | 创建/编辑/删除所有仪表板;管理租户仪表板模板 |
| 租户管理员 | 所属租户 | 创建/编辑/删除租户级仪表板;分配给客户;设置公开访问 |
| 客户用户 | 所属客户 | 查看被分配的仪表板;如果获得编辑权限,可修改个人视图 |
| 匿名用户(公开) | 无 | 仅查看标记为“公开”的仪表板(只读) |
仪表板权限的配置方式:
- 仪表板分配:租户管理员可以将仪表板分配给一个或多个客户。分配后,该客户的所有用户都能看到该仪表板。
- 编辑权限:在分配仪表板时,可以勾选“允许客户用户编辑仪表板”。启用后,客户用户可以在自己的范围内修改小部件配置(但无法更改别名或状态结构)。
- 公开访问:将仪表板标记为“公开”后,任何知道链接的人(无需登录)都可以查看。适用于大屏展示或对外报告。
- 移动端权限:可以单独控制仪表板是否在移动端应用上可见。
权限模型的工作流程:
最佳实践: 对于生产环境,建议遵循“最小权限原则”。为客户用户分配只读权限,仅在需要时启用编辑。使用公开访问时,确保仪表板不包含敏感数据或操作按钮。