CN112422525B - 一种故障数据传输方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种故障数据传输方法、装置、设备及存储介质，涉及计算机技术领域，用于解决故障数据传输时占用网络带宽大以及传输效率低的问题。该方法包括：获取待传输的故障数据包；根据设定的数据量与传输策略之间的对应关系，确定所述故障数据包对应的传输策略；其中，所述传输策略包括数据包传输时所需压缩次数以及每一次压缩所采用的压缩方法；根据确定的传输策略中指示的压缩次数以及每一次压缩对应的压缩方法对所述故障数据包进行多次压缩，得到压缩数据包；将所述压缩数据包传输至后台服务器。

Description

一种故障数据传输方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，提供一种故障数据传输方法、装置、设备及存储介质。

背景技术

随着人们生活水平的提高，空调的应用越来越广泛，然而空调在销售之后，由于使用不当或者受到环境因素的影响，会使得空调出现故障，进而影响用户的正常使用。对于简单常见的故障，用户可以根据空调控制器中预存储的解决方案自行解决，但是，对于一些复杂的、非常见的故障，就需要由售后人员进行解决。因此，制造商需要收集这些故障数据，对空调进行必要的维修判断，以采取相应的维修措施。在售后人员去现场进行数据采集与判断时，由于售后人员的知识有限，当采集到的空调故障数据较为复杂时，售后人员并不能准确判断出具体的故障类型，此时，就需要将相关的故障数据拿回由专业人员进行研究，进而根据研究结果再去现场对空调进行维修，如此反复，这样就带来的一个问题，降低了空调的维修效率，浪费了大量时间。

因此，为了解决上述问题，可通过网络将故障数据传输给空调厂商，实现对故障数据的采集，这种方式省去了售后人员去故障现场进行数据采集的过程，提高了空调的维修效率。但是，目前使用网络传输故障数据的方式，在传输的故障数据较多的情况下，会大量占用用户的网络带宽，造成网络传输速度变慢、接收内容耗时长等问题。

发明内容

本申请实施例提供一种故障数据传输方法、装置、设备及存储介质，用于解决故障数据传输时占用网络带宽大以及传输效率低的问题。

一方面，提供一种故障数据传输方法，所述方法包括：

获取待传输的故障数据包；

根据设定的数据量与传输策略之间的对应关系，确定所述故障数据包对应的传输策略；其中，所述传输策略包括数据包传输时所需压缩次数以及每一次压缩所采用的压缩方法；

根据确定的传输策略中指示的压缩次数以及每一次压缩对应的压缩方法对所述故障数据包进行多次压缩，得到压缩数据包；

将所述压缩数据包传输至后台服务器。

一方面，提供一种故障数据传输装置，所述装置包括：

获取单元，用于获取待传输的故障数据包；

确定单元，用于根据设定的数据量与传输策略之间的对应关系，确定所述故障数据包对应的传输策略；其中，所述传输策略包括数据包传输时所需压缩次数以及每一次压缩所采用的压缩方法；

压缩单元，用于根据确定的传输策略中指示的压缩次数以及每一次压缩对应的压缩方法对所述故障数据包进行多次压缩，得到压缩数据包；

传输单元，用于将所述压缩数据包传输至后台服务器。

可选的，所述传输单元，还用于：

向所述后台服务器发送查询请求；其中，所述查询请求用于查询压缩方法库的版本号；

根据所述后台服务器返回的版本号确定压缩方法库是否需要更新；

在确定所述压缩方法库需要更新时，从所述后台服务器获取更新压缩方法集合，以更新所述压缩本地方法库。

可选的，所述装置还包括监控单元，用于：

监控自身与所述后台服务器的连接状态；

当监控到自身与所述后台服务器连接断开时，将所述故障数据包储存于本地存储空间中；

则根据设定的数据量与传输策略之间的对应关系，确定所述故障数据包对应的传输策略，包括：

当监控到自身与所述后台服务器已连接时，根据设定的数据量与传输策略之间的对应关系，确定所述故障数据包对应的传输策略。

可选的，所述确定单元，还用于：

确定每一设定数据量所对应的压缩效率最高的压缩方法；

针对每一数据量，以及每次压缩得到的压缩数据包的数据量，将多种压缩效率最高的压缩方法进行级联组合，得到与待压缩的数据包的数据量对应的压缩策略；

根据所有数据量与各自对应的压缩策略得到所述数据量与压缩策略之间的对应关系。

可选的，所述确定单元，还用于：

根据所述故障数据包的数据量，以及设定的数据量与传输策略之间的对应关系，确定出使得所述故障数据包的传输效率最高的传输策略。

可选的，所述压缩单元，还用于：

根据每一次压缩时的数据量对所述故障数据包进行多次压缩，直至所述最终获得的压缩数据包满足设定的压缩终止条件；其中，每一次压缩过程包括如下过程：

