Air conditioning apparatus and firmware upgrade method thereof

Abstract

This application relates to an air conditioning device and its firmware upgrade method, including a communication component, a main control component, and multiple upgradeable components. When a firmware upgrade instruction is received indicating that multiple target components should be upgraded, an upgrade queue is first formed based on the component identifier and upgrade priority of the target components. An upgrade duration is allocated to each target component in the queue. Then, according to the queue order, and provided that a target component is in an upgradeable state, the data packet transmission task for that target component is executed according to its upgrade duration. The upgrade data packet is transmitted to the target component according to the corresponding preset transmission parameters. This application, through serial scheduling and duration allocation, avoids collisions and conflicts of data packets on the bus caused by disordered contention, significantly improving data transmission efficiency and enabling the smooth execution of OTA upgrades for multiple components within the air conditioning device simultaneously.

Description

Technical Field

[0001] This application relates to the field of air conditioning control technology, and in particular to an air conditioning device and its firmware upgrade method. Background Technology

[0002] With the rapid development of IoT technology, OTA (Over-the-Air Technology) has become one of the important hallmarks of smart home appliances, and its wireless communication method and update speed have been widely recognized by users. Through product iterations, OTA technology can not only repair the functions of sold products but also innovate functions using existing hardware, bringing new experiences to users.

[0003] However, in related technologies, traditional OTA upgrade solutions are mostly designed for single components or adopt a mode where each component initiates and processes the upgrade independently. When a user initiates OTA upgrade requests for multiple components in the air conditioning equipment at the same time, the concurrently executed OTA tasks will compete for limited communication bus resources to transmit upgrade data packets, significantly reducing data transmission efficiency and even causing data packet loss, resulting in upgrade process failure or abnormal interruption. Summary of the Invention

[0004] This application provides an air conditioning device and its firmware upgrade method to solve the technical problem of task conflicts caused by the air conditioning device concurrently executing multiple OTA tasks and competing for limited communication bus resources to transmit upgrade data packets.

[0005] In a first aspect, some embodiments provide an air conditioning device, the air conditioning device comprising:

[0006] Multiple upgradeable components;

[0007] Communication components that communicate with user terminals and data servers;

[0008] The main control component is connected to the communication component and the plurality of the upgradeable components;

[0009] The main control component is configured as follows:

[0010] Obtain firmware upgrade instructions received through the communication component;

[0011] Parse the firmware upgrade command to determine the component identifiers of the multiple target components to be upgraded;

[0012] Based on the component identifier and the upgrade priority of each upgradeable component, an upgrade queue is formed, and each target component in the upgrade queue is assigned a corresponding upgrade duration.

[0013] According to the component order in the upgrade queue, when the target component is determined to be in an upgradeable state, a data packet transmission task is executed for the target component according to the upgrade duration of the target component; the data packet transmission task includes: according to the preset transmission parameters corresponding to the target component, transmitting the upgrade data packet of the target component obtained from the data server through the communication component to the target component.

[0014] The aforementioned air conditioning equipment includes a communication component, a main control component, and multiple upgradeable components. When a firmware upgrade command instructs the upgrading of multiple target components, an upgrade queue is first formed based on the component identifier and upgrade priority of the target components. An upgrade duration is allocated to each target component in the queue. Then, according to the queue order, and provided that a target component is in an upgradeable state, the data packet transmission task is executed according to its upgrade duration. The upgrade data packet is transmitted to the target component according to the corresponding preset transmission parameters. This application, through serial scheduling and duration allocation, avoids collisions and conflicts of data packets on the bus caused by disordered contention, significantly improving data transmission efficiency and enabling the smooth execution of OTA upgrades for multiple components within the air conditioning equipment simultaneously.

[0015] In one embodiment, the master control component is configured as follows:

[0016] Upon receiving data transmission completion information from the current target component, execute the data packet transmission task for the next target component in the upgrade queue;

[0017] If no data transmission completion information is received from the current target component and the corresponding upgrade time for the current target component has been reached, the data packet transmission task for the next target component in the upgrade queue is executed, and the current target component is added to the tail of the upgrade queue.

[0018] In one embodiment, the master control component is configured as follows:

[0019] Based on preset dynamic routing rules, the component identifier of the target component is mapped to the corresponding communication identifier;

[0020] A status query command is sent to the target component based on the communication identifier;

[0021] Receive response information from the target component in response to the status query instruction, wherein the response information includes at least the upgrade status information of the target component;

[0022] If the upgrade status information of the target component is in an idle state, the target component is determined to be in an upgradeable state.

[0023] In one embodiment, the master control component is configured as follows:

[0024] The upgrade data packet is converted according to a preset communication protocol and a preset communication baud rate to obtain upgrade message data.

[0025] Based on the communication identifier, the upgrade message data is sent to the target component, and the upgrade message data is used to instruct the target component to perform a firmware upgrade according to the received upgrade message data.

[0026] In one embodiment, the master control component is configured as follows:

[0027] Based on the component identifier, obtain the historical upgrade time of each target component;

[0028] Based on the historical upgrade time of the target components, a corresponding upgrade duration is allocated to each target component.

[0029] In one embodiment, the master control component is configured as follows:

[0030] The system obtains an upgrade registration instruction for the newly added component received through the communication component; the upgrade registration instruction carries a registration instruction code, verification data, and component parameter information of the newly added component.

[0031] If the registration instruction code and the verification data are verified to be correct, the newly added component will be identified as an upgradeable component.

[0032] In one embodiment, the master control component is configured as follows:

[0033] After the air conditioning equipment is powered on, a corresponding component identifier is generated for each upgradeable component based on a preset identifier generation rule, and the component identifiers of each upgradeable component are sent to the user terminal and the data server through the communication component.

[0034] In one embodiment, when arranged in descending order of upgrade priority, the upgradeable components include at least a display component, an indoor component, an outdoor component, a power component, and a voice component.

[0035] In one embodiment, the display component is connected to the damper drive mechanism;

[0036] The main control component is configured as follows:

[0037] Upon receiving the upgrade completion information from the display component, a damper reset trigger command with a damper zeroing step count is sent to the display component according to the communication identifier corresponding to the display component. The damper reset trigger command is used to instruct the display component to control the damper drive mechanism to perform a reset action based on the damper zeroing step count.

