CN114048017A - 一种物联网设备协同联动方法和装置 - Google Patents

Abstract

本发明公开了一种物联网设备协同联动方法和装置，方法包括：S1、物联网中具备服务器功能的设备相互协商、推选出主服务器；S2、物联网中具备条件器功能的设备接收到所述设备协同联动规则，根据所述设备协同联动规则，将自身条件器设备条件信息同步到物联网中相关的具备执行器功能的设备；S3、物联网中具备执行器功能的设备接收到所述设备协同联动规则和所述条件器设备条件信息，根据所述设备协同联动规则和条件器设备条件信息决定自身执行动作；S4、物联网中具备条件器功能和/或执行器功能的设备提供人机接口和存储机制；S5、物联网中具备条件器功能和/或执行器功能的设备运行网络消息调度机制。本发明不依赖云端或集中式控制器即可实现联动。

Description

一种物联网设备协同联动方法和装置

技术领域

本发明涉及物联网技术领域，特别涉及一种物联网设备协同联动方法和装置。

背景技术

近些年，物联网技术与应用仍在如火如荼的发展进程当中，以IFTTT为代表的设备联动规则也逐渐应用在智能家居等场景当中。但当前的设备联动多以云端或集中式服务器作为控制中心，这种中心化的设备联动方式在延时、安全性、用户隐私等方面存在先天性不足。而随着Mesh网络的发展，去中心化的组网拓扑已经能够以较低的成本实现，因而去中心化的设备协同联动问题也亟待解决。

发明内容

本发明的目的在于提供一种物联网设备协同联动方法和装置，以克服现有技术中的不足。

为实现上述目的，本发明提供如下技术方案：

本发明第一方面公开了一种物联网设备协同联动方法，所述物联网设备相互联接构成物联网，所述物联网设备包含条件器功能、执行器功能和服务器功能的功能组合，具体如下步骤：

步骤S1、物联网中具备服务器功能的设备相互协商、推选出主服务器，所述主服务器获取用户设定的设备协同联动规则，并将所述设备协同联动规则同步到物联网中的其他设备；

步骤S2、物联网中具备条件器功能的设备接收到所述设备协同联动规则，根据所述设备协同联动规则，将自身条件器设备条件信息同步到物联网中相关的具备执行器功能的设备；

步骤S3、物联网中具备执行器功能的设备接收到所述设备协同联动规则和所述条件器设备条件信息，根据所述设备协同联动规则和条件器设备条件信息决定自身执行动作；

步骤S4、物联网中具备条件器功能和/或执行器功能的设备提供人机接口和存储机制，所述人机接口由用户直接输入设备协同联动规则，所述存储机制将所述设备协同联动规则进行保存，所述人机接口和存储机制用于保障物联网中缺少具备服务器功能的设备的情况下依然能够协同联动；

步骤S5、物联网中具备条件器功能和/或执行器功能的设备运行网络消息调度机制，所述网络消息调度机制用于避免短时间内大量数据包涌入或输出时产生逻辑错误。

作为优选，所述步骤S1中所述的物联网中具备服务器功能的设备相互协商、推选出主服务器的方法为具备服务器功能的设备上电后默认自身为主服务器并周期性发送广播包；当其他服务器收到广播包后，判断广播包是否优于自身资源，若优于自身资源，则自动将自身设为从服务器，关闭广播，并向主服务器回复确认消息；若有新的资源更强的服务器设备上电后，最终判定哪个设备为主服务器，关闭广播，并回复确认消息，并执行后续功能；和/或，所述步骤S1中所述的物联网中具备服务器功能的设备相互协商、推选出主服务器的方法还可以为当物联网当中有多个服务器时，则推选出主服务器，推选方式是在设备初始化时即设定好各个服务器的优先级，其他服务器按照功能和性能指标依次递减；和/或，所述步骤S1中所述的设备协同联动规则包含规则信息、条件器信息和执行器信息；和/或，所述步骤S1中所述的将所述设备协同联动规则同步到物联网中的其他设备的方法具体包含以下子步骤：

步骤S11、对所述设备协同联动规则进行有效性检测；

步骤S12、对所述设备协同联动规则进行查重；

步骤S13、分发条件器消息包；

步骤S14、分发规则消息包。

