【具体实施方式】
为了使本发明的目的、技术方案和优点更加清楚,下面结合附图和具体实施例对本发明进行详细描述。
在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。
应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地,取决于语境,短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
为了方便对本发明的理解,首先对于本发明所基于的系统架构进行简单描述。如图1中所示,该系统至少包括云端设备和智能设备,其中云端设备可以是云端的一个服务器,也可以是由多个服务器构成的服务器集群。智能设备可以是诸如智能家电设备、智能网络设备、智能汽车、智能穿戴式设备、智能医疗设备等。其中智能家电设备可以包括诸如智能电视、智能空调、智能热水器、智能电灯、智能门窗、智能冰箱、智能空气净化器等搭载了智能硬件的家电设备。智能网络设备可以包括诸如搭载了智能硬件的交换机、无线AP等。智能穿戴式设备可以包括诸如搭载了智能硬件的智能手表、智能眼镜、智能手环、智能头盔、AR设备、VR设备等等。智能医疗设备可以包括诸如搭载了智能硬件的智能体温计、智能血压仪、智能血糖仪等。
除此之外,该系统还可以包括开发设备,开发设备负责针对智能设备的开发工作,在本发明中体现为向云端设备发送设备配置文件。具体将在后续实施例中详细描述。
首先对该事件处理在智能设备端的实现进行描述,智能设备端的事件处理主要由智能设备中的控制中枢实现,控制中枢可以为智能设备中完成各功能模块的控制和协调功能的单元,如图2中所示,该控制中枢主要执行以下步骤:
在201中,获取功能模块上报的Event。
智能设备中各功能模块对各自支持的Event进行监测,一旦监测到Event,则将该Event上报至控制中枢。功能模块指的是智能设备中能够完成一定功能的程序元素的集合,通常一个功能模块与智能设备的一个功能对应,但功能的粒度划分比较灵活。例如,智能电灯中的光线检测模块、开关模块等都是功能模块。
在202中,依据该Event的注册信息,将该Event的信息通过Event消息发送给云端设备,或者触发该Event所联动的功能模块。
从本步骤可以看出,对Event事件的处理可以主要包括两种情形,一种情形是将Event上报至云端设备,这种情形可以用于实现智能设备与云端设备的互联;另一种情形是依据Event触发同一智能设备的其他功能模块,这种情形可以用于实现同一智能设备的不同功能模块之间的联动。在控制中枢中若要实现这两种情形,需要预先在本地进行Event注册,这将在后续实施例中进行详述。
为了方便对图2所示方法的理解,下面通过两个实施例分别对上述Event事件处理的两种情形进行描述。
图3为本发明实施例提供的一种Event处理情形的流程图,如图3所示,可以执行以下步骤:
在301中,智能设备的控制中枢接收开发设备发送的设备配置文件。
在302中,智能设备的控制中枢依据设备配置文件,在本地进行Event注册,包括注册向云端设备上报的Event信息。
上述两个步骤可以为预先的注册过程,开发者可以针对自己的智能硬件(即智能设备)定义设备配置文件(Device Profile),然后通过开发设备将Device Profile发送给智能设备和云端设备,如图4中所示。通过这种方式,智能设备的开发者就能够实现远程的Event的配置。在本实施例中,Profile中可以定义Event名称及其对应的事件参数。采用的格式可以为“Event名称:事件参数”,例如:
event1name:power_low args:10%
表示电量低于10%的事件。
在本发明实施例中,可以针对某一类智能设备提供一个通用的Device Profile,例如A智能音箱开发者和B智能音箱开发者提供的智能音箱都有播放、暂停、恢复、音量设置等功能,这两种智能音箱就可以共用这个Device Profile。对于两种智能音箱各自有特色的功能,则可以通过分别的Device Profile进行定义。这种方式可以减少智能硬件开发的重复劳动,形成累积,同时也降低了智能硬件的开发门槛,便于智能硬件开发的普及。
Device Profile可以通过一个文档来说明,更优地,可以通过树形的头文件目录形式进行组织。在该树形的头文件目录中,各节点的子节点是该节点的子功能,如图5中所示。根节点为智能设备(device),其子节点包括:电源模块(power)、音频模块(audio)、视频模块(video)……,还可以存在更多层次的子节点,在此图中不一一穷举。在电源模块、音频模块、视频模块对应的节点上分别存储电源模块、音频模块、视频模块所对应的配置信息,包括Event名称及其对应参数。如图5中所示,power上可以包括电源管理相关的配置信息(power_manage.h),audio上可以包括声音控制相关的配置信息(voice_control.h)、播放列表相关的配置信息(play_list.h)、播放控制相关的配置信息(play_control.h),vedio上可以包括亮度控制相关的配置信息(light_control.h)、图像相关的配置信息(image.h)。其中,“.h”为配置信息的格式后缀。
在智能设备端进行的Event注册可以包括:控制中枢解析Device Profile,在本地注册Device Profile所包含的事件标识,或者在本地注册Device Profile所包含的事件标识以及事件标识对应的事件参数。其中事件标识可以是Event id,或者Event名称等形式,在本发明后续实施例中,均以Event名称为例进行描述。
这些注册的Event名称为向云端设备上报的Event名称。其中,“注册”包括在本地对要注册的信息(例如Event名称、Event名称以及Event名称对应的时间参数)进行记录。
另外,在智能设备端的注册除了包含Event注册之外,还可以包含功能模块的注册,所谓功能模块指的是智能设备中具有特定功能的部分,例如电源模块、控制模块、检测模块等。开发者通过开发设备能够将功能模块注册文件发送给智能设备的控制中枢中,或者直接预置于智能设备的控制中枢,智能设备的控制中枢能够依据该功能模块注册文件进行功能模块的注册。其中功能模块注册文件可以包括各功能模块的初始化流程信息,使得智能设备在系统启动时能够自动运行各功能模块的初始化过程。另外,功能模块注册文件还可以包括各功能模块支持上报的Event名称,使得各功能模块能够将监测到的Event对应的Event名称上报给控制中枢。
在云端设备侧也存在一个注册过程,该注册过程类似地,接收开发设备发送的Device Profile,依据该Device Profile在本地注册事件信息和事件信息对应的控制指令,其中事件信息可以包括Event名称及其对应的Event参数,或者包括Event名称。这种注册可以应用于云端设备依据智能设备上报的Event实现对该同一智能设备进行控制。或者,云端设备依据Device Profile在本地注册事件信息、事件信息对应的目的设备标识和控制指令。这种注册可以应用于云端设备依据智能设备上报的Event实现对其他智能设备进行控制。关于云端设备的处理将在后续步骤中描述。
上述注册机制,除了可以在智能设备激活时执行之外,在智能设备运行过程中也可以执行,用以实现设备升级等。通过上述注册机制,开发者对智能设备的升级更加简单,例如当有新的Event注册信息时,可以将包含该新的Event注册信息的Device Profile发送给智能设备和云端设备。云端设备和智能设备通过上述的注册机制,就可以轻松实现新的Event注册。其中云端设备和智能设备的注册过程中,可以对Device Profile包含的所有Event信息均进行注册,也可以仅注册尚未注册的Event信息,对于本地已经存在的Event信息可以跳过。
需要说明的是,除了开发者通过开发设备向智能设备的控制中枢发送DeviceProfile的方式之外,也可以在控制中枢中预置Device Profile,例如在智能设备出厂时将Device Profile预置于控制中枢。还可以由用于依据自身的使用习惯或者实际使用需求,自定义地在智能设备配置Device Profile。例如通过智能设备向用户提供的接口,配置Device Profile,并由智能设备的控制中枢存储该用户配置的Device Profile。DeviceProfile的上述几种配置方式,使得无论是开发者还是智能设备的使用者,均能够根据需求灵活地对智能设备的控制方案进行配置。
在303中,智能设备的控制中枢获取功能模块上报的Event名称。
当某功能模块监测到Event后,将该Event的Event名称上报给控制中枢。
在304中,若确定功能模块上报的Event名称属于本地注册的向云端设备上报的事件标识,则控制中枢将Event名称通过Event消息发送给云端设备。
本申请实施例中,事件标识可以包括任何可以用于确定该事件的描述信息。
控制中枢在向云端设备发送Event消息时,该Event消息中可以仅携带Event名称,例如,这种方式可以适用于云端设备在注册时,注册Event名称及其对应Event参数的情况。或者Event消息中可以携带Event名称及其对应的Event参数,例如,这种情况可以适用于云端设备在注册时,并未注册Event名称对应的Event参数的情况。
后续云端设备可以基于Event消息进行各种操作,例如,云端设备可以不对Event消息进行任何确认,对接收到的Event信息进行记录。例如,云端设备还可以进行以下处理:
云端设备依据预先注册的Event名称对应的控制指令,向该智能设备发送接收到的Event名称对应的控制指令。即云端设备依据接收到的Event,对上报Event的智能设备进行控制的情况,例如控制语音录制的Event会触发对该智能设备的控制。
还有一种情况,就是云端设备在本地注册有Event名称、该Event名称对应的目的设备标识和控制指令。其中目的设备标识指向发送Event消息的智能设备或其他智能设备,对于目的设备标识指向其他智能设备的情况,用于基于一个智能设备的Event触发对另一智能设备的控制。云端设备接收到智能设备上报的Event名称后,确定在本地注册的该Event名称对应的目的设备标识和控制指令,将确定出的控制指令发送给该目的设备标识对应的智能设备。对于云端设备向智能设备下发控制指令的实现将在图7所示实施例中描述。
为了提高安全性,上报给云端设备的Event消息中可以携带智能设备的设备标识信息,云端设备接收到Event消息后,可以首先基于Event消息携带的设备标识信息进行身份验证,即判断是否为合法的设备标识,如果是,则对接收到的Event消息进行处理,否则可以直接丢弃。
该智能设备的设备标识可以是任意的能够唯一标识智能设备的信息,优选地,可以采用由标识分配设备统一分配给各智能设备的、唯一的物联网ID,该ID在出厂时被固化于智能设备的芯片中,不可篡改和非法获取。在云端设备处可以预先设置合法的设备标识,若智能设备的设备标识由标识分配设备统一分配,则云端设备可以预先从标识分配设备处获取合法的设备标识。
对于Event消息而言,除了包含Event名称、Event参数(可以不包含)以及设备标识信息之外,还可以包含其他内容字段,本发明对此不加以限制。
对于云端设备而言,可以被设置为对接收到的Event消息不做任何响应的返回,也可以被设置为对向智能设备返回Event响应消息。
在云端设备被设置为向智能设备返回Event响应消息的情况下,若智能设备在上报Event消息后的设定时长内未接收到Event响应消息,则可以进行Event消息的重传,并且可以对重传次数进行限制。Event响应消息中可以包含Event名称,该Event名称用于标识与Event消息之间的对应关系。
图6为本发明实施例提供的另一种Event处理情形的流程图,如图6所示,可以执行以下步骤:
在601中,智能设备的控制中枢接收开发设备发送的设备配置文件。
在602中,智能设备的控制中枢依据设备配置文件,在本地进行Event注册,包括注册Event信息所联动的功能模块和控制指令。
同样,这两个步骤可以为预先的注册过程,关于设备配置文件(Device Profile)的相关描述可以参见图3所示实施例中的相关描述,在此不再赘述。
在本实施例中的Event注册与图3所示实施例不同的是,该注册可以仅在智能设备中进行,控制中枢解析Device Profile后,在本地注册Device Profile所包含的Event名称以及Event名称所联动的功能模块和执行指令。
在603中,控制中枢获取功能模块1上报的Event名称。
当功能模块1监测到Event后,将该Event的Event名称上报给控制中枢。
在604中,控制中枢确定本地注册的功能模块1上报的Event名称所联动的功能模块2和执行指令。
若在本地注册有与该Event名称存在联动关系的功能模块,则就可以向该功能模块发送与该Event名称对应的执行指令,从而实现基于一个功能模块的Event控制另一功能模块。
在605中,控制中枢向功能模块2发送确定的执行指令。
图7为本发明实施例提供的云端设备基于Event消息向智能设备下发控制指令的实现流程图,如图7所示,该流程可以包括以下步骤:
在701中,云端设备接收智能设备上报的Event消息后,向智能设备发送第一Action消息,该第一Action消息包括Action标识。
需要说明的是,第一Action消息和第二Action消息为本发明实施例中列举的第一消息和第二消息的名称,但本发明实施例并不限于这种消息名称。云端设备接收到智能设备上报的Event后,触发第一Action消息的下发。在一些业务逻辑中,云端设备对智能设备的控制是基于一些特定事件的,例如控制语音录制的Event会触发云端设备进行语音识别后,下发对应的控制。
在这种情况下,云端设备可以接收到一个智能设备上报的Event后,向该智能设备下发第一Action消息。
当智能设备向云端设备上报该Event时,云端设备查询与该Event相关的业务逻辑。可以预先在云端设备设置Event与Action标识之间的对应关系,在查询与该Event相关的业务逻辑时,实际上就是确定该Event对应的Action标识,然后再依据预先在本地注册的信息,将Action标识及其对应的控制参数通过第一Action消息下发给智能终端。
还存在这样的情况:云端设备接收到一个智能设备上报的Event后,向另一个智能设备下发第一Action消息。
当智能设备向云端上报该Event时,云端设备查询与该Event相关的业务逻辑。这里的业务逻辑实际上是预置的Event与Action标识以及目的设备标识信息之间的对应关系。也就是说,通过Event一方面可以确定出对应的Action标识,另一方面可以确定出目的设备标识,然后将该Action标识包含在第一Action消息中发送给该目的设备标识对应的智能设备。
对于上述两种情况,云端设备在发送第一Action消息之前,可以首先判断该第一Action消息对应的目的终端设备的标识信息(控制指令中携带的目的设备标识信息、发送Event的智能设备的标识信息或者已注册的与Event对应的目的设备标识信息),是否为合法的设备标识,如果否,则禁止向智能设备发送第一Action消息;如果是,才允许向智能设备发送第一Action消息。
其中,在云端设备处可以预先设置合法的设备标识,若智能设备的设备标识由标识分配设备统一分配,则云端设备可以预先从标识分配设备处获取合法的设备标识。
对于第一Action消息而言,除了包括Action标识、控制参数、智能设备的标识信息之外,还可以包含其他内容字段,本发明对此不加以限制。
在702中,云端设备接收智能设备返回的第二Action消息,该第二Action消息包括上述Action标识和Action状态。
其中,第二Action消息中的Action标识与第一Action消息中的Action标识一致,用以指示该第二Action消息与第一Action消息之间的关联。Action状态用于指示智能设备针对第一Action消息的动作执行状况,鉴于动作执行的不同阶段,Action状态可以包括但不限于:
第一状态:指示接收到第一Action消息。
第二状态:指示依据第一Action消息中的Action标识所对应的控制参数执行动作的准备工作已完成。
第三状态:指示依据第一Action消息中的Action标识所对应的控制参数执行动作已完毕。
第四状态:指示依据第一Action消息中的Action标识所对应的控制参数执行动作出现异常。
下面通过具体实施例对Action注册的机制进行详细描述。本发明实施例中涉及的Action可以理解为云端设备下发给智能设备的控制信息,其对应的是智能设备提供的各种功能,云端设备下发的Action可以对应一个动作,也可以对应一个动作序列。Action消息可以理解为针对Action在云端设备和智能设备之间交互的消息。
为了区分不同的动作,在本发明实施例中,可以采用Action标识来标识和区分各Action。Action标识与具体的控制参数对应,其中控制参数可以包括动作类型,例如播放、暂停等。诸如暂停等一些Action仅需要动作类型即可,但还有一些诸如播放、调高音量等Action需要一些其他的参数,例如播放对象、调高音量的幅度。这些Action标识及其对应的控制参数可以通过设备配置文件(Device Profile)进行定义。Device Profile中可以采用这样的格式:“Action标识:控制参数”,其中多个控制参数可以采用逗号隔开,例如:
action1name:play,args:“小苹果”
action2name:pause
其中,action1name对应的动作是播放小苹果;action2name对应的动作是暂停。
另外,Device Profile除了可以定义Action标识及其对应的控制参数之外,还可以定义Event标识及其对应的事件参数。采用的格式可以为“Event标识:事件参数”,例如:
event1name:power_low args:10%
表示电量低于10%的事件。
开发者可以针对自己的智能硬件(即智能设备)定义Device Profile,然后通过开发设备将Device Profile发送给云端设备和智能设备。通过这种方式,智能设备的开发者就能够实现远程的Action和Event的配置。在本发明实施例中,可以针对某一类智能设备提供一个通用的Device Profile,例如A智能音箱开发者和B智能音箱开发者提供的智能音箱都有播放、暂停、恢复、音量设置等功能,这两种智能音箱就可以共用这个Device Profile。对于两种智能音箱各自有特色的功能,则可以通过分别的Device Profile进行定义。这种方式可以减少智能硬件开发的重复劳动,形成累积,同时也降低了智能硬件的开发门槛,便于智能硬件开发的普及。
Device Profile可以通过一个文档来说明,更优地,可以通过树形的头文件目录形式进行组织。其组织结构可以如图5所示,不再赘述。
在云端的注册过程主要是:解析某类型智能设备的Device Profile,针对该类型智能设备在本地注册Device Profile所包含的各Action标识以及Action标识对应的控制参数、Event标识以及Event标识对应的事件参数。这样云端设备就能够进行Action消息的下发和Event消息的接收、处理。
在智能设备端的注册过程主要是:智能设备的控制中枢解析Device Profile,在本地注册Device Profile所包含的各Action标识以及Action标识对应的控制参数、Event标识以及Event标识对应的事件参数。这样,智能设备就能够针对Action消息进行接收、处理和发送,以及对Event消息进行发送和处理。
另外,与云端设备的注册不太一样的是,在智能设备端的注册除了包含Action注册和Event注册之外,还可以包含功能模块的注册,所谓功能模块指的是智能设备中具有特定功能的部分,例如电源模块、控制模块、检测模块等。开发者通过开发设备能够将功能模块注册文件发送给智能设备的控制中枢中,或者直接预置于智能设备的控制中枢,智能设备的控制中枢能够依据该功能模块注册文件进行功能模块的注册。其中功能模块注册文件可以包括各功能模块的初始化流程信息,使得智能设备在系统启动时能够自动运行各功能模块的初始化过程。另外,功能模块注册文件还可以包括各功能模块支持的Action标识,使得控制中枢接收到第一Action指令后,能够依据其中的Action标识确定执行动作的功能模块,并将该Action标识对应的控制参数提供给相应的功能模块以执行动作。
通过上述注册机制,开发者对智能设备的升级更加简单,例如当有新的Action标识时,可以将包含该新的Action标识及对应控制参数的Device Profile发送给云端设备和智能设备,云端设备和智能设备通过上述的注册机制,就能够轻松实现新的Action的升级。其中云端设备和智能设备在注册过程中,可以对Device Profile包含的所有Action标识均进行注册,也可以仅注册尚未注册的Action标识,对于本地已经存在的Action标识可以跳过。
以上是对本发明所提供的方法进行的详细描述,下面结合具体实施例对本发明所提供的装置进行详细描述。
图8为本发明实施例提供的设置于智能终端的装置结构图,该装置对应于方法实施例中涉及的控制中枢。如图8所示,该装置可以包括:事件获取单元01和事件处理单元02,还可以包括注册接口03、注册单元04、消息接收单元05、消息发送单元06和确定单元07。其中各组成单元的主要功能如下:
事件获取单元01负责获取功能模块上报的Event。智能设备中各功能模块对各自支持的Event进行监测,一旦监测到Event,则将该Event上报至本装置,本装置的事件获取单元01就可以获取到该Event。
事件处理单元02负责依据Event的注册信息,向云端设备发送事件消息,或者触发Event所联动的功能模块。也就是说,对Event事件的处理可以主要包括两种情形,一种情形是将Event上报至云端设备,这种情形可以用于实现智能设备与云端设备的互联;另一种情形是依据Event触发其他功能模块,这种情形可以用于实现功能模块之间的联动。
针对上述第一种情形,即将Event上报至云端设备的情形,可以采用如下的注册方式:
注册接口03负责获取开发设备发送的设备配置文件或者在本地预置的设备配置文件。开发者可以针对自己的智能硬件(即智能设备)定义设备配置文件(DeviceProfile),然后通过开发设备将Device Profile发送给智能设备。通过这种方式,智能设备的开发者就能够实现远程的Event的配置。在本实施例中,Profile中可以定义Event名称及其对应的事件参数。
注册单元04负责依据设备配置文件,在本地进行Event的注册。包括:控制中枢解析Device Profile,在本地注册Device Profile所包含的Event名称,或者在本地注册Device Profile所包含的Event名称以及Event名称对应的事件参数。这些注册的Event名称为向云端设备上报的Event名称。
这种情况下,事件获取单元01获取功能模块上报的Event名称,若事件获取单元01获取的Event名称属于本地注册的向云端设备上报的Event名称,则事件处理单元02向云端设备发送Event消息。
其中,事件处理单元02在向云端设备发送Event消息时可以将包含Event名称的Event消息发送给云端设备,这种方式适用于云端设备在注册时,注册Event名称及其对应Event参数的情况。也可以将包含Event名称和该Event名称对应的Event参数的Event消息发送给云端设备,这种情况可以适用于云端设备在注册时,并未注册Event名称对应的Event参数的情况。
针对上述第二种情形,即依据Event触发其他功能模块的情形,这种情形下,事件的注册信息可以包括:Event名称以及Event名称所联动的功能模块和执行指令。
这种情形下,事件获取单元01获取功能模块上报的事件标识;事件处理单元02确定本地注册的事件获取单元01获取的Event名称所联动的功能模块和执行指令;向所联动的功能模块发送确定出的执行指令。
另外,在智能设备端的注册除了包含Event注册之外,还可以包含功能模块的注册,注册接口03获取开发设备发送的或者在本地预置的功能模块注册文件,注册单元04依据功能模块注册文件,进行功能模块的注册。其中功能模块注册文件可以包括:各功能模块的初始化流程信息,用于在系统启动时自动运行各功能模块的初始化过程;或者,各功能模块支持上报的事件标识。
上述的事件处理单元02还可以接收云端设备返回的Event响应消息。在向云端设备发送Event消息的设定时长内未接收到该Event响应消息,则可以重新向云端设备发送该Event消息。在此可以控制Event消息的重传次数。
消息接收单元05负责接收云端设备针对事件消息发送的第一消息,第一消息包括动作标识。
消息发送单元06负责向云端设备返回第二消息,第二消息包括动作标识和动作状态,动作状态用于指示智能设备针对第一消息的动作执行状况。
确定单元07负责利用第一消息中包含的动作标识,确定注册的该动作标识对应的控制参数,以便利用控制参数执行相应动作。
其中,上述第一消息中还可以包括动作标识对应的控制参数,以便智能设备利用控制参数执行相应动作。
上述的动作状态可以包括以下四种状态:
第一种状态:指示接收到第一消息的第一状态。
第二种状态:指示依据动作标识对应的控制参数执行动作的准备工作已完成的第二状态。
第三种状态:指示依据动作标识对应的控制参数执行动作已完毕的第三状态。
第四种状态:指示依据动作标识对应的控制参数执行动作出现异常的第四状态。
图9为本发明实施例提供的设置于云端设备的装置结构图,如图9所示,该装置可以包括:事件接收单元11,还可以进一步包括记录单元12、消息发送单元13、注册接口14、注册单元15、响应发送单元16、消息接收单元17和确定单元18。其中各组成单元的主要功能如下:
事件接收单元11负责接收智能设备上报的包含Event信息的Event消息。其中,Event信息可以包括:Event名称,这种情况适用于在云端设备注册有Event名称及其对应Event参数的情况。或者,Event信息可以包括Event名称和Event名称对应的Event参数,这种情况可以适用于在云端设备注册有Event名称的情况。
在接收到Event消息之后,记录单元12可以对事件信息进行记录。对于云端设备而言,可以对来自智能设备端的Event消息不进行确认。也可以由响应发送单元16在事件接收单元11接收到Event消息后,向智能设备返回针对该Event消息的Event响应消息。
除此之外,更进一步地,消息发送单元13可以依据Event信息,向该发送Event消息的智能设备或者其他智能设备发送第一消息,该第一消息包括动作标识。
消息接收单元17负责接收智能设备针对第一消息返回的第二消息,第二消息包括动作标识和动作状态,动作状态用于指示智能设备针对第一消息的动作执行状况。
确定单元18负责获取注册的动作标识对应的控制参数,将该控制参数包含在第一消息中。
上述的动作状态可以包括但不限于以下四种状态:
第一种状态:指示接收到第一消息的第一状态。
第二种状态:指示依据动作标识对应的控制参数执行动作的准备工作已完成的第二状态。
第三种状态:指示依据动作标识对应的控制参数执行动作已完毕的第三状态。
第四种状态:指示依据动作标识对应的控制参数执行动作出现异常的第四状态。
对于云端设备上Event的注册,开发者可以通过开发设备向云端设备发送DeviceProfile。注册接口14接收开发设备发送的Device Profile。注册单元15依据DeviceProfile,在本地注册Event信息和该Event信息对应的控制指令,或者在本地注册Event信息、该Event信息对应的目的设备标识和控制指令。其中,Event信息可以包括Event名称,还可以进一步包括Event名称对应的Event参数。
本发明实施例提供的上述方法和装置可以以设置并运行于设备中的计算机程序体现。该设备可以包括一个或多个处理器,还包括存储器和一个或多个程序,如图10中所示。其中该一个或多个程序存储于存储器中,被上述一个或多个处理器执行以实现本发明上述实施例中所示的方法流程和/或装置操作。例如,被上述一个或多个处理器执行的方法流程,可以包括:
获取功能模块上报的事件;
依据所述事件的注册信息,向云端设备发送事件消息,或者触发所述事件所联动的功能模块。
下面列举本发明的几个应用场景的实例:
应用场景1:
该应用场景是终端与云端之间的Event机制。
由于开发者预先将智能音响中语音控制模块的相关Event注册到了智能硬件中的控制中枢,并且该相关Event也预先注册到了云端。其中一种Event为控制语音录制。当智能音响中语音录制模块监测到控制语音录制Event被触发时,将该Event名称上报给控制中枢。
控制中枢确定其属于预先注册的上报给云端设备的Event名称。智能音响将包含该Event名称的Event消息上报给云端设备。云端设备对于该Event本身可以不做任何确认,但可以基于该Event进行后续处理,例如对该Event所包含的控制语音进行识别,依据控制语音箱该智能音响下发相应的控制指令等。
在这种应用场景中,本发明提供的Event机制能够实现智能设备与云端设备的互联。
应用场景2:
智能门窗中的状态监测模块监测到开门的Event后,将该Event名称上报给智能门窗中的控制中枢。控制中枢确定该Event名称属于上报给云端设备的Event后,将该Event名称通过Event消息上报给云端设备。
云端设备接收到该Event消息后,通过查询预先注册的Event注册信息,确定该Event名称对应的目的设备标识和控制指令。假设确定的目的设备标识指向智能电灯,控制指令为开灯的指令,那么云端设备向智能电灯发送开灯的控制指令。这种场景能够实现,当用户开门后,智能电灯自动点亮。
在这种应用场景中,本发明提供的Event机制能够实现智能设备通过云端设备与其他智能设备的互联。
应用场景3:
该应用场景是智能设备中功能模块间的Event机制。
智能电灯中的光线检测模块监测到光线亮度低于预设阈值的Event后,将该Event名称发送给智能电灯中的控制中枢。控制中枢确定在本地注册的该Event名称存在联动的功能模块和控制指令,即该Event名称联动开关模块,对应的控制指令为开灯指令。则控制中枢向智能电灯的开关模块发送开灯指令。此时智能电灯就被打开。这种场景能够实现,当环境光线亮度低于预设阈值时,智能电灯自动点亮。
在这种应用场景中,本发明提供的Event机制能够实现智能设备内部模块之间的互联。
在上面图7所示的实施例中以及提及关于第二Action消息的几种情况,下面结合一个具体实施例对云端设备和智能设备之间的Action消息交互进行详细描述。图11为本发明实施例提供的云端设备与智能设备之间的Action消息交互流程图,如图11中所示,该流程可以具体包括以下步骤:
在1101中,云端设备向智能设备发送包含Action标识和控制参数的第一Action消息,图中以动作(Action)消息进行表示。
在该第一Action消息(对应于图7所示实施例中的第一Action消息)中,通过Action标识进行唯一标识。
在1102中,智能设备接收到第一Action消息后,向云端设备返回包括上述Action标识和第一状态信息的第二Action消息,图中以动作_已接收(Action_received)消息表示。
本步骤中的第二Action消息通过Action标识和第一状态信息进行唯一标识,其中第一状态指示接收到第一Action消息。
在1103中,智能设备在依据第一Action消息中的控制参数完成执行动作的准备工作候,向云端设备返回包括上述Action标识和第二状态信息的第二Action消息,图中以动作_执行中(Action_doing)表示。
本步骤中的第二Action消息通过Action标识和第二状态信息进行唯一标识,其中第二状态指示依据第一Action消息中的控制参数执行动作的准备工作已完成。
在1104中,智能设备在依据控制参数执行动作完毕后,向云端设备返回包括上述Action标识和第三状态信息的第二Action消息,图中以动作_已完成(Action_done)消息表示。
本步骤中的第二Action消息通过Action标识和第三状态信息进行唯一标识,其中第三状态指示依据第一Action消息中的控制参数执行动作完毕。
在1105中,智能设备在依据控制参数执行动作发生异常时,向云端设备返回包括上述Action标识和第四状态信息的第二Action消息,图中以动作_异常(Action_exception)消息表示。
本步骤中的第二Action消息通过Action标识和第四状态信息进行唯一标识,其中第四状态指示依据第一Action消息中的控制参数执行动作出现异常。需要说明的是,步骤1105并不一定出现于步骤1104之后,其可能产生于步骤1102之后的任何时间中,只要发生异常,就可能会执行。
对于云端设备而言,若在发送Action的设定时长内未接收到Action_received,则重发Action。若在接收到Action_received的设定时长内未接收到Action_doing,则重发Action。若在接收到Action_doing的设定时长内未接收到Action_done,则重发Action。若接收到Action_exception,则重发Action。另外,也可以设置Action的重发次数上限,达到该重发次数上限后,不再重发Action。
另外,对于云端设备接收到的各种Action状态,可以返回给发送控制指令的控制设备。
针对云端设备与智能设备之间的Action交互,列举几个应用场景实例:
应用场景1:
用户手机通过云端向智能音响发送播放“小苹果”音频的控制指令。在云端设备预先存储有action标识与控制指令之间的对应关系。云端设备接收到用户手机发送来的播放“小苹果”音频的控制指令后,依据上述对应关系,确定该指令对应的action标识,例如该action标识为:
action name1:play,args:“小苹果”。
其中action name1为action标识,play和args:“小苹果”为控制参数。
然后,云端设备依据该控制指令中包含的ID2(一种由标识分配设备统一分配的、唯一标识智能设备的物联网ID)确定目的终端设备,即智能音响,向智能音响发送第一Action消息。该第一Action消息中可以包含以下字段:action标识和控制参数。
智能音响接收到第一Action消息后,向云端设备返回包含状态为action_received的第二Action消息。该第二Action消息中可以包含以下字段:action name1以及本次action状态(即action_received),这两个字段可以唯一标识智能音响本次返回的消息。
如果云端设备在设定时长内未接收到智能音响返回的包含状态为action_received的第二Action消息,则可以重新发送第一Action消息。
智能音响向云端设备返回包含状态为action_received的第二Action消息后,开始依据第一Action消息中的控制参数进行动作执行的准备工作。待准备工作完成后,向云端返回包含状态为action_doing的第二Action消息。该包含状态为action_doing的第二Action消息中可以包含以下字段:action name1以及本次action状态(即action_doing),这两个字段可以唯一标识智能音响本次返回的消息。
智能音响执行播放“小苹果”音频的动作后,向云端设备返回包含状态为action_done的第二Action消息。该包含状态为action_done的第二Action消息中可以包含以下字段:action name1以及本次action状态(即action_done),这两个字段可以唯一标识智能音响本次返回的指令。
智能音响若在动作执行过程中出现异常,则可以向云端返回包含状态为action_exception的第二Action消息。该包含状态为action_exception的第二Action消息中可以包含以下字段:action name1和本次action状态(即action_exception),这两个字段可以唯一标识智能音响本次返回的指令。另外该包含状态为action_exception的第二Action消息还可以包括指示具体异常类型的参数字段。
云端设备可以依据智能音响返回的action状态,获知智能音响对Action的动作执行状态,从而确保了云端设备下发的控制在智能硬件设备上执行的各个状态都在监控中,保证了动作执行的完整性和追查性。另外,云端设备还可以将智能音响返回的action状态返回给发送控制指令的智能手机,以便用户能够及时获知动作的执行状态。
应用场景2:
该应用场景是智能设备与云端设备之间的Event机制。
由于开发者预先将智能音响中语音控制模块的相关Event注册到了智能硬件中的IDJS CORE(控制中枢),并且该相关Event也预先注册到了云端设备。其中一种Event为控制语音录制。当智能音响的控制语音录制Event被触发时,智能音响将该Event发送给云端。云端对于该Event本身可以不做任何确认,但可以基于该Event进行后续处理,例如对该Event所包含的控制语音进行识别,依据控制语音确定相应的Action标识和控制参数,并携带在第一Action消息中下发。
应用场景3:
智能门窗检测到开门的Event后,将该Event上报给云端设备。云端设备确定该Event对应的Action标识、控制参数和目的终端设备。例如,确定的Action标识为:Actionname2,控制参数为:light,目的终端设备为智能电灯。则云端设备通过第一Action消息将Action name2及其对应的控制参数发送给智能电灯,智能电灯接收到该第一Action消息后,可以依据其中的Action name2及其对应的控制参数,进行智能电灯的点亮。并可以返回不同状态的第二Action消息。
在本发明所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。