OTA upgrading method and device of Internet of Things system, electronic equipment and system

Abstract

The invention discloses an OTA upgrading method and device for an Internet of Things system, electronic equipment and the system, and belongs to the field of OTA upgrading. The method comprises the following steps: acquiring current version information of a concentrator and sub-equipment; based on the current version information and the latest version information, determining target equipment needing to be subjected to OTA upgrading; when the target equipment comprises a concentrator and sub-equipment at the same time, determining an upgrading sequence based on version information of the concentrator and the sub-equipment; and performing OTA upgrading on the target equipment based on the upgrading sequence. When multiple different types of target devices are included, the upgrading sequence can be determined based on the version information, then the target devices are upgraded according to the upgrading sequence, manual operation in the multi-device OTA process is remarkably reduced, and efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of OTA upgrade technology, and in particular, to an OTA upgrade method, apparatus, electronic device and system for an Internet of Things (IoT) system. Background Technology

[0002] A typical IoT system for a photovoltaic (PV) power plant consists of a cloud platform, a data concentrator, and sub-devices (usually smart shut-off devices, smart optimizers, etc.). In this IoT system, a cloud platform typically connects to multiple data concentrators, and each data concentrator connects to multiple sub-devices. Each sub-device manages and controls the PV panels, collects raw data from them, and then transmits the collected raw data to the connected data concentrator. The data concentrator then sends the collected data back to the cloud platform.

[0003] Each time a sub-device's software version is updated, a remote OTA (Over-the-Air) software program operation must be performed by sending commands via a cloud platform or MQTT (Message Queuing Telemetry Transport) host computer. If there are multiple devices in the power plant, the remote OTA program must be executed separately for each device, and a command must be manually sent to initiate the next round of OTA after each OTA is completed. The time required for each OTA varies and increases with the number of OTA sub-devices.

[0004] In summary, the current OTA process for multiple devices relies on manual operation, which is time-consuming, and when performing OTA on multiple power stations, it is necessary to monitor the current OTA status in real time. Summary of the Invention

[0005] To overcome the shortcomings of the prior art, this application provides an OTA upgrade method, device, electronic device and system for an Internet of Things (IoT) system, in order to solve the problems that the OTA process of IoT systems in the prior art relies on manual operation, is time-consuming, and requires real-time monitoring of the current OTA status when performing OTA on multiple power stations.

[0006] The technical solution adopted by this application to solve its technical problem is: Firstly, an OTA upgrade method for an Internet of Things (IoT) system is provided, including: Obtain the current version information of the concentrator and the sub-devices connected to the concentrator respectively; Based on the current version information and the latest version information, the target device that needs to be upgraded via OTA is determined, wherein the target device is the concentrator and / or the sub-device; When the target device includes both a concentrator and a sub-device, the upgrade order is determined based on the version information of the concentrator and the sub-device. The target device is upgraded via OTA based on the upgrade sequence.

[0007] As an optional implementation of this application, determining the upgrade order based on the version information of the concentrator and the sub-device includes: When the current version of the concentrator meets the OTA upgrade requirements of all sub-devices, the upgrade order is determined to be to upgrade all sub-devices first, and then upgrade the concentrator. When the current version of the concentrator does not meet the OTA upgrade requirements of all sub-devices, the first sub-device that can be upgraded via OTA and the second sub-device that cannot be upgraded via OTA under the current version of the concentrator are identified; the upgrade order is determined to be to upgrade the first sub-device first, then upgrade the concentrator, and finally upgrade the second sub-device. Alternatively, if the current version of the concentrator does not meet the OTA upgrade requirements of all sub-devices, the third sub-device that cannot be upgraded via OTA and the fourth sub-device that can be upgraded via OTA are obtained under the version of the concentrator after the OTA upgrade. The upgrade order is determined to be to upgrade the third sub-device first, then upgrade the concentrator, and finally upgrade the fourth sub-device.

[0008] As an optional implementation of this application, when performing an OTA upgrade on the target device, the method further includes: When the target parameters of the target device do not support OTA upgrades of the target device, the target parameters are adjusted so that the adjusted target parameters support OTA upgrades of the target device. When the target parameters of the target device support OTA upgrades, the target device is upgraded via OTA.