作为优选，所述规则信息包含规则ID、规则时效；所述条件器信息包含所述规则信息相关的条件，以及各个条件之间的逻辑关系；所述执行器信息包含所述规则信息的最终执行目的。

作为优选，所述步骤S11中，对所述设备协同联动规则进行有效性检测包括：规则当中是否存在逻辑错误的检测以及当前规则与已有规则之间是否存在逻辑冲突的检测；和/或，所述步骤S14中所述分发规则消息包过程如下：所述规则消息包发送给具备执行器功能的设备以及物联网中的其他具备服务器功能的设备，一方面告诉具备执行器功能的设备准备接收具备条件器功能的设备的消息，并根据条件和规则判定是否要执行动作；另一方面告诉其他具备服务器功能的设备，并在其他具备服务器功能的设备上对规则进行备份，从而保证每个具备服务器功能的设备上都有统一且完备的用户规则。

作为优选，所述步骤S2中所述的将自身条件器设备条件信息同步到物联网中相关的具备执行器功能的设备的方法具体包含以下子步骤：

步骤S21、获取到所述设备协同联动规则中所述条件器信息和执行器信息，更新订阅信息表，所述订阅信息表中的每一个表项保存了获取到的所述条件器信息和执行器信息；

步骤S22、获取自身设备状态，查询订阅信息表，当所述条件器信息的满足情况发生变化时，通知相应的具备执行器功能的设备。

作为优选，所述步骤S22中所述的获取自身设备状态包含扫描性获取和触发性获取；所述扫描性获取的具体方法为周期性扫描自身设备状态，获取状态信息；所述触发性获取的具体方法为提前设定触发条件，当满足触发条件时立即通知具备条件器功能的设备获取自身设备状态。

作为优选，所述步骤S5具体包含以下子步骤：

步骤S51、按照读取策略，读入网络消息并保存到接收缓冲区；

步骤S52、按照调度策略，选取接收缓冲区中的消息包进行处理；

步骤S53、将条件器和执行器生成的消息保存到发送缓冲区，按照发送策略，将消息包发送出去。

作为优选，所述步骤S51中所述读取策略为：设定实时更新的时间窗口，若时间窗口内平均数据包数量不超过设定阈值，则在处理器周期发现有大量数据包涌入时，暂不采用阻塞读取，仍然每个处理器周期先读取一个或少量的数据包；反之，若时间窗口内平均数据包数量超过设定阈值，则当下个处理器周期仍然有大量数据包涌入时，则进行阻塞读取，先将网络数据包读完，防止丢包；和/或，所述步骤S52中所述调度策略为：针对不同类型的消息设计一个权重，然后对缓冲区中的消息按照权重进行优先级时间累加方式排序，任何消息的优先级可以在缓冲区内随着时间累加，在特定时间后，任何低优先级的消息也必然会成为最高优先级，从而得到调度。

本发明第二方面提供一种物联网设备协同联动装置，包括存储器和一个或多个处理器，所述存储器中存储有可执行代码，所述一个或多个处理器执行所述可执行代码时，用于实现上述任一项所述的一种物联网设备协同联动方法。

本发明第三方面提供一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时，实现上述任一项所述的一种物联网设备协同联动方法。

本发明的有益效果：通过设计条件器、执行器和服务器，使得设备的不同功能角色之间实现解耦。本发明可以极其突出轻量化的特征，以C语言实现后编译成二进制文件甚至能控制在5k以内，运行10条普通长度的规则（条件数<3、执行数<3）总内存占用量也小于5k，因而可以在几乎所有的物联网设备上进行移植。同时，本发明通过分布式的条件器、执行器和服务器各司其职，可以实现不依赖云端或者集中式控制器，即可实现联动，可以避免集中式控制所带来的时延和用户隐私等问题。如果采用Mesh网络的组网方式，则可以实现真正意义上的去中心化，即使个别设备甚至服务器设备损坏后，其余大部分设备都不受影响，继续行使联动功能，使得整体系统的鲁棒性大大增强。

本发明的特征及优点将通过实施例结合附图进行详细说明。

附图说明

图1是本发明实施例提供的一种物联网设备协同联动方法的流程图。

图2是多服务器组网示意图。

图3是设备联动规则协议示意图。