[0038] Receive the reset status information fed back by the display component, and perform reset verification based on the reset status information;

[0039] If the reset verification passes, the damper reset is confirmed to be complete.

[0040] Secondly, some embodiments also provide a firmware upgrade method for an air conditioning device, the firmware upgrade method comprising:

[0041] Retrieve firmware upgrade instructions received via the communication component;

[0042] Parse the firmware upgrade command to determine the component identifiers of the multiple target components to be upgraded;

[0043] Based on the component identifier and the upgrade priority of each upgradeable component, an upgrade queue is formed, and each target component in the upgrade queue is assigned a corresponding upgrade duration.

[0044] According to the component order in the upgrade queue, when the target component is determined to be in an upgradeable state, a data packet transmission task is executed for the target component according to the upgrade duration of the target component; the data packet transmission task includes: according to the preset transmission parameters corresponding to the target component, transmitting the upgrade data packet of the target component obtained from the data server through the communication component to the target component. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a schematic diagram of the structure of an air conditioning device in one embodiment;

[0047] Figure 2 This is a flowchart illustrating the process of registering a new component in one embodiment;

[0048] Figure 3 This is an interactive diagram illustrating the damper reset process in one embodiment;

[0049] Figure 4 This is a flowchart illustrating a firmware upgrade method for an air conditioning device in one embodiment.

[0050] Figure 5 This is a flowchart illustrating a firmware upgrade method for an air conditioning device in another embodiment;

[0051] Figure 6 This is a flowchart illustrating a firmware upgrade method for an air conditioning device in another embodiment;

[0052] Figure 7 This is a flowchart illustrating a firmware upgrade method for an air conditioning device in another embodiment;

[0053] Figure 8 This is a flowchart illustrating a firmware upgrade method for an air conditioning device in another embodiment;

[0054] Figure 9 This is a flowchart illustrating a firmware upgrade method for an air conditioning device in another embodiment;

[0055] Figure 10 This is a flowchart illustrating a firmware upgrade method for an air conditioning device in another embodiment. Detailed Implementation

[0056] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0057] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0058] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0059] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0060] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0061] As described in the background section, with the rapid development of IoT technology, OTA (Over-The-Air) updates have become a key feature of smart home appliances, and their wireless communication methods and update speeds have been widely recognized by users. Through product iterations, OTA technology can not only repair the functions of already sold products but also innovate functions using existing hardware, bringing new experiences to users.

[0062] However, in related technologies, traditional OTA upgrade solutions are mostly designed for single components or adopt a model where each component initiates and processes upgrades independently. When a user simultaneously initiates OTA upgrade requests for multiple components within an air conditioning unit, the existing distributed upgrade architecture exposes many inherent flaws:

[0063] 1. High communication bus collision rate: In scenarios where multiple components concurrently initiate OTA upgrade tasks, each component will compete for limited communication bus resources to transmit upgrade data packets. Due to the lack of a unified scheduling and management mechanism, this disorderly competition can easily lead to collisions and conflicts of data packets on the bus, significantly reducing data transmission efficiency and even causing data packet loss, resulting in upgrade process failure or abnormal interruption.

[0064] 2. Complex protocol compatibility and difficult development and maintenance: In air conditioning equipment where both the main control component and the display component have independent processing capabilities, each component needs to be individually integrated and adapted to multiple different communication and upgrade protocols to support its respective OTA process. This not only greatly increases the complexity of software development and code redundancy, but also makes subsequent protocol iterations, function expansions, and system maintenance extremely difficult and expensive.

[0065] Therefore, there is an urgent need to develop an air conditioning device that can solve the technical problem of task conflicts caused by air conditioning devices competing for limited communication bus resources to transmit upgrade data packets when executing multiple OTA tasks concurrently.

[0066] In one exemplary embodiment, an air conditioning device is provided, such as... Figure 1 As shown, the air conditioning equipment includes a communication component 110, a main control component 120, and multiple upgradeable components 130. The communication component 110 is communicatively connected to the user terminal 10 and the data server 20; the main control component 120 is connected to the communication component 110 and the multiple upgradeable components 130.

[0067] The communication component 110 is an interface module for data exchange between the air conditioning equipment and the external environment. It can be understood that the communication component 110 can be configured to support one or more wireless communication protocols and establish a bidirectional communication connection with the user terminal 10 and the data server 20.

[0068] In one example, the communication component 110 may support wireless communication protocols including but not limited to Wi-Fi, Bluetooth, ZigBee, and 4G / 5G cellular networks. The user terminal 10 may be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices may include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection devices. Portable wearable devices may include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays may include virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. The data server 20 may be a firmware distribution server in the cloud.

[0069] Upgradeable component 130 is a component within the air conditioning equipment that has independent functions and supports over-the-air firmware upgrades. In practical applications, the specific components included in upgradeable component 130 are not fixed and can be determined based on the specific circumstances of each component in the air conditioning equipment. New components can also be registered and added later during use. In one embodiment, upgradeable component 130 includes a display component 134, an indoor component, an outdoor component 131, a power component 132, and a voice component 133, etc.

[0070] The main control component 120 serves as the control center of the air conditioning equipment and is typically a microcontroller unit (MCU), microprocessor unit (MPU), or system-on-a-chip (SoC). The main control component 120, communication component 110, and all upgradeable components 130 are interconnected via an internal bus (such as a CAN bus, SPI bus, or Ethernet) or other dedicated communication links, forming a collaborative embedded system. The main control component 120 is responsible for coordinating and executing the entire OTA (Over-The-Air) process.

[0071] In one exemplary embodiment, please continue to refer to Figure 1 The main control component 120 is configured as follows:

[0072] Retrieve firmware upgrade instructions received via the communication component;

[0073] Parse the firmware upgrade command to determine the component identifiers of the multiple target components to be upgraded;

[0074] Based on the component identifier and the upgrade priority of each upgradeable component, an upgrade queue is formed, and each target component in the upgrade queue is assigned a corresponding upgrade duration.

[0075] According to the component order in the upgrade queue, and assuming the target component is in an upgradeable state, the data packet transmission task for the target component is executed sequentially according to the upgrade duration of the target component. The data packet transmission task includes: according to the preset transmission parameters corresponding to the target component, transmitting the upgrade data packet of the target component obtained from the data server through the communication component to the target component.

