关于米家自动化的功能、卡片介绍及使用小技巧。抛砖引玉，仅供参考。

一、简介

二、卡片介绍

事件或状态卡片

在设备分类中，第一个卡片是“事件发生或状态更新”。我们可以通过一个简单的场景来理解它的作用：当灯被打开时，“灯被打开的瞬间”属于一个事件，而“灯处于开启状态”则表示一个状态。事件强调的是某一动作的发生瞬间，而状态则反映的是该动作所带来的持续性结果。

自定义状态卡片

自定义状态卡片可以视为一个布尔类型的变量。与事件卡片相比，它更适合用于表示持续性的状态，并具备记录和存储值的能力。作为状态使用时，若未进行初始化，默认值为假。

如下图所示，当流程启动后，音响将播放“哒哒”声。

状态维持卡片

该卡片用于检测状态是否持续了一段时间：输入为某一状态和设定的持续时间，输出则为一个状态或事件。其核心在于对状态的持续保持进行判断。

当作为事件使用时，它有些类似于延时卡片与判断卡片的结合体。它不仅可以延迟事件的触发，还能有效减少因瞬时波动导致的误判，从而提升自动化流程的稳定性与准确性。

变量卡片

变量分为文本型和数值型两类。在进行数值运算时，需特别注意精度问题。为确保结果的准确性，建议使用函数对数值进行四舍五入处理。

循环卡片

循环卡片可按照预设的时间间隔周期性地发送信号，并支持随时停止循环操作。一个典型的应用场景是：通过循环查询的方式，间接实现某些无法作为触发源的智能设备的触发功能。

以米家饮水机为例：我希望在水箱缺水时收到提醒，但由于饮水机本身无法作为自动触发设备，这一需求无法直接实现。此时，可以借助循环卡片定时查询饮水机的状态，从而实现“缺水提醒”的功能。

由于当前极客版尚未提供类似任务管理器的功能，因此在使用循环卡片时需格外谨慎。原则上应尽量避免设置秒级别的高频循环，以防系统资源被过度占用。

此外，也可以通过设定条件来动态调整循环频率，从而降低系统负担。例如，可以模拟如下逻辑：当循环连续触发三次后，自动停止运行，并在 30 秒后重新启动循环。通过这种方式，可以在保证功能实现的同时，提升系统的稳定性与效率。

延时卡片

在使用延时卡片的过程中，我曾思考过一个问题：如果某个自动化流程较长，且每次执行所需时间较久，那么当该流程第二次被触发时，若上一次的流程尚未完全执行完毕，系统是否会中断上一次尚未完成的节点，直接从头开始执行新的流程？

正确答案是：延时会被立即重置。由于延时卡片本身不具备“停止”机制，它只能被重置或自然结束。因此，当第一个延时尚未完成就被重置时，若流程中存在第二个延时节点，它可能仍会保留上一次的执行状态。这种情况下，可能会出现例如“连续听到两次滴滴声”这样的现象。

米家极客版中的延时卡片实现逻辑，是不是让你感到有些熟悉？没错，这其实就是一个典型的 防抖（Debounce） 机制：在限定时间内的多次触发中，仅执行最后一次操作。那么问题来了：在极客版中，能不能实现 节流（Throttle） 功能呢？当然可以！👇请见下图展示的实现方法～

三、小技巧

减少循环卡片的触发

上述循环卡片的自动化实现了白天最多三次的水箱缺水提醒，尽管这种循环方式在设计上不够优雅。如果能再引入一个存在传感器，整体效果将更加理想：

亦或者，添加更多的限制：

动态卡片的状态维持

循环卡片在首次触发时会立即输出一次事件，例如音响发出“滴滴”声。需要注意的是，循环卡片不会重置其循环状态——也就是说，首次触发后再次触发，并不会重新计时。因此，在开启台灯的场景中，音响只会发出“滴滴”声，而不会同时播放“哒哒”声。

相比之下，延时卡片的状态会被重置。每次被触发时，延时都会重新计时，因此如果延时始终未能完成，后续事件将不会被执行。例如，在上述逻辑下，音响将永远不会发出“呱呱”声。

事件或状态卡片与状态与

假设一个场景，包含两种设备：一个人体传感器和一盏灯，目标是在夜晚有人时自动开灯。常见的实现方式是：当人体传感器检测到有人，且环境光较暗时，执行开灯操作。这种流程适用于“人进入环境后触发开灯”的场景。然而，如果人在环境中本就存在，且环境光逐渐变暗，就不再适用。因为传感器始终处于“有人”状态，缺少“无人 → 有人”的状态变化，事件无法被触发。