图4是本发明一种物联网设备协同联动装置的结构图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面通过附图及实施例，对本发明进行进一步详细说明。但是应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

参考图1，本发明实施例提供一种物联网设备协同联动方法，所述物联网设备相互联接构成物联网，所述物联网设备包含条件器功能、执行器功能和服务器功能的功能组合。

具体的，所述物联网设备既可能仅具备条件器或执行器或服务器功能，也可能同时具备条件器、执行器和服务器功能，也可能同时具备条件器、执行器和服务器三者中任意两个功能的组合。

以智能家居场景为例，智能空调就是典型的兼具条件器（具有温湿度传感器）、执行器（空调制冷制热等功能）和服务器（具备MCU并且有额外的RAM、ROM等资源运行服务器逻辑）功能的设备。家庭当中常用的人体红外传感器、烟雾报警器等则是典型的只具备条件器功能的设备，灯、风扇等则是典型的只具备执行器功能的设备。摄像头则可以认为是具备条件器和服务器功能的结合体，其他几种类型角色的结合还有很多，不再一一列举。

具体的，所述方法具体如下步骤：

步骤S1、物联网中具备服务器功能的设备相互协商、推选出主服务器，所述主服务器获取用户设定的设备协同联动规则，并将所述设备协同联动规则同步到物联网中的其他设备。

所述步骤S1中所述的物联网中具备服务器功能的设备相互协商、推选出主服务器的方法为具备服务器功能的设备上电后默认自身为主服务器并周期性发送广播包；当其他服务器收到广播包后，判断广播包是否优于自身资源，若优于自身资源，则自动将自身设为从服务器，关闭广播，并向主服务器回复确认消息；若有新的资源更强的服务器设备上电后，最终判定哪个设备为主服务器，关闭广播，并回复确认消息，并执行后续功能；和/或，所述步骤S1中所述的物联网中具备服务器功能的设备相互协商、推选出主服务器的方法还可以为当物联网当中有多个服务器时，则推选出主服务器，推选方式是在设备初始化时即设定好各个服务器的优先级，其他服务器按照功能和性能等指标依次递减。

具体的，参考图2，一个物联网当中，可能有多个具备服务器功能的设备，具备服务器功能的设备首要的作用是接收用户设定的规则，并将规则信息分发给其他物联网设备。另外，具备服务器功能的设备的作用，还有检测到具备条件器功能的设备掉电重启后重新发送订阅消息、检测到具备执行器和/或服务器功能的设备掉电重启后重新发送规则消息等等。另外，还有修改规则、删除规则等功能，其具体实现方式基本是上述方案的子集。

当物联网当中有多个具备服务器功能的设备时，则需要推选出主服务器。最简单的推选方式是在设备初始化时即设定好各个服务器的优先级，例如智能家居场景中，可以设置手机作为服务器的优先级最高，其他服务器按照功能和性能等指标依次递减。但这种方式灵活性不足，可扩展性较差。

还有一种基于资源的协商方式，具体方案为：具备服务器功能的设备A上电后默认自身为主服务器并周期性发送广播包，该消息包中包含了RAM、ROM等软硬件资源信息；当其他具备服务器功能的设备（例如设备B）收到该消息包后，判断该资源是否优于自身资源，若优于自身资源，则自动将自身设为从服务器，关闭广播，并向主服务器回复确认消息；若有新的资源更强的具备服务器功能的设备C上电后，无论是设备C先收到设备A的广播包，抑或设备A先收到设备C的广播包，最终判定下来是设备C替代设备A作为主服务器，此时设备A会关闭广播，并向设备C回复确认消息，设备B收到广播后也会回复确认消息，从而设备C作为主服务器，可以完成服务器A和服务器B的信息收集，并执行后续功能。

所述步骤S1中所述的设备协同联动规则包含规则信息、条件器信息和执行器信息。

所述规则信息包含规则ID、规则时效；所述条件器信息包含所述规则信息相关的条件，以及各个条件之间的逻辑关系；所述执行器信息包含所述规则信息的最终执行目的。

具体的，以智能家庭为例，用户首先创建一个规则（自动生成规则ID）并设定规则时效，然后指定规则条件和目的。例如，设定的规则是工作日早上7-9点有效，规则内容是“当温度传感器检测到温度大于10摄氏度且人体传感器检测到人起床，则智能窗自动开窗”，那么该规则当中有两个条件器信息，且两个条件器之间的逻辑与关系；同时该规则还包含一个执行器信息，代表该规则最终的执行目的。