[0076] Specifically, the firmware upgrade instruction is an instruction to perform a firmware upgrade on one or more upgradeable components 130. During the execution of the above OTA process, the communication component 110 can be used to receive firmware upgrade instructions from the user terminal 10 or the data server 20, which can be triggered by the user through the application on the user terminal 10, or can be automatically issued by the data server 20 according to the upgrade policy.

[0077] The main control component 120 can capture firmware upgrade commands in real time by listening to the data interface of the communication component 110. This command can be a structured data message (such as JSON format or binary protocol) carrying the component identifier of the upgradeable component 130 to be upgraded. The main control component 120 can call its command parsing module to decrypt, verify the validity of, and analyze the content of the firmware upgrade command, extracting the component identifiers of the multiple target components to be upgraded.

[0078] It can be understood that the component identifier is a unique identifier possessed by each upgradeable component 130, used to accurately identify the corresponding upgradeable component 130. Furthermore, by parsing the firmware upgrade command, it can be determined which upgradeable components 130 need to be upgraded in this OTA process. Correspondingly, the number of target components to be upgraded that can be carried in the firmware upgrade command is not fixed; it can be one or multiple, depending on the specific circumstances of the firmware update. The embodiments in this application are explained and illustrated in the context of scenarios with multiple target components to be upgraded.

[0079] Furthermore, after determining which target components need to be upgraded in this OTA process, an upgrade queue needs to be formed based on the component identifier and the upgrade priority of each upgradeable component 130. This queue is then used to sequentially schedule the target components to transmit upgrade data packets using limited bus resources. The upgrade priority of each upgradeable component 130 is not fixed and can be set according to actual priority rules. For example, safety-critical components, such as indoor and outdoor components, can be set to the highest priority. Failures in components like compressors can cause equipment malfunctions, thus requiring firmware updates with the highest priority. Other function-dependent components can have lower priorities to minimize the impact of their upgrades on other components. User experience-related components can also have lower priorities.

[0080] It is understandable that a priority table can be pre-maintained in memory to represent the upgrade priority of each upgradeable component 130 for use by the main control component 120. In the priority table, each upgradeable component 130 can be assigned a corresponding upgrade priority weight to sort the upgradeable components 130 according to their upgrade priority. Correspondingly, the priority table also needs to contain the component identifier of each upgradeable component 130. Furthermore, when forming the upgrade queue, the main control component 120 looks up the parsed component identifier of the target component in the priority table to obtain the upgrade priority weight corresponding to each target component, and then sorts the target components from high to low according to the priority weight to generate the upgrade queue.

[0081] To ensure the overall transmission efficiency of upgrade data packets, the main control component 120 allocates corresponding upgrade durations to each target component in the upgrade queue. The data packet transmission task for each target component must be completed within its corresponding upgrade duration. For example, an upgrade duration table can be pre-maintained in memory to represent the upgrade duration of each upgradable component 130 for the main control component 120 to access. The upgrade duration table can set a corresponding upgrade duration for each upgradable component 130 and must also include the component identifier of the upgradable component 130. Then, after forming the upgrade queue, the main control component 120 allocates a fixed upgrade duration to each target component based on the upgrade duration table. The upgrade duration of each upgradable component 130 can be determined based on experience or calculation, sufficient to complete the transmission and preliminary verification of the component's upgrade data packets.

[0082] Before initiating the upgrade of each target component, the master control component 120 needs to confirm that the component is in an upgradeable state. This can be done by communicating with the target component to determine its upgradeability. For example, if the target component returns a response, it indicates that the upgrade can proceed; if the target component does not respond or returns a non-upgradeable response, it indicates that the upgrade cannot proceed. If any target component in the upgrade queue is in a non-upgradeable state, it is marked as skipped for this round, and the next target component in the queue is moved to. The skipped target component will be retried in subsequent rounds.

[0083] During the data packet transmission task phase, the master control component 120 must strictly follow the order of the upgrade queue and upgrade each target component one by one, executing the data packet transmission task for the target component according to the upgrade duration of the target component. The data packet transmission task includes: according to the preset transmission parameters corresponding to the target component, transmitting the upgrade data packet of the target component obtained from the data server 20 via the communication component 110 to the target component. It can be understood that after determining the component identifiers of multiple target components to be upgraded, the communication component 110 can download the encrypted or unencrypted upgrade data packet corresponding to the target component from the data server 20. Therefore, during the data packet transmission task phase, the master control component 120 must first obtain the downloaded upgrade data packet from the communication component 110 and then transmit it to the target component.

[0084] The preset transmission parameters are data transmission parameters predefined by each target component. These parameters may include, but are not limited to, communication baud rate, communication protocol, data block size, verification method, and number of retries. Based on these parameters, the master control component 120 segments, verifies, and reliably transmits the upgrade data packet obtained from the data server 20 to the target components.

[0085] The aforementioned air conditioning equipment includes a communication component, a main control component, and multiple upgradeable components. When a firmware upgrade command instructs the upgrading of multiple target components, an upgrade queue is first formed based on the component identifier and upgrade priority of the target components. An upgrade duration is allocated to each target component in the queue. Then, according to the queue order, and provided that a target component is in an upgradeable state, the data packet transmission task is executed according to its upgrade duration. The upgrade data packet is transmitted to the target component according to the corresponding preset transmission parameters. This application, through serial scheduling and duration allocation, avoids collisions and conflicts of data packets on the bus caused by disordered contention, significantly improving data transmission efficiency and enabling the smooth execution of OTA upgrades for multiple components within the air conditioning equipment simultaneously.

[0086] In one exemplary embodiment, please refer to Figure 1 The main control component 120 is configured as follows:

[0087] Upon receiving data transmission completion information from the current target component, execute the data packet transmission task for the next target component in the upgrade queue;

[0088] If no data transmission completion information is received from the current target component, and the corresponding upgrade time for the current target component has been reached, execute the data packet transmission task for the next target component in the upgrade queue, and add the current target component to the tail of the upgrade queue.

[0089] Specifically, during the data packet transmission phase, after the master control component 120 transmits the upgrade data packet of the target component to the target component, if the target component has completely received the upgrade data packet and verified it, the target component will send a confirmation message, namely, a data transmission completion message, back to the master control component 120. The data transmission completion message indicates that the target component has successfully received the upgrade data packet, and the firmware upgrade phase can proceed based on the upgrade data packet.