根据输入数据包的数据量确定对应的压缩方法；其中，当为第一次压缩时，所述输入数据包为所述故障数据包；或者，当不是第一次压缩时，所述输入数据包为上一次压缩过程得到的压缩数据包；

通过确定的压缩方法对所述输入数据包进行压缩；

确定压缩得到的数据包是否满足设定的压缩终止条件；

若确定压缩得到的数据包满足设定的压缩终止条件，则压缩过程结束；或者，若确定压缩得到的数据包不满足设定的压缩终止条件，则进入下一次压缩过程。

可选的，所述装置还包括加密单元，用于：

根据本地方法库中的加密方法对所述压缩数据包进行加密处理，获取加密后的压缩数据包；

将所述压缩数据包传输至后台服务器，包括：

将所述加密后的压缩数据包传输至所述后台服务器。

一方面，提供一种故障数据传输方法，所述方法包括：

接收智能家居设备发送的故障数据上传请求；所述故障数据上传请求携带由所述智能家居设备的故障数据包压缩后得到的压缩数据包以及指示对所述故障数据包进行压缩时采用的压缩策略的指示信息；

根据所述指示信息确定所述压缩数据包对应的解压策略；所述解压策略包括解压次数以及每一次解压采用的解压方法；

根据确定的解压策略中指示的解压次数以及每一次解压对应的压缩方法对所述压缩数据包进行多次解压，得到所述故障数据包；

基于所述故障数据包获取所述智能家居设备的故障数据。

一方面，提供一种故障数据传输装置，所述装置包括：

接收单元，用于接收智能家居设备发送的故障数据上传请求；所述故障数据上传请求携带由所述智能家居设备的故障数据包压缩后得到的压缩数据包以及指示对所述故障数据包进行压缩时采用的压缩策略的指示信息；

确定单元，用于根据所述指示信息确定所述压缩数据包对应的解压策略；所述解压策略包括解压次数以及每一次解压采用的解压方法；

解压单元，用于根据确定的解压策略中指示的解压次数以及每一次解压对应的压缩方法对所述压缩数据包进行多次解压，得到所述故障数据包；

获取单元，用于基于所述故障数据包获取所述智能家居设备的故障数据。

一方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一种方法的步骤。

一方面，提供一种计算机存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

本申请实施例中，获取待传输的故障数据包，并根据设定的数据量与压缩策略之间的对应关系，确定故障数据包对应的压缩策略，然后，根据确定的压缩策略中指示的压缩次数以及每一次压缩对应的压缩方法对故障数据包进行多次压缩，以得到压缩数据包，且将得到的压缩数据包传输至后台服务器。因此，在获取待传输的故障数据包之后，可以根据数据量与压缩策略之间的对应关系来确定待传输的故障数据包对应的压缩策略，其中，压缩策略中包含了对故障数据包多次压缩时每一次压缩所采用的压缩方法，所以，依据压缩策略中的多个压缩方法进行压缩处理可以获得最终的压缩数据包，通过多次压缩，最终得到的压缩数据包的数据量得以更小，在传输时占用网络带宽以及时延更小，进而提升了传输效率。

附图说明

为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的智能家居设备的一种示意图；

图3为本申请实施例提供的故障数据传输方法的一种流程示意图；

图4为本申请实施例提供的获取压缩数据包的一种示意图；

图5为本申请实施例提供的故障数据上报的一种示意图；

图6为本申请实施例提供的智能家居设备侧故障数据传输装置的示意图；

图7为本申请实施例提供的后台服务器侧故障数据传输装置的示意图；

图8为本申请实施例提供的计算机设备的一种示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

由于在使用网络进行故障数据传输时，因为传输的故障数据较多，从而导致大量占用了用户的网络带宽，造成了网络传输速度变慢、接收内容耗时长等问题，进而使得故障数据的传输效率变低。但是目前在故障数据传输时，通常只是采用固定的压缩算法进行单次压缩，因此进行压缩后的数据包的数据量依然很大，依然需要占用较多的网络带宽，传输效率不高。

基于此，本申请实施例提供一种故障数据传输方法，在该方法中，获取待传输的故障数据包，并根据设定的数据量与压缩策略之间的对应关系，确定故障数据包对应的压缩策略，然后，根据确定的压缩策略中指示的压缩次数以及每一次压缩对应的压缩方法对故障数据包进行多次压缩，以得到压缩数据包，且将得到的压缩数据包传输至后台服务器。本申请实施例在获取待传输的故障数据包之后，可以根据数据量与压缩策略之间的对应关系来确定待传输的故障数据包对应的压缩策略，其中，压缩策略中包含了对故障数据包多次压缩时每一次压缩所采用的压缩方法，所以，依据压缩策略中的多个压缩方法进行压缩处理可以获得最终的压缩数据包，通过多次压缩，最终得到的压缩数据包的数据量得以更小，在传输时占用网络带宽以及时延更小，进而提升了传输效率。在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

