一种智能家居设备自适应联动规则生成方法与流程

本发明涉及智能家居技术领域，特别是涉及一种智能家居设备自适应联动规则生成方法。

背景技术：

随着物联网技术的不断普及和蓬勃发展，设备、系统以及服务的互联互通形成了一个信息交互、远程连通、智能调控的物联世界。智能家居作为当前物联网行业的热门应用，又名家庭自动化，是以住宅为平台，利用物联网技术将家中的各种异构型设备连接到一起，提供家电自动控制、灯光控制、防盗报警等个性化服务的应用场景。如今，除了为每个独立的住房提供家居环境智能管控，还面向大范围生活环境如小区、城市服务，这就意味着有成千上万的家居设备接入，以及要满足成千上万的用户个性化需求，过往的基于用户干预或者固定程序来实现家居服务的做法已经不足以支撑，需要一种自适应机制——根据服务需求以及用户偏好能够自主的构建设备互联和发起控制，从而实现更丰富的智能家居服务。

智能家居之所以能具有智能性，一是因为遍布了各种传感器以监测环境信息，二是因为涵盖了各种智能设备以满足用户日常生活所需，三是因为存在一个从传感到分析再到控制的循环机制，这样的循环机制需要依靠设备的联动实现，如上图所示，根据分析数据得出的当前环境的状态以及用户自身的状态去依据相应的领域知识以及用户自定义偏好来调控相应的智能设备，达到智能调控以满足用户需求的目的。然而，在现有的智能家居中，虽然可以自动实现这样一个循环机制，但是中间环节繁多，且面向场景为单一，具体表现如下：

(1)智能家居设备功能孤立，需要依靠特定的程序实现联动。

智能家居设备众多，大多只面向用户自主控制独立工作。当需要环境调控时，常常依赖于用户自身的感受并且由用户主动对设备进行操控；要么就依靠特定的程序来实现设备的互联和控制流程，家居设备很少能够自主的知晓向哪个设备发起交互强求可以实现相应的家居服务。

(2)人机交互方式单一，无法提供用户个性化服务。

智能家居的设备联动控制参数一般都是预定义的，出厂后就无法改变，通常没有提供用户配置接口从而调整其联动条件和控制操作，造成人机交互方式固定，无法提供用户个性化服务，甚至用户难以理解部分功能服务。

(3)设备联动无法动态添加。

智能家居的设备联动控制是依靠在相关产品中注入相应的预设程序从而产生作用，然而并没有提供一种方式来动态的添加通用的设备联动控制规则，那么一种服务需求就需要添加一段具体的设备联动逻辑代码，一来影响了工作效率，二来无法根据场景需求主动或被动生成设备的自适应联动，造成设备与应用服务之间无法灵活连接，也就无法适应智能家居需求的动态变化。

基于上述特征的描述与分析，在智能家居中，现存比较棘手的问题即为：1)如何通过家居设备间的互联网络，实现设备与服务的灵活链接。2)如何根据智能家居环境的动态性自适应的生成设备的联动控制，去实现场景的自适应。3)如何能够根据用户的偏好需求自使用的对智能家居设备进行控制。

与本发明相关的现有技术一：

swot(semanticwebofthings)：传感器采集到的感知数据，利用ssn本体的扩展——m3本体进行设备数据语义标注，然而设备语义化的数据还不足以支撑上层应用的推理和决策，因此利用linkedopenrules来扩充语义化的传感器数据，将领域规则作用于现有的实例化数据，将实例化数据转换成语义化状态信息，并根据推理出的环境状态信息判断当前情境，再利用定义从状态到设备控制的领域规则来获取建议信息，做出相应决策。

本方案依靠领域规则和语义化数据的结合来实现，存在以下缺陷：

(1)首先需要利用领域规则推理传感设备产生的传感数据所代表的环境状态，再根据推理出的状态结果结合领域规则来产生相应的设备控制建议信息。这种设备联动需要两次推理过程才能完成，面向于智能家居这种需要快速决策以及多个设备交互的场景，这样的做法会影响设备联动控制和服务响应的效率。

(2)由于智能家居中用户偏好的多样性，对于某一条规则，其作用的条件以及参数往往因为用户的不同而发生变化，但是swot中领域规则常常是引用专家知识，推理的过程也没有提供用户配置规则的接口，从而无法满足用户个性化的偏好和需求。