具体的，设备联动规则协议的具体协议格式，业界有基于JSON格式的IFTTT协议规则设计，但JSON格式的规则需要额外的封装和解析模块，并且JSON消息格式会占用额外的数据位，因而本实施例参考IP协议，直接以数据字段来定义各个规则项，这样以C语言实现该规则协议栈，通过结构体可以直接解析和封装规则数据流。

具体的，参考图3，首先是16位的规则ID，最多可以表示65535条规则，在智能家居、物流、工控等绝大多数场景下可以满足规则数量需求。第二项是32位的规则时效信息，前12位为规则开始时间，中12位为规则截止时间，最后8位是规则总开关和规则每周执行日信息。所述规则总开关，用最后8位的第一位来表示，第一位为1，则代表规则开启；相反为0，则代表用户设置了该规则，但规则暂时不执行。所述的每周执行日信息，用7位数据表示，例如0b1111 1111代表周一到周日每一天都执行，例如0b1100 0000代表只在周一执行。

规则当中的第三项是条件信息，条件信息是个数组，因而条件信息项中第一个8位子项即为数组数量信息，如果数量信息为0代表没有条件器，意味着按规定时效直接触发执行器，例如“每晚8点定时开启空调”。如果数量信息大于1，则第一个8位子项的首位代表了逻辑与（0）或者逻辑或（1），也就是各个条件之间的与或关系。需要注意的是，当前实施例当中协议不支持A or B and C这种复合逻辑关系，这也是大多数智能家居场景当中常用的策略，以减小开发和运维难度；若实际场景需要这种复合逻辑，则可以根据需求扩展规则协议。条件子项第一个8位数据之后，紧跟着是id-k-o-v格式项的数组，例如规则条件是设备mac1温度 大于 10℃，那么id = mac1、k = temperature、o = <、v = 10，id-k-o-v之间以及条件-条件之间用特定的分隔符进行分离，例如“：”或者“\r\n”。

规则当中的第四项是执行信息，执行信息同样也是一个数组，其结构与条件信息类似。

所述步骤S1中所述的将所述设备协同联动规则同步到物联网中的其他设备的方法具体包含以下子步骤：

步骤S11、对所述设备协同联动规则进行有效性检测。

规则有效性检测一方面包括规则当中是否存在逻辑错误，例如开始时间>截止时间等等；另一方面，还应该检查当前规则与已有规则之间是否存在逻辑冲突，例如已有A =>B规则下，又设置~A=>B，则这两个规则是冲突的。若规则有效性检查不通过，则向用户报错。

步骤S12、对所述设备协同联动规则进行查重。

设置后的规则查看跟已有规则是否重复，若重复则提醒用户重复信息（不一定需要报错）。

如果资源和运维条件允许，查重功能还可以扩展为当前设定的规则是否是已有规则的子集，或者当前设置的规则是否可以跟已有规则合并等高阶功能。

步骤S13、分发条件器消息包。

如果完成了规则有效性检测和规则查重，则可以对条件器消息包进行分发。以图3所示的规则为例，则需要向两个条件器功能所属的设备分发规则条件信息，完成一个订阅过程，告诉条件器所属的设备在触发了相应条件的情况下，应该通知执行器所属的设备。

具备服务器功能的设备通过规则当中的条件器id来寻找条件器所属的设备，该条件器id可以直接用设备mac地址来标识。而感知组网其他设备mac地址以及向特定mac地址发送数据的过程，依赖底层的网络协议栈完成。

具体分发给条件器所属的设备的消息，可以是步骤S1当中描述的规则协议的一个子集，并且可以根据实际业务需求来进行扩展。最基础的场景下，可以只发送一个k-o-v的信息以及执行器的mac、ip地址，并在消息头部封装一下消息类型。例如以图3所示的规则为例，则发给设备1的消息为“[sub]\r\ntemperature:<:10\r\n[设备3mac/ip地址]\r\n”，用于通知设备1在自身检测到温度小于10摄氏度时，需要发消息通知设备3。

步骤S14、分发规则消息包。