如图1所示，为本申请实施例提供的一种应用场景示意图。该故障数据传输的应用场景可以包括智能家居设备101、网关102以及服务器103。

智能家居设备101例如可以为智能空调、智能电视机或者智能洗衣机等家居设备。网关102可以为家庭网关设备等，服务器103可以为智能家居设备101的厂商对应的后台服务器，该服务器103可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。

在一种可能的实施方式中，当智能家居设备101发生故障时，可以在采集自身的故障数据包后，通过智能家居设备101执行本申请实施例的故障数据传输方法得到压缩数据包，并通过网关102传输给服务器103。

如图2所示，智能家居设备101可以包括一个或多个处理器1011、存储器1012以及与其他设备交互的I/O接口1013等。此外，智能家居设备101还可以配置数据库1014，数据库104可以用于存储本申请实施例提供的方案中涉及到的故障数据、压缩算法以及加密算法等。其中，智能家居设备101的存储器1012中可以存储本申请实施例提供的故障数据传输方法的程序指令，这些程序指令被处理器1011执行时能够用以实现本申请实施例提供的故障数据传输方法的步骤，以提高故障数据传输的效率。

在另一种可能的实施方式中，当智能家居设备101发生故障时，可以将采集的故障数据包发送给网关102，进而网关102可以执行本申请实施例的故障数据传输方法得到压缩数据包，并传输给服务器103。

当然，本申请实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其他可能的应用场景，本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。下面，将结合附图对本申请实施例的方法进行介绍。

如图3所示，为本申请实施例提供的故障数据传输方法的流程示意图，该方法的流程介绍如下，该方法可以通过图1所示的智能家居设备101或者网关102结合服务器103来执行，下面以智能家居设备为例进行介绍。

步骤301：智能家居设备获取待传输的故障数据包。

当家居设备发生故障时，则可以采集发生故障时的故障数据，得到故障数据包。例如，以智能家居设备为空调为例，在空调在环境温度过高时，会导致空调压缩机停运，此时，空调则会获取到相应的故障数据，例如故障代码以及故障时空调参数等等，进而根据故障数据生成故障数据包。

步骤302：智能家居设备监控自身与后台服务器的连接状态。

在本申请实施例中，智能家居设备可以监控自身与后台服务器的连接状态，那么在智能家居设备在获取待传输的故障数据包之后，则可以根据监控结果确定是否发送故障数据包。当智能家居设备监控到自身与后台服务器连接断开时，无法进行数据包的发送，因此可以将故障数据包储存于本地存储空间中。当智能家居设备监控到自身与后台服务器已连接时，则可以进行故障数据包的发送。那么可以将本地存储的故障数据包依次发送给后台服务器。

示例性的，如图3所示，以智能家居设备为空调为例，在空调获取了待传输的故障数据包之后，空调会监控自身用于网络连接的无线保真(Wireless Fidelity，WIFI)模块与后台服务器是否处于连接状态。如果空调监控到自身的WIFI模块与后台服务器处于连接断开状态，那么空调会将故障数据包储存于空调的存储空间中。如果空调监控到自身的WIFI模块与后台服务器处于连接状态，那么空调则会进行后续的压缩、加密等操作，为故障数据包作进一步处理。

步骤303：智能家居设备向后台服务器发送查询请求。

在本申请实施例中，由于使用最新的压缩方法有助于减少故障数据的压缩数据损失，使故障数据压缩到最小，提高故障数据的传输效率。所以智能家居设备在设定的更新时机到达时，可向后台服务器发送用于查询压缩方法库版本号的查询请求。

更新时机可以设置为在智能家居设备每次开机启动时进行更新，也可以设置更新周期，进行周期性的更新，还可以通过智能家居设备相应的控制器的按键让用户自主进行更新。在本申请实施例中，对于更新时机的设置并不进行限制。

示例性的，如图3所示，为本申请实施例提供的网络模块与后台服务器交互的一种示意图。同样以空调为例，例如，压缩方法库的更新周期为12小时，则空调在使用过程中，每12小时则可以向后台服务器发送用于查询压缩方法库版本号的查询请求，以确定是否更新压缩方法库。

步骤304：后台服务器向智能家居设备反馈压缩方法库的版本号。

在本申请实施例中，后台服务器会根据智能家居设备发送的查询请求查询当前后台服务器中的压缩方法库的最新版本号，并将最新版本号给智能家居设备，智能家居设备可以根据后台服务器反馈的版本号确定自身的压缩方法库是否需要更新。当确定压缩方法库需要更新时，智能家居设备可以从后台服务器获取更新压缩方法集合，并更新自身压缩方法库。