[0009] As an optional implementation of this application, it also includes: The target parameter before adjustment is recorded as the target parameter before adjustment. After the target parameters are adjusted and the target device completes an OTA upgrade, the target parameters are restored to the original target parameters.

[0010] As an optional implementation of this application, it also includes: The target parameters of the target device do not support OTA upgrades if at least one of the following conditions exists: The concentrator's command transmission mode does not match the data reception format of the sub-device to be upgraded via OTA; The data transmission mode of the concentrator is not the target data transmission mode, where the target data transmission mode is the mode that supports large data transmission. Data collection function of sub-devices awaiting OTA upgrade is enabled.

[0011] As an optional implementation of this application, the OTA upgrade of the target device further includes: After the communication program of the target device is upgraded via OTA, the main control program of the target device is upgraded via OTA.

[0012] As an optional implementation of this application, obtaining the current version information of the concentrator and the sub-devices connected to the concentrator includes: The concentrator is sequentially sent with commands to read concentrator device information, read concentrator file, and read sub-device information to obtain the current version information of the concentrator and the sub-devices connected to the concentrator. If no response is received after a preset time has elapsed after sending a read command, the read command will be resent. The read command is one of the following: read concentrator device information command, read concentrator file command, and read sub-device information command. If the number of times the current read instruction is resent reaches a preset number, the current read instruction will be entered into the timeout record, and the next read instruction will be sent. The current read instruction is either a read concentrator device information instruction or a read concentrator file instruction. Upon receiving a response to the next read instruction, resend the current read instruction from the timeout log.

[0013] Secondly, an OTA upgrade device for an Internet of Things (IoT) system is provided, comprising: The version information acquisition module is used to acquire the current version information of the concentrator and the sub-devices connected to the concentrator, respectively. The target device determination module is used to determine the target device that needs to be upgraded via OTA based on the current version information and the latest version information, wherein the target device is the concentrator and / or the sub-device; The upgrade order determination module is used to determine the upgrade order based on the version information of the concentrator and the sub-device when the target device includes both a concentrator and a sub-device. The target device upgrade module is used to perform OTA upgrades on the target device based on the upgrade sequence.

[0014] Thirdly, an electronic device is provided, comprising: At least one processor and at least one memory; The memory stores the executable instructions of the processor; The processor is configured to perform the OTA upgrade method for the Internet of Things system described above.

[0015] Fourthly, an Internet of Things (IoT) system is provided, which applies the OTA upgrade method for IoT systems described in any of the above-mentioned aspects.

[0016] Beneficial effects: This application provides an OTA (Over-The-Air) upgrade method, apparatus, electronic device, and system for an Internet of Things (IoT) system. After obtaining the current version information of the concentrator and sub-devices, the application determines the target devices requiring OTA upgrades based on the current version information and the latest version information. When the target devices include both concentrators and sub-devices, the application determines the upgrade order based on the version information of the concentrator and the sub-devices. The application then performs an OTA upgrade on the target devices according to this upgrade order. When multiple target devices of different types are involved, this application can determine the upgrade order based on version information and then upgrade the target devices according to the upgrade order, significantly reducing manual operations during multi-device OTA processes and improving efficiency. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of an OTA upgrade method for an Internet of Things (IoT) system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a device information reading process provided in an embodiment of this application; Figure 3 This is a specific OTA flowchart provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an OTA upgrade device for an Internet of Things system provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings and embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] Example 1: Reference Figure 1 This application provides an OTA upgrade method for an Internet of Things (IoT) system, including: S11: Obtain the current version information of the concentrator and the sub-devices connected to the concentrator respectively; Generally, the current version information of the concentrator and sub-devices is obtained through a host computer or cloud platform. Therefore, when obtaining the current version information of the concentrator and the sub-devices connected to it, it is necessary to ensure that normal communication is possible between the host computer or cloud platform and the concentrator, as well as between the concentrators themselves. Therefore, as a preferred implementation of this application embodiment, obtaining the current version information of the concentrator and the sub-devices connected to it includes: S111: Send the command to read concentrator device information, the command to read concentrator file, and the command to read sub-device information in sequence to obtain the current version information of the concentrator and the sub-devices connected to the concentrator; For example, the concentrator device information includes version information of the main control program and communication program (such as the carrier chip program), concentrator heartbeat packet status, concentrator data transmission method, concentrator current OTA status, concentrator heartbeat status, and concentrator data acquisition status. The concentrator file includes unique identifiers for all sub-devices connected to the concentrator, such as serial numbers. Sub-device information includes the version information of the communication program and main control program for each sub-device, as well as its corresponding serial number.

