故障排查与解决
故障现象 / 场景
客人按「睡眠模式」或「离房模式」后，灯光与窗帘动作了，但空调或排气扇没有执行；有时同一场景在部分房间正常、部分房间只执行前两步。
排查思路（由易到难）
- 先看该场景的定义表：包含哪些回路与设备、是否有先后顺序与延时；
- 确认停止的位置是否总是同一环节，若固定停在某设备上，问题在该设备的联动配置或通信；
- 检查是否设置了互锁或优先级（如睡眠模式下禁止窗帘全开），排除被策略主动拦截；
- 检查涉及第三方设备（空调、排气扇、电动窗帘）的通信协议与点表是否正确；
- 查看 RCU 日志中的执行记录，确认指令是否发出以及是否有超时。
解决方案
1) 补齐场景定义表中缺失的设备或回路，并明确每一步的目标状态与延时。 2) 对第三方设备逐台验证通信：点表地址、协议参数、超时重试设置。 3) 校核互锁与优先级规则，确认设计意图与运营预期一致。 4) 对执行时长较长的设备（如电动窗帘）设置合理的等待与状态回读，避免后续步骤被打断。 5) 把场景定义表纳入交付资料，并在调试记录中标注每个场景的验证结果。
适配型号客控主机与场景面板、电动窗帘/空调等第三方联动设备
根因总结
场景联动是一串有序指令，中断在固定位置说明该环节的配置或通信有问题，而不是整个场景配置丢失。定位的关键是把「场景」拆成「步骤」，找出断在哪一步。
延伸知识
同样的方法可用于灯光场景、会议模式、宴会模式等任何「一键多设备」的场景；先把场景写成步骤表，再逐项验证，比现场反复试按要快得多。
避坑要点
不要在未核对场景定义表前就重建场景。重建后若原定义表未更新，交付资料与现场实现会长期不一致，后续运维会反复踩坑。
把「场景」拆成「步骤表」
调试场景最有效的方法是先写表再验证：
图片素材来自免费商用图库（pixabay，摄影师 HomeoGrapher），非本站项目实拍。
| 步骤 |
目标设备 |
目标状态 |
延时 |
验证结果 |
| 1 |
主灯 |
关 |
0s |
✅ |
| 2 |
床头灯 |
20% |
0s |
✅ |
| 3 |
电动窗帘 |
关闭 |
— |
❌ 未执行 |
| 4 |
空调 |
26℃ 制冷 |
5s |
✅ |
一旦有了这张表，「执行一半就停」立刻变成一个具体的断点，而不是抽象的「场景坏了」。
三类常见断点
- 配置缺失：场景定义里根本没写这一项；
- 通信失败：第三方设备点表地址或协议参数错误、超时；
- 策略拦截：互锁或优先级规则主动禁止，属设计行为而非故障。
第三类最容易被误判为故障 —— 例如「睡眠模式不允许打开主灯」是设计意图，不是坏了。
调试记录的价值
把每个场景的验证结果与日期记入调试记录，交付时一并发给酒店工程部。之后客人报「某场景不对」，可以直接对照记录确认是设计如此还是真的坏了，避免重复排查。
本文由 58120 智能网络 原创发布。转载请注明出处并保留原文链接。
评论 0
还没有评论，来抢沙发吧。