示例性的，同样以空调为例，在后台服务器接收到空调的查询请求之后，后台服务器查询到当前压缩方法库的最新版本号为2.0，则将最新版本号为2.0作为反馈结果发送给空调，空调根据后台服务器最新版本号为2.0与自身压缩方法库的版本号进行比对，以确定空调自身安装的压缩方法库是否需要更新。例如，在空调存储的压缩方法库的版本号为2.0时，而后台服务器返回的最新版本号也为2.0，则确定空调存储的压缩方法库不需要更新。若是空调自身存储的压缩方法库的版本号为1.9时，而后台服务器返回的最新版本号为2.0，则确定空调自身安装的压缩方法库需要更新，此时，空调则可以从后台服务器获取更新压缩方法集合，并更新空调自身的压缩方法库。

步骤305：智能家居设备确定压缩策略。

在本申请实施例中，数据量与压缩策略之间的对应关系可以是预先得到并存储在智能家居设备的本地存储空间中的。

具体的，如表1所示，当故障数据包的数据量相同时，采用不同的压缩方法进行压缩，压缩后得到的压缩包的传输效率可能是不同的，而如表2所示同一压缩方法也可能有最适合的压缩数据区间，比如哈夫曼压缩(Huffman)算法、串表压缩(Lempel Ziv Welch，LZW)算法或行程长度编码压缩算法(Run Length Encode，RLE)等算法比较适合于较长字符串的压缩，而Smaz压缩算法、GZIP压缩算法或Unicode标准压缩方案等算法则比较适合于短字符串的压缩，由此可见，对于各个压缩算法在压缩不同数据量的数据包时，压缩后得到的压缩包的传输效率也可能是不同的，因此为了达到提高传输效率的目的，可以在进行多次压缩时，根据当前需要压缩的数据包的大小使用与当前数据量对应的传输效率最高的压缩方法，因此，可以预先根据数据量区间设定好每个数据量区间对应的压缩策略，压缩策略是指故障数据包传输所需要的压缩次数，以及每次压缩所采用的压缩算法。

表1

表2

在本申请实施例中，在对故障数据进行压缩的过程中，同一个故障数据包在压缩效率越高的情况下，压缩后得到的压缩数据包的数据量就越小，所对应进行故障数据传输时的传输效率也就越高。所以，为了提高传输效率，可以根据针对拥有某一数据量的数据包所对应的压缩效率最高的压缩方法作为该故障数据包压缩时采用的压缩方法。而由于进行一次压缩所得的数据包的数据量依然很大，因此，针对某一数据包可能需要进行多次压缩。

具体的，可以预先获取每个数据量与压缩策略之间的对应关系，在后续进行使用时，则可以根据需要压缩的数据包的数据量以及该对应关系查找获取相应的压缩策略。

其中，针对数据包的数据量以及每次压缩得到的压缩数据包的数据量，可以将多种压缩效率最高的压缩方法进行级联组合，以得到与待压缩数据包的数据量对应的压缩策略，从而可以就根据所有数据量与各自所对应的压缩策略得到设定的数据量与压缩策略之间的对应关系。

示例性的，如表1所示，同样以空调为例，在待传输的故障数据包的数据量12000Bit时，空调根据待传输的故障数据包的数据量，以“压缩效率最大”作为确定压缩方法的条件进行压缩方法的确定。因为15000>12000>10000，所以根据待传输的故障数据包的数据量12000Bit在空调的储存空间中查找到编号为a1、a2、a3的传输结果的数据量符合要求。在编号为a1、a2、a3的传输结果中，由于编号为a3的传输结果中压缩效率最高，因此，可以采用编号为a3相应使用的压缩方法A3来对数据量12000Bit的待传输的故障数据包进行压缩处理，得到数据量为6000Bit的第一压缩数据包。

此时，由于8000>6000>5000，所以根据待传输的第一压缩数据包的数据量6000Bit在空调的储存空间中查找到编号为b1、b2、b3的数据量符合要求，在编号为b1、b2、b3的传输结果中，由于编号b3的传输结果中压缩效率最高，因此，可以采用编号为a3相应使用的压缩方法B3来对数据量6000Bit的待传输的故障数据包进行压缩处理，得到数据量为550Bit的第二压缩数据包。

又由于1000>550>500，所以根据待传输的第二压缩数据包的数据量550Bit在空调的储存空间中查找到编号为d1、d2、d3的数据量符合要求，在编号为d1、d2、d3的传输结果中，由于编号d3的传输结果中压缩效率最高，因此，可以编号为d3相应使用的压缩方法D3来对数据量550Bit的待传输的故障数据包进行压缩处理，得到数据量为55Bit的第三压缩数据包。

综上，可以得到与待传输的故障数据包的数据量12000Bit对应的压缩策略：

压缩3次，依次采用压缩方法A3+压缩方法B3+压缩方法D3。

由于“压缩3次，依次采用压缩方法A3+压缩方法B3+压缩方法D3”的压缩策略可以使得待传输故障数据包的数据量12000Bit的压缩效率最高，那么该压缩策略也可以使得待传输故障数据包的数据量12000Bit的传输效率最高。因此，当待传输的故障数据包的数据量为12000Bit时，就可采用“压缩3次，依次采用压缩方法A3+压缩方法B3+压缩方法D3”的压缩策略进行故障数据压缩。

