一、触发条件基础：触发条件的定义、类型与生命周期

大家好，我是这次课程的主讲工程师。做智能场景联动这么多年，我见过太多「场景不生效」的翻车现场。排查到最后，十有八九是触发条件没搞明白。今天咱们就把这块地基打牢。

说白了，触发条件就是「场景启动的开关」。你设定了一个场景——比如「回家模式」——系统怎么知道该执行了？靠的就是触发条件。

我习惯把触发条件比作门卫。门卫看到特定的人（设备状态变化）、在特定的时间（定时）、或者收到特定的通知（事件），才会开门放行。场景联动也一样，触发条件满足了，动作才会被执行。

核心定义：触发条件是指引起场景联动开始执行的信号或状态变化。没有触发条件，场景就是一堆死规则。

嗯，这里要注意：触发条件和执行条件不是一回事。触发条件是「什么时候开始干活」，执行条件是「干活前再检查一遍」。很多新手把两者混了，结果场景要么乱执行，要么死活不执行。

我在实际项目中归纳过，触发条件就三大类。你想想看，是不是所有场景都逃不出这个框架？

这是最常见的一种。设备的状态发生变化，触发场景执行。

我曾经做过一个项目，用户反映「开窗时空调不关」。排查后发现，触发条件写的是「门窗传感器状态=打开」，但传感器上报有2秒延迟，空调已经先启动了。后来加了0.5秒的防抖延迟才解决。

我的经验：设备触发尽量用「变化后」而不是「等于」。比如「温度>30℃」比「温度=30℃」更可靠，因为传感器可能跳变，直接等于容易漏触发。

按时间点或时间周期来触发场景。这类触发不依赖设备状态，纯粹看时间。

我个人习惯把时间触发分成「硬时间」和「软时间」。硬时间是固定时刻，比如早上7点；软时间是相对时间，比如日出日落。软时间需要配合地理位置计算，精度要求高的话，建议用专业气象服务的数据。

事件触发比较特殊，它不是设备状态变化，而是系统内部或外部发生的「消息」。比如安防报警、设备离线、固件升级完成等。

注意：事件触发通常是一次性的，不像设备触发可以持续监测。事件发完就没了，如果场景没来得及响应，事件就丢失了。我曾经遇到过网关重启后，所有告警事件都丢了，导致安防场景没触发。后来加了事件持久化才解决。

搞清楚了类型，还得知道触发条件是怎么「活」的。我画了一张图，帮你理解触发条件从创建到销毁的全过程。

这张图我画了好几次才满意。你看，触发条件不是「配完就完了」，它有一个完整的生命周期。我见过不少开发者只关注「创建」和「触发」，忽略了「注册」和「监听」阶段的资源管理，结果系统里堆了几百个僵尸监听，网关内存爆了。

理解了生命周期，咱们再聊聊触发条件的几个关键特性。这些特性决定了场景的稳定性和可靠性。

避坑指南：我曾经做过一个全屋智能项目，用户配了50多个场景。结果网关每天凌晨3点准时卡死。排查发现，有20多个场景用了「每5分钟触发一次」的时间触发，凌晨3点正好是系统定时任务高峰期，所有触发条件同时检查，把网关跑崩了。后来改成错峰触发，问题解决。

最后，我必须强调一下这个容易混淆的点。很多新手把触发条件和执行条件混为一谈，结果场景逻辑一团糟。

你想想看，如果「门窗传感器打开」既是触发条件又是执行条件，那场景会变成什么样？每次开门都触发，但执行条件检查时发现「门窗传感器已经打开了」，条件满足，执行。然后再次触发...死循环了。所以设计场景时，一定要把触发和执行分开考虑。

好了，触发条件的基础就讲到这里。记住：触发条件是场景的「启动钥匙」，选对类型、管好生命周期、分清触发和执行，你的场景联动就成功了一半。

核心总结：