(3)设备联动过程中利用的领域规则都根据场景预先定义好，与设备联动相关的规则也与场景中所有的设备一一对应，如果场景设备增多，或是需求增多，swot这种方式就无法自适应的做出相应的联动控制建议。

与本发明相关的现有技术二：

海尔物联网智慧家庭uhome：为高端住宅提供智能生活解决方案。底层部署各种家居传感器以及海尔自品牌家电，通过家庭网络互联，实现家居智能管控、红外家电管控、海尔网络家电、第三方设备管控、安防监控、可视对讲等家居服务。用户可以利用手机、pc、智能终端、智能遥控器等多种终端设备管控家居环境，也提供对第三方平台及服务的支持。用户可以安装多种app来实现设备远程控制及多场景联动。

本方案存在以下缺陷：海尔物联网智慧家庭uhome集成了底层设备及上层应用，通过集中处理底层和上层数据，可以实现对家居环境的智能管控。但是无论是app，还是终端显控设备，都只是作为家居环境信息的展示平台，以及设备控制的远程操控中枢。实际对于环境的调控还需要依靠用户的手动干预，即使能够针对一些场景系统能够自动生成设备联动控制解决方案，那也是程序预先定义，对于没有预设到的场景就无法做出判断并且产生相应的多设备联动控制。也就无法自主的代替用户生成设备的联动控制方案，尤其是能够根据环境及场景的变化自适应的生成设备的联动调控方案。

技术实现要素：

基于背景技术的分析，本发明旨在解决现有的智能家居设备联动需要特定的程序执行，无法根据场景需求自适应的互联和变化的技术问题；现有的智能家居设备联动触发条件和操作参数都由程序事先给定参数等由有预定的程序给定，无法根据场景需求用户自行定义的技术问题，提供一种智能家居设备自适应联动规则生成方法。

在此方法中，发明人定义了服务主体，作为设备与应用服务的链接者，根据服务需求链接相应的设备和环境属性，基于服务主体关联的环境属性的传感和控制关系，再基于用户的配置和反馈来决定规则的具体参数，从而解决了物联网系统很难为动态的环境和用户需求自适应的生成设备联动控制的问题。

本发明采用的技术方案如下：

一种智能家居设备自适应联动规则生成方法，包括以下步骤：

(1)智能家居系统获取应用发起的服务请求所包含的关联要素，查询与所述关联要素对应的服务主体是否已创建：如果未创建，创建对应的服务主体，创建成功后执行步骤(2)；如果已创建，直接执行步骤(2)；

(2)智能家居系统将包含环境属性的设备自适应联动规则请求发送给所述服务主体，所述服务主体查询所述环境属性；其中，环境属性包含在关联要素之中；

关联要素对应的服务主体可以关联多个环境属性，设备自适应联动规则请求包含的环境属性属于关联要素对应的服务主体的环境属性集合。

(3)所述服务主体查询存在的能够感知所述环境属性的传感设备，若存在，执行步骤(4)；若不存在，结束；

此处查询的是能够感知设备自适应联动规则请求所包含的环境属性的传感设备。

(4)所述服务主体查询能够调控所述环境属性的控制设备；

(5)所述服务主体依据查询到的传感设备和控制设备映射成互联关系，构造关于环境属性的设备联动规则框架；

(6)所述服务主体请求服务用户反馈设备联动规则框架所涉及参数的具体参数；

(7)根据用户反馈的具体参数，生成关于环境属性的设备联动规则并添加用户标识。

所述的一种智能家居设备自适应联动规则生成方法，步骤(1)中所述关联要素包括服务地理区域、服务用户、环境属性。

上述的一种智能家居设备自适应联动规则生成方法，所述步骤(1)中创建对应的服务主体具体包括以下步骤：

(1)智能家居系统查询服务地理区域内属于该服务用户的能够感知和控制环境属性的设备；

此处查询的是所有的具有感知能力和控制能力的设备，包括传感设备、控制设备。

(2)智能家居系统依据服务地理区域、服务用户、环境属性的集合、设备的集合创建对应的服务主体，创建的服务主体表达式如下：

serviceentity＝<id,seloc,seuser,{p1,p2,…,pm},{d1,d2,…,dm},{rule}>

其中：id为服务主体的唯一标识；seloc为服务主体的服务地理区域；seuser为服务主体的服务用户；{p1,p2,…,pm}为服务主体关联的环境属性的集合；{d1,d2,…,dm}为服务主体关联的设备的集合；{rule}为服务主体存储的作用于其关联的设备的设备联动规则集合。

