Page 70 - 《软件学报》2021年第12期

3734 Journal of Software 软件学报 Vol.32, No.12, December 2021

(3) 智能家居系统的实现
对 TAP 规则的静态检测和修复可以在规则实际运行前识别出部分规则缺陷,并尝试手工/自动修复.但是如
表 2 第 4 列所说,还有许多缺陷是静态无法检测,或是由于难以判断用户意图从而无法确定缺陷是否存在.因此,
智能家居系统在实现时需要提供:
1) 给用户更多的提示和警告:针对那些潜在有歧义、有冲突或已做动作不会被自动撤销等情况,系统要
给出用户易于理解的提示或警告;
2) 提供不易让用户混淆的选项供用户选择;
3) 提供运行时日志的记录,需要权衡日志的存储量与事后推理的便利性;
4) 支持和提供含义更明确的顶层 trigger-action 结构,等等.

2 SSRules 智能家居系统总体设计

为使终端用户易于编程,本文重点探索状态触发器-状态动作的 TAP 编程范式(简称 SS 规则范式),并基于
HA 构建了支持 SS 规则范式输入的 SSRules 系统.SSRules 在不改变 HA 规则执行引擎的基础上,扩展提供更易
被用户理解和掌握的规则表达方式以及对应的规则转译器.虽然 SS 规则范式尚不支持表达无状态或难以抽象
出状态的事件动作,但由于这类动作所占比重小、用户需求低,因此,SSRules 可以支持用户的绝大多数需求.未
来可以设计专门的机制,将这些无状态的事件动作加入到 SSRules 系统中.本节首先简要介绍 SSRules 的设计目
标,然后分析 HA 的关键特征,最后给出 SSRules 总体架构以及所引入的 Entity-Capability 抽象.
2.1 设计目标
智能家居正进入寻常百姓家,为了让 SSRules 满足用户的不同需求,现阶段至少应围绕如下目标设计.
G1. 易写易改.针对用户调查 [5,6,15,17] 反映的 TAP 规则编写和修改的问题,SSRules 应提供让无编程经验的
终端用户快速学习并正确使用的编程范式,方便表达所期望的智能家居系统性质,且在需求变化时容
易修改;
G2. 可管可控.SSRules 系统应能提供按终端用户的有效需求对来自不同厂商的设备实时监测与控制,感
知系统中动态加入和退出的管控对象,而不能只支持特定厂商的设备和仅提供极其有限的监测能力;
G3. 异常检测.智能家居系统的可靠性受限于网络、设备故障等不定因素,而用户希望系统提供实时反馈
以及对系统更多的控制感.因此,系统需要能够帮助用户监视运行状况,并将异常信息反馈给用户;
G4. 协调需求.作用于同一设备的多种需求存在冲突,是智能家居中的常见现象.系统要提供简单的处理
方式,便于用户协调好同一设备存在冲突的多种需求.例如希望灯在夜间关闭,但是有人经过则应以
较低亮度打开一段时间,如果遇到紧急情况(如厨房着火)则应当完全打开;
G5. 多方信息.智能家居系统的功能边界应当不限于家庭的物理空间.系统不仅要能够处理家庭中存在的
物理设备,也要能处理虚拟传感器和虚拟的设备,如情景模式、天气、时钟等.
2.2 HomeAssistant(HA)
本文的研究重点为探索 TAP 编程的表示及其在现有执行引擎的实现,同时提供一定的规则有效性检查功
能.因此,为更有效地实现 G2 和 G5 涉及的目标,SSRules 需要选择成熟开源的智能家居执行引擎来实现与各种
(虚拟)设备的连接、实时监控、动态感知以及自动化管理等.
在开源智能家居系统中,HA 是基于 Python 的成熟智能家居开源系统,能部署在任何能运行 Python 3 的机
器上,从树莓派到网络存储,还可以使用 Docker 部署到其他系统上.它主要根据 automations.yaml 等配置文件实
现集中化的智能家居设备管理,设备支持度高,具有自动化、群组化、UI 客制化等高度定制化设置;同时,其开发
者数量、版本更新速度在所有开源项目中也都属于佼佼者.因此,我们最终选取 HA 作为 SSRules 的执行引擎.
• 灵活的集成方式
在 HA 中,物理设备和虚拟设备均被抽象为实体,带有状态的实体可以与状态对象关联.天气、太阳角度等