完成上述的条件器消息包分发后，一般情况下为了考虑程序的健壮性，会要求条件器所属的设备进行回复，当服务器收到了规则当中所有条件器所属的设备回复的订阅成功的消息后，说明规则可以按照条件执行，从而可以将规则消息包进行分发。

规则消息包会发送给执行器所属的设备以及网络中的其他服务器所属的设备，一方面告诉执行器所属的设备准备接收条件器所属的设备的消息，并根据条件和规则判定是否要执行动作；另一方面告诉其他服务器所属的设备，是在其他服务器所属的设备上对规则进行备份，从而保证每个服务器上都有统一且完备的用户规则。

规则消息包为“[rule]\r\n[规则协议]\r\n”，即步骤S1当中描述的规则协议加上一个标记消息类型的消息头。

步骤S2、物联网中具备条件器功能的设备接收到所述设备协同联动规则，根据所述设备协同联动规则，将自身条件器设备条件信息同步到物联网中相关的具备执行器功能的设备。

所述步骤S2中所述的将自身条件器设备条件信息同步到物联网中相关的具备执行器功能的设备的方法具体包含以下子步骤：

步骤S21、获取到所述设备协同联动规则中所述条件器信息和执行器信息，更新订阅信息表，所述订阅信息表中的每一个表项保存了获取到的所述条件器信息和执行器信息。

步骤S22、获取自身设备状态，查询订阅信息表，当所述条件器信息的满足情况发生变化时，通知相应的具备执行器功能的设备。

所述步骤S22中所述的获取自身设备状态包含扫描性获取和触发性获取；所述扫描性获取的具体方法为周期性扫描自身设备状态，获取状态信息；所述触发性获取的具体方法为提前设定触发条件，当满足触发条件时立即通知具备条件器功能的设备获取自身设备状态。例如，温度传单器为典型的扫描性获取，即周期性（一般为1ms或1s）扫描自身温度值，并将该温度值作为设备属性提交给条件器功能业务逻辑进行处理；而人体红外传感器为典型的触发性获取，即设置一个中断函数，当人体红外传感器检测到有人经过时触发中断函数，中断函数当中再执行条件器功能业务逻辑。

所述步骤S22中所述条件信息的满足情况发生了变化，即从不满足变为满足或者从满足变为不满足，而不是条件信息本身发送变化。例如，温度计接收到某个订阅是“温度＞10℃”，假设原始温度为8℃，那么当温度降低或者温度升高为10℃时，条件器均不会发送消息；一旦温度升高到10℃以上，那么就将通知执行器所在设备，该温度条件已经从不满足变为满足。这样可以极大程度上减少条件器和执行器之间的消息往来，节省软硬件资源。

步骤S3、物联网中具备执行器功能的设备接收到所述设备协同联动规则和所述条件器设备条件信息，根据所述设备协同联动规则和条件器设备条件信息决定自身执行动作。

例如用户设置了图3中所示的规则，设备3作为具备执行器功能的设备，会接收到该规则信息以及设备1和设备2发送的条件器信息，当设备3接收到设备1温度小于10℃以及设备2检测到人体红外信号（body=1）时，则执行打开空调设置温度为18℃（airconditiong=18）的动作。

步骤S4、物联网中具备条件器功能和/或执行器功能的设备提供人机接口和存储机制，所述人机接口由用户直接输入设备协同联动规则，所述存储机制将所述设备协同联动规则进行保存，所述人机接口和存储机制用于保障物联网中缺少具备服务器功能的设备的情况下依然能够协同联动。

当物联网中缺少具备服务器功能的设备，用户通过具备条件器功能和/或执行器功能的设备提供人机接口直接向设备输入规则，该人机接口可以是串口等形式。

具备条件器功能的设备通过人机接口直接获得用户输入规则时，会执行步骤S2类似的业务逻辑，更新订阅信息表，获取自身设备状态，并通知相应的具备执行器功能的设备。

具备执行器功能的设备通过人机接口直接获得用户输入规则时，会执行步骤S3类似的业务逻辑。

具备条件器功能和/或执行器功能的设备提供存储机制，将用户直接输入的设备协同联动规则进行保存，从而保证自身设备上电重启后且物联网中缺少具备服务器功能的设备时仍然能够执行设备协同联动规则的内容。