通过将具有不同数据量的多个故障数据包进行上述过程，可得到多个障数据包对应的数据量与压缩策略之间的对应关系。在上述得到的数据量与压缩策略之间的对应关系中，各个数据量对应的压缩策略均为传输效率最高的压缩策略，因此，在获取故障数据包之后，则可以根据该故障数据包的数据量确定相对应的压缩策略。

步骤306：智能家居设备获取压缩数据包。

根据确定的压缩策略中指示的压缩次数以及每一次压缩对应的压缩方法对故障数据包进行多次压缩，得到压缩数据包。

在本申请实施例中，智能家居设备会根据确定出的压缩策略中指示的压缩次数以及每一次压缩对应的压缩方法对故障数据包进行多次压缩，直至最终获得的压缩数据包满足设定的压缩终止条件；其中，每一次压缩的具体过程如下：

步骤3061：根据输入数据包的数据量确定对应的压缩方法；其中，当为第一次压缩时，输入数据包为故障数据包；或者，当不是第一次压缩时，输入数据包为上一次压缩过程得到的压缩数据包；

步骤3062：通过确定的压缩方法对输入数据包进行压缩；

步骤3063：确定压缩得到的数据包是否满足设定的压缩终止条件；

步骤3064：若确定压缩得到的数据包满足设定的压缩终止条件，则压缩过程结束；

步骤3065：若确定压缩得到的数据包不满足设定的压缩终止条件，则进入下一次压缩过程。

示例性的，同样以故障数据包数据量为12000Bit为例。如图4所示，在确定出的压缩策略为“进行3次压缩，采用压缩方法A3+压缩方法B3+压缩方法D3”时，空调根据确定出的压缩策略中指示的进行3次压缩，依次采用压缩方法A3+压缩方法B3+压缩方法D3”对故障数据包进行多次压缩，直至最终获得的压缩数据包满足设定的压缩终止条件“数据包的数据量小于150Bit”。

具体的，首先根据输入数据包的数据量12000Bit采用对应的压缩方法A3进行第一次压缩获得数据量为6000Bit的第一压缩数据包，并根据第一压缩数据包的数据量6000Bit采用对应的压缩方法B3进行第二次压缩获得数据量为550Bit的第二压缩数据包，再根据第二压缩数据包的数据量550Bit采用对应的压缩方法D3进行第三次压缩获得数据量为55Bit的第三压缩数据包，而第三压缩数据包的数据量55<150，压缩过程结束，获得最终需要传输至后台服务器的压缩数据包，即数据量为55Bit的第三压缩数据包。

步骤307：智能家居设备向后台服务器发送故障数据上传请求，后台服务器接收故障数据上传请求。

在本申请实施例中，由于传输的故障数据包可能包含用户隐私数据以及协议类信息，为防止被截取，需要通过加密方式进行传输。因此，在将压缩数据包传输至后台服务器之前，可以根据本地算法库中的加密算法对压缩数据包进行加密处理，获取加密后的压缩数据包，并将加密后的压缩数据包传输至后台服务器。

其中，加密算法例如可以为高级加密标准(Advanced Encryption Standard，AES)或RSA(Rivest-Shamir-Adleman)等加密算法，当然，也可以为其他的加密算法，本申请实施例对此不做限制。

步骤308：后台服务器确定解压策略。

其中，故障数据上传请求可以携带由智能家居设备的故障数据包压缩后得到的压缩数据包以及指示对故障数据包进行压缩时采用的压缩策略的指示信息。

在本申请实施例中，为了使得后台服务器知晓智能家居设备采用的压缩策略，进而可以根据压缩策略确定相对应的解压策略，智能家居设备在发送压缩数据包时，可以携带指示故障数据包传输时采用的压缩策略的指示信息，这样，后台服务器接收到智能家居设备发送的故障数据上传请求之后，则可以根据指示信息确定压缩数据包对应的解压策略。若压缩数据包还存在加密的情况，则还需在进行解压处理之前，先进行解密处理。

示例性的，以厂商的后台服务器为例，在接收到的来自于空调发送的加密的压缩数据包中，压缩数据包的报文头部中含有空调传输数据量为12000Bit的故障数据包传输时采用的压缩策略与加密方法对应的指示信息，即“进行3次压缩，依次采用压缩方法A3+压缩方法B3+压缩方法D3”以及“采用AES加密方法”的指示信息。所以，根据指示信息，后台服务器可以确定解压策略与解密方法，即“进行3次解压，依次采用逆压缩方法D3+逆压缩方法B3+逆压缩方法A3”以及“采用逆AES加密方法”。

步骤309：后台服务器对压缩数据包解压，获取解压数据包。

在本申请实施例中，后台服务器根据确定好的解压策略中指示的解压次数以及每一次解压对应的压缩方法对压缩数据包依次进行解压，以得到解压后数据包。