[0021] In one embodiment, only one form is used to send the read command. This results in smaller data sizes and faster transmission speeds. For example, the command can be sent in hexadecimal (hex) format. However, since there are many sub-devices in the system, some sub-devices may not be able to parse hex commands.

[0022] Therefore, in another embodiment, two different forms are used to send the read command. The first form is a lightweight structured data format, which is readable and easy to use, such as JSON, and can be parsed by all sub-devices. The second form is a more efficient and low-level compatible format, such as hexadecimal (hex), which makes data parsing easier in the command receiving process. Using two different forms avoids the situation where the concentrator version is outdated and cannot parse the second form of command, and also prevents errors in the concentrator's command parsing due to the loss of partial commands.

[0023] S112: If no response is received after a preset time period after sending the read command, the read command is resent. The read command is one of the following: read concentrator device information command, read concentrator file command, and read sub-device information command. Understandably, receiving a response within the preset time indicates that communication is working properly. At this point, the next command is sent. If no response is received, it is considered that temporary interference is causing the issue, and the read command is resent.

[0024] S113: If the number of times the current read instruction is resent reaches a preset number, the current read instruction is recorded in the timeout record, and the next read instruction is sent at the same time. The current read instruction is one of the read concentrator device information instruction and the read concentrator file instruction. To avoid the problem of repeatedly sending the read command without receiving a response, resulting in excessive time consumption, this application sets a preset number of attempts, such as 3. If no response is received after 3 resends, the current read command is recorded as a timeout, and the next read command is sent directly. The next read command can be either a concentrator file read command or a sub-device information read command.

[0025] If a command to read sub-device information is sent but no reply is received and the number of resends reaches a preset number, the reading is directly determined to have failed, and a prompt message is sent to remind the user to check the concentrator communication.

[0026] S114: Upon receiving a response to the next read instruction, resend the current read instruction from the timeout record.

[0027] Upon receiving a response to the next read command, the read command in the timeout record can be resent. If no response is received, the read operation is deemed to have failed, and a prompt message is sent to remind the user to check the concentrator communication.

[0028] The above mechanism ensures that the required information is obtained while avoiding delays in sending the next instruction due to a lack of response to a certain instruction, thus greatly improving the efficiency of information acquisition.

[0029] S12: Based on the current version information and the latest version information, determine the target device that needs to be upgraded via OTA, wherein the target device is the concentrator and / or the sub-device; The latest version information is obtained either through user input or from a cloud platform. When obtaining information from the cloud platform, the name of the OTA-upgradeable program for the concentrator and sub-devices is retrieved. Based on this name, the latest version is retrieved from the cloud platform and compared with the current version. If the current version is not the latest version, the corresponding concentrator or sub-device is identified as the target device.

[0030] S13: When the target device includes both a concentrator and a sub-device, determine the upgrade order based on the version information of the concentrator and the sub-device; Understandably, due to the unique structure of IoT systems, cloud platforms or host computers can only communicate with concentrators, while sub-devices can only communicate with the concentrators they are connected to. Therefore, when both concentrators and sub-devices are involved, the upgrade order needs to be determined. Upgrading the concentrator first might lead to protocol incompatibility between the sub-devices and the upgraded concentrator, preventing subsequent upgrades of the sub-devices.

[0031] Therefore, under normal circumstances, all sub-devices are upgraded first, followed by the concentrator. However, in practical applications, the current version of the concentrator may be too low to support OTA upgrades for all sub-devices, in which case the concentrator needs to be upgraded in advance.