[0090] In one example, the data transmission completion information returned by the target component can be a short status code message or a checksum containing the data for secondary verification by the master component.

[0091] Furthermore, once the main control component 120 receives the data transmission completion information from the current target component, the queue scheduling module will immediately remove the current target component from the upgrade queue and unconditionally start the data packet transmission task for the next target component in the upgrade queue, thereby achieving seamless connection of the upgrade process.

[0092] In cases of poor network conditions, busy components, or corrupted data packets leading to multiple retransmissions, the upgrade time allocated to the current component may be exhausted. If the data transmission completion information from the current target component is not received by then, the data packet transmission task for the next target component in the upgrade queue needs to be executed, and the current target component is added to the tail of the upgrade queue.

[0093] Specifically, the timer module built into the main control component 120 continuously monitors the elapsed upgrade time of the current target component. When both of the following conditions are met simultaneously, the timeout handling logic is triggered: no data transmission completion information is received from the current target component, and the timer has reached the preset upgrade time for that target component. At this point, the main control component 120 immediately interrupts the current task, stops the current data packet sending thread, saves the transmitted progress, and then executes the data packet transmission task for the next target component in the upgrade queue. This ensures the strong progress of the entire upgrade queue.

[0094] At the same time, the main control component 120 will add the current target component that failed to upgrade to the tail of the upgrade queue, mark the OTA status of the component as upgrade failed or waiting for retry, so that the data packet transmission task will be re-executed after the target component ahead in the upgrade queue completes the data packet transmission task.

[0095] In this embodiment, the data packet transmission task of a single upgradeable component is strictly limited to its own time slice. If a transmission failure occurs, the entire process will not be affected, nor will a single point of stagnation cause a complete shutdown. By forcing process switching, it is ensured that the main control component is processing effective upgrade tasks in each time unit, thereby guaranteeing the efficiency and throughput of the entire upgrade process on a macro level.

[0096] In one exemplary embodiment, please refer to Figure 1 The main control component 120 is configured as follows:

[0097] Based on preset dynamic routing rules, the component identifier of the target component is mapped to the corresponding communication identifier;

[0098] Based on the communication identifier, send a status query command to the target component;

[0099] Receive the response information from the target component in response to the status query command. The response information shall include at least the upgrade status information of the target component.

[0100] If the upgrade status information of the target component is idle, the target component is determined to be in an upgradeable state.

[0101] Specifically, the main control component 120 can determine the communication address of the target component based on preset dynamic routing rules in order to issue a status query command to it.

[0102] The form of the preset dynamic routing rules is not unique. It can be calculated directly from the component identifier using a hash function or a specific encoding algorithm to determine the communication bus address. Alternatively, it can be a dynamic routing table maintained in memory, recording the mapping relationship between component identifiers and communication identifiers. In this embodiment, the preset dynamic routing rules are explained using a dynamic routing table. The mapping relationship of the dynamic routing table can be represented as database records, as shown in Table 1 below:

[0103] Table 1 Dynamic Routing Table

[0104]

[0105] Specifically, when communication with a target component is required, the main control component 120 calls the aforementioned dynamic routing table to perform a mapping process from component identifier to communication identifier, mapping the target component's component identifier to the corresponding communication identifier. It can be understood that the communication identifier is an instruction address that the hardware driver can directly recognize. This communication identifier is often represented as an instruction header in the communication frame structure, used to indicate a uniquely identified target component.

[0106] Before initiating a substantive upgrade data packet transmission, the master control component 120 can handshake with the target component to confirm that the target component is in an upgradeable state. Specifically, the network stack or communication driver of the master control component 120 uses the mapped communication identifier as the destination address to construct and send a short status query command. This command can be a dedicated command word (such as 0x11 to indicate a status query) and is sent through the corresponding physical interface (such as a UART or CAN transceiver).

[0107] After issuing a query command, the master control component 120 initiates a brief waiting period to listen for feedback from the target component. Upon receiving the query command, the target component immediately reads its current upgrade status information from its status register and encapsulates it into a response message, which is then returned. This upgrade status information includes at least the states of idle, upgrading in progress, and upgrading complete. In one example, the response message may also include the target component's software version information, allowing the master control component to determine if it is lower than the version of the upgrade data package to be upgraded, thus avoiding duplicate upgrades.

[0108] After receiving the target component's response to the status query command, the master control component 120 needs to decode the upgrade status information field in the response. Only when the parsed upgrade status information field is in an idle state does the master control component 120 determine that the target component is in an upgradeable state. Once upgradeable is determined, the master control component 120 then formally initiates the data packet transmission task to the target component.

[0109] In this embodiment, by performing a preliminary status check on the target component, it effectively prevents inevitable failures or task conflicts caused by blindly initiating an upgrade when the component is busy, faulty, or already undergoing an upgrade. Even if the target component is unresponsive or returns an error status, the master component can make the correct decision based on this criterion (such as marking it as unavailable or scheduling a retry), rather than freezing or crashing.

[0110] In one exemplary embodiment, please refer to Figure 1 The main control component 120 is configured as follows:

[0111] The upgrade data packets are converted based on the preset communication protocol and preset communication baud rate to obtain upgrade message data.

[0112] Based on the communication identifier, upgrade message data is sent to the target component. The upgrade message data is used to instruct the target component to perform a firmware upgrade based on the received upgrade message data.

[0113] Specifically, the upgrade data packets obtained from data server 20 are typically formatted to conform to higher-level network protocols (such as TCP / IP). However, the target components may reside on an internal bus network, requiring adherence to specific frame structures and verification rules. The default communication protocol is a multi-device addressing protocol, referring to the protocol used to transmit upgrade data packets to multiple different target components, typically an x-modem protocol.

[0114] The steps of protocol conversion processing for upgrade data packets based on a preset communication protocol can be understood as steps of data structure reconstruction for the data packets. Specifically, this may include adding frame headers and trailers, adding start bits, end bits, etc., to the original data according to the requirements of the preset communication protocol; embedding the target address, embedding the mapped communication identifier as the target address into the frame; calculating and appending a checksum, for example, calculating a CRC cyclic redundancy checksum for the entire data frame and appending it to the frame trailer to ensure data integrity during transmission; and serialization, which converts the structured upgrade data packets into a binary byte stream that can be transmitted over the line, i.e., the final upgrade message data.