步骤S5、物联网中具备条件器功能和/或执行器功能的设备运行网络消息调度机制，所述网络消息调度机制用于避免短时间内大量数据包涌入或输出时产生逻辑错误。

所述步骤S5具体包含以下子步骤：

步骤S51、按照读取策略，读入网络消息并保存到接收缓冲区。

所述步骤S51中所述读取策略为：设定实时更新的时间窗口，若时间窗口内平均数据包数量不超过设定阈值，则在处理器周期发现有大量数据包涌入时，暂不采用阻塞读取，仍然每个处理器周期先读取一个或少量的数据包；反之，若时间窗口内平均数据包数量超过设定阈值，则当下个处理器周期仍然有大量数据包涌入时，则进行阻塞读取，先将网络数据包读完，防止丢包。

由于从网卡当中读取消息包的过程往往是阻塞的，在消息量小的时候，阻塞读取可能影响不大，但在消息量非常大时，阻塞读取可能会影响其他正常业务逻辑的运行。

Linux有一个IO多路复用技术（select/poll），但大多数情况下物联网设备是裸机运行或者采用freeRTOS等轻量级的操作系统，不一定支持IO多路复用技术，因而，此处需要设计一个读取策略。一种简单的方案，是按照“短期经验”来决定是否阻塞：设定一个不太长的实时更新的时间窗口，如果窗口内平均数据包数量不超过某个阈值，那么在某个处理器周期突然发现有大量数据包涌入时，也暂不采用阻塞读取，仍然每个处理器周期先读取一个或少量的数据包；反之，如果在时间窗口内平均数据包数量超过了某个阈值，那么当下个处理器周期仍然有大量数据包涌入时，则进行阻塞读取，先将网络数据包读完，防止丢包。

步骤S52、按照调度策略，选取接收缓冲区中的消息包进行处理。

所述步骤S52中所述调度策略为：针对不同类型的消息设计一个权重，然后对缓冲区中的消息按照权重进行优先级时间累加方式排序，任何消息的优先级可以在缓冲区内随着时间累加，在特定时间后，任何低优先级的消息也必然会成为最高优先级，从而得到调度。

最简单的调度策略，是在读取数据包后，按照数据包消息类型分类，分别放到条件器缓冲区和接收器缓冲区，然后依次从两个缓冲区中分别拿出消息，分发给条件器功能业务逻辑模块和执行器功能业务逻辑模块。

这种策略实现起来较为简单，但有可能存在各种不重要的消息（例如心跳消息、组播的设备发现消息等）阻塞消息缓冲区，导致重要的消息迟迟得不到解决。针对这种场景，可以针对不同类型的消息设计一个权重，然后对缓冲区中的消息按照权重进行排序。这种排序方式有多种实现方法，可以参考有序集合这种数据结构来实现。这样，每次分发给事件处理器的消息都是优先级最高的消息。但这样同样也可能存在问题，导致某些低优先级的消息始终被高优先级消息抢占，低优先消息迟迟得不到处理也会出现业务逻辑问题。解决这个问题可以采用优先级时间累加方式，任何消息的优先级可以在缓冲区内随着时间累加，那么在某个特定时间后，任何低优先级的消息也必然会成为最高优先级，从而得到调度。

步骤S53、将条件器和执行器生成的消息保存到发送缓冲区，按照发送策略，将消息包发送出去。

条件器功能业务逻辑模块和执行器功能业务逻辑模块随时可能产生待发送消息，例如条件器需要发送通知消息给执行器。这些消息也先放到发送缓冲区当中，这个缓冲区的消息管理也可以参考上述步骤，考虑优先级和时效性。消息发送过程也是阻塞的，此处的阻塞发送的处理也可以参考阻塞接收的方案。