设备自适应联动规则请求包含的环境属性属于服务主体关联的环境属性的集合。

上述的一种智能家居设备自适应联动规则生成方法，还包括步骤：

(3)服务主体创建完毕后，向应用发送创建结果。

所述的一种智能家居设备自适应联动规则生成方法，步骤(1)中所述关联要素包括服务地理区域、服务用户、环境属性。

上述的一种智能家居设备自适应联动规则生成方法，所述查询与所述关联要素对应的服务主体是否已创建具体为：

(1)智能家居系统推理服务请求包含的服务地理区域、服务用户；

(2)智能家居系统推理服务请求包含的环境属性；

(3)智能家居系统根据推理出的服务地理区域+服务用户+环境属性查询对应的服务主体是否已创建，具体为：若推理出的服务地理区域、服务用户与服务主体关联的服务地理区域、服务用户一致，并且推理出的服务请求包含的环境属性属于服务主体关联的环境属性的集合，则所述关联要素对应的服务主体已创建。

所述的一种智能家居设备自适应联动规则生成方法，所述服务主体查询存在的能够感知所述环境属性的传感设备具体为：基于统一的设备能力信息模型对设备能力信息建模，然后根据设备能力信息来查询具有感知所述环境属性的感知能力的传感设备；所述服务主体查询能够调控所述环境属性的控制设备具体为：基于统一的设备能力信息模型对设备能力信息建模，然后根据设备能力信息来查询具有调控所述环境属性的控制能力的控制设备。

所述的一种智能家居设备自适应联动规则生成方法，所述服务主体构造关于环境属性的设备联动规则框架具体为：依据设备控制功能将查询到的传感设备和控制设备映射成互联关系，构造关于环境属性的设备联动规则框架：环境属性的值满足某一条件m就由控制设备发出一条将控制参数x值设为y的命令，并将设备联动规则框架存储(rule)；

上述的一种智能家居设备自适应联动规则生成方法，所述服务主体生成关于环境属性的设备联动规则具体为：根据服务用户反馈的具体参数m1，x1，y1，生成关于环境属性的设备联动规则：当环境属性的值满足条件m1时就控制控制设备发出一条将控制参数x1值设为y1的控制命令；

所述的一种智能家居设备自适应联动规则生成方法，步骤(1)所述应用为app或终端显控设备。

所述的一种智能家居设备自适应联动规则生成方法，还包括步骤：

(8)所述服务主体向智能家居系统返回消息：规则创建成功。

综上，由于采用了上述技术方案，本发明的有益效果是：

一、针对物联网系统中应用程序与设备交互的屏障，构建基于服务需求的服务主体，并使其作为设备联动控制单元，从而连接应用程序与设备，并且能够根据场景需求进行多样组合，满足复杂的场景变化；并且当出现新的场景需求时，本方案能够动态添加规则满足需求的动态变化。

二、相比于传统需要预先设定特定逻辑程序的方案，本技术方案通过自主寻找服务主体，依据对环境属性的传感和控制映射成传感和控制设备的互联，面向服务主体构造智能家居中的设备联动规则框架，并根据用户反馈来生成具体的设备联动规则，从而实现智能家居从传感设备到控制设备的直接联动，不需要根据特定的场景一一编写对应的设备联动逻辑，也省去了环境状态的解析过程和设备的匹配过程，服务实现的效率也会有所提高。

三、相比传统的在程序里规定好参数的方案，本发明提供给用户配置规则具体参数的权限，从而生成具体的符合用户需求的设备联动规则，当达到特定的环境条件下，触发相应的设备控制，从而对环境属性产生实际的调控。本方案能够满足用户自行定义的个性化需求。

附图说明

图1是服务主体创建时序图；

图2是服务主体创建后设备联动规则生成流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

下面结合图1、图2对本发明做详细说明。

应用(例如：app或终端显控设备)向智能家居系统发出服务请求，智能家居系统接收到请求后解析收到的服务请求，推理与服务请求相关的关联因素，包括服务地理区域(例如：厨房、楼道、客厅、街道等)、服务用户(来源于用户标识)、环境属性(温度、湿度、光照、pm2.5等)，根据推理出的结果查询其对应的服务主体是否已创建，并根据查询结果做出不同操作。

若对应的服务主体未创建，则立即创建服务主体：

(a)系统查询服务地理区域内属于服务用户的能够感知和控制环境属性的所有设备

(b)依据服务区域、服务用户、环境属性集、设备集创建相应的服务主体

其中，创建的服务主体表达式如下：