[0115] In addition, before transmission, the main control component 120 initializes the physical interface (such as UART, CAN controller) for communication with the target component to a preset communication baud rate through its driver, so as to ensure that both parties can decode at the same speed at the physical signal level.

[0116] After the above process is completed, the encapsulated upgrade message data containing the target address (communication identifier) ​​can be sent to the target component through the correct hardware interface. The main control component 120 calls the sending interface to submit the upgrade message data to the corresponding hardware driver, which converts the data bit stream into a level signal at a preset communication baud rate and sends it to the bus. The target component continuously listens to the bus, and when it recognizes a frame that matches its communication identifier, it receives the frame. Then, it performs a firmware upgrade based on the received upgrade message data. The specific firmware upgrade process performed by the target component is not described in detail in this embodiment.

[0117] In one example, different upgradeable components have different permissions and therefore different preset communication baud rates. For instance, the display component has high real-time requirements, so its preset communication baud rate could be 115200bps. The voice component's preset communication baud rate could also be 115200bps. The outdoor component requires high reliability, so its preset communication baud rate could be 2400bps. The communication baud rate between the communication components and the main control component could be 115200bps.

[0118] In this embodiment, the master control component is specifically configured as a hub for protocol adaptation and data distribution. It is responsible for converting the raw upgrade data packets received from the data server by the upstream communication component into a format that the downstream target component can recognize and process, and then reliably transmitting them. Compared to the traditional architecture where both the display component and the master control component are used for data distribution, this significantly reduces the workload of protocol adaptation and development.

[0119] In one exemplary embodiment, please refer to Figure 1 The main control component 120 is configured as follows:

[0120] Based on the component identifier, obtain the historical upgrade time of each target component;

[0121] Based on the historical upgrade time of the target components, allocate corresponding upgrade durations to each target component.

[0122] Specifically, the memory can maintain an upgrade history table. Whenever a target component completes an upgrade, its actual upgrade time is recorded in this upgrade history table, and this data is associated with the component identifier of the corresponding target component. In other words, the source of the historical upgrade time data is the device's past OTA operation logs.

[0123] Furthermore, when allocating corresponding upgrade durations to each target component, the main control component 120 can access the upgrade history table and, based on the component identifier, match and retrieve the historical upgrade time of each target component from the upgrade history table. Specifically, the historical upgrade time can be the time taken for all successful upgrades in the component's history. The average time is then calculated based on these historical upgrade times and used as the upgrade duration for the target component. In some examples, when calculating the average based on these historical upgrade times, more recent upgrade records can be given higher weight to reflect the latest upgrade status of the target component. Additionally, for newly added components or components without historical records, a default upgrade duration can be used for allocation.

[0124] In this embodiment, the main control component is configured to perform personalized resource allocation based on historical data. By analyzing past upgrade performance, it allocates appropriate upgrade durations to different target components, thereby maximizing upgrade efficiency while ensuring system stability.

[0125] In one exemplary embodiment, please refer to Figure 1 The main control component 120 is configured as follows:

[0126] After the air conditioning equipment is powered on, based on the preset identification generation rules, a corresponding component identification is generated for each upgradeable component, and the component identification of each upgradeable component is sent to the user terminal and the data server through the communication component.

[0127] Specifically, after the air conditioning equipment is powered on, or after the air conditioning equipment is connected to the power supply and completes hardware initialization, the main control component can actively execute the identifier allocation process to dynamically generate the corresponding component identifier for each upgradeable component 130.

[0128] The specific method for generating the preset identifiers is not unique. It can be based on the component topology for sequential encoding. When the main control component 120 starts up, it scans the bus to detect all connected upgradeable components 130 and assigns them sequential numbers according to their enumeration order on the physical or logical bus. For example, if three upgradeable components 130 are detected, namely display component 134, voice component 133, and outdoor component 131, they can be assigned component identifiers of 0x01, 0x02, and 0x03, respectively.

[0129] Furthermore, after generating component identifiers for each upgradeable component 130, in order for the external user terminal 10 and data server 20 to correctly identify and locate these upgradeable components 130 within the air conditioning equipment, the component identifiers of each upgradeable component 130 need to be sent to the user terminal 10 and data server 20 via communication component 110. Specifically, the main control component 120 can encapsulate all generated component identifiers into a structured list, which is then sent to the user terminal 10 via communication component 110, allowing the user to view the component list corresponding to the component identifiers on the application of the user terminal 10. It can also be sent to the data server 20, enabling it to create or update the component list corresponding to this air conditioning equipment in its database.

[0130] In this embodiment, by dynamically generating component identifiers for upgradeable components, the drawbacks of fixed identifiers are overcome. There is no need to burn different identifier firmware for different batches or models of circuit boards. All boards of the same model can be completely interchangeable, reducing the complexity of production and maintenance.

[0131] In one exemplary embodiment, please refer to Figure 1The main control component 120 is configured as follows:

[0132] Obtain the upgrade registration instruction for the newly added component received through the communication component; the upgrade registration instruction carries the registration instruction code, verification data, and component parameter information of the newly added component;

[0133] If the registration command code and verification data are verified to be correct, the newly added component will be identified as an upgradeable component.

[0134] Specifically, the upgrade registration instruction is usually initiated by a user with advanced privileges (such as a technician from the manufacturer) through the user terminal 10, or automatically issued by the data server 20 based on changes in device configuration, for dynamically adding new upgradeable components 130 during the life cycle of the air conditioning equipment.

[0135] The upgrade registration command carries a registration command code, verification data, and component parameter information for the newly added component. The registration command code can be a predefined encrypted operation code used to identify the upgrade registration command as a legitimate registration request, rather than a erroneous or malicious command. The verification data is used to verify the integrity of the command and the authenticity of its source. The component parameter information for the newly added component indicates its specific details, which may include component type, hardware encoding, the highest supported protocol version, and applicable communication baud rate.