以上所述的一种物联网设备协同联动设计方法的具体实施例，通过设计条件器、执行器和服务器，使得设备的不同功能角色之间实现解耦。本方案可以极其突出轻量化的特征，仅实现基本功能的话，代码量不超过2000行，如果通过编译宏隔离不相关的功能代码，例如只运行条件器的传感器，则代码量只有几百行。本方案的基本功能以C语言实现后编译成二进制文件仅不到5k大小，运行10条普通长度的规则（条件数<3、执行数<3）总内存占用量也小于5k，因而可以在几乎所有的物联网设备上进行移植。同时，本方案通过分布式的条件器、执行器和服务器各司其职，可以实现不依赖云端或者集中式控制器，即可实现联动，可以避免集中式控制所带来的时延和用户隐私等问题。如果采用Mesh网络的组网方式，则可以实现真正意义上的去中心化，即使个别设备甚至服务器设备损坏后，其余大部分设备都不受影响，继续行使联动功能，使得整体系统的鲁棒性大大增强。

与前述一种物联网设备协同联动方法的实施例相对应，本发明还提供了一种物联网设备协同联动装置的实施例。

参见图4，本发明实施例提供的一种物联网设备协同联动装置，包括存储器和一个或多个处理器，所述存储器中存储有可执行代码，所述一个或多个处理器执行所述可执行代码时，用于实现上述实施例中的一种物联网设备协同联动方法。

本发明一种物联网设备协同联动装置的实施例可以应用在任意具备数据处理能力的设备上，该任意具备数据处理能力的设备可以为诸如计算机等设备或装置。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在任意具备数据处理能力的设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本发明一种物联网设备协同联动装置所在任意具备数据处理能力的设备的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的任意具备数据处理能力的设备通常根据该任意具备数据处理能力的设备的实际功能，还可以包括其他硬件，对此不再赘述。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本发明实施例还提供一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时，实现上述实施例中的一种物联网设备协同联动方法。

所述计算机可读存储介质可以是前述任一实施例所述的任意具备数据处理能力的设备的内部存储单元，例如硬盘或内存。所述计算机可读存储介质也可以是任意具备数据处理能力的设备的外部存储设备，例如所述设备上配备的插接式硬盘、智能存储卡（Smart Media Card，SMC）、SD卡、闪存卡（Flash Card）等。进一步的，所述计算机可读存储介质还可以既包括任意具备数据处理能力的设备的内部存储单元也包括外部存储设备。所述计算机可读存储介质用于存储所述计算机程序以及所述任意具备数据处理能力的设备所需的其他程序和数据，还可以用于暂时地存储已经输出或者将要输出的数据。

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

Claims (10)

1.一种物联网设备协同联动方法，其特征在于，所述物联网设备相互联接构成物联网，所述物联网设备包含条件器功能、执行器功能和服务器功能的功能组合，具体如下步骤：

步骤S1、物联网中具备服务器功能的设备相互协商、推选出主服务器，所述主服务器获取用户设定的设备协同联动规则，并将所述设备协同联动规则同步到物联网中的其他设备；

步骤S2、物联网中具备条件器功能的设备接收到所述设备协同联动规则，根据所述设备协同联动规则，将自身条件器设备条件信息同步到物联网中相关的具备执行器功能的设备；

步骤S3、物联网中具备执行器功能的设备接收到所述设备协同联动规则和所述条件器设备条件信息，根据所述设备协同联动规则和条件器设备条件信息决定自身执行动作；

步骤S4、物联网中具备条件器功能和/或执行器功能的设备提供人机接口和存储机制，所述人机接口由用户直接输入设备协同联动规则，所述存储机制将所述设备协同联动规则进行保存，所述人机接口和存储机制用于保障物联网中缺少具备服务器功能的设备的情况下依然能够协同联动；

步骤S5、物联网中具备条件器功能和/或执行器功能的设备运行网络消息调度机制，所述网络消息调度机制用于避免短时间内大量数据包涌入或输出时产生逻辑错误。

2.如权利要求1所述的一种物联网设备协同联动方法，其特征在于，所述步骤S1中所述的物联网中具备服务器功能的设备相互协商、推选出主服务器的方法为具备服务器功能的设备上电后默认自身为主服务器并周期性发送广播包；当其他服务器收到广播包后，判断广播包是否优于自身资源，若优于自身资源，则自动将自身设为从服务器，关闭广播，并向主服务器回复确认消息；若有新的资源更强的服务器设备上电后，最终判定哪个设备为主服务器，关闭广播，并回复确认消息，并执行后续功能；和/或，所述步骤S1中所述的物联网中具备服务器功能的设备相互协商、推选出主服务器的方法还可以为当物联网当中有多个服务器时，则推选出主服务器，推选方式是在设备初始化时即设定好各个服务器的优先级，其他服务器按照功能和性能指标依次递减；和/或，所述步骤S1中所述的设备协同联动规则包含规则信息、条件器信息和执行器信息；和/或，所述步骤S1中所述的将所述设备协同联动规则同步到物联网中的其他设备的方法具体包含以下子步骤：