示例性的，以厂商的后台服务器为例，首先采用逆AES加密方法对加密的压缩数据包进行解密处理，以获取解密后的压缩数据包。然后，根据逆压缩方法D3进行解压处理获取第一解压数据包，并根据逆压缩方法B3进行解压处理获取第二解压数据包，然后，根据逆压缩方法A3进行解压处理获取第三解压数据包，即获取故障数据。

步骤310：后台服务器获取完整故障内容。

在本申请实施例中，为了便于故障数据的传输，智能家居设备发送故障数据通常为不可识别的参数数据形式，需要使用相应的数据协议对故障数据进行解析，才能呈现为用户能够理解的完整故障内容。因此，后台服务器在解压接收到压缩数据包获得故障数据之后，需要依据相应的数据协议对故障数据进行处理。

示例性的，如图5所示，在后台服务器获得故障数据之后，通过数据解析使用的profibus DP数据协议，将解压后的故障数据还原成可识别的空调参数数据。

综上，在本申请实施例中，如图5所示，以空调为例，整体的故障数据传输过程如下：

在空调出现故障时，空调的数据处理模块可以获取故障对应的故障数据，且在数据处理模块确定WIFI模块未连接网络，或者通过WIFI模块与空调厂商的后台服务器尝试连接失败时，会先将故障数据对应的数据包存储在空调的储存空间中，在数据处理模块确定WIFI模块处于网络连接的状态，或者WIFI模块与空调厂商的后台服务器尝试连接成功时，数据处理模块会从空调的储存空间按储存的时间顺序提取故障数据包进行后续处理过程。而如果WIFI模块会采集故障对应的故障数据之后，WIFI模块与空调厂商的后台服务器连接，那么直接将故障数据包进行后续处理过程。

针对一个故障数据包，数据处理模块可以确定该故障数据包的数据量对应的压缩策略，如压缩策略为“进行2次压缩，采用压缩方法A+压缩方法C”。在确定压缩策略之后，据压缩策略进行2次压缩，采用压缩方法A+压缩方法C”，那么则可以采用压缩算法A对故障数据包进行第一次压缩，获得第一压缩数据包，然后再采用压缩算法C进行第二次压缩，获得第二压缩数据包。然后对第二压缩数据包采用加密算法进行加密处理，获得加密后的第二压缩数据包，并将加密后的第二压缩数据包发送给空调厂商的后台服务器。

空调厂商的后台服务器在接收加密后的第二压缩数据包之后，根据接收的指示压缩策略和加密算法的指示信息确定对应的解压策略与解密算法，继而根据解密算法对接收到的加密后的第二压缩数据包进行解密处理，就可以获得第二压缩数据包，然后，根据解压策略采用逆压缩算法C进行第一次解压，获得第一压缩数据包，接下来，根据解压策略采用逆压缩算法A进行第二次解压，获得故障数据包。

后台服务器采用数据协议对解压后的故障数据包进行解析，获得完整的故障内容。

综上所述，本申请实施例中，在获取待传输的故障数据包之后，可以根据数据量与压缩策略之间的对应关系来确定待传输的故障数据包对应的压缩策略，其中，压缩策略中包含了对故障数据包多次压缩时每一次压缩所采用的压缩方法，所以，依据压缩策略中的多个压缩方法进行压缩处理可以获得最终的压缩数据包，通过多次压缩，最终得到的压缩数据包的数据量得以更小，在传输时占用网络带宽以及时延更小，进而提升了传输效率。

基于同一发明构思，本申请实施例提供一种故障数据传输装置，如图6所示，该装置应用于故障数据传输方法中，该装置包括：

获取单元601，用于获取待传输的故障数据包；

确定单元602，用于根据设定的数据量与传输策略之间的对应关系，确定故障数据包对应的传输策略；其中，传输策略包括数据包传输时所需压缩次数以及每一次压缩所采用的压缩方法；

压缩单元603，用于根据确定的传输策略中指示的压缩次数以及每一次压缩对应的压缩方法对故障数据包进行多次压缩，得到压缩数据包；

传输单元604，用于将压缩数据包传输至后台服务器。

可选的，传输单元604，还用于：

向后台服务器发送查询请求；其中，查询请求用于查询压缩方法库的版本号；

根据后台服务器返回的版本号确定压缩方法库是否需要更新；

在确定压缩方法库需要更新时，从后台服务器获取更新压缩方法集合，以更新压缩本地方法库。

可选的，装置还包括监控单元605，用于：

监控自身与后台服务器的连接状态；

当监控到自身与后台服务器连接断开时，将故障数据包储存于本地存储空间中；

则根据设定的数据量与传输策略之间的对应关系，确定故障数据包对应的传输策略，包括：

当监控到自身与后台服务器已连接时，根据设定的数据量与传输策略之间的对应关系，确定故障数据包对应的传输策略。