serviceentity＝<id,seloc,seuser,{p1,p2,…,pm},{d1,d2,…,dm},{rule}>

其中：id为服务主体的唯一标识；seloc为服务主体的服务地理区域；seuser为服务主体的服务用户；{p1,p2,…,pm}为服务主体关联的环境属性的集合；{d1,d2,…,dm}为服务主体关联的设备的集合；{rule}为服务主体存储的作用于其关联的设备的设备联动规则集合。

(c)向应用发送创建结果；

若对应的服务主体已创建，则调用查询到的服务主体。

经过上述过程后，关联要素所对应的服务主体已被创建和调用，如图1所示。之后进入设备联动规则框架构造流程：

服务主体查询设备联动请求所包含的环境属性p，然后基于统一的设备能力信息模型查询具有感知所述环境属性p的感知能力的传感设备dm。若存在，继续基于统一的设备能力信息模型查询具有调控所述环境属性的控制能力的控制设备dn，之后依据设备控制功能将查询到的传感设备dm和控制设备dn映射成互联关系，构造关于环境属性p的设备联动规则框架：p值满足某一条件m就由控制设备dn发出一条将控制参数x值设为y的命令，并将设备联动规则框架存储(rule)；若不存在，直接结束流程；

关联要素对应的服务主体可以关联多个环境属性，设备自适应联动规则请求包含的环境属性属于关联要素对应的服务主体的环境属性集合。

服务主体请求服务用户反馈设备联动规则框架所涉及参数m，x，y的具体参数m1，x1，y1，生成关于当前需要调控的环境属性p的设备联动规则：当p值满足条件m1时就控制控制设备dn发出一条将控制参数x1值设为y1的控制命令，并将设备联动规则存储，同时添加用户标识，以便查询服务用户，如图2所示。

最后，服务主体向智能家居系统返回消息规则创建成功。

所述服务主体查询存在的能够感知所述环境属性的传感设备具体为：基于统一的设备能力信息模型对设备能力信息建模，然后根据设备能力信息来查询具有感知所述环境属性的感知能力的传感设备；所述服务主体查询能够调控所述环境属性的控制设备具体为：基于统一的设备能力信息模型对设备能力信息建模，然后根据设备能力信息来查询具有调控所述环境属性的控制能力的控制设备。

实施例一

在本部分选取智能家居作为实施例，家中所有的设备都会连接到系统平台中，用户信息也会在平台中做相应的配置。传感设备实时的上报自己的监测数据，系统平台会汇总这些数据并作相应的分析，如发现异常情况，会做出有关的设备联动控制，将指挥控制指令发送给执行设备，进而对家中的环境进行有效的调节。现选取一个房间，房间住户为admin，房间中部署有温度、湿度传感器、空气盒子以对卧室的温度、湿度、光照进行监测，还部署有空调、加湿器、空气净化器，能对卧室的温度、湿度、空气质量进行调控，空调的可调控温度范围为16-30℃，加湿器的加湿等级为1-5级，空气净化器的空气质量净化等级为1-3级。向智能家居系统注册并创建能够实现该房间环境调控的服务主体，下文简称房间主体。下面详述基于该房间主体创建房间内设备联动规则的具体流程：

1)房间主体创建完成之后，智能家居系统向房间主体发送设备联动规则创建请求。

2)房间主体接收到请求后，查询其关联的环境属性，结果包括温度，湿度，pm2.5。

3)房间主体查询关联的能对温度、湿度、pm2.5进行传感的设备，分别为温度传感器、湿度传感器、空气盒子。

4)房间主体查询关联的能对温度、湿度、pm2.5进行调控的控制设备，分别为：空调，加湿器，空气净化器。

5)依据设备控制功能分别构造规则框架：

1.if温度满足条件1，then空调参数a值设为x。

2.if湿度满足条件2，then加湿器参数b值设为y。

3.ifpm2.5满足条件3，then空气净化器参数c值设为z。

6)存储上述规则框架。

7)向admin请求用户反馈上述规则中的具体参数：条件1，条件2，条件3，a，b，c，x,y,z。

8)用户admin反馈上述规则中的具体参数：

条件1＝<大于，28>，a＝<制冷模式，温度>,x＝<open,26>

条件1＝<小于，7>，a＝<制热模式，温度>，x＝<open,23>

条件2＝<大于，200>，b＝<加湿等级>y＝<2>

条件3＝<大于，100>，c＝<净化等级>z＝<1>

