🎉 文章更新日志
  • 2024/11/20 修改展示案例。
  • 2024/11/05 补充替换一些表达不清晰的配图。
  • 2024/11/05 全文推倒重写。
  • 2024/10/25 补充一些小技巧、重写案例部分的内容。
  • 2024/03/03 补充米家与小米手机联动部分的内容。
  • 2023/11/10 补充极客版虚拟事件、更新案例内容、替换配图。
  • 2023/02/09 初始化文章,更换主图、配图。

一、简介

极客版依托于中枢网关,相较于米家,它提供了更自由、更强大的功能。

可以预见,米家在智能化方面已经事实上放弃了 Zigbee 路线,新品主要采用 WIFI 协议和蓝牙 MESH 协议。在此背景下,米家推出了小米智能中枢网关,官方宣称该网关可同时连接 200 个蓝牙 Mesh 设备和 100 个蓝牙设备,并且部分自动化功能可以在本地运行,即使在外网缺失时也能正常运行。

与米家客户端相比,极客版展示了智能家居的所有预设属性、方法和事件,并且支持查询、判断、逻辑运算等流程处理能力,能够实现许多在米家 APP 中不便实现的功能。例如,在典型的 if-else 流程中,米家 APP 需要将判断拆分成两条自动化规则,而极客版则可以直接处理。

极客版以卡片为主,主要分为事件节点和状态节点两类。通过在不同卡片间连接输入和输出节点,用户可以设计完整的自动化流程。尽管名为极客版,但总体上手难度较低。最后需要强调的是,极客版是对米家自动化场景的补充和增强,不能完全替代米家自动化场景。两者结合使用,效果会更佳。

二、卡片

2.1 卡片类型

✨ 下面简单介绍几个需要特别注意的卡片类型。

循环卡片

循环卡片可以按照设定的时间间隔循环发出信号,并支持停止循环操作。一个使用场景是通过循环查询来间接实现无法作为触发的智能设备的触发功能。例如,对于米家的饮水机,我希望它能在水箱没水时提醒我,但饮水机无法直接作为触发设备,这时可以通过循环查询来实现这一功能。

水箱缺水提醒

由于目前极客版没有类似任务管理器的功能,使用循环卡片时需要谨慎。原则上应尽量避免使用秒级循环。此外,还可以在满足一定条件下减缓循环的频率。一个模拟示例是:当循环连续触发三次后,停止循环运行,并在 30 秒后重新启动循环。

延迟循环触发

延时卡片

在使用延时卡片时,我曾想到一个问题:如果某个自动化流程很长,执行一次所需的时间也很久,那么当该自动化流程第二次触发时,如果上一次流程还没有完全执行完毕,第二次触发会放弃上一次流程中的未完成节点并直接重新开始吗?

延时测试

正确答案是:延时会立即重置。由于延时没有停止的概念,只能重置或结束。因此,当第一个延时被重置但还未到达第二个延时时,第二个延时会继续保留上一次的执行状态,这可能会导致听到两次滴滴声的情况。

自定义状态卡片

自定义状态卡片可以视为一个布尔类型的变量,相较于事件,它更常用于表示状态,可以记录和存储一个值。作为状态使用时,如果没有初始化,默认值为假。如下图所示,音响会播放“哒哒”声。

测试:自定义状态

状态维持卡片

状态维持了一段时间:输入状态和限定时间,输出状态或事件。核心在于状态的保持。作为事件时,它有点类似于延时和判断卡片的结合体,也可以用于减少误判,延缓事件的立即执行。

状态维持

变量卡片

变量分为文本和数值两类。在进行数值运算时,需要特别注意精度问题,可以使用函数将值四舍五入以确保准确性。

数值精度

2.2 小技巧

对循环卡片的改进

上面的循环卡片自动化实现了白天最多三次的水箱缺水提醒,尽管这种循环设计不够优雅。如果再加入一个存在传感器,效果会更好:

用真实的人存在作为触发更实用

循环及延时卡片的状态维持

循环卡片首次触发时会立即产生一次输出事件,例如音响发出“滴滴”声。循环卡片不会重置循环状态,即首次触发后,二次触发不会重置循环时间:开启台灯后,音响不会同时发出“滴滴”和“哒哒”声。延迟卡片则会被重置状态,每次被触发时,延时都会重新开始,因此音响永远不会发出“呱呱”声。

状态维持

优先记录状态而非现查

中枢网关需要处理不同物理设备之间的通信,这些通信需要考虑到现实中的时间因素。提前将状态值记录到中枢网关中,比在触发前再进行查询速度更快。

状态替代查询

操控未被支持的设备

由于极客版和米家是独立的,如果想操控不被支持的设备,可以尝试使用米家音响类设备,通过【智能音响-执行文本指令】静默执行相关命令。典型场景包括第三方配件和小爱音箱创建的红外控制卡片。总之,任何能被小爱执行的命令都可以使用执行文本指令来触发。