可选的，确定单元602，还用于：

确定每一设定数据量所对应的压缩效率最高的压缩方法；

针对每一数据量，以及每次压缩得到的压缩数据包的数据量，将多种压缩效率最高的压缩方法进行级联组合，得到与待压缩的数据包的数据量对应的压缩策略；

根据所有数据量与各自对应的压缩策略得到数据量与压缩策略之间的对应关系。

可选的，确定单元602，还用于：

根据故障数据包的数据量，以及设定的数据量与传输策略之间的对应关系，确定出使得故障数据包的传输效率最高的传输策略。

可选的，压缩单元603，还用于：

根据每一次压缩时的数据量对故障数据包进行多次压缩，直至最终获得的压缩数据包满足设定的压缩终止条件；其中，每一次压缩过程包括如下过程：

根据输入数据包的数据量确定对应的压缩方法；其中，当为第一次压缩时，输入数据包为故障数据包；或者，当不是第一次压缩时，输入数据包为上一次压缩过程得到的压缩数据包；

通过确定的压缩方法对输入数据包进行压缩；

确定压缩得到的数据包是否满足设定的压缩终止条件；

若确定压缩得到的数据包满足设定的压缩终止条件，则压缩过程结束；或者，若确定压缩得到的数据包不满足设定的压缩终止条件，则进入下一次压缩过程。

可选的，装置还包括加密单元606，用于：

根据本地方法库中的加密方法对压缩数据包进行加密处理，获取加密后的压缩数据包；

将压缩数据包传输至后台服务器，包括：

将加密后的压缩数据包传输至后台服务器。

该装置可以用于执行图3～图5所示的实施例中智能家居设备侧所执行的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考图3～图5所示的实施例的描述，不多赘述。

基于同一发明构思，本申请实施例提供一种故障数据传输装置，如图7所示，该装置应用于故障数据传输方法中，该装置包括：

接收单元701，用于接收智能家居设备发送的故障数据上传请求；故障数据上传请求携带由智能家居设备的故障数据包压缩后得到的压缩数据包以及指示对故障数据包进行压缩时采用的压缩策略的指示信息；

确定单元702，用于根据指示信息确定压缩数据包对应的解压策略；解压策略包括解压次数以及每一次解压采用的解压方法；

解压单元703，用于根据确定的解压策略中指示的解压次数以及每一次解压对应的压缩方法对压缩数据包进行多次解压，得到故障数据包；

获取单元704，用于基于故障数据包获取智能家居设备的故障数据。

该装置可以用于执行图3～图5所示的实施例中后台服务器侧所执行的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考图3～图5所示的实施例的描述，不多赘述。

请参见图8，基于同一技术构思，本申请实施例还提供了一种计算机设备80，可以包括存储器801和处理器802。

所述存储器801，用于存储处理器802执行的计算机程序。存储器801可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序等；存储数据区可存储根据计算机设备的使用所创建的数据等。处理器802，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等等。本申请实施例中不限定上述存储器801和处理器802之间的具体连接介质。本申请实施例在图8中以存储器801和处理器802之间通过总线803连接，总线803在图8中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线803可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器801可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器801也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器801是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器801可以是上述存储器的组合。

处理器802，用于调用所述存储器801中存储的计算机程序时执行如图3～图5所示的实施例中设备所执行的方法。

在一些可能的实施方式中，本申请提供的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的方法中的步骤，例如，所述计算机设备可以执行如图3～图5所示的实施例中智能家居设备或者后台服务器所执行的方法。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种故障数据传输方法，其特征在于，所述方法包括：

获取待传输的故障数据包；

根据设定的数据量与压缩策略之间的对应关系，确定所述故障数据包对应的压缩策略；其中，所述压缩策略包括数据包传输时所需压缩次数以及每一次压缩所采用的压缩方法；所述压缩策略是各个设定数据量所对应的多种压缩效率最高的压缩方法进行级联组合得到的；

根据确定的压缩策略中指示的压缩次数以及每一次压缩对应的压缩方法对所述故障数据包进行多次压缩，得到压缩数据包；

将所述压缩数据包传输至后台服务器。

2.如权利要求1所述的方法，其特征在于，在获取待传输的故障数据包之后，所述方法还包括：

向所述后台服务器发送查询请求；其中，所述查询请求用于查询压缩方法库的版本号；

根据所述后台服务器返回的版本号确定压缩方法库是否需要更新；

在确定所述压缩方法库需要更新时，从所述后台服务器获取更新压缩方法集合，以更新本地方法库。

3.如权利要求1所述的方法，其特征在于，在获取待传输的故障数据包之后，所述方法还包括：

监控自身与所述后台服务器的连接状态；

当监控到自身与所述后台服务器连接断开时，将所述故障数据包储存于本地存储空间中；

则根据设定的数据量与压缩策略之间的对应关系，确定所述故障数据包对应的压缩策略，包括：