[0032] In one embodiment, when the current version of the concentrator meets the OTA upgrade requirements of all sub-devices, the upgrade order is determined to be to upgrade all sub-devices first and then upgrade the concentrator. When the current version of the concentrator does not meet the OTA upgrade requirements of all sub-devices, the first sub-device that can be upgraded via OTA and the second sub-device that cannot be upgraded via OTA under the current version of the concentrator are identified; the upgrade order is determined to be to upgrade the first sub-device first, then upgrade the concentrator, and finally upgrade the second sub-device.

[0033] In another embodiment, when the current version of the concentrator meets the OTA upgrade requirements of all sub-devices, the upgrade order is determined to be to upgrade all sub-devices first and then upgrade the concentrator. When the current version of the concentrator does not meet the OTA upgrade requirements of all sub-devices, the third sub-device that cannot be upgraded via OTA and the fourth sub-device that can be upgraded via OTA are obtained under the version of the concentrator after the OTA upgrade. The upgrade order is determined to be to upgrade the third sub-device first, then upgrade the concentrator, and finally upgrade the fourth sub-device.

[0034] S14: Perform an OTA upgrade on the target device based on the upgrade sequence.

[0035] When performing an OTA upgrade on the target device, the following is also included: S141: When the target parameters of the target device do not support the OTA upgrade of the target device, adjust the target parameters and record the target parameters before the adjustment as the target parameters before adjustment, so that the adjusted target parameters support the OTA upgrade of the target device. The target parameters of the target device do not support OTA upgrades if at least one of the following conditions exists: The concentrator's command transmission mode is incompatible with the data reception format of the sub-device undergoing OTA upgrade. In this case, the sub-device cannot correctly parse the upgrade commands and data packets, leading to verification failures, command misunderstandings, or state machine deadlocks. Format mismatch can completely disable data transmission, causing anything from interrupting the upgrade process to rendering the device unusable.

[0036] The concentrator's data transmission mode is not the target data transmission mode, which supports large data transfer. The concentrator's data transmission mode directly affects the reliability and success rate of OTA upgrades. OTA relies on stable, ordered, and verifiable data streams. The transmission mode (such as broadcast, unicast, fragmentation strategy, and acknowledgment mechanism) determines how data is distributed and received. If the modes do not match, the sub-device may fail to correctly identify, receive, or reassemble data packets, leading to corrupted upgrade files, transmission timeouts, or protocol interaction failures. For example, using broadcast push while the sub-device only listens to unicast, or having fragment sizes exceeding the sub-device's buffer, will interrupt the upgrade process. Therefore, a matching transmission mode is fundamental to ensuring end-to-end data integrity and process controllability in OTA.

[0037] Data collection for the sub-device awaiting OTA upgrade is enabled. OTA upgrade packages are typically large (hundreds of MB to several GB), requiring a stable and high-speed network connection for download. If the target device is simultaneously uploading a large amount of collected data, it will severely strain bandwidth and consume system resources, resulting in extremely slow OTA download speeds, or even download failures or interruptions, impacting upgrade success rates and user experience.

[0038] S142: When the target parameters of the target device support the OTA upgrade of the target device, perform an OTA upgrade on the target device.

[0039] S143: After adjusting the target parameters and when the target device completes the OTA upgrade, the target parameters are restored to the original target parameters.

[0040] It should be noted that the upgrade can be to the latest version or to a user-defined target version (not the latest version).

[0041] Furthermore, as a preferred implementation of this application, the OTA upgrade of the target device further includes: after the OTA upgrade of the target device's communication program is completed, an OTA upgrade of the target device's main control program is performed. This is because if the upgraded main control program is incompatible with the communication program (e.g., due to protocol changes), the device may be unable to connect to the network. Alternatively, if a power outage occurs during the main control program upgrade, the device may completely lose control, and the communication module may not be able to independently repair the main control. Therefore, it is necessary to upgrade the communication program first to ensure that if the subsequent main control upgrade fails, the device can still report errors through the communication module, attempt to re-download the firmware, or trigger a rollback mechanism. Prioritizing ensuring the uninterrupted communication channel of the target device before performing the high-risk main control upgrade maximizes the upgrade success rate and system recoverability.