[0136] Furthermore, referring to Figure 2 Upon receiving the upgrade registration command, the main control component 120 does not immediately execute the registration but instead initiates an authentication and authorization process. First, it compares the registration command code in the upgrade registration command with the internally stored whitelist to confirm that it is a known and legitimate operation. Then, it performs data integrity verification based on the verification data. Only if both of these checks pass correctly does the main control component 120 officially designate the new component as an upgradeable component. Afterward, the main control component 120 can automatically generate a component identifier for the new component, add it to the upgradeable component list, and update the dynamic routing rules, enabling the component to be addressed and managed by subsequent OTA (Over-The-Air) processes.

[0137] In this embodiment, new components can be registered through an upgrade registration process, thereby enabling the scalability of the firmware upgrade function of the air conditioning equipment.

[0138] In one exemplary embodiment, please refer to Figure 1 When arranged in descending order of upgrade priority, the upgradeable components 130 include at least the display component 134, indoor component, outdoor component 131, power component 132, and voice component 133.

[0139] Specifically, display component 134 is the module responsible for rendering and controlling the human-machine interface. It can be understood that display component 134 is the primary window for users to perceive the status of the air conditioning equipment. If its firmware is corrupted or the version is incompatible, it may cause a black screen, garbled characters, or touch malfunction. Although this does not affect the core cooling function, it can lead users to misjudge the status of the air conditioning equipment. Therefore, display component 134 can be set to the highest upgrade priority to ensure its normal operation, and even if the upgrade fails, it will not affect the subsequent upgrades of core components.

[0140] The indoor unit is located inside the air conditioner's indoor unit and directly participates in the core environmental control functions. The outdoor unit 131 is located inside the air conditioner's outdoor unit and is responsible for the core heat exchange and compression functions. These two components are core components of the air conditioning equipment and can be set to secondary priority to ensure the normal operation of the air conditioning equipment's core functions. The power component 132 is a module responsible for monitoring, managing, and protecting the power consumption of the entire unit and its components. The voice component 133 is a module that provides voice recognition and broadcast functions. These two components are set to a lower upgrade priority.

[0141] In this embodiment, given the limited total OTA time, this sequence ensures that the most important functional modules get the upgrade opportunity first and have relatively sufficient upgrade time, thereby maximizing the security and effectiveness of the upgrade process as a whole.

[0142] In one exemplary embodiment, refer to Figure 1 The display component 134 is connected to the damper drive mechanism 140.

[0143] Specifically, the damper drive mechanism 140 is a mechanism for controlling the operation of the air guide plate. Since the air guide plate and the damper drive mechanism 140 are physically close to the display component 134 but far from the main control component 120, the display component 134 can indirectly control the damper drive mechanism 140 based on communication between the display component 134 and the main control component 120. That is, the main control component 120 sends damper control commands to the display component 134, which then forwards them to the damper drive mechanism 140 to drive it.

[0144] After the display component 134 completes the firmware upgrade, it cannot remember the step count or position of the damper drive mechanism 140 before the upgrade. If a reset is not performed, the display component 134 may fail to drive the air guide plate properly after the upgrade, resulting in abnormal noise, jamming, or even damage to the gears. However, since the main control component can remember the step count or position of the damper drive mechanism 140, it can trigger the damper reset process to guide the display component 134 to complete the damper reset.

[0145] Based on this, in an exemplary embodiment, please refer to Figure 1 The main control component 120 is configured as follows:

[0146] Upon receiving the upgrade completion information from the display component, a damper reset trigger command with the damper zeroing step count is sent to the display component according to the communication identifier corresponding to the display component. The damper reset trigger command is used to instruct the display component to control the damper drive mechanism to perform a reset action based on the damper zeroing step count.

[0147] Receive reset status information from the display component and perform reset verification based on the reset status information;

[0148] If the reset verification passes, the damper reset is confirmed to be complete.

[0149] Specifically, after completing the firmware upgrade process, the display component 134 can send a confirmation message, namely the upgrade completion message, to the main control component 120. When the main control component 120 receives the upgrade completion message and confirms that the firmware data transmission of the display component 134 is complete and the firmware upgrade process is also completed, it can trigger the damper reset process.

[0150] Furthermore, the main control component 120 uses the communication identifier of the display component 134, previously mapped through the dynamic routing table, to send a damper reset trigger command to it. The damper reset trigger command carries the damper zeroing step count, which represents the number of step pulses required for the air conditioning unit's damper to rotate from its pre-upgrade memory position to the zero position. Upon receiving the damper reset trigger command, the display component 134 parses the damper zeroing step count and controls the damper drive mechanism 140 to operate at that count, and receives the actual number of step pulses actually executed by the damper drive mechanism 140. In one example, when controlling the damper drive mechanism 140 to operate at the damper zeroing step count, it is typically controlled to operate with a target number of step pulses greater than the preset number of damper zeroing steps. That is, when the damper zeroing step count is 95 steps, the target number of step pulses can be set to 100 steps to ensure that the damper is effectively reset.

[0151] After the display component 134 controls the damper drive mechanism 140 to complete the operation of the damper zeroing step count, it can send reset status information back to the main control component 120. This reset status information can carry the actual number of step pulses. The main control component 120 can perform a reset verification based on this actual number of step pulses and the damper zeroing step count to determine whether the damper reset is complete. It can be understood that if the difference between the actual number of step pulses and the damper zeroing step count is less than or equal to the preset number of steps, the reset verification is considered successful, meaning the damper reset is complete.

[0152] Reference Figure 3After the display component upgrade is complete, the main control component sends a 0x91 reset trigger code, and the display component responds with a 0x92 pre-reset code and initiates the damper reset. The damper drive mechanism further performs a zeroing operation and feeds back the actual number of stepper motor pulses it actually operates on. After the operation is completed, the display component sends a 0x93 reset status code to the main control component, carrying the actual number of stepper pulses. The difference verification module completes the reset verification based on the actual number of stepper pulses and the number of zeroing steps of the damper. In this embodiment, the preset number of steps can be set to 5 steps. If the difference Δ between the two is less than or equal to 5 steps, the reset verification is considered to have passed, that is, the damper reset is determined to be complete. If the difference Δ is greater than 5 steps, the reset verification is considered to have failed, and a 0x94 redundant reset trigger code needs to be sent to the display component to achieve a second reset.

[0153] In one exemplary embodiment, please refer to Figure 1 The main control component 120 is configured as follows:

