★ FEATURED ARTICLE 物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载本文以 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让它就近处理来自附近公交定位设备的数据。这种拓扑结构带来三个直接收益实时分析与决策边缘节点可以在本地完成诸如公交车偏离预定路线之类的告警判断无需等待数据往返云端断网不丢数据当中央 ThingsBoard 服务器之间网络中断时边缘节点继续在本地处理数据任何数据都不会丢失所需决策也在本地即时做出网络恢复后自动同步一旦网络连接恢复必要的数据会被自动推送回云端。更关键的是这种边缘业务逻辑的配置是集中式的——所有边缘计算规则都统一在 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 devicesDEVICE 设备组将该组内所有设备自动下发provision到边缘节点Fleet trackingDASHBOARD 仪表板组将车队追踪仪表板同步到边缘节点而Bus devices设备组中的成员正是方案预置的 4 台演示公交设备 Bus ABus D定义见 entities/devices.json设备类型所属组关联模拟器Bus AbusBus devicesonRouteBus正常行驶Bus BbusBus devicesonRouteBus正常行驶Bus CbusBus devicesbrokenBus抛锚故障Bus DbusBus devicesrefuelingBus加油中从源码结构可以推断安装解决方案时这些设备会被创建并归入Bus devices组随后整个组被绑定到边缘实体从而形成组即边界的简洁下发模型想扩展现有车队边缘节点只需把新设备加入该组。安装 ThingsBoard Edge 并连接云端安装步骤在文档中描述得非常简洁实际操作路径如下在 ThingsBoard 云端的 Edge 管理页面中找到方案创建的Remote Bus Station R1边缘实体进入该边缘实体的详情页面即文档中的 edge details page点击页面上的Install Connect instructions安装与连接指南按钮获取当前环境对应的 Edge 安装命令在目标主机例如公交站点机房上执行安装脚本完成 Edge 的部署与云端连接连接成功后使用租户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 绑定端口改为 18080curl -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为速度示例 50fuel为燃油余量百分比示例 5已处于低油量告警区间status为车辆状态示例 On route。推送成功后用浏览器打开方案生成的 Fleet Tracking 仪表板即可看到地图上车辆位置与状态实时刷新与此同时边缘节点上配置的告警规则也会基于这批数据触发告警。数据回传边缘遥测同步到云端文档明确说明了一个关键结论向 Edge 上的设备 Bus C 推送数据后该设备在云端的遥测数据也会同步更新。这正是 ThingsBoard Edge 断网自治、联网回传特性的落地体现。其背后机制为Edge 在本地完成数据存储与规则处理的同时维护与云端的同步通道当网络连接可用时遥测数据、告警、设备状态等增量会按配置策略推送回中央 ThingsBoard 服务器从而保证云端仪表板与边缘处理结果的一致性。因此Fleet Tracking 的云端仪表板即使部署了边缘节点也依然能实时反映车辆的最新位置与状态。联动告警规则边缘数据驱动的决策逻辑虽然 edge_instructions.md 本身聚焦于部署与数据推送但结合方案预置的告警规则可以更完整地理解边缘分析决策到底分析什么。方案在 bus 设备配置文件中预置了三条告警规则对应文件位于 alarm_rules 目录规则文件触发条件严重级别清除条件bus_low_fuel.jsonfuel 20MAJORfuel 25bus_speed_limit.jsonspeed 45CRITICALspeed 45bus_stopped.jsonspeed 0持续 5 秒WARNINGspeed 0持续 5 秒从这些规则可以看出上文 curl 示例中推送的fuel: 5与speed: 50都是刻意构造的越界数据——推送到 Edge 后边缘节点会立即在本地完成低油量MAJOR与超速CRITICAL告警的判断与生成这正是文档所述本地实时分析与决策的实例。而三份规则文件都引用了TS_LATEST最新遥测值作为判断依据说明决策完全依赖设备最近一次上报的数据即可完成非常适合边缘侧低延迟处理。从源码看解决方案的边缘模板注入机制最后从仓库源码层面补充说明边缘说明文档本身是如何进入安装流程的。DefaultSolutionService.java 在渲染解决方案说明时执行了以下关键逻辑检查主模板instructions.md中是否存在${edge_instructions}占位符若本次安装没有创建任何边缘实体则该占位符被替换为空字符串不显示边缘章节若创建了边缘实体则读取解决方案目录下的 edge_instructions.md 文件内容并注入模板同时将${边缘实体名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 等文件。赞分享物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载相关推荐ThingsBoard 温湿度传感器解决方案的 Edge 边缘计算部署与数据同步实战ThingsBoard 温湿度传感器解决方案的 Edge 边缘计算部署与数据同步实战 导读 本文围绕 ThingsBoard 开源 IoT 平台内置的 Temp物联网后端数据可视化消息队列超分辨率图像重建终极指南如何用PyTorch实现多种先进模型超分辨率图像重建终极指南如何用PyTorch实现多种先进模型 你是否曾面对模糊的老照片或低分辨率图像渴望能恢复其清晰的细节 在数字图像处理领域超分辨示例工程人工智能计算机视觉深度学习针对皮肤问题的负面词针对皮肤问题的负面词 deformed iris, deformed pupils:1.3 plastic skin, waxy texture:1.2 unr上一篇VectorFlow性能优化技巧提升向量嵌入吞吐量的5个实用方法下一篇如何快速掌握组合数学从排列组合到概率问题的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