[0042] Example 2 In a photovoltaic power plant IoT system, the primary task is to determine whether normal communication can be achieved between the host computer and the concentrator, and between the concentrator and the sub-devices. For example, by sending commands to query concentrator device information and commands to query sub-device operating data, the host computer can determine that the MQTT communication connection is normal when it successfully receives and parses the reply information.

[0043] After completing the communication test, the automated OTA process can be initiated. The specific automated OTA device implementation process is as follows: 1. The MQTT host computer sequentially sends commands to read concentrator device information, read concentrator file, and read sub-device information. It acquires and stores the concentrator's main control chip program version, carrier chip software program version, the quantity of various sub-devices, and the sub-device serial number (SN) and its corresponding version information. Simultaneously, it determines the device type based on the concentrator's SN code. The main purposes of the three commands sent by the host computer are as follows: Concentrator device information: Obtain the version information of the concentrator main control program and carrier chip program, record the concentrator heartbeat packet status, concentrator data transmission method, concentrator current OTA status, concentrator heartbeat status, and concentrator data acquisition status.

[0044] Concentrator Files: Obtain the number of concentrator files and compare them with the stored information, and record the serial numbers (SN) of all sub-devices.

[0045] Sub-device information: The carrier chip version and main control chip version information corresponding to each sub-device, along with the corresponding serial number, are stored in the host computer.

[0046] The MQTT host application is a desktop / client application built on the MQTT protocol. Its core function is as a "client node" in the MQTT communication architecture, enabling bidirectional data interaction with the MQTT Broker (message broker server) and lower-level devices (embedded terminals / sensor nodes) to perform functions such as data monitoring, command issuance, and status display. This functionality is implemented using Python code, and additional functions can be implemented by writing custom code according to actual needs.

[0047] If the concentrator version is outdated, it will directly enter the OTA (Over-The-Air) phase, automatically sending OTA commands to sequentially perform OTA operations on the concentrator's main control chip and carrier chip programs to avoid the inability to execute OTA operations on sub-devices. Conversely, if the current version of the concentrator can support the normal OTA process of all sub-devices under the concentrator, the concentrator will initiate OTA only after all sub-devices have completed their OTA operations, in order to avoid affecting the normal OTA process of the sub-devices.

[0048] If the concentrator's response command times out, the next command is sent first; after successfully receiving the current response, the unreplyed command is resent. The specific flowchart is as follows: Figure 2 As shown: If the host computer software does not receive a response within a preset time, it is considered a timeout, and the command retry mechanism is triggered. If a response is received within three retries, this situation is not recorded in the timeout record; if the number of retries exceeds three, this situation is recorded in the timeout record, and the command will be retried again after the remaining commands are successfully sent.

[0049] Specifically, commands are sent in both JSON and hexadecimal (hex) formats. JSON is a lightweight structured data format, offering readability and ease of use. Using JSON commands in the command receiving process allows for intuitive reading, facilitating debugging and maintenance. Hexadecimal (hex) is a simplified visual representation of binary data, offering efficiency and low-level compatibility. Using hex commands in the command receiving process makes data parsing easier. Using two different formats avoids situations where the concentrator version is outdated and cannot parse hex commands, while also preventing errors in command parsing due to missing parts. If a command is sent three times without a response, the host computer stops the data acquisition process and prompts the user to check the concentrator communication.

[0050] After collecting the necessary information for OTA (Over-The-Air) updates, the MQTT host computer compares the target version in the configuration file with the currently collected version information to generate a corresponding OTA project list. First, based on the currently read concentrator and sub-device types, the MQTT host computer retrieves the latest official software version link for the corresponding device type via a cloud platform webpage. Then, it compares the version information carried by the link obtained from the cloud platform with the currently collected version information one by one. If the current version is lower than the latest official program version, the MQTT host computer stores the comparison result. After the comparison is completed, the results are statistically analyzed to generate the corresponding OTA project list. Users can replace the OTA target version by changing the OTA links in the OTA list according to their needs. If OTA is not required for a specific device, deleting the specified link will skip the OTA operation for that device.