步骤S11、对所述设备协同联动规则进行有效性检测；

步骤S12、对所述设备协同联动规则进行查重；

步骤S13、分发条件器消息包；

步骤S14、分发规则消息包。

3.如权利要求2所述的一种物联网设备协同联动方法，其特征在于，所述规则信息包含规则ID、规则时效；所述条件器信息包含所述规则信息相关的条件，以及各个条件之间的逻辑关系；所述执行器信息包含所述规则信息的最终执行目的。

4.如权利要求2所述的一种物联网设备协同联动方法，其特征在于，所述步骤S11中，对所述设备协同联动规则进行有效性检测包括：规则当中是否存在逻辑错误的检测以及当前规则与已有规则之间是否存在逻辑冲突的检测；和/或，所述步骤S14中所述分发规则消息包过程如下：所述规则消息包发送给具备执行器功能的设备以及物联网中的其他具备服务器功能的设备，一方面告诉具备执行器功能的设备准备接收具备条件器功能的设备的消息，并根据条件和规则判定是否要执行动作；另一方面告诉其他具备服务器功能的设备，并在其他具备服务器功能的设备上对规则进行备份，从而保证每个具备服务器功能的设备上都有统一且完备的用户规则。

5.如权利要求1所述的一种物联网设备协同联动方法，其特征在于，所述步骤S2中所述的将自身条件器设备条件信息同步到物联网中相关的具备执行器功能的设备的方法具体包含以下子步骤：

步骤S21、获取到所述设备协同联动规则中所述条件器信息和执行器信息，更新订阅信息表，所述订阅信息表中的每一个表项保存了获取到的所述条件器信息和执行器信息；

步骤S22、获取自身设备状态，查询订阅信息表，当所述条件器信息的满足情况发生变化时，通知相应的具备执行器功能的设备。

6.如权利要求5所述的一种物联网设备协同联动方法，其特征在于，所述步骤S22中所述的获取自身设备状态包含扫描性获取和触发性获取；所述扫描性获取的具体方法为周期性扫描自身设备状态，获取状态信息；所述触发性获取的具体方法为提前设定触发条件，当满足触发条件时立即通知具备条件器功能的设备获取自身设备状态。

7.如权利要求1所述的一种物联网设备协同联动方法，其特征在于，所述步骤S5具体包含以下子步骤：

步骤S51、按照读取策略，读入网络消息并保存到接收缓冲区；

步骤S52、按照调度策略，选取接收缓冲区中的消息包进行处理；

步骤S53、将条件器和执行器生成的消息保存到发送缓冲区，按照发送策略，将消息包发送出去。

8.如权利要求7所述的一种物联网设备协同联动方法，其特征在于，所述步骤S51中所述读取策略为：设定实时更新的时间窗口，若时间窗口内平均数据包数量不超过设定阈值，则在处理器周期发现有大量数据包涌入时，暂不采用阻塞读取，仍然每个处理器周期先读取一个或少量的数据包；反之，若时间窗口内平均数据包数量超过设定阈值，则当下个处理器周期仍然有大量数据包涌入时，则进行阻塞读取，先将网络数据包读完，防止丢包；和/或，所述步骤S52中所述调度策略为：针对不同类型的消息设计一个权重，然后对缓冲区中的消息按照权重进行优先级时间累加方式排序，任何消息的优先级可以在缓冲区内随着时间累加，在特定时间后，任何低优先级的消息也必然会成为最高优先级，从而得到调度。

9.一种物联网设备协同联动装置，其特征在于，包括存储器和一个或多个处理器，所述存储器中存储有可执行代码，所述一个或多个处理器执行所述可执行代码时，用于实现权利要求1-8中任一项所述的一种物联网设备协同联动方法。

10.一种计算机可读存储介质，其特征在于，其上存储有程序，该程序被处理器执行时，实现权利要求1-8中任一项所述的一种物联网设备协同联动方法。

Images