设备状态查询与冲突判断

有些指令的下发依赖设备当前状态,而不只是「解析用户意图 → 下发指令」这么简单:

• 查询类指令:如「当前灯的亮度是多少」——需要拿到设备实时状态才能回答;
• 状态冲突判断:如用户说「开灯」但灯本就开着——需要先知道灯的当前状态,才能回复「灯已经开着啦」而非重复下发开灯指令。

这类场景的共同前提是:模型需要提前知道设备当前状态。

1. 为什么需要「提前知道设备状态」

普通控制指令(如「开灯」)是单向的:解析意图 → 下发指令,不关心设备原本什么状态。

但查询与冲突判断是状态相关的:

用户 query
    ↓
必须先拿到「设备当前状态」
    ↓
├─ 查询类:用当前状态组织回复(「当前亮度 60%」)
└─ 冲突判断:比较目标状态与当前状态
       ├─ 已处于目标状态 → 提示用户,不重复下发(「灯已经开着啦」)
       └─ 未处于目标状态 → 正常下发指令

核心结论:模型只有拿到设备当前状态,才能完成查询类与状态冲突类场景的闭环。而设备状态从哪里来,取决于你的设备是 IoT 设备还是端侧直连设备。

2. 按设备类型区分要做的事

2.1 IoT 设备:无需额外操作

若设备接入了 IoT 平台,设备状态由 IoT 平台侧维护,平台可自动获取。

• 你无需做任何额外配置,查询类与状态冲突类场景即可正常闭环。

2.2 端侧直连设备:需要上报状态

若设备为端侧直连(不经 IoT 平台),平台默认不掌握设备的实时状态。此时:

• 端侧需要周期性、以及状态发生变更时,主动上报设备当前状态;
• 只有端侧上报了状态,模型才能知道设备当前状态,进而完成查询类与状态冲突类场景的闭环;
• 若端侧未上报,平台无从获知设备状态,查询与冲突判断将无法正确工作。

状态上报通过端侧上行事件 CLIENT_UPDATE_CHAT_CONTEXT(主动更新对话上下文)完成,将设备状态放入 kvData.status 中上报。

内容示例:

{
  "code": 200,
  "requestId": "1",
  "mid": "1",
  "contentType": "ACTIVITY",
  "content": {
    "activityType": "CLIENT_UPDATE_CHAT_CONTEXT",
    "effectiveTimeMinutes": 5,
    "kvData": {
      "status": {}
    }
  }
}

⚠️ status 必须上报文本,不要用标识 / 编码类内容,否则模型无法理解。

• ✅ 正确:开关 = 开、模式 = 手动模式
• ❌ 错误:switch = 1、mode = 0x02

事件字段的完整说明见:CLIENT_UPDATE_CHAT_CONTEXT(主动更新对话上下文)。

3. 一览对照

设备类型	状态从哪来	你需要做什么
IoT 设备	IoT 平台侧维护	无需额外操作
端侧直连设备	端侧主动上报	周期性 + 状态变更时上报设备状态

4. 相关链接

• 上级导航:自定义指令集
• 联动配置:静默指令 · 定时指令
• 测试相关:指令的测试和调优
• 上游技能:AIoT 指令控制