[0051] 2. After confirmation, click "Start OTA" to initiate the automatic OTA process. The MQTT host computer will perform OTA operations sequentially according to the following order: the carrier chip program of the sub-device (carrier chips are mainly used in the communication field; prioritizing carrier chip updates ensures sub-device support for the latest version of the communication protocol, thus avoiding command parsing errors and communication anomalies), the main control program of the sub-device, the main control program of the concentrator, and the carrier chip program of the concentrator. Due to functional updates and changes in implementation processes, different versions of the carrier chip program and the main control program have compatibility differences. Prioritizing the upgrade of the carrier chip program avoids situations where the sub-device cannot function properly after the main control program is upgraded. Simultaneously, incompatibility issues may arise when the concentrator performs OTA on the sub-device, causing the sub-device to fail to perform OTA after the concentrator's OTA is completed. Therefore, performing OTA upgrades sequentially according to the established order effectively reduces various conflicts caused by compatibility differences during version iteration, thereby ensuring a smooth and stable upgrade process.

[0052] First, an OTA start command is sent, enabling the concentrator to obtain the address of the upgrade package and download it. Then, based on the target device, it decides whether to send the upgrade package or perform its own OTA. After OTA completion, an OTA end message is reported. When the MQTT host computer receives the end message or an OTA timeout occurs, it sends a version information query command. By comparing the current version with the target version, it determines whether the OTA was successful. If all current devices' OTAs are successful, the next OTA step is initiated, and the corresponding OTA information is stored. If any failures occur, the current OTA operation is repeated, up to a maximum of three times. After three attempts, regardless of success or failure, the next OTA step is initiated.

[0053] Since all commands are sent remotely, if the concentrator's communication is poor, it may fail to receive commands from the host computer or fail to report information. Therefore, the host computer needs to resend commands to avoid command loss. Furthermore, because concentrator upgrades affect the upgrade process of its sub-devices, under normal circumstances, sub-device OTA upgrades should be prioritized, and the concentrator's OTA upgrade should only be performed after all sub-devices have completed their OTA upgrades.

[0054] In a hybrid power plant system, sub-equipment includes various equipment types. Some sub-equipment have outdated versions; prioritizing OTA (Over-The-Air) updates for other equipment could lead to erroneous software upgrades for these sub-equipment devices, rendering them malfunctioning. Therefore, in special circumstances, the MQTT host computer will send parameter modification commands based on the software version to adjust the OTA environment (which mainly includes command sending mode, data reception format, whether the concentrator heartbeat function is enabled, whether data acquisition is disabled during OTA, and the concentrator data transmission mode) to match the current OTA upgrade target, prioritizing the upgrade operation for these sub-equipment devices. For example, when the concentrator version is relatively new, but the sub-equipment version is significantly outdated, given that the concentrator sends commands via heartbeat packets (i.e., the commands are included in the heartbeat signal), but the current version of the sub-equipment does not support heartbeat packets, a command must first be sent to switch the concentrator to a separate command sending mode. Simultaneously, by comparing the current version of the sub-equipment, the format of the received data packets is determined, and then a command is sent to update the concentrator's transmission mode. After ensuring the current sub-device can perform OTA normally, issue OTA commands and record previous modifications. After the OTA upgrade is successful, switch back to the regular OTA environment to proceed with subsequent OTA work. The specific process is as follows: Figure 3 As shown.

[0055] 3. Once all OTA processes are completed, the MQTT host computer will indicate the end and generate an OTA result report. It will also store all received and sent command information during the OTA process. The final report can be used to analyze the automatic OTA situation and prepare for the next round of automatic OTA.

[0056] The solution in this application can automatically acquire the version information of the concentrator and sub-devices, and automatically identify the target devices that need OTA based on the OTA target version configured in the software. After confirmation by the operator, the OTA process is automatically executed on the devices sequentially, and the OTA process information is stored. After all devices to be upgraded have completed OTA, the OTA results are statistically analyzed and reported. The effectiveness of OTA can be confirmed based on the final reported results, and the next round of OTA can be initiated. This method significantly reduces manual operations in the multi-device OTA process and improves efficiency.