[0154] If no confirmation is received from the target component within a specified time when performing a data packet transmission task or sending any instruction to the target component, the transmission is deemed to have failed and will be retransmitted according to preset rules.

[0155] Specifically, an exponential backoff algorithm can be used for retransmission, where the retransmission interval increases exponentially with the number of retransmissions. For example, the first retransmission: after the initial failure, waits 20 milliseconds before proceeding; the second retransmission: if it fails again, the waiting time is extended to 40 milliseconds; the third retransmission: the waiting time is doubled again to 80 milliseconds, and so on.

[0156] Furthermore, when the number of retransmissions reaches a preset number, the main control component 120 will trigger an error code. For example, when using the aforementioned exponential backoff algorithm, if no valid response is received from the target component after five consecutive data packet transmissions, a specific 0xE1 error code will be automatically generated. This error code explicitly indicates a communication timeout and a lack of response from the target component. The main control component 120 can also transmit this error code and related context information to the display component 134 via an internal interface. Upon receiving this error code, the display component 134 will invoke its alarm module to notify the user of the current fault by displaying specific error information on the screen, flashing icons, or changing the backlight color.

[0157] In one exemplary embodiment, see Figure 4 This is a flowchart illustrating a firmware upgrade method for an air conditioning device performed by the main control component provided in this application embodiment, specifically including steps S102 to S108, wherein:

[0158] Step S102: Obtain the firmware upgrade instruction received through the communication component;

[0159] Step S104: Parse the firmware upgrade command and determine the component identifiers of the multiple target components to be upgraded;

[0160] Step S106: Based on the component identifier and the upgrade priority of each upgradeable component, an upgrade queue is formed, and each target component in the upgrade queue is assigned a corresponding upgrade duration.

[0161] Step S108: According to the component order in the upgrade queue, and assuming the target component is in an upgradeable state, execute the data packet transmission task for the target component according to the upgrade duration of the target component. The data packet transmission task includes: according to the preset transmission parameters corresponding to the target component, transmitting the upgrade data packet of the target component obtained from the data server through the communication component to the target component.

[0162] In one exemplary embodiment, see Figure 5 This is a flowchart illustrating a firmware upgrade method for an air conditioning device performed by the main control component provided in this application embodiment, specifically including steps S202 to S204, wherein:

[0163] Step S202: Upon receiving data transmission completion information from the current target component, execute the data packet transmission task for the next target component in the upgrade queue.

[0164] Step S204: If no data transmission completion information is received from the current target component and the corresponding upgrade time for the current target component has been reached, execute the data packet transmission task for the next target component in the upgrade queue and add the current target component to the tail of the upgrade queue.

[0165] In one exemplary embodiment, see Figure 6 This is a flowchart illustrating a firmware upgrade method for an air conditioning device performed by the main control component provided in this application embodiment, specifically including steps S302 to S308, wherein:

[0166] Step S302: Based on preset dynamic routing rules, map the component identifier of the target component to the corresponding communication identifier;

[0167] Step S304: Send a status query command to the target component according to the communication identifier;

[0168] Step S306: Receive the response information from the target component in response to the status query command. The response information includes at least the upgrade status information of the target component.

[0169] Step S308: If the upgrade status information of the target component is in an idle state, determine that the target component is in an upgradeable state.

[0170] In one exemplary embodiment, see Figure 7 This is a flowchart illustrating a firmware upgrade method for an air conditioning device performed by the main control component provided in this application embodiment, specifically including steps S402 to S404, wherein:

[0171] Step S402: Perform protocol conversion processing on the upgrade data packet based on the preset communication protocol and preset communication baud rate to obtain upgrade message data;

[0172] Step S404: Based on the communication identifier, send upgrade message data to the target component. The upgrade message data is used to instruct the target component to perform firmware upgrade according to the received upgrade message data.

[0173] In one exemplary embodiment, see Figure 8 This is a flowchart illustrating a firmware upgrade method for an air conditioning device performed by the main control component provided in this application embodiment, specifically including steps S502 to S504, wherein:

[0174] Step S502: Obtain the historical upgrade time of each target component based on the component identifier;

[0175] Step S504: Based on the historical upgrade time of the target components, allocate corresponding upgrade durations to each target component.

[0176] In one exemplary embodiment, see Figure 9 This is a flowchart illustrating a firmware upgrade method for an air conditioning device performed by the main control component provided in this application embodiment, specifically including steps S602 to S604, wherein:

[0177] Step S602: Obtain the upgrade registration instruction for the newly added component received through the communication component; the upgrade registration instruction carries the registration instruction code, verification data, and component parameter information of the newly added component;

[0178] Step S604: If the registration instruction code and verification data are correct, the newly added component is identified as an upgradeable component.

[0179] In an exemplary embodiment, the firmware upgrade method for an air conditioning device executed by the main control component provided in this application embodiment specifically includes: after the air conditioning device is powered on, generating a corresponding component identifier for each upgradeable component based on a preset identifier generation rule, and sending the component identifier of each upgradeable component to the user terminal and the data server through a communication component.

[0180] In one exemplary embodiment, see Figure 10This is a flowchart illustrating a firmware upgrade method for an air conditioning device performed by the main control component provided in this application embodiment, specifically including steps S702 to S706, wherein:

[0181] Step S702: Upon receiving upgrade completion information from the display component, a damper reset trigger command with damper zeroing steps is sent to the display component according to the communication identifier corresponding to the display component. The damper reset trigger command is used to instruct the display component to control the damper drive mechanism to perform a reset action based on the damper zeroing steps.

[0182] Step S704: Receive reset status information fed back by the display component, and perform reset verification based on the reset status information;

[0183] Step S706: If the reset verification passes, determine that the damper reset is complete.

[0184] In this embodiment, when the acquired firmware upgrade instruction indicates that multiple target components should be upgraded, an upgrade queue is first formed based on the component identifier and upgrade priority of the target components. An upgrade duration is then allocated to each target component in the queue. Then, according to the queue order, and provided that a target component is in an upgradeable state, the data packet transmission task for that target component is executed sequentially according to its upgrade duration. The upgrade data packet is transmitted to the target component according to the corresponding preset transmission parameters. This application, through serial scheduling and duration allocation, avoids collisions and conflicts of data packets on the bus caused by disordered contention, significantly improving data transmission efficiency and enabling the smooth execution of OTA upgrades for multiple components within the air conditioning equipment simultaneously.