目前,极客版已经支持蓝牙网关发出和接收虚拟事件,并且可以在米家自动化中接收和触发这些事件。

外网访问米家极客版

这个比较简单,虽然聊胜于无:

  • 映射任意端口到中枢网关地址的 80 端口;
  • 映射 8082 端口到中枢网关地址的 8082 端口。

TIP:8082 端口使用 ws 协议作为心跳,故而无法使用 https 协议,这在外网环境下可能存在安全隐患。

米家中枢极客版助手

显示设备与规则的关系,方便查看规则与设备的对应关系,支持快捷键折叠/展开,关闭,适应画布布局,设备高亮,日志高亮,自动适应画布、设置规则列表布局样式等功能。

米家中枢极客版助手

三、案例

抛砖引玉,仅供参考~

离家与到家判定

我们先准备一个全局变量 离家状态 ,用于存储到家和离家的状态。对于到家状态的判断,原则上应该选择与人高度相关的触发条件,例如手机在家中、电视机开机等(其触发源一定来自人)。而对于离家状态的判断,则分为两类:基于设备的无人判断(真实无人)和基于传感器的无人判断(推测无人)。

基于设备

基于设备的无人判断是通过个人携带的设备(如手机)来实现的,主要有以下几种方案:

  • 地理围栏传感器:通过蓝牙和 Wi-Fi 检测设备的在线状态,精准度高且兼容性强。
  • 米家事件联动:当连接或断开指定名称的 Wi-Fi 时触发事件,缺点是手机必须是小米手机。[1]
  • 小米路由器联动:通过小米路由器检测设备的 MAC 地址上下线情况,进而判断具体人员的状态。

以第二个方案为例,首先在米家 APP 中设置对应的 Wi-Fi 事件触发,通过虚拟事件传递给中枢网关,在中枢网关处理判断后,再传回米家进行设备开关的操作。

米家@移动设备联动

基于传感器

基于传感器的无人判断,是通过整合家中所有现有传感器的数据,根据其感知到的信息,推测无人存在。

全局@推测无人

设置推测无人的自动化,是为了补充基于设备的无人判断,确保离家状态能够被正确执行。

双无线开关的按键模拟

在双无线开关中,希望实现一个按键启用极速模式,另一个按键启用标准模式,并且支持单击、双击、三击或更多点击操作。虽然无法在米家中直接这样设置,但可以在极速模式下对其中一个按键进行模拟,以实现此效果。请注意:由于上报时间的限制,从按下按键到执行所需的时间为 n-1 秒 (n>2)。

硬件@双无线开关模拟

自动化开关灯的动态延时

存在这样一种场景:灯设置为无人1分钟后自动关灯,但由于人频繁出入这个房间,间隔时间可能大于1分钟,这导致灯频繁地在开启和关闭之间切换。因此,需要适当延长或缩短自动化关灯的时间,从而实现动态的关灯时间控制。

主要思路如下:由于在循环和延时卡片中无法使用变量,我们需要先计算出数据,然后逐一判断并执行。所以,我们先记录自动化行为导致的开关灯时间,接着比较这个时间差,根据实际需求将差值转换成延时(惩罚)系数,最后对这个系数进行判断,进而决定具体的延时关灯时间。

次卧@自动化开关灯

水暖毯睡眠模式模拟

水暖毯是 Wi-Fi 设备,不支持在极客版中进行自动化触发。同时,睡眠模式的执行情况也无法传递给极客版。我们在极客版中模拟实现了这一效果,设定入睡和开机作为睡眠模式的启动条件,并以日出前半小时作为第四阶段的触发条件。详细规则可在下图中查看。

主卧@水暖毯睡眠模式

摄像机状态修正

针对云台版摄像机,在启用人形追踪功能后,摄像机应当在追踪结束后自动回到初始位置。然而,在日常使用中发现,摄像机有时未能完全回到初始监控位置。额外发现一个 Bug:在卡片执行操作中的 摄像机控制-录制模式 里,无论修改任何项目,都会关闭存储卡的存储开关。

设备@摄像机控制

四、联控

客厅、主卧灯光及状态联控

不同的家庭、设备和环境对智能化的需求各不相同,这里只是抛砖引玉,供大家参考。

传感器和设备位置布局简图
传感器和设备位置布局简图

总体设备配置如下:三个邻普人在传感器,两个通过小米单火开关接入米家的灯,一个蓝牙 MESH 协议的智能灯,一个蓝牙 MESH 协议的门窗传感器,还有一个蓝牙协议米家夜灯。大致布局位置请参考上图。

客厅自动化开关灯

