ThingsBoard 如何判断设备的在线/离线状态

如下三个配置项协同工作，共同决定了 ThingsBoard 如何判断设备的在线/离线状态（即服务端属性 active）。它们分别扮演“标准制定者”、“定期执行者”和“信息上报者”的角色。

1. 核心参数详解

2. 三者如何协同工作

用一个比喻可以帮你更好地理解这三者的关系：

• Transport 服务：像一个“记分员”，它负责时刻留意设备的一举一动。
• Device State 服务：像一个“裁判”，它负责最终判定设备是“活跃”还是“不活跃”。
• report_timeout (3秒)：是“记分员”向“裁判”喊话汇报的频率。每隔3秒，记分员就会把看到的设备活动情况告诉裁判。
• defaultInactivityTimeoutInSec (10分钟)：是“裁判”的耐心。如果裁判在整整10分钟内没收到任何关于某个设备的活动报告，他就会判定该设备“不活跃”。
• defaultStateCheckIntervalInSec (1分钟)：是“裁判”低头看表、做出判决的频率。即便设备已经沉默了10分钟，裁判也要等到自己每1分钟一次的“检查时刻”，才会正式宣布该设备“不活跃”，并更新状态。

3. 关键约束与逻辑关系

三者之间存在一个强制的逻辑约束，以确保状态判断的准确性：

约束条件：transport.sessions.report_timeout 必须小于 defaultInactivityTimeoutInSec

这是 ThingsBoard 官方在配置文件中明确要求的。这个条件的核心目的是确保“裁判”在宣布结果前，一定能收到“记分员”的最新报告。

• 正确示例 ✅：记分员每 3 秒 汇报一次，裁判的耐心是 600 秒。裁判每次都能在耐心耗尽前收到“续命信号”，判断准确。
• 错误示例 ❌：假设你错误地将 report_timeout 设为 600 秒，而 defaultInactivityTimeoutInSec 设为 60 秒。那么，裁判在第 60 秒时就会因没收到报告而误判设备离线。直到 600 秒后，记分员才慢悠悠地送来报告，裁判又会将状态改回在线。这会导致 active 状态频繁错误震荡。

4. 配置调优建议

了解这些参数的关系后，你可以根据业务需求进行调整：

5. 重要说明

1. active ≠ 实时连接状态：active 代表的是业务活跃度。即使设备物理断开，只要没超过 inactivityTimeout，其状态依然可能显示为 active。要获取实时连接事件，应使用规则链处理 Connect 和 Disconnect 事件。
2. 状态更新存在延迟：由于 defaultStateCheckIntervalInSec 的存在，设备从达到“不活跃”条件到页面状态更新，最多会有1个检查周期的延迟（实际状态变更延迟 = 超时 + 最多一个检查周期）。