当监控到自身与所述后台服务器已连接时，根据设定的数据量与压缩策略之间的对应关系，确定所述故障数据包对应的压缩策略。

4.如权利要求1所述的方法，其特征在于，在根据设定的数据量与压缩策略之间的对应关系，确定所述故障数据包对应的压缩策略之前，所述方法还包括：

确定每一设定数据量所对应的压缩效率最高的压缩方法；

针对每一数据量，以及每次压缩得到的压缩数据包的数据量，将多种压缩效率最高的压缩方法进行级联组合，得到与待压缩的数据包的数据量对应的压缩策略；

根据所有数据量与各自对应的压缩策略得到所述数据量与压缩策略之间的对应关系。

5.如权利要求1所述的方法，其特征在于，根据设定的数据量与压缩策略之间的对应关系，确定所述故障数据包对应的压缩策略，包括：

根据所述故障数据包的数据量，以及设定的数据量与压缩策略之间的对应关系，确定出使得所述故障数据包的传输效率最高的压缩策略。

6.如权利要求1所述的方法，其特征在于，根据确定的压缩策略中指示的压缩次数以及每一次压缩对应的压缩方法对所述故障数据包进行多次压缩，得到压缩数据包，包括：

根据每一次压缩时的数据量对所述故障数据包进行多次压缩，直至最终获得的压缩数据包满足设定的压缩终止条件；其中，每一次压缩过程包括如下过程：

根据输入数据包的数据量确定对应的压缩方法；其中，当为第一次压缩时，所述输入数据包为所述故障数据包；或者，当不是第一次压缩时，所述输入数据包为上一次压缩过程得到的压缩数据包；

通过确定的压缩方法对所述输入数据包进行压缩；

确定压缩得到的数据包是否满足设定的压缩终止条件；

若确定压缩得到的数据包满足设定的压缩终止条件，则压缩过程结束；或者，若确定压缩得到的数据包不满足设定的压缩终止条件，则进入下一次压缩过程。

7.如权利要求1所述的方法，其特征在于，在将所述压缩数据包传输至后台服务器之前，所述方法还包括：

根据本地方法库中的加密方法对所述压缩数据包进行加密处理，获取加密后的压缩数据包；

将所述压缩数据包传输至后台服务器，包括：

将所述加密后的压缩数据包传输至所述后台服务器。

8.一种故障数据传输方法，其特征在于，所述方法包括：

接收智能家居设备发送的故障数据上传请求；所述故障数据上传请求携带由所述智能家居设备的故障数据包压缩后得到的压缩数据包以及指示对所述故障数据包进行压缩时采用的压缩策略的指示信息；

根据所述指示信息确定所述压缩数据包对应的解压策略；所述解压策略包括解压次数以及每一次解压采用的解压方法；所述压缩策略是各个设定数据量所对应的多种压缩效率最高的压缩方法进行级联组合得到的；

根据确定的解压策略中指示的解压次数以及每一次解压对应的压缩方法对所述压缩数据包进行多次解压，得到所述故障数据包；

基于所述故障数据包获取所述智能家居设备的故障数据。

9.一种故障数据传输装置，其特征在于，所述装置包括：

获取单元，用于获取待传输的故障数据包；

确定单元，用于根据设定的数据量与压缩策略之间的对应关系，确定所述故障数据包对应的压缩策略；其中，所述压缩策略包括数据包传输时所需压缩次数以及每一次压缩所采用的压缩方法；所述压缩策略是各个设定数据量所对应的多种压缩效率最高的压缩方法进行级联组合得到的；

压缩单元，用于根据确定的压缩策略中指示的压缩次数以及每一次压缩对应的压缩方法对所述故障数据包进行多次压缩，得到压缩数据包；

传输单元，用于将所述压缩数据包传输至后台服务器。

10.一种故障数据传输装置，其特征在于，所述装置包括：

接收单元，用于接收智能家居设备发送的故障数据上传请求；所述故障数据上传请求携带由所述智能家居设备的故障数据包压缩后得到的压缩数据包以及指示对所述故障数据包进行压缩时采用的压缩策略的指示信息；

确定单元，用于根据所述指示信息确定所述压缩数据包对应的解压策略；所述解压策略包括解压次数以及每一次解压采用的解压方法；所述压缩策略是各个设定数据量所对应的多种压缩效率最高的压缩方法进行级联组合得到的；

解压单元，用于根据确定的解压策略中指示的解压次数以及每一次解压对应的压缩方法对所述压缩数据包进行多次解压，得到所述故障数据包；

获取单元，用于基于所述故障数据包获取所述智能家居设备的故障数据。

11.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，

所述处理器执行所述计算机程序时实现权利要求1至8任一项所述方法的步骤。

12.一种计算机存储介质，其上存储有计算机程序指令，其特征在于，

该计算机程序指令被处理器执行时实现权利要求1至8任一项所述方法的步骤。

Images