9)存储相应的规则，并添加admin用户标识：

1.if温度大于28，then空调制冷模式打开，温度设为26。

2.if温度小于7，then空调制热模式打开，温度设为23。

3.if湿度大于200，then加湿器加湿等级设为2。

4.ifpm2.5大于100，then空气净化器净化等级设为1。

10)房间主体向智能家居系统返回规则创建成功。

实施例二

本部分选取智慧楼宇作为实施例，在智慧楼宇中，所有的家庭及其设备都会连接到大楼平台中，设备及其用户信息都会在平台中注册，家庭服务也由平台统一管理和实现。由于楼宇中存在不同的用户角色，设备的控制偏好也会有所不同，场景服务多样，平台需要结合服务需求发现能够实现服务的服务主体，再构建相应的设备联动规则。节能和安防是智能家居中需要提供的重要功能，1号大楼是员工办公楼，共有5层，每层公共区域均匀分不了20个光照传感器，每层有8个办公室，每个办公室部署了5个光照传感器，每个办公室部署了1个灯控系统，用来控制办公室内的灯光，主管有权限自主决定办公室内的灯光控制；大楼有一个集中灯控系统，能够控制整个大楼的灯光，大楼管理员是admin，有权限决定整个大楼灯光控制，而没有权限决定单个办公室灯光。白天外界光照足够的情况下，大楼公共区域以及办公区域实际不需要补充灯光，此时就可以把大楼灯光关闭。而夜晚为了楼宇安全起见，大楼即使没有员工也需要开启公共区域的灯光，这样即达到节能又能保障安全。而同样是光照需求，大楼公共区域和办公区域由于用户不同而存在极大不同，就此场景来描述光照设备联动规则的生成过程：

1)大楼管理员admin向大楼平台发送大楼的光照服务请求。

2)大楼平台搜索具有大楼光照服务功能的服务主体，结果显示存在大楼服务主体。

3)大楼平台向大楼服务主体发送光照属性的设备联动规则创建请求。

4)大楼服务主体查询是否存在关联的对光照进行感知的传感设备，结果显示存在。然后查询关联的能对光照进行调控的控制设备，结果为：大楼光控系统。

5)大楼服务主体依据设备控制功能构造规则框架：if光照满足条件1，then大楼光控系统参数a值设为x。

6)大楼服务主体存储上述规则框架。

7)请求用户反馈上述规则中的具体参数

1.大楼服务主体查询关联的能对大楼光照进行调控的服务用户，结果为admin

2.大楼服务主体请求admin反馈上述规则中的具体参数：条件1，a，x

8)admin向大楼服务主体反馈上述规则中的具体参数：

条件1＝<大于，80>，a＝<灯光>,x＝<close>

条件1＝<小于，20>，a＝<灯光>，x＝<open>

9)大楼服务主体存储相应的规则，并添加admin用户标识：

1.if光照大于80，then大楼光控系统灯光关闭

2.if光照小于20，then大楼光控系统灯光打开

10)大楼服务主体向大楼平台返回光照联动规则创建成功。

11)5号办公室主管想要自定义自己的办公室的灯光调控规则，因此向大楼平台发送5号办公室光照服务请求。

12)大楼平台搜索具有5号办公室光照服务功能的服务主体，结果显示存在5号办公室服务主体。

13)大楼平台向5号办公室服务主体发送光照属性的设备联动规则创建请求。

14)5号办公室服务主体查询是否关联有对5号办公室光照进行感知的传感设备，结果显示存在。然后查询关联的能对5号办公室光照进行控制的控制设备，结果为5号办公室光控系统。

15)5号办公室服务主体依据设备控制功能构造规则框架：if光照满足条件1，then5号办公室光控系统参数a值设为x。

16)5号办公室服务主体存储上述规则框架。

17)5号办公室服务主体查询关联的能对5号办公室光照进行调控的服务用户，结果为5号办公室主管

18)5号办公室服务主体请求5号办公室主管反馈上述规则中的具体参数：条件1，a，x

19)用户反馈上述规则中的具体参数：

条件1＝<大于，60>，a＝<灯光>,x＝<close>

条件1＝<小于，15>，a＝<灯光>，x＝<open>

20)存储相应的规则，并添加5号办公室主管标识：

1.if光照大于60，then5号办公室光控系统灯光关闭。

2.if光照小于15，then5号办公室光控系统灯光打开。

21)5号办公室服务主体向大楼平台返回光照联动规则创建成功。

以上仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。