ThingsBoard 车联网边缘计算实战：基于 Fleet Tracking 方案将设备数据下沉到 ThingsBoard Edge

本文以 ThingsBoard 开源仓库内置的 Fleet Tracking（车队追踪）解决方案为蓝本，完整讲解如何在其基础上扩展 ThingsBoard Edge 边缘计算能力：包括边缘节点的适用场景、方案预置的边缘实体与实体组、Edge 安装连接流程，以及通过 HTTP Telemetry API 将设备数据推送到边缘节点并最终回传云端的方法。读完本文你将掌握 Fleet Tracking 方案边缘化部署的完整链路，并能直接复制运行其中的 curl 数据推送命令进行验证。

边缘计算在 Fleet Tracking 方案中的定位

Fleet Tracking 是 ThingsBoard 仓库内置的物流运输解决方案模板，它在 description.md 中被定位为"加速器型模板"，开箱即可获得实时车辆地图、告警监控和历史轨迹分析能力。而边缘计算（Edge computing）是该方案的可选扩展能力，对应仓库内的说明文档 edge_instructions.md。

ThingsBoard Edge 的核心价值在于：把数据分析和设备管理能力下沉到数据产生的现场，同时根据业务需要与 ThingsBoard 云端无缝同步。对于 Fleet Tracking 场景而言，这意味着车队数据不必全部汇聚到中心云服务器，而是可以在靠近车辆的边缘侧完成实时处理与决策。

典型应用场景：分散的公交站点

文档中给出的参考场景非常明确：当公交站点分散在城镇各处时，可以在每一个公交站点内部署一台 ThingsBoard Edge，让它就近处理来自附近公交定位设备的数据。这种拓扑结构带来三个直接收益：

1. 实时分析与决策：边缘节点可以在本地完成诸如"公交车偏离预定路线"之类的告警判断，无需等待数据往返云端；
2. 断网不丢数据：当中央 ThingsBoard 服务器之间网络中断时，边缘节点继续在本地处理数据，任何数据都不会丢失，所需决策也在本地即时做出；
3. 网络恢复后自动同步：一旦网络连接恢复，必要的数据会被自动推送回云端。

更关键的是，这种边缘业务逻辑的配置是集中式的——所有边缘计算规则都统一在 ThingsBoard 服务器侧管理配置，而不是分散到每个边缘节点逐一维护。这与仓库内 DefaultSolutionService.java 中按解决方案统一编排边缘实体、实体组和模板注入的实现方式是一致的。

方案预置的边缘实体与实体组

为了降低边缘部署的复杂度，Fleet Tracking 方案在安装时自动创建了一个名为 Remote Bus Station R1 的新边缘实体，并将两个实体组预先分配给它。这一点可以直接从 entities/edges.json 中验证：

[
  {
    "name": "Remote Bus Station R1",
    "type": "station",
    "deviceGroups": [
      {
        "name": "Bus devices"
      }
    ],
    "dashboardGroups": [
      {
        "name": "Fleet tracking"
      }
    ]
  }
]

其中实体组分配情况如下：

实体组名称	组类型	作用
Bus devices	DEVICE 设备组	将该组内所有设备自动下发（provision）到边缘节点
Fleet tracking	DASHBOARD 仪表板组	将车队追踪仪表板同步到边缘节点

而"Bus devices"设备组中的成员，正是方案预置的 4 台演示公交设备 Bus A～Bus D，定义见 entities/devices.json：

设备	类型	所属组	关联模拟器
Bus A	bus	Bus devices	onRouteBus（正常行驶）
Bus B	bus	Bus devices	onRouteBus（正常行驶）
Bus C	bus	Bus devices	brokenBus（抛锚故障）
Bus D	bus	Bus devices	refuelingBus（加油中）

从源码结构可以推断，安装解决方案时这些设备会被创建并归入"Bus devices"组，随后整个组被绑定到边缘实体，从而形成"组即边界"的简洁下发模型：想扩展现有车队边缘节点，只需把新设备加入该组。

安装 ThingsBoard Edge 并连接云端

安装步骤在文档中描述得非常简洁，实际操作路径如下：

1. 在 ThingsBoard 云端的 Edge 管理页面中找到方案创建的 Remote Bus Station R1 边缘实体；
2. 进入该边缘实体的详情页面（即文档中的 edge details page）；
3. 点击页面上的 Install & Connect instructions（安装与连接指南）按钮，获取当前环境对应的 Edge 安装命令；
4. 在目标主机（例如公交站点机房）上执行安装脚本，完成 Edge 的部署与云端连接；
5. 连接成功后，使用租户（tenant）凭证登录 Edge，即可管理这台边缘设备。

这里对应的 UI 链接在服务端由占位符 ${Remote Bus Station R1EDGE_DETAILS_URL} 动态替换为真实的边缘详情页地址——DefaultSolutionService.java 中对该占位符的替换逻辑清晰可见（构建 /edgeManagement/edges/all/<edgeId> 形式的详情 URL）。

数据下发与查看：从云端自动同步到边缘

由于 "Bus devices" 设备组已分配给边缘实体 "Remote Bus Station R1"，组内所有设备都会被自动下发（provision）到 Edge 上，无需手动逐台复制。

当您用租户凭证登录 Edge 后，在 Entities -> Devices（实体 -> 设备） 页面即可看到这些自动同步过来的公交设备。这意味着边缘节点已经具备了与云端一致的设备目录，可以独立完成设备数据接入。

实战：用 curl 向边缘设备推送遥测数据