[0185] The solution provided by the firmware upgrade method for this air conditioning device is similar to the solution described in the above-mentioned air conditioning device. Therefore, the specific limitations in the one or more firmware upgrade method embodiments of the air conditioning device provided above can be found in the limitations of the air conditioning device described above, and will not be repeated here.

[0186] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0187] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0188] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An air conditioning device, characterized in that, The air conditioning equipment includes: Multiple upgradeable components, including a display component connected to the damper drive mechanism; Communication components that communicate with user terminals and data servers; The main control component is connected to the communication component and the plurality of the upgradeable components; The main control component is configured as follows: Obtain firmware upgrade instructions received through the communication component; Parse the firmware upgrade command to determine the component identifiers of the multiple target components to be upgraded; Based on the component identifier and the upgrade priority of each upgradeable component, an upgrade queue is formed, and each target component in the upgrade queue is assigned a corresponding upgrade duration. According to the component order in the upgrade queue, when it is determined that the target component is in an upgradeable state, a data packet transmission task is executed for the target component according to the upgrade duration of the target component; the data packet transmission task includes: according to the preset transmission parameters corresponding to the target component, transmitting the upgrade data packet of the target component obtained from the data server through the communication component to the target component; Upon receiving the upgrade completion information from the display component, a damper reset trigger command with a damper zeroing step count is sent to the display component according to the communication identifier corresponding to the display component. The damper reset trigger command is used to instruct the display component to control the damper drive mechanism to perform a reset action based on the damper zeroing step count. Receive reset status information fed back by the display component, the reset status information carrying the actual number of step pulses of the damper drive mechanism during actual operation; Calculate the difference between the actual number of step pulses and the number of zeroing steps of the damper. If the difference is less than or equal to a preset number of steps, the reset verification is determined to be successful. If the difference is greater than the preset number of steps, a redundant reset trigger command is sent to the display component to instruct the display component to control the damper drive mechanism to perform a reset action again. If the reset verification passes, the damper reset is confirmed to be complete.

2. The air conditioning equipment according to claim 1, characterized in that, The main control component is configured as follows: Upon receiving data transmission completion information from the current target component, execute the data packet transmission task for the next target component in the upgrade queue; If no data transmission completion information is received from the current target component and the corresponding upgrade time for the current target component has been reached, the data packet transmission task for the next target component in the upgrade queue is executed, and the current target component is added to the tail of the upgrade queue.

3. The air conditioning equipment according to claim 1, characterized in that, The main control component is configured as follows: Based on preset dynamic routing rules, the component identifier of the target component is mapped to the corresponding communication identifier; A status query command is sent to the target component based on the communication identifier; Receive response information from the target component in response to the status query instruction, wherein the response information includes at least the upgrade status information of the target component; If the upgrade status information of the target component is in an idle state, the target component is determined to be in an upgradeable state.

4. The air conditioning equipment according to claim 3, characterized in that, The main control component is configured as follows: The upgrade data packet is converted according to a preset communication protocol and a preset communication baud rate to obtain upgrade message data. Based on the communication identifier, the upgrade message data is sent to the target component, and the upgrade message data is used to instruct the target component to perform a firmware upgrade according to the received upgrade message data.

5. The air conditioning equipment according to claim 1, characterized in that, The main control component is configured as follows: Based on the component identifier, obtain the historical upgrade time of each target component; Based on the historical upgrade time of the target components, a corresponding upgrade duration is allocated to each target component.

6. The air conditioning equipment according to claim 1, characterized in that, The main control component is configured as follows: The system obtains an upgrade registration instruction for the newly added component received through the communication component; the upgrade registration instruction carries a registration instruction code, verification data, and component parameter information of the newly added component. If the registration instruction code and the verification data are verified to be correct, the newly added component will be identified as an upgradeable component.

7. The air conditioning equipment according to claim 1, characterized in that, The main control component is configured as follows: After the air conditioning equipment is powered on, a corresponding component identifier is generated for each upgradeable component based on a preset identifier generation rule, and the component identifiers of each upgradeable component are sent to the user terminal and the data server through the communication component.

8. The air conditioning equipment according to claim 1, characterized in that, When arranged in descending order of upgrade priority, the upgradeable components include at least a display component, an indoor component, an outdoor component, a power component, and a voice component.

9. The air conditioning equipment according to claim 1, characterized in that, The main control component is configured as follows: If no confirmation is received from the target component within a specified time when the data packet transmission task is being performed or any instruction is being sent to the target component, the transmission is deemed to have failed and will be retransmitted according to preset rules.

10. A firmware upgrade method for an air conditioning device, applied to the air conditioning device according to any one of claims 1 to 9, characterized in that, The firmware upgrade method includes: Retrieve firmware upgrade instructions received via the communication component; Parse the firmware upgrade command to determine the component identifiers of the multiple target components to be upgraded; Based on the component identifier and the upgrade priority of each upgradeable component, an upgrade queue is formed, and each target component in the upgrade queue is assigned a corresponding upgrade duration. According to the component order in the upgrade queue, when it is determined that the target component is in an upgradeable state, a data packet transmission task is executed for the target component according to the upgrade duration of the target component; the data packet transmission task includes: according to the preset transmission parameters corresponding to the target component, transmitting the upgrade data packet of the target component obtained from the data server through the communication component to the target component; Upon receiving upgrade completion information from the display component, a damper reset trigger command with a damper zeroing step count is sent to the display component according to the communication identifier corresponding to the display component. The damper reset trigger command is used to instruct the display component to control the damper drive mechanism to perform a reset action based on the damper zeroing step count. Receive reset status information fed back by the display component, the reset status information carrying the actual number of step pulses of the damper drive mechanism during actual operation; Calculate the difference between the actual number of step pulses and the number of zeroing steps of the damper. If the difference is less than or equal to a preset number of steps, the reset verification is determined to be successful. If the difference is greater than the preset number of steps, a redundant reset trigger command is sent to the display component to instruct the display component to control the damper drive mechanism to perform a reset action again. If the reset verification passes, the damper reset is confirmed to be complete.

Images