[0057] Based on the same inventive concept, such as Figure 4 As shown, this application also provides an OTA upgrade device 40 for an Internet of Things (IoT) system, comprising: Version information acquisition module 41 is used to acquire the current version information of the concentrator and the sub-devices connected to the concentrator respectively; The step of obtaining the current version information of the concentrator and the sub-devices connected to the concentrator includes: The system sequentially sends commands to read concentrator device information, read concentrator file, and read sub-device information to obtain the current version information of the concentrator and the sub-devices connected to it. If no response is received within a preset time after sending a read command, the read command is resent. The read command can be one of the following: read concentrator device information, read concentrator file, or read sub-device information. If the number of resentments of the current read command reaches a preset number, the current read command is added to the timeout record, and a next read command is sent. The current read command can be one of the following: read concentrator device information or read concentrator file. Upon receiving a response to the next read command, the current read command from the timeout record is resent.

[0058] The target device determination module 42 is used to determine the target device that needs to be upgraded via OTA based on the current version information and the latest version information, wherein the target device is the concentrator and / or the sub-device.

[0059] The upgrade order determination module 43 is used to determine the upgrade order based on the version information of the concentrator and the sub-device when the target device includes both a concentrator and a sub-device. The step of determining the upgrade order based on the version information of the concentrator and the sub-devices includes: when the current version of the concentrator satisfies the OTA upgrade requirements of all sub-devices, determining the upgrade order to upgrade all sub-devices first, then the concentrator; when the current version of the concentrator does not satisfy the OTA upgrade requirements of all sub-devices, obtaining the first sub-device that can be upgraded via OTA and the second sub-device that cannot be upgraded via OTA under the current version of the concentrator; determining the upgrade order to upgrade the first sub-device first, then the concentrator, and finally the second sub-device; or, when the current version of the concentrator does not satisfy the OTA upgrade requirements of all sub-devices, obtaining the third sub-device that cannot be upgraded via OTA and the fourth sub-device that can be upgraded via OTA under the version after the concentrator is OTA upgraded, determining the upgrade order to upgrade the third sub-device first, then the concentrator, and finally the fourth sub-device.

[0060] The target device upgrade module 44 is used to perform OTA upgrades on the target device based on the upgrade sequence.

[0061] The method of performing an OTA upgrade on the target device further includes: adjusting the target parameters when the target parameters of the target device do not support the OTA upgrade, so that the adjusted target parameters support the OTA upgrade; and performing an OTA upgrade on the target device when the target parameters of the target device support the OTA upgrade.

[0062] Furthermore, it also includes: recording the target parameter before adjustment as the target parameter before adjustment; and restoring the target parameter to the target parameter before adjustment when the target device completes the OTA upgrade after the target parameter is adjusted.

[0063] It should be noted that the target parameters of the target device do not support OTA upgrade of the target device under at least one of the following conditions: the command sending mode of the concentrator does not match the data receiving format of the sub-device to be upgraded via OTA; the data transmission mode of the concentrator is not the target data transmission mode, wherein the target data transmission mode is a mode that supports large data transmission; the data acquisition function of the sub-device to be upgraded via OTA is enabled.

[0064] In addition, when performing an OTA upgrade on the target device, the process also includes: after the OTA upgrade of the target device's communication program is completed, performing an OTA upgrade on the target device's main control program.

[0065] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the OTA upgrade method for an Internet of Things system as provided in any of the above embodiments.

[0066] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0067] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0068] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0069] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0070] Based on the same inventive concept, this application also provides an electronic device, comprising: At least one processor and at least one memory; The memory stores the executable instructions of the processor; The processor is configured to execute the IoT system OTA upgrade method provided in the above embodiments.

[0071] Based on the same inventive concept, this application also provides an Internet of Things (IoT) system that applies the OTA upgrade method for IoT systems provided in any of the above embodiments.

[0072] It should be noted that any process or method description in the flowchart or otherwise described herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order according to the functions involved, as should be understood by those skilled in the art to which the embodiments of this application pertain.

