布尔状态 Cluster(BooleanState)
Cluster ID: 0x0045 |
所在 Endpoint: 通常在 Endpoint 1(功能端点) |
角色: Server(只读,无命令)
BooleanState 是 Matter 中最简单的 Cluster 之一 —— 只有 1 个属性、0 个命令、1 个事件。 它用于报告一个通用的布尔(true/false)状态,典型的使用场景包括门窗传感器、水浸传感器、烟雾报警器等只需要表达「正常 / 异常」两态的设备。
这个 Cluster 是纯只读的 —— App 端只能读取状态和订阅变化,不能向设备发送任何命令来改变状态。 状态的变化完全由设备端的物理传感器驱动。
BooleanState 本身不定义 true/false 的具体含义 —— 语义由搭配的设备类型(Device Type)决定。 这是开发中最容易踩的坑。
例如,对于 ContactSensor(门窗传感器,Device Type 0x0015):
true= 门/窗已关闭(正常,触点闭合)false= 门/窗已打开(告警,触点断开)
这和直觉可能相反 —— 很多人会以为 true = 打开。
Matter 的设计逻辑是:true 表示「正常/安全」状态,false 表示「需要注意」的状态。
务必根据具体设备类型的规范来解读,不要想当然。
属性
BooleanState 只有一个属性,且是必须支持的。
| ID | 名称 | 类型 | 读写 | 说明 |
|---|---|---|---|---|
0x00 |
StateValue | bool | 只读 | 当前布尔状态 |
StateValue(当前状态)
设备当前的布尔状态值。只读,不能通过写属性或命令来改变 —— 只有设备端的物理传感器触发才会更新这个值。
| 值 | 通用含义 | ContactSensor 含义 |
|---|---|---|
true |
正常 / 安全 | 门窗已关闭(触点闭合) |
false |
异常 / 需注意 | 门窗已打开(触点断开) |
不要在代码里硬写 if (stateValue) "已关闭"。应该根据设备的 Device Type
(从 Descriptor Cluster 的 DeviceTypeList 获取)来决定如何展示文案。
未来可能有新的设备类型复用 BooleanState,true/false 的含义可能完全不同。
事件(Events)
BooleanState 定义了一个事件,当 StateValue 发生变化时由设备端主动上报。
相比轮询属性,订阅事件是监听状态变化的推荐方式。
| ID | 名称 | 优先级 | 说明 |
|---|---|---|---|
0x00 |
StateChange | Info | StateValue 发生变化时触发 |
StateChange —— 状态变更事件(0x00)
当设备的物理状态发生变化(如门被打开、检测到漏水)时,设备会发出此事件。
事件数据中携带变化后的新 StateValue。
| 字段 | ID | 类型 | 说明 |
|---|---|---|---|
| StateValue | 0x00 |
bool | 变化后的新状态值 |
事件上报示例:
{
"eventReports": [{
"eventData": {
"path": {
"endpointId": 1,
"clusterId": "0x0045",
"eventId": "0x00" // StateChange
},
"eventNumber": 42,
"priority": "INFO",
"data": {
"0": false // StateValue = false(状态变化:如门被打开)
}
}
}]
}
对于门窗传感器这类设备,状态变化通常很突然且不频繁。
推荐使用 Subscribe 同时订阅 StateValue 属性和 StateChange 事件,
这样既能在连接建立时立即获取当前状态,又能实时收到变化通知。
订阅请求示例:
{
"subscribeRequests": [{
"attributeRequests": [{
"endpointId": 1,
"clusterId": "0x0045",
"attributeId": "0x00" // StateValue
}],
"eventRequests": [{
"endpointId": 1,
"clusterId": "0x0045",
"eventId": "0x00" // StateChange
}]
}],
"minIntervalFloor": 0, // 最短上报间隔(秒)
"maxIntervalCeiling": 300 // 最长上报间隔(秒)
}
示例数据
读取一个门窗传感器的 BooleanState Cluster 属性:
{
// --- 属性 ---
"0x0": true // StateValue = true(正常状态,如门已关闭、无漏水)
}
常见场景
场景 1:门窗传感器(ContactSensor)
最常见的使用场景。门窗传感器由磁铁和簧片开关组成,门关闭时磁铁靠近簧片,触点闭合。
- 从 Descriptor Cluster 确认设备类型为
0x0015(ContactSensor) - 订阅 BooleanState 的
StateValue属性和StateChange事件 - 收到
true→ 显示「门已关闭」(绿色安全状态) - 收到
false→ 显示「门已打开」(黄色提醒状态) - 可结合自动化:门打开超过 5 分钟未关 → 推送提醒
场景 2:水浸传感器(Water Leak Detector)
水浸传感器放置在可能漏水的位置(洗衣机旁、热水器下方),检测到水时触发告警。
- 订阅
StateChange事件 - 收到
true→ 正常,无漏水 - 收到
false→ 检测到漏水,触发紧急通知 - 建议搭配自动化规则:漏水时自动关闭对应区域的智能水阀
场景 3:通用接触式传感器
BooleanState 不局限于门窗和水浸,任何需要二值状态的传感器都可以复用。
- 冰箱门传感器 —— 门开着时
false,搭配定时提醒 - 邮箱传感器 —— 邮箱被打开时触发通知
- 抽屉/柜门传感器 —— 安防场景,异常打开时告警
关键是要从 Descriptor Cluster 读取设备类型,根据具体类型决定 UI 文案和图标, 而不是假设所有 BooleanState 都是门窗传感器。