基于ThingsBoard的复杂IoT业务逻辑实现架构选型咨询

当前使用情况 #

我们基于ThingsBoard完成IoT设备的基础管理，涵盖设备列表查看、活跃状态监控、仪表板遥测数据可视化（如电池状态）、OTA升级等功能。

核心需求与现有方案瓶颈 #

目前设备需按业务逻辑协同运作，而非独立运行。官方文档提到可通过rule chains和资产实现多设备数据聚合及上层状态管理，但官方示例场景简单，我们在落地复杂逻辑时发现rule chains配置繁琐、扩展性不足。

当前尝试的架构及痛点 #

我们选择在独立服务器中实现核心业务逻辑，但遇到设备数据传输与指令下发的障碍：

• 最初尝试让服务器接入ThingsBoard内置MQTT broker，但该broker并非为外部服务对接设计，无法直接使用
• 当前采用的方案：通过ThingsBoard的rule chain将设备MQTT消息转发至第三方MQTT broker，供独立服务器订阅；指令下发则通过ThingsBoard的REST接口发送RPC调用（据官方文档，REST是外部系统下发RPC的唯一途径）
• 这套架构链路长、复杂度高，增加了维护成本与潜在故障点

需要实现的复杂业务逻辑 #

我们的核心业务场景包括：

1. 同一工位下的两台设备，当设备发起运行请求时，仅允许其中一台启动
2. 运行中的设备若超时未上报指定遥测数据，需通过RPC指令强制停止
3. 某工位部署10台设备，当外部系统触发事件时，需自动启动两台处于未运行状态的设备

寻求有相关实践经验的开发者分享超出基础仪表盘控制与rule chains的设备管控方案。

内容的提问来源于stack exchange，提问作者Tobias Uhmann