[0073] Furthermore, in the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0074] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0075] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0076] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. An OTA upgrade method for an Internet of Things (IoT) system, characterized in that, include: Obtain the current version information of the concentrator and the sub-devices connected to the concentrator respectively; Based on the current version information and the latest version information, the target device that needs to be upgraded via OTA is determined, wherein the target device is the concentrator and / or the sub-device; When the target device includes both a concentrator and a sub-device, the upgrade order is determined based on the version information of the concentrator and the sub-device. The target device is upgraded via OTA based on the upgrade sequence.

2. The method according to claim 1, characterized in that: The process of determining the upgrade order based on the version information of the concentrator and the sub-device includes: When the current version of the concentrator meets the OTA upgrade requirements of all sub-devices, the upgrade order is determined to be to upgrade all sub-devices first, and then upgrade the concentrator. When the current version of the concentrator does not meet the OTA upgrade requirements of all sub-devices, the first sub-device that can be upgraded via OTA and the second sub-device that cannot be upgraded via OTA under the current version of the concentrator are identified; the upgrade order is determined to be to upgrade the first sub-device first, then upgrade the concentrator, and finally upgrade the second sub-device. Alternatively, if the current version of the concentrator does not meet the OTA upgrade requirements of all sub-devices, the third sub-device that cannot be upgraded via OTA and the fourth sub-device that can be upgraded via OTA are obtained under the version of the concentrator after the OTA upgrade. The upgrade order is determined to be to upgrade the third sub-device first, then upgrade the concentrator, and finally upgrade the fourth sub-device.

3. The method according to claim 1, characterized in that, When performing an OTA upgrade on the target device, the following is also included: When the target parameters of the target device do not support OTA upgrades of the target device, the target parameters are adjusted so that the adjusted target parameters support OTA upgrades of the target device. When the target parameters of the target device support OTA upgrades, the target device is upgraded via OTA.

4. The method according to claim 3, characterized in that, Also includes: The target parameter before adjustment is recorded as the target parameter before adjustment. After the target parameters are adjusted and the target device completes an OTA upgrade, the target parameters are restored to the original target parameters.

5. The method according to claim 3, characterized in that, Also includes: The target parameters of the target device do not support OTA upgrades if at least one of the following conditions exists: The concentrator's command transmission mode does not match the data reception format of the sub-device to be upgraded via OTA; The data transmission mode of the concentrator is not the target data transmission mode, where the target data transmission mode is the mode that supports large data transmission. Data collection function of sub-devices awaiting OTA upgrade is enabled.

6. The method according to claim 1, characterized in that: The OTA upgrade of the target device also includes: After the communication program of the target device is upgraded via OTA, the main control program of the target device is upgraded via OTA.

7. The method according to claim 1, characterized in that: The step of obtaining the current version information of the concentrator and the sub-devices connected to the concentrator includes: The concentrator is sequentially sent with commands to read concentrator device information, read concentrator file, and read sub-device information to obtain the current version information of the concentrator and the sub-devices connected to the concentrator. If no response is received after a preset time has elapsed after sending a read command, the read command will be resent. The read command is one of the following: read concentrator device information command, read concentrator file command, and read sub-device information command. If the number of times the current read instruction is resent reaches a preset number, the current read instruction will be entered into the timeout record, and the next read instruction will be sent. The current read instruction is either a read concentrator device information instruction or a read concentrator file instruction. Upon receiving a response to the next read instruction, resend the current read instruction from the timeout log.

8. An OTA upgrade device for an Internet of Things (IoT) system, characterized in that, include: The version information acquisition module is used to acquire the current version information of the concentrator and the sub-devices connected to the concentrator, respectively. The target device determination module is used to determine the target device that needs to be upgraded via OTA based on the current version information and the latest version information, wherein the target device is the concentrator and / or the sub-device; The upgrade order determination module is used to determine the upgrade order based on the version information of the concentrator and the sub-device when the target device includes both a concentrator and a sub-device. The target device upgrade module is used to perform OTA upgrades on the target device based on the upgrade sequence.

9. An electronic device, characterized in that, include: At least one processor and at least one memory; The memory stores the executable instructions of the processor; The processor is configured to perform the method according to any one of claims 1-7.

10. An Internet of Things (IoT) system, characterized in that, The method described in any one of claims 1-7.

Images