为了解决这个问题，我们可以换一个角度，关注另一个会发生变化的属性——环境光。也就是说，当环境光低于某个阈值时，如果此时检测到有人，则执行开灯操作。乍一看，这似乎需要两个独立的流程，但实际上，我们可以通过组合“事件或状态”卡片与逻辑分类中的“满足全部条件”卡片来实现这一需求。

TIP：上述示例实现了“客厅昏暗且有人时自动开灯”的流程，但会导致昏暗有人存在时灯无法关闭的问题。在实际应用中，需要额外添加逻辑来处理灯的开启条件，以确保流程完整、行为合理。

操控未被中枢网关支持的设备

部分智能家居设备虽然可以在米家 App 中使用，但由于无法连接至中枢网关，导致其属性无法上传至极客版中使用。此时，我们可以借助中枢网关的虚拟事件功能，将事件或属性值间接传递给中枢。例如，对于米家空调伴侣，可以在米家 App 的“智能”页面中创建其开关相关的自动化规则，并通过虚拟事件将状态发送至中枢，从而实现联动控制。

如下图所示，通过空调伴侣与门窗传感器的配合，实现了“空调开启时门窗未关闭”的超时提醒功能。

联动状态下的自动化开关灯

在典型的自动化开关灯场景中，误触几乎难以避免，可能源于风吹、宠物活动等非人为因素。理想状态下，若家中无人，所有自动化功能（尤其是与开灯相关的部分）应自动停止运作。

为此，在极客版中可以创建一个全局变量，作为开关灯自动化的最终判断条件，并将该变量的变更与“离家状态”进行关联，实现智能控制。类似地，夜间场景中的自动化开灯功能也应与“入睡状态”对应的全局变量绑定，在用户入睡后自动停用相关灯光控制逻辑。

外网访问米家极客版

极客版默认通过 80 端口进行访问，但在实际使用中，国内多数运营商会对常见端口（如 80）进行封禁。为实现从外网访问内网服务，可以借助 Nginx 反向代理，将请求转发至其他可用端口。

额外：①公网环境的配置及 Nginx 的搭建不属于本主题范围，本文不作展开。②为保障内网设备的安全，强制要求在外网访问时使用 HTTPS 协议。

# Nginx 配置（部分）

location / {
    proxy_pass http://10.0.10.201:80/;
    proxy_set_header X-Forwarded-Proto $scheme;
}
location /centrallinkws/ {
    proxy_pass http://10.0.10.201:80/centrallinkws/;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 86400s;
}

硬件事件转中枢变量

将设备的所有触发、查询和执行操作统一封装为中枢的全局变量或规则变量。这样一来，未来若更换设备，只需修改变量赋值相关的卡片，无需调整逻辑处理部分的卡片，从而避免重复配置。具体实现方式可参考 事了拂猫去 在 B 站发布的视频教程：

合集·【米家极客版】ZERO V1.0

https://space.bilibili.com

TIP：我对此方法持中立态度，原因在于，这种方式势必会引入大量变量定义，而当前米家极客版在变量的筛选与检索方面支持有限，即便借助第三方插件，也难以从根本上简化问题，反而可能增加维护成本。

此外，极客版目前在更换卡片并重新选择设备时，已支持同类设备的替换，且卡片中记录的属性值不会丢失，在一定程度上降低了更换设备所带来的配置负担。

米家中枢极客版助手

GreasyFork 米家中枢极客版助手

https://greasyfork.org

登录极客版页面后，自动开启助手插件，显示设备、变量与自动化的关系，方便查找设备或变量用在了哪些自动化中。点击自动化规则名称即可跳转到自动化页面并高亮所对应的设备或变量卡片。支持快捷键折叠/展开，关闭，适应画布布局，设备高亮，日志高亮，自动适应画布、设置自动化列表布局样式等功能。

点评：在日志追踪以及设备与变量监测方面表现尤为出色。

四、案例

由于各个家庭在智能设备的数量、摆放位置及功能需求方面存在差异，本文将本节内容拆分为单独的文章进行展示。我将在文中详细阐述设计需求、具体实现方法及背后的设计逻辑。详见下方链接：

米家自动化极客版案例分享

/post/792883f5/

TIP：还在施工中，尚未推送发布…