对应图片:客厅@自动化开关灯

  • 环境暗 + 人出现和人存在 + 环境变暗的双触发

    这个场景对应于人出现在昏暗的环境中,或人在环境中一直存在而环境光逐渐变暗。

  • 有物理开关用于开启自动化

    当极客版不方便访问时[2],可以使用其他方法持久性地关闭自动化开关灯行为。在这种情况下,可以借用传感器的指示灯开关状态作为限制。此外,还应确保能够自动恢复指示灯开关。

  • 只有自动化开启的灯,才进行自动关灯

    主动开启的灯只在无人状态下设置最大时间关灯限制。场景例如:在卫生间时借用客厅的光源照明[3],但客厅的传感器在检测到无人后立即关闭灯,导致室内全黑。因此,对于主动开启的灯,不应自动关闭。

  • 走廊灯开启时,不进行客厅灯自动化开启

    对应的场景是,在客厅观看投影时,可能会开启走廊灯以提供柔和照明,在这种情况下无需自动开启客厅灯。

  • 主动关灯后立即被自动开启的灯,询问是否临时关闭自动化

    双重触发条件在夜间可能导致有人时灯无法关闭。增加功能,让小爱音响主动询问是否临时关闭自动化开灯。

  • 自动化关灯行为的区别

    客厅灯只有在检测到客厅和走廊都无人时才关闭,而走廊灯则在走廊传感器检测到无人十分钟后关闭。

  • 自动化开灯的短期抑制

    对应主动询问的具体实现,可以在短期内(如半小时内)临时关闭自动化开灯。

  • 短期抑制行为的主动解除

    设置短期抑制后,允许手动解除抑制。

主卧自动化开关灯

  • 主卧开灯状态修正 (对应图片:主卧@晚开灯状态修正)

    主卧灯通过单火开关接入米家系统。第一次开启时,仅有 LED 灯珠亮(光线较暗),第二次开启时灯泡才会亮。因此,需要模拟直接达到第二次开灯时的状态。

  • 主卧自动开灯限制 (对应图片:主卧@自动化开关灯)

    主卧较为特殊,入睡后要避免被自动开灯,故要求如下:

    • 传感器感应到人进入
    • 非入睡状态
    • 客厅灯开启
    • 主卧门开启
    • 主卧昏暗

    当所有这些条件同时满足时,才会自动开灯。除此之外的主卧夜间照明需求,由位于主卧角落的小夜灯提供。

全局入睡状态

入睡状态没有一个准确的检测标准(小米澎湃 2.0 似乎支持将手表的入睡状态发送到米家)。鉴于入睡后门和灯通常是关闭的,因此目前主要根据这两点进行判断。

  • 入睡状态开始设定 (对应图片:主卧@晚安熄灯事件)

    • 主卧开灯 15s 后 + 主卧关门状态
    • 涉及到主卧相关的所有传感器的共同判断
    • 中枢网关虚拟事件主动调用
  • 入睡状态结束设定 (对应图片:主卧@入睡结束判断)

    • 主卧开门维持 5 分钟 + 日出状态
    • 主卧无人大于 10分钟 + 主卧开门状态
    • 客厅灯开启时 + 走廊灯处于夜灯模式开启状态 + 主卧开门状态
  • 客厅、主卧入睡后联动

    • 入睡触发时,立即关闭客厅下所有灯(客厅灯、走廊灯、台灯)。
    • 入睡后,当客厅传感器感应到有人时,只以夜灯模式开启走廊灯。
    • 入睡结束时,如果走廊灯处在夜灯模式下的开灯状态处,则关闭走廊灯。

入睡状态触发后,夜间进入客厅通常是上厕所路过客厅等场景。由于客厅灯光过亮,在客厅传感器感应到有人时,不启用客厅灯,而是以夜灯模式下开启走廊灯。如果此时又主动开启客厅灯则视为入睡状态结束,同时关闭走廊灯。这样子设计入睡状态(全局变量)所记录的值可能会根据实际情况随时改变,更能实际对应白天睡觉场景。

最终流程展示

客厅@自动化开关灯

客厅@自动化开关灯

主卧@开灯状态修正

主卧@开灯状态修正

主卧@自动化开关灯

主卧@自动化开关灯

主卧@晚安熄灯事件

主卧@晚安熄灯事件

主卧@入睡结束判断

主卧@入睡结束判断

辅助流程示例

【全局变量汇总设定】
【全局变量汇总设定】
全局@通用函数调用
全局@通用函数调用
全局@传感器统一查询
全局@传感器统一查询

  1. 此外,这些手机还需要在米家中登录相同的账户,这是另一个小缺点。 ↩︎

  2. 极客版只能通过浏览器进行管理,并且登录时需要在米家中查看动态密码,步骤相对繁琐。 ↩︎

  3. 计划在过道处放置一个邻普 ES3 人在传感器,以便在感应到卫生间有人时,不关闭客厅的灯。 ↩︎

评论