Upgrading method based on dynamic type identification code of air conditioner
By building a hardware compatibility tree and upgrading the package tree structure, the problem of matching the upgrade package after the air conditioner MCU is replaced is solved, and a rapid search of compatible upgrade packages is realized to ensure the successful upgrade of the air conditioner.
Patent Information
- Application Number
- CN202510548362.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-28
- Publication Date
- 2025-08-19
AI Technical Summary
After the air conditioner is replaced with the MCU, the upgrade package sent by the cloud server cannot match the replaced MCU model, resulting in the upgrade failure.
Build a hardware compatible tree structure and upgrade package tree structure, read the hardware feature data of the air conditioner through mobile terminal devices, check the model identification code of the cloud server and query the hardware compatible tree structure and upgrade package tree structure to ensure that the adaptive compatible upgrade package is sent.
It realizes the rapid search of compatible upgrade packages after MCU replacement, avoiding upgrade failures, and improving upgrade efficiency and accuracy.
Smart Images

Figure CN120508305A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of air conditioner upgrade optimization, and in particular relates to an upgrade method based on a dynamic model identification code of an air conditioner. Background Art
[0002] The air conditioner includes an indoor controller and an outdoor controller. The MCU model of the air conditioner is fixed when it leaves the factory, so the MCU model corresponds to a fixed model identification code. When the air conditioner is upgraded online, the mobile terminal device used in conjunction with the air conditioner can request an online upgrade from the cloud server through the fixed model identification code. The cloud server sends the corresponding upgrade package to the air conditioner based on the fixed model identification code, so that the indoor controller or the outdoor controller can perform the corresponding upgrade operation.
[0003] With long-term use of the air conditioner, when the air conditioner needs to be repaired, if the indoor controller or outdoor controller needs to be replaced to meet the repair conditions, the maintenance personnel may replace the indoor controller or outdoor controller with another MCU model for maintenance cost considerations or if the maintenance personnel are not from the original air conditioner manufacturer, resulting in a different MCU model for the air conditioner. When an upgrade is needed later, the mobile terminal device will still request an online upgrade from the cloud server based on the previous fixed model identification code, resulting in the upgrade package sent by the cloud server to the air conditioner being unable to match the replaced MCU model, causing the air conditioner upgrade to fail. Therefore, based on the above problem, it is necessary to optimize the way the air conditioner is upgraded based on the model identification code. Summary of the Invention
[0004] In response to the problems raised in the background technology, the present invention proposes an upgrade method based on a dynamic model identification code of an air conditioner.
[0005] To achieve this object, the present invention adopts the following technical solutions:
[0006] An upgrade method based on a dynamic model identification code of an air conditioner comprises the following steps: A) constructing a hardware compatibility tree structure based on hardware feature data of MCUs of air conditioners of different models, and constructing an upgrade package tree structure based on compatible upgrade packages of MCUs of air conditioners of different models;
[0007] Associating the hardware compatibility tree structure with the upgrade package tree structure;
[0008] Step B: constructing a model identification code based on the hardware feature data, the mobile terminal device initiates an upgrade request to the air conditioner main control board, and the air conditioner main control board reads the model identification code of the air conditioner MCU and sends it to the mobile terminal device;
[0009] Step C: The mobile terminal device initiates an upgrade package download request to the cloud server based on the model identification code. The cloud server verifies whether the model identification code is consistent with the pre-stored identification code. If so, the cloud server sends the original upgrade package to the air conditioner, and the air conditioner performs the upgrade operation according to the original upgrade package. If not, step D is executed.
[0010] Step D: The cloud server queries the hardware compatibility tree structure based on the model identification code to see whether corresponding hardware feature data exists. If so, the cloud server searches the upgrade package tree structure based on the hardware feature data to obtain a compatible upgrade package. The cloud server sends the compatible upgrade package to the air conditioner, and the air conditioner performs an upgrade operation based on the compatible upgrade package.
[0011] If it does not exist, the cloud server will feedback the upgrade error information to the mobile terminal device.
[0012] Preferably, in step A, a hardware compatibility tree structure is constructed based on hardware feature data of air conditioner MCUs of different models, including:
[0013] Step A1: Acquire hardware feature data of air conditioner MCUs of different models, the hardware feature data including a firmware compatibility identifier, an air conditioner MCU model, and a version number of each air conditioner MCU model;
[0014] Step A2: Constructing a hardware compatibility tree structure, including establishing a corresponding number of second-layer nodes according to the number of firmware compatibility identifiers, each second-layer node storing a firmware compatibility identifier;
[0015] According to the number of air conditioner MCU models corresponding to each firmware compatibility identifier, a corresponding number of third-layer nodes are established for each second-layer node, and each third-layer node stores an air conditioner MCU model;
[0016] According to the number of version numbers of each air conditioner MCU model, a corresponding number of fourth-layer nodes are established for each third-layer node, and each fourth-layer node stores a version number of an air conditioner MCU model.
[0017] Preferably, in step A, constructing an upgrade package tree structure based on compatible upgrade packages of air conditioner MCUs of different models includes:
[0018] Step a1: Establish a corresponding number of second-layer nodes according to the number of compatible upgrade packages. Each second-layer node stores a common compatible upgrade package. The common compatible upgrade package indicates that air conditioner MCUs of the same model but different versions, or air conditioner MCUs of different models but the same version, or air conditioner MCUs of different models but different versions are all compatible for use.
[0019] Step a2: Among all version numbers, the maximum value N of the main version number 主max Determine the number of levels L in the upgrade package tree structure, where L = N 主max +2, N 主max ≥1;
[0020] Step a3: Determine the number of nodes in the Lth layer according to the type of the air conditioner MCU model and the sub-version number value of the version number, where: i represents the type of air conditioner MCU model, M represents the number of nodes in the Lth layer, Indicates the minor version number value of the version number of the i-th air conditioner MCU model, n indicates that there are n types of air conditioner MCU models, and the minor version number value is 0;
[0021] Step a4: Change the main version number value of all models to N at different levels of the upgrade package tree structure. 主 =1 is stored in the nodes of the third layer, and the main version number value N of different machine models is stored in the nodes of the third layer. 主 =2 is stored in the nodes of the fourth layer, and the main version number value N of different machine models is 主 =3 is stored in the node at level 5, and so on;
[0022] In the same level of the upgrade package tree structure, the version numbers are stored in ascending order of the minor version number value in the nodes from left to right. The nodes corresponding to the version numbers of the same type of machine model are adjacent to each other.
[0023] In the current level, any node containing the version number of a machine model of the same type is selected as the root node of all nodes corresponding to the version numbers of the machine model of the same type in the next level.
[0024] Preferably, if there is no node in the current level containing the version number of the same type of machine model that can serve as the root node of the nodes corresponding to all version numbers of the same type of machine model in the next level, a virtual root node is established in the current level and used as the root node of the nodes corresponding to all version numbers of the same type of machine model in the next level, and the virtual root node stores an empty value.
[0025] Preferably, before performing step B, the process includes:
[0026] Step B1: Adding a non-volatile memory to the air conditioner to store hardware feature data of the air conditioner MCU. When the air conditioner MCU is replaced, the hardware feature data of the new MCU is stored in the non-volatile memory. When the air conditioner MCU is not replaced, the non-volatile memory does not need to store the hardware feature data of the original air conditioner MCU.
[0027] Step B2: Set a static code area and a dynamic code area for the model identification code. When the original air conditioner MCU has not been replaced, the model identification code corresponding to the original air conditioner MCU model is used as the static code in the static code area, and the dynamic code in the dynamic code area is set to a null value.
[0028] When the MCU of the original air conditioner is replaced, the hardware feature data in the non-volatile memory is read, and the hardware feature data of the new air conditioner MCU is written into the dynamic code area as a dynamic code.
[0029] Preferably, in step C, the cloud server verifies whether the model identification code is consistent with the pre-stored identification code, including:
[0030] The cloud server reads the static code and the dynamic code of the model identification code. When the dynamic code is a null value, the model identification code is consistent with the pre-stored identification code. When the dynamic code is a non-null value, the model identification code is inconsistent with the pre-stored identification code.
[0031] Preferably, in said step D, it includes:
[0032] Step D1: When the cloud server reads the dynamic code of the model identification code and finds a non-null value, the cloud server parses the dynamic code to obtain the firmware compatibility identifier, the air conditioner MCU model and the version number of the air conditioner MCU model;
[0033] Step D2: Querying the hardware compatibility tree structure to determine whether the parsed firmware compatibility identifier, air conditioner MCU model, and air conditioner MCU model version number exist; if so, executing step D3; if not, generating an upgrade error message on the cloud server and feeding it back to the mobile terminal device;
[0034] Step D3: In the upgrade package tree structure, check whether there are multiple nodes corresponding to the version number of the air conditioner MCU model. If not, traverse backward to the node corresponding to the second layer based on the location of the branch where the node corresponding to the version number of the air conditioner MCU model is located, and send the shared compatible upgrade package stored in the node corresponding to the second layer to the air conditioner;
[0035] If it exists, find the node corresponding to the version number of the air conditioner MCU model with a non-empty value, and traverse back to the node corresponding to the second layer according to the position of the branch where the node with the non-empty value is located, and send the shared compatible upgrade package stored in the node corresponding to the second layer to the air conditioner.
[0036] The beneficial effects of the present invention compared to the prior art are as follows:
[0037] 1. The present invention ensures that the mobile terminal device does not use the model identification code of the MCU before the replacement to request the upgrade package by adding a step in which the air conditioner reads the hardware feature data before the mobile terminal device requests the upgrade package from the cloud server;
[0038] 2. The present invention sets the model identification code as a static code and a dynamic code, and adds a link for the cloud server to identify the dynamic code to determine whether to replace the MCU, ensuring that the original upgrade package of the MCU before the replacement will not be sent to the air conditioner;
[0039] 3. The present invention sets up a hardware compatibility tree structure and an upgrade package tree structure, and uses the read hardware feature data to query whether there is an adapted compatible model in the hardware compatibility tree structure to determine whether there is a compatible upgrade package. At the same time, the unique design structure of the upgrade package tree structure is used to achieve the effect of quickly finding the corresponding compatible upgrade package based on the hardware feature data. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] Figure 1 This is a flowchart of the upgrade sequence based on the dynamic model code of the air conditioner of the present invention;
[0041] Figure 2 is a schematic diagram of a hardware compatibility tree structure according to an embodiment of the present invention;
[0042] Figure 3 This is a schematic diagram of the upgrade package tree structure according to an embodiment of the present invention;
[0043] Figure 4 It is a schematic diagram of an upgrade package tree structure (including a virtual root node) according to another embodiment of the present invention. DETAILED DESCRIPTION
[0044] The technical solution of the present invention will be further described below with reference to the accompanying drawings and through specific implementation methods.
[0045] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.
[0046] The terms "first," "second," and so on, in the description and claims of the present invention and the accompanying drawings are used to distinguish between different items, not to describe a specific order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or end comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed therein, or may optionally include other steps or elements inherent to such process, method, product, or end.
[0047] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute a separate or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0048] In existing applications, when an air conditioner is replaced with a different MCU model, the mobile terminal device associated with the air conditioner, due to inertia, still uses the model identification code of the previous MCU to request an upgrade package from the cloud server. As a result, the cloud server still sends the upgrade package that matches the previous MCU to the air conditioner, resulting in a mismatch between the upgrade package and the replaced MCU, leading to upgrade failure. To solve the above problem, this application proposes an upgrade method based on the dynamic model identification code of the air conditioner, which specifically includes:
[0049] Step A: constructing a hardware compatibility tree structure based on the hardware feature data of the air conditioner MCUs of different models, and constructing an upgrade package tree structure based on the compatible upgrade packages of the air conditioner MCUs of different models;
[0050] Associating the hardware compatibility tree structure with the upgrade package tree structure;
[0051] In this embodiment, the key to solving the above problem lies in that after the mobile terminal device sends a new model identification code to the cloud server, the cloud server needs to perform two operations after recognizing it as a new model identification code: one is to check whether a compatible upgrade package that can adapt to the new MCU model is stored in the database, and the other is to quickly find the corresponding compatible upgrade package in the database based on the new model identification code and send it to the air conditioner to improve upgrade efficiency. Based on these two operations, this application proposes to construct a hardware compatibility tree structure and an upgrade package tree structure. The hardware compatibility tree structure is used by the cloud server to query whether a compatible upgrade package is stored. Through the association between the hardware compatibility tree structure and the upgrade package tree structure, the corresponding compatible upgrade package can be quickly found in the upgrade package tree structure.
[0052] Preferably, in step A, a hardware compatibility tree structure is constructed based on hardware feature data of air conditioner MCUs of different models, including:
[0053] Step A1: Acquire hardware feature data of air conditioner MCUs of different models, the hardware feature data including a firmware compatibility identifier, an air conditioner MCU model, and a version number of each air conditioner MCU model;
[0054] Step A2: Constructing a hardware compatibility tree structure, including establishing a corresponding number of second-layer nodes according to the number of firmware compatibility identifiers, each second-layer node storing a firmware compatibility identifier;
[0055] According to the number of air conditioner MCU models corresponding to each firmware compatibility identifier, a corresponding number of third-layer nodes are established for each second-layer node, and each third-layer node stores an air conditioner MCU model;
[0056] According to the number of version numbers of each air conditioner MCU model, a corresponding number of fourth-layer nodes are established for each third-layer node, and each fourth-layer node stores a version number of an air conditioner MCU model.
[0057] In actual applications, each air conditioner MCU manufacturer will publish a compatibility table of the MCUs that can be adapted for different models of their own. The compatibility table will show whether different versions of MCUs of different models are compatible through the firmware compatibility mark. For example, for different versions of the same model MCU, if there is the same firmware compatibility mark, it means that different versions of the same model MCU are compatible with each other. For example, if the V1.0 and V2.0 versions of a certain model MCU have the same firmware compatibility mark, it means that the two versions of MCU are compatible with each other and have little difference in function. If the two versions have different firmware compatibility marks, it means that the two versions of MCU are incompatible, with too large a difference in function or performance, and are cross-version MCUs. For example, if two MCUs, model A's V1.0 version and model B's V2.0 version, have the same firmware compatibility identifier in different versions of these two models, they are also considered to be compatible with each other. For manufacturers, the publicly available compatibility table will not only show the compatibility between their own MCUs of different models and versions, but also the compatibility and adaptability between their own MCUs and MCUs from other manufacturers. Therefore, for industry specifications, by collecting the compatibility tables of MCUs of different models and versions produced by different manufacturers and then reassembling them, we can use the firmware compatibility identifier to determine the compatibility between MCUs of the same model but different versions, or MCUs of different models with the same version, or MCUs of different models but different versions, and pre-prepare common upgrade packages that these MCUs can adapt to based on compatibility.
[0058] Based on the relevant contents of the compatibility table disclosed in the above prior art, the hardware compatibility tree structure constructed in this embodiment is specifically operated as follows:
[0059] First, by obtaining MCU compatibility tables between different manufacturers and deduplicating the compatibility tables, hardware feature data of MCUs of different models and versions can be obtained. In this embodiment, the hardware feature data can be understood as the firmware compatibility identifier, the air conditioner MCU model and the version number of each air conditioner MCU model; then, a multi-branch tree structure is constructed, and the first-level root node of the multi-branch tree structure is used to represent that the tree structure is an MCU hardware compatibility set. Starting from the second level of the multi-branch tree, the second-level nodes are used to store the firmware compatibility identifier. The number of nodes in the second level is determined according to the number of firmware compatibility identifiers. In the third level, the number of nodes in the third level is determined according to the number of all types of MCU models collected. Each node in the third level stores one type of MCU. The third-level nodes corresponding to different types of MCU models belonging to the same firmware compatibility identifier are used as child nodes of the node in the second level where the corresponding firmware compatibility identifier is located. Similarly, all version numbers of all types of MCUs are stored in the nodes of the fourth level, and the fourth-level nodes corresponding to different version numbers of MCUs belonging to the same type of MCU are used as child nodes of the node corresponding to the type of MCU in the third level, thereby establishing a hardware compatibility tree structure. Specifically, the hardware compatibility tree structure can be embodied in the following embodiments: Figure 2 As shown, the second-level nodes of the hardware compatibility tree store three firmware compatibility identifiers FW, AC, and KFR35GW. The third-level nodes store five different MCU models: A, B, C, D, and E. Among them, model A and model B belong to the firmware compatibility identifier FW, model C belongs to the firmware compatibility identifier AC, and model D and model E belong to the firmware compatibility identifier KFR35GW. This means that model A and model B are compatible with each other, but not with other models, model D and model E are compatible with each other, but not with other models, and model C has no other compatible models. In the fourth-level nodes, model A has two versions V1 .0 and V2.0, model B has two versions V1.0 and V1.2, model C has one version V2.0, model D has one version V3.0, and model E has one version V2.1. This means that the two versions of model A are compatible with each other, and the two versions of model B are compatible with each other. At the same time, since the two versions of model A and model B belong to the same firmware compatibility mark FW, a total of 4 versions of model A and model B are compatible with each other. Similarly, version V3.0 of model D and version V2.1 of model E belong to the same firmware compatibility mark KFR35GW, so these two versions are compatible with each other.
[0060] Preferably, in step A, constructing an upgrade package tree structure based on compatible upgrade packages of air conditioner MCUs of different models includes:
[0061] Step a1: Establish a corresponding number of second-layer nodes according to the number of compatible upgrade packages. Each second-layer node stores a common compatible upgrade package. The common compatible upgrade package indicates that air conditioner MCUs of the same model but different versions, or air conditioner MCUs of different models but the same version, or air conditioner MCUs of different models but different versions are all compatible for use.
[0062] Step a2: Among all version numbers, the maximum value N of the main version number 主max Determine the number of levels L in the upgrade package tree structure, where L = N 主max +2, N 主max ≥1;
[0063] Step a3: Determine the number of nodes in the Lth layer according to the type of the air conditioner MCU model and the sub-version number value of the version number, where: i represents the type of air conditioner MCU model, M represents the number of nodes in the Lth layer, Indicates the minor version number value of the version number of the i-th air conditioner MCU model, n indicates that there are n types of air conditioner MCU models, and the minor version number value is 0;
[0064] Step a4: Change the main version number value of all models to N at different levels of the upgrade package tree structure. 主 =1 is stored in the nodes of the third layer, and the main version number value N of different machine models is stored in the nodes of the third layer. 主 =2 is stored in the nodes of the fourth layer, and the main version number value N of different machine models is 主 =3 is stored in the node at level 5, and so on;
[0065] In the same level of the upgrade package tree structure, the version numbers are stored in ascending order of the minor version number value in the nodes from left to right. The nodes corresponding to the version numbers of the same type of machine model are adjacent to each other.
[0066] In the current level, any node containing the version number of a machine model of the same type is selected as the root node of all nodes corresponding to the version numbers of the machine model of the same type in the next level.
[0067] The previous article explained how to build a hardware compatibility tree structure. From the hardware compatibility tree structure, we can see that MCUs of the same model but different versions, MCUs of different models but the same version, and MCUs of different models but different versions with the same firmware compatibility identifier are compatible with each other or have a high degree of compatibility. For MCUs with the same firmware compatibility identifier, the same compatible upgrade package can be developed. That is, the compatible upgrade package can be adapted to all MCUs with the same firmware compatibility identifier. Based on this, a corresponding number of shared compatible upgrade packages can be developed in advance.
[0068] Furthermore, the upgrade package tree structure depends on the industry naming convention design of the version number. In the industry, the first digit of the version number is the prefix V, which represents the abbreviation of the English version. The second digit is the major version number value. The major version number value indicates when there are major changes in the functional modules, such as adding modules or changes in the overall architecture; the third digit is the minor version number value. The minor version number value indicates when there are certain additions or changes in the functions, such as adding functions such as permission control; the fourth digit is the revision number value, which is generally a bug fix or some minor changes. Revisions should be released frequently with no time limit. A revision can be released after fixing a serious bug; the fifth digit is the date version number value, which is used to record the current date of the modified project. Every day, the modification of the project requires changing the date version number. The sixth digit is the Greek letter version number value. There are five types of Greek letter version numbers, namely base, alpha, beta, RC, and release. The first three Greek letter versions represent test The RC version indicates that the version is quite mature and basically does not have any bugs that cause errors. It is almost the same as the official version to be released. The release version indicates the delivery version, that is, the final version for users to use, sometimes also called the standard version. For example, a version number is: V1.0.0.20241028_release, the major version number value is 1, the minor version number value is 0, the revision version number value is 0, the date version number value is 20241028, and the Greek version number value is release, which means that this version is the standard version and the final version delivered to users for use. In this embodiment, we only use the major version number value and the minor version number value to construct the upgrade package tree structure. Because the revision version number value indicates the revision, and the functions of the revision will not be greatly adjusted, the main factor affecting functional compatibility is the major version number and the minor version number. For the Greek version number, the manufacturer's publicly available compatibility table generally refers to the delivery version, so it is not very useful for reference. It should be noted that the version number described in this embodiment is the same as the version number stored in the node of the last layer in the hardware compatibility tree structure.
[0069] Based on the above explanation of version numbers, building an upgrade package tree structure includes building another multi-tree structure. The first-level root node of the multi-tree structure also represents that this tree structure is a set of compatible upgrade packages. In the second-level nodes, a corresponding number of nodes are configured according to the number of compatible upgrade packages, and each second-level node stores a shared compatible upgrade package. Starting from the third level, we need to determine how many levels the upgrade package tree structure needs to be configured. The number of levels can be determined by removing the maximum value of the main version number from all version numbers. For example, all version numbers have 3 versions, such as V1.0.0.20241028_re lease, V2.0.0.20241028_release, V3.0.0.20241028_release, then the largest major version number value is 3, then we need to build a total of L=3+2=5 layers of nodes. The first layer represents the root node, the second layer is used to store compatible upgrade packages, the third layer is used to store all version numbers with a major version number value of 1, the fourth layer is used to store all versions with a major version number value of 2, and the fifth layer is used to store all versions with a major version number value of 3. Determining the hierarchical structure by the major version number value will help subsequent traversal search queries and other operations.
[0070] Furthermore, in order to facilitate the explanation of the present technical solution, the version numbers involved below are all reflected in the sub-version number value, and the following digits of the version number value will not be additionally reflected; starting from the third layer, each layer needs to determine the number of nodes for subsequent storage of version numbers. In this embodiment, for example, according to the firmware compatibility identifiers FW and AC, the A model V1.0 version, V1.1 version and the B model V1.1 version, V2.0 version and V2.1 version all belong to the FW firmware compatibility identifier, that is, they share a compatible upgrade package; the C model V1.0 version, V2.0 version and the D model V2.0 version all belong to the AC firmware compatibility identifier, that is, they share another compatible upgrade package. Then, if Figure 3 As shown, the upgrade package tree structure needs to build L=N 主max+2=2+2=4, the upgrade package needs to build 4 layers of nodes, the second layer has 2 nodes, which are used to store the compatible upgrade packages corresponding to FW and AC respectively, the third layer is used to store all version numbers with a major version value of 1 in the four models A, B, C, and D, and the fourth layer is used to store all version numbers with a major version value of 2 in the four models A, B, C, and D; the calculation of the number of nodes in the third layer includes the minor version values of 0 and 1 for model A, the minor version value of 1 for model B, and the minor version value of 0 for model C. Model D only has version V2.0 and no version number with a major version value of 1, but because the major version value of V2.0 is 2, it needs to be stored in the nodes of the fourth layer, so we need to create a virtual node in the nodes of the third layer. The virtual node serves as the root node of the V2.0 version of model D. At the same time, since the minor version number values of model A and model C are both 0, n=2, and the number of nodes in the third layer is M=0+1(model A)+1(model B)+0(model C)+1(number of virtual nodes of model D)+2(the minor version number values of model A and model C are 0, then n=2)=5. The number of nodes in the third layer is 5. Similarly, the calculation results show that there are 4 nodes in the fourth layer, which respectively store the V2.0 and V2.1 versions of model B, the V2.0 version of model C and the V2.0 version of model D; in the fourth layer, since model B and model A share the same compatible upgrade package, the node of model B in the fourth layer can arbitrarily select a node of model A in the third layer as the root node.
[0071] Within a given layer of nodes, all versions of the same model are prioritized for placement next to each other, sorted from left to right by the minor version number. By constructing the upgrade package tree structure and designing the node distribution described above, when the cloud server obtains a version number from the hardware compatibility tree structure, it simply locates the node containing the version number in the upgrade package tree structure and directly determines the second-level node in the branch where that node resides. This allows it to quickly find the corresponding compatible upgrade package without traversing other node branches.
[0072] Preferably, if there is no node in the current level containing the version number of the same type of machine model that can serve as the root node of the nodes corresponding to all version numbers of the same type of machine model in the next level, a virtual root node is established in the current level and used as the root node of the nodes corresponding to all version numbers of the same type of machine model in the next level, and the virtual root node stores an empty value.
[0073] In this embodiment, since the main version number value is used to determine which level of nodes the versions of different models are stored in, there may be a situation where different versions of the same model need to be adapted to different compatible upgrade packages. If the above establishment method is followed, there may be two nodes with the same version number in the upgrade package tree structure, which will disrupt subsequent searches and result in two compatible upgrade packages being searched out. Therefore, it is necessary to set a virtual root node, use the virtual root node to store null values, and store actual version number values in other nodes to solve this problem. Figure 4 As shown, for example, the V1.0 version of the C model needs to adapt to the compatible upgrade package corresponding to the firmware compatibility identifier FW, and the V2.0 version needs to adapt to the compatible upgrade package corresponding to the firmware compatibility identifier AC. In this way, we will build a virtual root node of the V1.0 version on the AC branch to associate with the V2.0 version, and build an actual V1.0 version on the FW branch. In this way, when the V1.0 version of the C model is used to query the upgrade package tree structure, two V1.0 version nodes will be found. You only need to determine which V1.0 version node has a non-empty value to find the corresponding compatible upgrade package.
[0074] Step B: constructing a model identification code based on the hardware feature data, the mobile terminal device initiates an upgrade request to the air conditioner main control board, and the air conditioner main control board reads the model identification code of the air conditioner MCU and sends it to the mobile terminal device;
[0075] In this embodiment, after the mobile terminal device initiates an upgrade request to the air conditioner main control board, we add a link, that is, the air conditioner main control board will read the model identification code of the air conditioner MCU and send it to the mobile terminal device, to ensure that the mobile terminal device will not directly use the model identification code of the MCU before replacement to apply for the upgrade package from the cloud server.
[0076] Preferably, before performing step B, the process includes:
[0077] Step B1: Adding a non-volatile memory to the air conditioner to store hardware feature data of the air conditioner MCU. When the air conditioner MCU is replaced, the hardware feature data of the new MCU is stored in the non-volatile memory. When the air conditioner MCU is not replaced, the non-volatile memory does not need to store the hardware feature data of the original air conditioner MCU.
[0078] Step B2: Set a static code area and a dynamic code area for the model identification code. When the original air conditioner MCU has not been replaced, the model identification code corresponding to the original air conditioner MCU model is used as the static code in the static code area, and the dynamic code in the dynamic code area is set to a null value.
[0079] When the MCU of the original air conditioner is replaced, the hardware feature data in the non-volatile memory is read, and the hardware feature data of the new air conditioner MCU is written into the dynamic code area as a dynamic code.
[0080] In this embodiment, the air conditioner main control board reads the model identification code of the air conditioner before the mobile terminal device requests the upgrade package from the cloud server. Therefore, it is necessary to add a non-volatile memory, such as an EEPROM, in the air conditioner to store the hardware feature data of the MCU. In order to reduce the amount of reading by the air conditioner main control board and improve reading efficiency, if the original air conditioner MCU is used, the original air conditioner MCU will not be stored in the non-volatile memory. In this way, as long as the MCU is not replaced, the data read by the air conditioner main control board during each upgrade will be a null value. This ensures that the upgrade package is still requested from the cloud server using the original model identification code.
[0081] Furthermore, in order to solve the problem of changes in the model identification code after the MCU is replaced, the present application designs the model identification code into a static code area and a dynamic code area. The static code area is used to store the model identification code of the original air conditioner MCU, and the dynamic code area is used to store the hardware feature data of the replaced MCU. That is, if the MCU has always been the original and has not been replaced, the model identification code sent by the mobile terminal device to the cloud server is only the static code. After the MCU is replaced, it will become a model identification code that is a combination of the static code of the original MCU and the hardware feature data of the replaced MCU.
[0082] Step C: The mobile terminal device initiates an upgrade package download request to the cloud server based on the model identification code. The cloud server verifies whether the model identification code is consistent with the pre-stored identification code. If so, the cloud server sends the original upgrade package to the air conditioner, and the air conditioner performs the upgrade operation according to the original upgrade package. If not, step D is executed.
[0083] Preferably, in step C, the cloud server verifies whether the model identification code is consistent with the pre-stored identification code, including:
[0084] The cloud server reads the static code and the dynamic code of the model identification code. When the dynamic code is a null value, the model identification code is consistent with the pre-stored identification code. When the dynamic code is a non-null value, the model identification code is inconsistent with the pre-stored identification code.
[0085] In this embodiment, after the mobile terminal device initiates an upgrade package download request to the cloud server with the model identification code sent by the air conditioner main control board, the cloud server will verify whether the model identification code is consistent with the pre-stored identification code, that is, the cloud server will read the static code and dynamic code. If it is the original MCU, the dynamic code is an empty value, and there is only a static code. The static code is the pre-stored identification code. At this time, you only need to send the original upgrade package to the air conditioner; if the dynamic code read is a non-empty value, that is, the hardware feature data after replacement is read, you need to perform the operation of step D.
[0086] Step D: The cloud server queries the hardware compatibility tree structure based on the model identification code to see whether corresponding hardware feature data exists. If so, the cloud server searches the upgrade package tree structure based on the hardware feature data to obtain a compatible upgrade package. The cloud server sends the compatible upgrade package to the air conditioner, and the air conditioner performs an upgrade operation based on the compatible upgrade package.
[0087] If it does not exist, the cloud server will feedback the upgrade error information to the mobile terminal device.
[0088] Preferably, in said step D, it includes:
[0089] Step D1: When the cloud server reads the dynamic code of the model identification code and finds a non-null value, the cloud server parses the dynamic code to obtain the firmware compatibility identifier, the air conditioner MCU model and the version number of the air conditioner MCU model;
[0090] Step D2: Querying the hardware compatibility tree structure to determine whether the parsed firmware compatibility identifier, air conditioner MCU model, and air conditioner MCU model version number exist; if so, executing step D3; if not, generating an upgrade error message on the cloud server and feeding it back to the mobile terminal device;
[0091] Step D3: In the upgrade package tree structure, check whether there are multiple nodes corresponding to the version number of the air conditioner MCU model. If not, traverse backward to the node corresponding to the second layer based on the location of the branch where the node corresponding to the version number of the air conditioner MCU model is located, and send the shared compatible upgrade package stored in the node corresponding to the second layer to the air conditioner;
[0092] If it exists, find the node corresponding to the version number of the air conditioner MCU model with a non-empty value, and traverse back to the node corresponding to the second layer according to the position of the branch where the node with the non-empty value is located, and send the shared compatible upgrade package stored in the node corresponding to the second layer to the air conditioner.
[0093] In this embodiment, when the cloud server reads the dynamic code of the model identification code and finds a non-null value, it will obtain the firmware compatibility identifier of the replaced MCU, the air conditioner MCU model, and the version number of the air conditioner MCU model. Then, it will first determine whether the firmware compatibility identifier exists in the hardware compatibility tree structure. If not, it will feedback an upgrade error message. If it exists, it will continue to query whether the read air conditioner MCU model and version number are under the firmware compatibility identifier. If no MCU model or version number exists, it will also feedback an upgrade error message. If it exists, it will use the version number to search for the corresponding node in the upgrade package tree structure. If only one node is found, it will directly reversely traverse the branches of the node to find the compatible upgrade package stored in the second-level node. If multiple nodes exist, it is necessary to determine the null value of the node and find the node with a non-null value. The other null-value nodes are virtual root nodes. The branches of the non-null-value nodes are reversely traversed to find the compatible upgrade package stored in the second layer. It is sent to the air conditioner for upgrade.
[0094] The technical principles of the present invention have been described above with reference to specific embodiments. These descriptions are intended solely to illustrate the principles of the present invention and are not to be construed in any way as limiting the scope of protection of the present invention. Based on the explanations herein, those skilled in the art will readily conceive of other specific embodiments of the present invention without inventive effort, and such embodiments will fall within the scope of protection of the present invention.
Claims
1. An upgrade method based on a dynamic model identification code of an air conditioner, characterized by: Step A: constructing a hardware compatibility tree structure based on the hardware feature data of the air conditioner MCUs of different models, and constructing an upgrade package tree structure based on the compatible upgrade packages of the air conditioner MCUs of different models; Associating the hardware compatibility tree structure with the upgrade package tree structure; Step B: constructing a model identification code based on the hardware feature data, the mobile terminal device initiates an upgrade request to the air conditioner main control board, and the air conditioner main control board reads the model identification code of the air conditioner MCU and sends it to the mobile terminal device; Step C: The mobile terminal device initiates an upgrade package download request to the cloud server based on the model identification code. The cloud server verifies whether the model identification code is consistent with the pre-stored identification code. If so, the cloud server sends the original upgrade package to the air conditioner, and the air conditioner performs the upgrade operation according to the original upgrade package. If not, step D is executed. Step D: The cloud server queries the hardware compatibility tree structure based on the model identification code to see whether corresponding hardware feature data exists. If so, the cloud server searches the upgrade package tree structure based on the hardware feature data to obtain a compatible upgrade package. The cloud server sends the compatible upgrade package to the air conditioner, and the air conditioner performs an upgrade operation based on the compatible upgrade package. If it does not exist, the cloud server will feedback the upgrade error information to the mobile terminal device.
2. The upgrade method based on the dynamic model identification code of the air conditioner according to claim 1, characterized in that: In step A, a hardware compatibility tree structure is constructed based on the hardware feature data of the air conditioner MCUs of different models, including: Step A1: Acquire hardware feature data of air conditioner MCUs of different models, the hardware feature data including a firmware compatibility identifier, an air conditioner MCU model, and a version number of each air conditioner MCU model; Step A2: Constructing a hardware compatibility tree structure, including establishing a corresponding number of second-layer nodes according to the number of firmware compatibility identifiers, each second-layer node storing a firmware compatibility identifier; According to the number of air conditioner MCU models corresponding to each firmware compatibility identifier, a corresponding number of third-layer nodes are established for each second-layer node, and each third-layer node stores an air conditioner MCU model; According to the number of version numbers of each air conditioner MCU model, a corresponding number of fourth-layer nodes are established for each third-layer node, and each fourth-layer node stores a version number of an air conditioner MCU model.
3. The upgrade method based on the dynamic model identification code of the air conditioner according to claim 1, characterized in that: In step A, an upgrade package tree structure is constructed based on compatible upgrade packages of air conditioner MCUs of different models, including: Step a1: Establish a corresponding number of second-layer nodes according to the number of compatible upgrade packages. Each second-layer node stores a common compatible upgrade package. The common compatible upgrade package indicates that air conditioner MCUs of the same model but different versions, or air conditioner MCUs of different models but the same version, or air conditioner MCUs of different models but different versions are all compatible for use. Step a2: Among all version numbers, the maximum value N of the main version number 主max Determine the number of levels L in the upgrade package tree structure, where L = N 主max +2, N 主max ≥1; Step a3: Determine the number of nodes in the Lth layer according to the type of the air conditioner MCU model and the sub-version number value of the version number, where: i represents the type of air conditioner MCU model, M represents the number of nodes in the Lth layer, Indicates the minor version number value of the version number of the i-th air conditioner MCU model, n indicates that there are n types of air conditioner MCU models, and the minor version number value is 0; Step a4: Change the main version number value of all models to N at different levels of the upgrade package tree structure. 主 =1 is stored in the nodes of the third layer, and the main version number value N of different machine models is stored in the nodes of the third layer. 主 =2 is stored in the nodes of the fourth layer, and the main version number value N of different machine models is 主 =3 is stored in the node at level 5, and so on; In the same level of the upgrade package tree structure, the version numbers are stored in ascending order of the minor version number value in the nodes from left to right. The nodes corresponding to the version numbers of the same type of machine model are adjacent to each other. In the current level, any node containing the version number of a machine model of the same type is selected as the root node of all nodes corresponding to the version numbers of the machine model of the same type in the next level.
4. The method for upgrading an air conditioner based on a dynamic model identification code according to claim 3, characterized in that: If there is no node in the current level with the version number of the same type of machine model that can be used as the root node of the nodes corresponding to all version numbers of the same type of machine model in the next level, a virtual root node is established in the current level and used as the root node of the nodes corresponding to all version numbers of the same type of machine model in the next level. The virtual root node stores an empty value.
5. The upgrade method based on the dynamic model identification code of the air conditioner according to claim 4, characterized in that: Before executing step B, include: Step B1: Adding a non-volatile memory to the air conditioner to store hardware feature data of the air conditioner MCU. When the air conditioner MCU is replaced, the hardware feature data of the new MCU is stored in the non-volatile memory. When the air conditioner MCU is not replaced, the non-volatile memory does not need to store the hardware feature data of the original air conditioner MCU. Step B2: Set a static code area and a dynamic code area for the model identification code. When the original air conditioner MCU has not been replaced, the model identification code corresponding to the original air conditioner MCU model is used as the static code in the static code area, and the dynamic code in the dynamic code area is set to a null value. When the MCU of the original air conditioner is replaced, the hardware feature data in the non-volatile memory is read, and the hardware feature data of the new air conditioner MCU is written into the dynamic code area as a dynamic code.
6. The upgrade method based on the dynamic model identification code of the air conditioner according to claim 5, characterized in that: In step C, the cloud server verifies whether the model identification code is consistent with the pre-stored identification code, including: The cloud server reads the static code and the dynamic code of the model identification code. When the dynamic code is a null value, the model identification code is consistent with the pre-stored identification code. When the dynamic code is a non-null value, the model identification code is inconsistent with the pre-stored identification code.
7. The method for upgrading an air conditioner based on a dynamic model identification code according to claim 6, characterized in that: In said step D, it includes: Step D1: When the cloud server reads the dynamic code of the model identification code and finds a non-null value, the cloud server parses the dynamic code to obtain the firmware compatibility identifier, the air conditioner MCU model and the version number of the air conditioner MCU model; Step D2: Querying the hardware compatibility tree structure to determine whether the parsed firmware compatibility identifier, air conditioner MCU model, and air conditioner MCU model version number exist; if so, executing step D3; if not, generating an upgrade error message on the cloud server and feeding it back to the mobile terminal device; Step D3: In the upgrade package tree structure, check whether there are multiple nodes corresponding to the version number of the air conditioner MCU model. If not, traverse backward to the node corresponding to the second layer based on the location of the branch where the node corresponding to the version number of the air conditioner MCU model is located, and send the shared compatible upgrade package stored in the node corresponding to the second layer to the air conditioner; If it exists, find the node corresponding to the version number of the air conditioner MCU model with a non-empty value, and traverse back to the node corresponding to the second layer according to the position of the branch where the node with the non-empty value is located, and send the shared compatible upgrade package stored in the node corresponding to the second layer to the air conditioner.