文档给出了两种可直接复制的验证命令。核心思路是：模拟 Bus C 设备，通过 HTTP Telemetry API 向 Edge 推送一条位置与状态遥测数据。数据字段与 Fleet Tracking 方案的遥测模型完全对应（latitude、longitude、speed、fuel、status），该模型定义可参见 instructions.md 与 device_emulators.json。

命令一：Edge 使用默认 HTTP 8080 绑定端口时：

curl -v -X POST -d "{\"latitude\":  37.764702, \"longitude\":  -122.476071, \"speed\":  50, \"fuel\":  5, \"status\": \"On route\"}" http://localhost:8080/api/v1/${Bus CACCESS_TOKEN}/telemetry --header "Content-Type:application/json"{:copy-code}

命令二：安装 Edge 时若将 HTTP 8080 绑定端口改为 18080：

curl -v -X POST -d "{\"latitude\":  37.764702, \"longitude\":  -122.476071, \"speed\":  50, \"fuel\":  5, \"status\": \"On route\"}" http://localhost:18080/api/v1/${Bus CACCESS_TOKEN}/telemetry --header "Content-Type:application/json"{:copy-code}

对命令的逐项拆解说明：

• ${Bus CACCESS_TOKEN} 是 Bus C 设备的访问令牌（Access Token），需要替换为登录 Edge 后在设备详情页中查到的实际令牌值；
• /api/v1/<ACCESS_TOKEN>/telemetry 是 ThingsBoard 标准 HTTP Telemetry 上传接口，令牌既是设备身份凭证，也是 URL 路径的一部分；
• -X POST 指定使用 HTTP POST 方法；-d 携带 JSON 格式的请求体；--header "Content-Type:application/json" 声明请求体类型；
• 遥测字段中 latitude/longitude 为经纬度坐标，speed 为速度（示例 50），fuel 为燃油余量百分比（示例 5，已处于低油量告警区间），status 为车辆状态（示例 "On route"）。

推送成功后，用浏览器打开方案生成的 Fleet Tracking 仪表板，即可看到地图上车辆位置与状态实时刷新；与此同时，边缘节点上配置的告警规则也会基于这批数据触发告警。

数据回传：边缘遥测同步到云端

文档明确说明了一个关键结论：向 Edge 上的设备 Bus C 推送数据后，该设备在云端的遥测数据也会同步更新。

这正是 ThingsBoard Edge "断网自治、联网回传"特性的落地体现。其背后机制为：Edge 在本地完成数据存储与规则处理的同时，维护与云端的同步通道；当网络连接可用时，遥测数据、告警、设备状态等增量会按配置策略推送回中央 ThingsBoard 服务器，从而保证云端仪表板与边缘处理结果的一致性。因此，Fleet Tracking 的云端仪表板即使部署了边缘节点，也依然能实时反映车辆的最新位置与状态。

联动告警规则：边缘数据驱动的决策逻辑

虽然 edge_instructions.md 本身聚焦于部署与数据推送，但结合方案预置的告警规则，可以更完整地理解"边缘分析决策"到底分析什么。方案在 bus 设备配置文件中预置了三条告警规则（对应文件位于 alarm_rules 目录）：

规则文件	触发条件	严重级别	清除条件
bus_low_fuel.json	fuel <= 20	MAJOR	fuel >= 25
bus_speed_limit.json	speed >= 45	CRITICAL	speed < 45
bus_stopped.json	speed == 0 持续 5 秒	WARNING	speed > 0 持续 5 秒

从这些规则可以看出，上文 curl 示例中推送的 "fuel": 5 与 "speed": 50 都是刻意构造的"越界"数据——推送到 Edge 后，边缘节点会立即在本地完成低油量（MAJOR）与超速（CRITICAL）告警的判断与生成，这正是文档所述"本地实时分析与决策"的实例。而三份规则文件都引用了 TS_LATEST（最新遥测值）作为判断依据，说明决策完全依赖设备最近一次上报的数据即可完成，非常适合边缘侧低延迟处理。

从源码看解决方案的边缘模板注入机制

最后从仓库源码层面补充说明边缘说明文档本身是如何进入安装流程的。DefaultSolutionService.java 在渲染解决方案说明时执行了以下关键逻辑：

1. 检查主模板（instructions.md）中是否存在 ${edge_instructions} 占位符；
2. 若本次安装没有创建任何边缘实体，则该占位符被替换为空字符串（不显示边缘章节）；
3. 若创建了边缘实体，则读取解决方案目录下的 edge_instructions.md 文件内容并注入模板；
4. 同时将 ${<边缘实体名>EDGE_DETAILS_URL} 占位符替换为真实的边缘详情页 URL。

这一机制说明两点事实：其一，边缘章节是否出现在解决方案说明中，取决于该解决方案是否定义了边缘实体（如 Remote Bus Station R1）；其二，edge_instructions.md 中的 ${Bus CACCESS_TOKEN} 等令牌占位符与实体组、设备的预置是一套完整的自动化装配流程，用户只需按文档步骤执行即可完成边缘化部署，无需手工创建任何边缘资源。

小结

Fleet Tracking 方案的边缘扩展是一条"零代码、组驱动"的实践路径：方案预置边缘实体 Remote Bus Station R1 并绑定设备组与仪表板组，用户安装 Edge 后设备自动下发，随后即可通过标准的 Telemetry HTTP API 向边缘设备推送数据，边缘本地完成分析决策，网络恢复后数据自动回传云端。整个过程的配置全部集中在 ThingsBoard 服务器侧，符合大规模车队分布式部署的管理诉求。相关实现细节可进一步查阅仓库内的 edge_instructions.md、entities/edges.json、entities/devices.json 与 DefaultSolutionService.java 等文件。