Iot device data transmission method, system, device and storage medium

Abstract

This application relates to a data transmission method, system, device, and storage medium for Internet of Things (IoT) devices, and pertains to the field of IoT technology. The method is applied to an IoT platform and includes: receiving raw data packets reported by IoT devices, performing stateful parsing operations using an uplink parsing cloud function to parse the raw data packets, and obtaining initial parsed data; obtaining at least one historical attribute value associated with the initial parsed data from the IoT device's device shadow service; converting the initial parsed data based on the at least one historical attribute value to obtain preset uplink format data; updating the preset uplink format data to the IoT platform's device shadow service; and sending the preset uplink format data to clients subscribing to IoT devices. This application can solve the problems of forced updates across multiple mobile application platforms, version fragmentation, and functional abnormalities caused by firmware upgrades in the prior art.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a data transmission method, system, device, and storage medium for IoT devices. Background Technology

[0002] In existing Internet of Things (IoT) systems, a common technical solution is to treat the IoT cloud platform merely as a "transparent" message conduit. The specific process is as follows: IoT devices report data using highly compressed, custom-defined private binary (or Hex) protocols to save bandwidth and device power. The IoT device sends this binary data packet to the cloud platform. The cloud platform does not perform any parsing and directly "transparently transmits" the raw binary data packet to mobile clients (APPs) subscribed to the device's topic. The mobile APP (such as iOS, Android, or HarmonyOS applications) embeds detailed protocol parsing logic for the device. The mobile APP locally parses the received binary data packet into a user-readable state and displays it on the UI. Similarly, when the user operates on the APP (such as issuing commands), the mobile APP, according to the embedded protocol logic, "packages" or "formats" the user's operation into a binary command packet that the device can recognize, and then "transparently transmits" it to the device through the cloud platform.

[0003] However, the above solution has the following drawbacks: 1. Difficult to update and maintain. When the device's protocol (firmware) is upgraded or its functional logic is modified, even if it's just adding a new function or changing the meaning of a single byte, all mobile apps (including iOS, Android, HarmonyOS, and mini-programs) must simultaneously modify their code, recompile, and release new versions. If users don't update their apps, the IoT device's functions will malfunction or even "go out of control"; 2. The control logic of each client may have subtle differences, leading to inaccurate data parsing locally; 3. Core protocols are easily leaked, resulting in poor security. The core, proprietary protocol parsing logic is completely embedded in the publicly released mobile app installation package, which is equivalent to handing the "key" to everyone. Private communication protocols can be cracked through decompilation (reverse engineering), posing a significant security risk. Summary of the Invention

[0004] In view of the above, this application provides a data transmission method, system, device and storage medium for Internet of Things devices, the purpose of which is to solve the above-mentioned technical problems.

[0005] In a first aspect, this application provides a data transmission method for an Internet of Things (IoT) device, the method being applied to an IoT platform, the method comprising:

[0006] Receive raw data packets reported by IoT devices;

[0007] In response to receiving the original data packet, the uplink parsing cloud function corresponding to the IoT device is invoked through the cloud function executor;

[0008] The uplink parsing cloud function is used to perform a stateful parsing operation to convert the original data packet into a preset uplink format data. The process of using the uplink parsing cloud function to perform the stateful parsing operation to convert the original data packet into the preset uplink format data includes: calling the uplink parsing cloud function to perform the following operations: parsing the original data packet to obtain initial parsed data; obtaining at least one historical attribute value associated with the initial parsed data from the device shadow service of the IoT device; and converting the initial parsed data based on the at least one historical attribute value to obtain the preset uplink format data.

[0009] The preset uplink format data is updated to the device shadow service of the IoT platform, and the preset uplink format data is sent to the clients that subscribe to the IoT devices.

[0010] In some embodiments, the transformation of the initial parsed data based on the at least one historical attribute value to obtain the preset uplink format data includes:

[0011] Based on the protocol header in the original data packet, determine the protocol type of the original data packet;

[0012] Based on the protocol type, determine the parsing logic protocol corresponding to the protocol type;

[0013] Based on the parsing logic protocol and the at least one historical attribute value, determine the target field corresponding to the initial parsed data;

[0014] The initial parsed data is assigned to the target field to obtain the preset uplink format data.

[0015] In some embodiments, determining the target field corresponding to the initial parsed data based on the parsing logic protocol and the at least one historical attribute value includes:

[0016] Based on the parsing logic protocol, a context parsing rule set is determined; wherein, the context parsing rule set includes the mapping relationship between different historical attributes and potential fields;

[0017] Match the value of at least one historical attribute with the context parsing rule set;

[0018] Based on the matching results, the target field corresponding to the initial parsed data is determined from the potential fields.

[0019] In some embodiments, after sending the preset uplink format data to the client subscribing to the IoT device, the process includes:

[0020] Receive instruction data packets from the client;

[0021] In response to receiving the instruction data packet, the cloud function executor calls the downlink formatted cloud function corresponding to the IoT device;

[0022] The downlink formatted cloud function is used to perform a stateful instruction extension operation to convert the instruction data packet into a target instruction packet corresponding to the IoT device;

[0023] The target instruction packet is sent to the IoT device.

[0024] In some embodiments, performing a stateful instruction extension operation using the downlink formatting cloud function to convert the instruction data packet into a target instruction packet corresponding to the IoT device includes:

[0025] Perform the following operations using the downlink formatted cloud function:

[0026] Parse the instruction data packet to obtain the upper-layer operation instructions;

[0027] Based on the instruction type of the upper-layer operation instruction, at least one device parameter required to complete the operation corresponding to the instruction data packet is obtained from the device shadow service;

[0028] Based on the at least one device parameter, the upper-layer operation instruction is extended into one or more lower-layer device instructions;

[0029] The one or more underlying device instructions are converted into the target instruction package according to the protocol format corresponding to the IoT device.

[0030] In some embodiments, expanding the upper-layer operation instruction into one or more lower-layer device instructions based on the at least one device parameter includes:

[0031] Based on the instruction type of the upper-level operation instruction, determine the instruction formatting type corresponding to the instruction type;

[0032] Based on the instruction formatting type and the at least one device parameter, one or more underlying device instructions are generated; wherein, if there are multiple underlying device instructions, the multiple underlying device instructions are merged.

[0033] Secondly, this application provides an Internet of Things (IoT) device data transmission system, which is applied to an IoT platform and includes:

[0034] The receiving module is used to receive raw data packets reported by IoT devices;

[0035] The calling module is used to call the uplink parsing cloud function corresponding to the IoT device through the cloud function executor in response to receiving the original data packet;

[0036] The conversion module is used to perform a stateful parsing operation using the uplink parsing cloud function to convert the original data packet into a preset uplink format data;

[0037] The sending module is used to update the preset uplink format data to the device shadow service of the IoT platform, and send the preset uplink format data to the client subscribing to the IoT device.

[0038] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0039] Memory, used to store computer programs;

[0040] When a processor executes a program stored in memory, it implements the steps of the Internet of Things device data transmission method according to any embodiment of the first aspect.

[0041] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the Internet of Things device data transmission method as described in any embodiment of the first aspect.

[0042] Compared with the prior art, the above-mentioned technical solutions provided in this application have the following advantages: (1) By separating the core protocol parsing logic from each terminal and centrally deploying it in the cloud function, the protocol changes only need to be modified once in the cloud to take effect globally, which solves the problems of forced updates, version fragmentation and functional abnormalities of mobile applications caused by firmware upgrades in traditional solutions; (2) Ensures the absolute consistency of data status of multiple terminals. As the only parsing center, the cloud receives standardized data after unified processing, which eliminates the data inconsistency caused by the differences in parsing logic of each client from the root; (3) Through the collaboration of cloud function and device shadow service, stateful parsing of uplink data (such as interpreting data in combination with historical status, obtaining historical attribute values ​​from the device shadow service of the IoT device, and performing data conversion based on historical attribute values ​​to obtain preset uplink format data) and stateful expansion of downlink instructions (such as expanding simple instructions into multiple device instructions) are realized, and business intelligence is centralized in the cloud, which significantly improves the system processing capability; (4) The private protocol logic of IoT devices is stored in the protected cloud and is not distributed to the client, which effectively prevents the security risks caused by obtaining the protocol through decompiling mobile applications. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0044] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a flowchart illustrating a preferred embodiment of the data transmission method for IoT devices according to this application;

[0046] Figure 2 This is a schematic flowchart of another embodiment of the data transmission method for IoT devices in this application;

[0047] Figure 3 This is a diagram of the cloud function-based architecture in the IoT platform of this application.

[0048] Figure 4 This is a schematic diagram illustrating the cloud function's cloud parsing process for sending data from the cloud to the client in this application;

[0049] Figure 5 This is a schematic diagram illustrating the cloud function's cloud parsing process from the client sending instructions to the IoT device, as described in this application.

[0050] Figure 6 This is a schematic diagram of a preferred embodiment of the Internet of Things (IoT) device data transmission system of this application;

[0051] Figure 7 This is a schematic diagram of a preferred embodiment of the electronic device of this application;

[0052] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0054] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0055] Reference Figure 1 The diagram shown is a flowchart illustrating an embodiment of the IoT device data transmission method of this application. This method is applied to an IoT cloud platform and executed by an electronic device, which can be implemented by a software system and / or a hardware system. The IoT device data transmission method includes:

[0056] Step 101: Receive the raw data packets reported by the IoT device.

[0057] Internet of Things (IoT) devices are intelligent hardware responsible for sending and receiving private binary data packets. For example, they refer to smart home appliances connected to an IoT platform. IoT devices can collect data and report it to the IoT platform over a network. IoT devices can include various home appliances, such as kitchen appliances, air conditioning units, or cleaning equipment. These devices have built-in sensors and communication modules to support data reporting. For example, a smart cooktop can report temperature data, power status, or fault codes; a smart air conditioner can report temperature, humidity, or operating mode.

[0058] An IoT platform, also known as an IoT cloud platform (or simply a platform or cloud platform), is a cloud-based system that provides basic services such as device connectivity, message routing, and rule engines.

[0059] Raw data packets refer to unprocessed binary data packets reported by IoT devices. Raw data packets can use highly compressed, custom proprietary binary protocols (or Hex protocols) to save bandwidth and device power consumption. Raw data packets are low-level data formats directly generated by the device and are typically unreadable by users, requiring parsing to understand.

[0060] IoT devices can send raw data packets to the message gateway of the IoT platform via wireless networks (such as Wi-Fi or cellular networks).

[0061] Step 102: In response to receiving the original data packet, the uplink parsing cloud function corresponding to the IoT device is invoked through the cloud function executor.

[0062] A cloud function executor is a component in an IoT platform responsible for executing cloud function scripts. It can dynamically load and run cloud functions based on device identifiers. Cloud function executors can be based on high-performance, lightweight scripting language runtimes (such as JavaScript, Python, or Java) and have built-in script caching mechanisms (such as LRU strategies) to optimize performance. For example, a cloud function executor can be a microservice that retrieves cloud function scripts from a protocol script library and executes them in an isolated runtime environment.

[0063] The cloud function executor can be embedded in the message flow path of an IoT platform. It can dynamically load and execute specific scripts (i.e., cloud functions) that match the device based on the device identifier (such as ProductKey). The protocol script library (cloud functions) consists of parsing scripts (uplink) and formatting scripts (downlink) for each device protocol, stored in the cloud.

[0064] Uplink parsing cloud functions are cloud function scripts specifically designed for parsing uplink data (from device to platform). These scripts include logic for parsing raw binary data packets and can access device shadow services for stateful parsing. Uplink parsing cloud functions are protocol-dependent, designed for specific IoT device protocols. For example, an uplink parsing cloud function for a smart cooktop could be a JavaScript function capable of parsing temperature bytes from binary data packets and converting them into JSON fields based on the protocol version.

[0065] After receiving the raw data packet, the IoT platform identifies the IoT device and triggers the cloud function executor. The cloud function executor loads the corresponding uplink parsing cloud function script from the protocol script library based on the device identifier, and then calls and executes the function.

[0066] Step 103 involves using the uplink parsing cloud function to perform a stateful parsing operation to convert the original data packet into a preset uplink format data. This includes calling the uplink parsing cloud function to perform the following operations: parsing the original data packet to obtain initial parsed data; obtaining at least one historical attribute value associated with the initial parsed data from the device shadow service of the IoT device; and converting the initial parsed data based on the at least one historical attribute value to obtain the preset uplink format data.

[0067] Stateful parsing operations refer to the uplink parsing cloud function's dynamic parsing behavior. It not only parses data based on the content of the original data packet but also actively accesses the device shadow service to obtain the device's current state. Stateful parsing operations include reading the state from the device shadow, modifying the parsing logic based on the state, and writing the new state to the shadow, implementing a read-modify-write loop.

[0068] Preset uplink format data refers to standardized data format generated after stateful parsing operations. It can be a JSON object, including user-readable device status information. For example, standardized JSON data is a structured data format that is parsed (uplink) or received (downlink) by cloud functions, conforms to the unified object model specification, and is easy for clients to understand and for cloud services to process.

[0069] The step of using the uplink parsing cloud function to perform a stateful parsing operation to convert the original data packet into a preset uplink format can be achieved through the following steps:

[0070] S10, the original data packet is parsed to obtain initial parsed data.

[0071] Initial parsed data refers to the intermediate data obtained after parsing the original data packet.

[0072] In some embodiments, the uplink parsing cloud function decomposes the original data packet into a byte stream according to predefined protocol rules, identifies the protocol type (such as protocol A or protocol B), and applies parsing algorithms (such as byte parsing, bit manipulation, or field mapping) to extract data fields and generate initial parsed data.

[0073] S11, Obtain at least one historical attribute value associated with the initial parsed data from the device shadow service of the IoT device.

[0074] The device shadow service for IoT devices refers to a service in an IoT platform that stores and manages device status, maintaining a virtual representation (called a shadow) for each IoT device, including the device's latest status, historical attribute values, metadata, and version information. In some embodiments, the device shadow can be a "standard JSON" cache of device status stored in the cloud.

[0075] Historical attribute values ​​refer to past values ​​related to the state of IoT devices stored in the device shadow service. These historical attribute values ​​can be previously reported data, calculated states, or user settings, and are used for stateful resolution. Historical attribute values ​​can be associated with timestamps to represent the device's historical behavior.

[0076] "Association" refers to the logical relationship between historical attribute values ​​and initial parsed data, such as belonging to the same data field, affecting parsing logic, or being used for status comparison. Association relationships are established based on business rules; for example, historical values ​​of the temperature field are used for temperature parsing. For instance, each reportable data item (such as temperature, on / off status, or error code) has a unique or definite identifier (e.g., a unique ID identifier). A mapping table between "unique ID identifiers" and "device shadow attribute names" is pre-established in the device shadow service. When the initial parsed data is parsed, the cloud function can use the unique ID identifier to find one or more associated device shadow attribute names, and then obtain the historical values ​​of the associated shadow device attributes.

[0077] During the parsing process, the uplink parsing cloud function dynamically requests the device shadow service to read relevant historical states and caches or directly uses the historical attribute values ​​for subsequent conversions.

[0078] S12, the initial parsed data is transformed based on the at least one historical attribute value to obtain the preset uplink format data.

[0079] Historical attribute values ​​represent the device's past state and are used to enhance or modify the initial parsed data.

[0080] Preset uplink format data refers to standardized JSON data during the data uplink process.

[0081] In some embodiments, the transformation of the initial parsed data based on the at least one historical attribute value to obtain the preset uplink format data may include the following operations:

[0082] S20, determine the protocol type of the original data packet based on the protocol header in the original data packet.

[0083] The protocol header is a specific part of the raw data packet used to identify the protocol format. It can be located at the beginning of the data packet and contains protocol version, type, or identifier information.

[0084] The protocol type refers to the protocol category to which the data packet belongs, as identified by the protocol header. This category defines the structure of the data packet, the meaning of its fields, and the parsing rules. For example, the protocol type may include temperature reporting protocols, status change protocols, or error reporting protocols, such as "Protocol A" for basic temperature data and "Protocol B" for advanced mode data.

[0085] In some embodiments, the uplink parsing cloud function parses the binary content of the raw data packet, extracts protocol header fields (such as fixed magic number or version bytes), and compares them with predefined protocol header patterns (such as lookup tables or rule sets) to determine the protocol type.

[0086] S21, determine the parsing logic protocol corresponding to the protocol type according to the protocol type.

[0087] A parsing logic protocol is a set of parsing rules associated with a specific protocol type. It defines how to parse data packet fields, handle data transformations, and apply business logic. Parsing logic protocols include field mapping, data type conversion, validation rules, and state handling logic.

[0088] The uplink parsing cloud function retrieves the corresponding parsing logic protocol from the protocol script library or configuration storage based on the determined protocol type.

[0089] S22, based on the parsing logic protocol and the at least one historical attribute value, determine the target field corresponding to the initial parsing data.

[0090] A target field refers to the name or path of a field in the predefined uplink formatted data that is used to store the final parsed result. A target field is a key in a JSON object, such as temperature, status, or timestamp. For example, a target field is used to organize data within a predefined uplink formatted data structure.

[0091] In some embodiments, the uplink parsing cloud function applies field mapping rules in the parsing logic protocol, refers to historical attribute values ​​(such as comparing the current value with historical values), and calculates or selects the appropriate target field.

[0092] In some embodiments, the uplink parsing cloud function uses matching results (such as field names or selection instructions) to map the fields of the initial parsed data to the target fields, referencing a potential field list.

[0093] S23, the initial parsed data is assigned to the target field to obtain the preset uplink format data.

[0094] Assignment refers to the process of assigning or mapping the values ​​of initially parsed data to target fields, involving data transformation, format adjustment, or value calculation to generate standardized output.

[0095] In some embodiments, the uplink parsing cloud function maps each field of the initial parsed data to the target field according to the parsing logic protocol and historical attribute values, applies format rules (such as data type conversion or unit standardization), and outputs data in a preset uplink format.

[0096] In some embodiments, determining the target field corresponding to the initial parsed data based on the parsing logic protocol and the at least one historical attribute value may include the following operations:

[0097] S30, Based on the parsing logic protocol, determine the context parsing rule set; wherein, the context parsing rule set includes the mapping relationship between different historical attributes and potential fields.

[0098] A context resolution rule set refers to a set of dynamic rules derived from a resolution logic protocol. These rules take into account contextual information, such as historical attribute values, and are used to determine the mapping relationship of data fields.

[0099] A context resolution rule set can be a structured collection of rules that includes association rules between historical attributes and potential fields. For example, a context resolution rule set could be a JSON configuration object that indicates how to map a historical temperature attribute to the current temperature field.

[0100] Potential fields refer to the set of field names or paths that can be used in the predefined uplink format data. They are candidate fields predefined based on the parsing logic protocol and historical attributes, used to store the final parsing results. Potential fields are a candidate list of target fields.

[0101] A mapping relationship refers to the association rule between historical attributes and potential fields. It defines how to select or map a specific potential field based on the type, value, or state of a historical attribute. Mapping relationships can be conditional rules, lookup tables, or functional mappings.

[0102] In some embodiments, the uplink parsing cloud function accesses the rule base defined in the parsing logic protocol, extracts the mapping rules related to the protocol type, and combines them with the definition of historical attributes to construct a context parsing rule set containing the mapping relationship between historical attributes and potential fields.

[0103] S31, match the value of the at least one historical attribute with the context parsing rule set.

[0104] Matching refers to the process of comparing the values ​​of historical attributes with the rule conditions in the context parsing rule set to find the applicable mapping relationship.

[0105] In some embodiments, the uplink parsing cloud function traverses historical attribute values, applies rule conditions (such as if-then statements, range checks, or string matching) from the context parsing rule set, evaluates whether each value meets the rule requirements, and generates a matching result.

[0106] S32, Based on the matching results, determine the target field corresponding to the initial parsed data from the potential fields.

[0107] The matching result refers to the output obtained after matching historical attribute values ​​with the context resolution rule set, indicating which rules were triggered or which mapping relationships applied. The matching result can be a field name, a flag value, or a selection instruction.

[0108] Step 104: Update the preset uplink format data to the device shadow service of the IoT platform, and send the preset uplink format data to the client subscribing to the IoT device.

[0109] The client is responsible for displaying standard JSON data pushed from the cloud (pre-defined upload format) and sending standard JSON commands (such as the command data packets described below). This can be done through mobile apps (iOS, Android, or HarmonyOS applications), web applications, or other terminals.

[0110] The client receives data pushes from the platform through a subscription mechanism. For example, a smart home app on a user's mobile phone subscribes to a data topic for a smart stove, and when there are data updates on the platform, the app automatically receives and displays them.

[0111] Reference Figure 2 The diagram shown is a flowchart illustrating another embodiment of the data transmission method for IoT devices according to this application. This method is executed by an electronic device, which can be implemented by a software system and / or a hardware system. In some embodiments, after sending the preset uplink format data to the client subscribing to the IoT device, the following operations may also be included:

[0112] Step 201: Receive instruction data packets from the client.

[0113] A command data packet is a data packet sent by the client that contains user operation instructions. Command data packets are user-readable, but need to be converted into a format that the device can recognize.

[0114] In some embodiments, the client sends instruction packets to the message gateway or API endpoint of the IoT platform via a network (such as the Internet). The platform receives and stores the instruction packets after verifying the client's identity and subscription permissions.

[0115] Step 202: In response to receiving the instruction data packet, the downlink formatted cloud function corresponding to the IoT device is invoked through the cloud function executor.

[0116] Downlink formatting cloud functions are cloud function scripts specifically designed for formatting downlink commands (from platform to device). These scripts contain logic that converts command packets into binary commands that the device can recognize and can access the device shadow service for stateful command extensions.

[0117] In some embodiments, the cloud function executor loads the corresponding downlink formatted cloud function script from the protocol script library based on the device identifier, and then calls and executes the function.

[0118] Step 203: Use the downlink formatted cloud function to perform a stateful instruction extension operation to convert the instruction data packet into a target instruction packet corresponding to the IoT device.

[0119] Stateful instruction extension operations refer to downlink formatting cloud functions that, when formatting instructions, not only base their operations on the content of the current instruction data packet but also actively access the device shadow service to obtain the current state of the device, thereby dynamically extending the instructions. Stateful instruction extension operations include reading the state from the device shadow, modifying instruction logic based on the state, and generating extended instructions, implementing a read-modify-write loop. For example, when a downlink formatting cloud function parses a temperature setting instruction, it first obtains the current temperature mode from the device shadow to determine whether a preheating instruction needs to be added or the instruction sequence adjusted.

[0120] A target instruction packet refers to a device-recognizable binary instruction packet generated after stateful instruction extension operations. It can employ a highly compressed, custom proprietary binary protocol (or Hex protocol). The target instruction packet can be a low-level format that the device executes directly.

[0121] In some embodiments, after the downlink formatting cloud function is invoked, it first parses the instruction data packet, extracts the instruction content, then accesses the device shadow service to obtain the current device status (such as working mode or historical instructions), combines the status information to execute the instruction extension logic, and finally generates the target instruction packet.

[0122] In some embodiments, the step of using the downlink formatting cloud function to perform a stateful instruction extension operation to convert the instruction data packet into a target instruction packet corresponding to the IoT device may include the following operations:

[0123] S40, parse the instruction data packet to obtain the upper-layer operation instructions.

[0124] Parsing refers to the process of decoding instruction data packets into more structured instruction information, involving extracting fields, validating formats, and applying parsing rules. The parsing operation transforms data packets into a processable representation of instructions. For example, the parsing process may include reading JSON fields, checking instruction integrity, or converting data types.

[0125] Upper-layer operation instructions refer to the abstract representation of the user's intent obtained after parsing the instruction data packet. They can be high-level, user-readable instructions, such as setting parameters or triggering operations.

[0126] In some embodiments, the downlink formatting cloud function reads the contents of the instruction data packet according to predefined format rules (such as JSON mode), extracts key fields (such as command type and parameters), and generates upper-layer operation instructions.

[0127] S41, based on the instruction type of the upper-layer operation instruction, obtain at least one device parameter required to complete the operation corresponding to the instruction data packet from the device shadow service.

[0128] The instruction type refers to the field in the upper-level operation instruction that identifies the operation category, such as setting the temperature, switching modes, or starting the device. The instruction type is used to determine the required device parameters and extended logic.

[0129] At least one device parameter refers to device-related parameters obtained from the device shadow service required to complete the operation. These parameters can be device configurations, state limitations, or historical settings, used for stateful command extensions. Device parameters can include numerical values, strings, or boolean values.

[0130] In some embodiments, the downlink formatting cloud function parses the instruction type in the upper-layer operation instruction, constructs a query request (such as using device identifier and parameter name), calls the API of the device shadow service, and obtains relevant parameters.

[0131] S42, based on the at least one device parameter, the upper-layer operation instruction is extended into one or more lower-layer device instructions.

[0132] Extension refers to the process of modifying or enhancing upper-level operation instructions, combining device parameters with business logic, such as adding additional instructions, adjusting parameter values, or serializing operations, to generate instructions that the device can execute.

[0133] Low-level device instructions refer to the extended device-level instruction representation. They can be low-level instruction abstractions that the device can directly understand, such as intermediate representations of binary commands. Low-level device instructions are intermediate formats before being converted into target instruction packets.

[0134] In some embodiments, the downlink formatting cloud function compares the upper-layer operation instructions with the device parameters, applies business rules, and generates one or more lower-layer device instructions.

[0135] S43, convert the one or more underlying device instructions into the target instruction package according to the protocol format corresponding to the IoT device.

[0136] The protocol format corresponding to IoT devices refers to the communication protocol format used by IoT devices. It can be a highly compressed, custom private binary protocol (or Hex protocol), which defines the encoding rules, field structure and verification mechanism of instructions.

[0137] The target instruction packet refers to the final binary instruction packet that the device can recognize after conversion. It adopts a protocol format and can be directly sent to IoT devices for execution.

[0138] In some embodiments, the downlink formatting cloud function serializes each underlying device instruction into binary data according to protocol rules (such as field mapping and encoding standards), merges multiple instructions (if necessary), adds protocol headers and footers (such as start characters and checksums), and generates the target instruction packet.

[0139] In some embodiments, expanding the upper-layer operation instruction into one or more lower-layer device instructions based on the at least one device parameter may include the following operations: determining an instruction formatting type corresponding to the instruction type according to the instruction type of the upper-layer operation instruction; and generating the one or more lower-layer device instructions based on the instruction formatting type and the at least one device parameter; wherein, if there are multiple lower-layer device instructions, the multiple lower-layer device instructions are merged.

[0140] Command formatting type refers to the category of formatting rules associated with a command type, defining the format and method for converting upper-level operation commands into lower-level device commands. Command formatting types specify extension methods, command structures, or serialization rules based on protocols and business logic.

[0141] In some embodiments, the downlink formatting cloud function parses the instruction type field in the upper-layer operation instruction, queries the formatting type configuration (such as a lookup table or rule engine), and matches the instruction type to the corresponding instruction formatting type.

[0142] Merging refers to the process of combining or optimizing multiple instructions into a more compact sequence when there are multiple instructions from the underlying device, in order to reduce transmission overhead or improve efficiency. Merging operations can include instruction sorting, deduplication, or packaging. For example, merging can combine multiple independent instructions into a single compound instruction, or adjust the order of instructions to conform to the device's processing flow.

[0143] Step 204: Send the target instruction packet to the IoT device.

[0144] In some embodiments, the IoT platform sends target instruction packets to IoT devices via a message delivery component.

[0145] Reference Figure 3The diagram shown illustrates the cloud function-based architecture of the IoT platform in this application. The "uplink" path (data reporting) is: Device -> Cloud platform receives data -> Cloud function processing logic -> (Update shadow attributes and client). The "downlink" path (command control) is: Client -> Cloud platform receives data -> Cloud function processing logic -> Device. The "Update Shadow Attributes" module, acting as the state center, interacts bidirectionally with the "Cloud Function Processing Logic," and is crucial for achieving stateful parsing and formatting.

[0146] Reference Figure 4 The diagram shown illustrates the cloud function's cloud parsing process for sending data from the cloud to the client in this application.

[0147] This process is an uplink process: IoT device → cloud platform → cloud function processing → update shadow attributes → cloud platform → APP, corresponding to... Figure 3 The upstream path.

[0148] Figure 4 The process shown includes the following steps:

[0149] Start: The process begins when the cloud platform receives the raw data packet reported by the home appliance device.

[0150] Parsing binary data into a byte stream: The uplink parsing cloud function decodes the received raw data packet (binary format) into a byte sequence that can be processed.

[0151] Identify the device protocol: Judgment steps. The cloud function examines the beginning of the byte stream (protocol header) to determine the specific communication protocol used by the data packet (such as protocol A or protocol B).

[0152] Entering Protocol A / B Parsing Logic: Based on the protocol identification result, the cloud function enters the corresponding predefined parsing logic branch. Different protocols correspond to different field definitions, lengths, and parsing rules.

[0153] Parsing specific data values: During the protocol parsing process, the cloud function determines whether certain specific data values ​​that need to be processed in conjunction with the device's historical status have been parsed (e.g., a flag representing a sudden temperature change, or a temperature reading that needs to be compared with historical values).

[0154] Access Device Shadow to Obtain Attributes: If “Yes”, the cloud function accesses the device shadow service in a stateful manner to obtain historical attribute values ​​related to the currently parsed data (such as the average temperature over the past hour and the device’s last operating mode).

[0155] Data processing: Cloud functions combine the obtained historical attribute values ​​to process the parsed initial data (such as calculating the rate of change, determining whether the state is abnormal, and supplementing context information).

[0156] Based on the data stored in the corresponding JSON fields: Regardless of whether the device shadow has been accessed, the cloud function will eventually map and store all the processed data into the corresponding fields of a standardized JSON object according to the preset format rules, generating preset uplink format data.

[0157] End: The uplink parsing process is complete, and the preset uplink format data is output.

[0158] For example, a complete example is as follows:

[0159] 1. An IoT device (such as a smart cooktop) reports a binary data packet;

[0160] 2. The cloud platform's message gateway receives the data packet;

[0161] 3. Triggering and parsing: The platform rules engine identifies the identifier of the IoT device, but does not directly forward this data packet to the APP (client). Instead, it passes this data packet and the device context (including the device shadow access capability) to the cloud function executor.

[0162] 4. The cloud function executor loads the corresponding uplink parsing cloud function from the protocol script library based on the device identifier;

[0163] 5. Figure 4 The cloud-based stateful parsing shown is as follows: The uplink parsing cloud function begins execution on the server side: a. Parses the binary data packet into a byte stream and identifies the "protocol type" (e.g., protocol A or protocol B) based on the protocol header; b. Enters different parsing logic branches according to different "protocol types"; c. Stateful interpretation: When the cloud function parses a specific data value (e.g., a temperature value), it actively accesses the device shadow to obtain an associated current state. Based on different attributes in the shadow, the cloud function can store the data value into different corresponding JSON fields; d. The cloud function finally outputs a standardized JSON object including the results of the above advanced logic processing.

[0164] 6. The platform updates this JSON object to the device shadow and simultaneously pushes the JSON data to all mobile apps that have subscribed to the device;

[0165] 7. The mobile app receives simple, easy-to-read JSON and directly renders the UI. The app itself does not need to know any complex state logic such as "memorized temperature" or "parameter list modification".

[0166] Reference Figure 5The diagram shown illustrates the cloud function parsing process from the client sending instructions to the IoT device.

[0167] This process is a downlink command formatting flow: APP -> Cloud Platform -> Cloud Function Processing -> Update Shadow Attributes -> Cloud Platform -> IoT Device, corresponding to... Figure 3 The downward path.

[0168] Figure 5 The process shown includes the following steps:

[0169] Start: The process begins when the cloud platform receives a data packet of instructions sent by the client.

[0170] Receive upper-layer JSON instructions: The downlink formatted cloud function receives instruction data packets encapsulated in JSON format from the client.

[0171] Cloud functions process data: Cloud functions perform preliminary parsing and processing of instructions to identify the basic operational intent.

[0172] Selecting the protocol prefix: a decision-making step. The cloud function determines which instruction format type to use to construct the underlying instructions based on the target device type, its current state (possibly obtained from a device shadow), and the complexity of the instructions. This determines the framework and encoding method of the final binary instruction packet.

[0173] Use standard instructions: suitable for simple and general control commands, directly mapped to device-predefined single opcodes.

[0174] Using parameter settings: This is suitable for commands that require specific parameters (such as setting temperature value or timer duration). Parameter data must be appended after the operation code.

[0175] Use case parameters: Suitable for complex scenario-based commands (such as "start baking mode"), which may need to be expanded into multiple low-level device command sequences, along with a set of parameters.

[0176] Packaging a complete binary instruction package: Based on the selected instruction format type, the cloud function encodes and serializes one or more underlying device instructions according to the device's proprietary binary protocol format, adds necessary protocol headers, checksums, etc., and assembles them into the final target instruction package (binary byte stream).

[0177] In the above process, selecting the protocol prefix is ​​a decision-making process. It determines the subsequent process execution path based on the intent, complexity, and current device status of the received upper-layer JSON command from the cloud function. Using standard commands, using parameter settings, and using scenario parameters are three different process execution paths based on different judgment results. Specifically, selecting the protocol prefix can be determined by the function parsing the JSON command, based on the "command type" and "required parameters," combined with the current device status queried from the device shadow service, to decide which formatting strategy to adopt. If the command is a simple operation that does not require additional parameters or status checks, its command type directly corresponds to the device's predefined opcode, and the cloud function can determine that the command can be executed without expansion, i.e., "using standard commands" is executed.

[0178] If the instruction needs to carry one or more specific running parameters, the instruction type is indicated as "setting", and specific values ​​need to be configured. The cloud function can encode the parameter values ​​according to the protocol format and append them to the opcode. At this time, "use parameter device" is executed.

[0179] If an instruction represents a complex scenario that needs to be broken down into multiple steps or depends on the device state, i.e. there is a need for state instruction expansion, then the cloud function, based on the instruction type, not only performs a simple mapping, but also obtains the current state from the device shadow, and may expand a single upper-level instruction into multiple lower-level device instructions. In this case, the "use case parameters" are executed.

[0180] End: Downlink formatting process complete, outputting target instruction packets that can be directly sent to devices.

[0181] For example, a complete example is as follows:

[0182] 1. The user clicks an operation button on the mobile app (e.g., "Switch to work mode A");

[0183] 2. The mobile app sends a standard and simple JSON command to the cloud platform (e.g., "Set working mode to A").

[0184] 3. Trigger packaging and expansion: The cloud platform receives this JSON instruction and passes it to the cloud function executor;

[0185] 4. The cloud function executor loads the corresponding downlink formatted cloud function;

[0186] 5. Figure 5The cloud-based stateful command extension shown follows: The cloud function begins execution on the server side as follows: a. The cloud function receives a simple, upper-level JSON command; b. Extension: The cloud function converts the JSON data into binary commands; c. The cloud function packages the commands (or merged command packages) into a complete binary command package according to protocol rules; d. The cloud function can also choose to use different protocols (e.g., "standard commands," "multi-parameter settings," or "scenario parameters") depending on the command type.

[0187] 6. The platform will distribute the binary instruction packages generated by the cloud function intelligent extension to IoT devices;

[0188] 7. The device receives and executes the binary instruction that it can uniquely recognize.

[0189] The embodiments provided in this application have the following beneficial effects: 1. High maintainability and instant updates: The protocol logic is uniformly maintained in the cloud. When the device firmware is upgraded, developers only need to update (or release) a new cloud function script in the cloud. This change takes effect immediately for all users worldwide, without the need for APP updates or app store review. 2. Ensures absolute consistency of state across multiple devices: Since the parsing and state logic are only available in the cloud, all clients (iOS, Android, Web) receive the same standard JSON data parsed by the cloud. This fundamentally eliminates the problem of inconsistent state across multiple devices. 3. Implements advanced state logic (core advantage): By utilizing the cooperation of cloud functions and device shadows, advanced state logic that cannot be completed by either the client or the device is implemented. 4. The cloud function becomes the intelligent core, carrying all complex business logic through uplink stateful parsing and downlink stateful instruction extension. 5. Protects core knowledge data and has high security: The most core and complex private binary protocol is securely stored in the cloud function and is not distributed to the client. Even if the client code is decompiled, only simple JSON interactions can be seen, and the core protocol cannot be obtained.

[0190] In addition, regarding the cloud functions, protocol script libraries, and protocol parsing involved in the above embodiments, this application embodiment also provides the following: 1. Selection of cloud function execution environment: The cloud function executor prioritizes using a high-performance, lightweight scripting language runtime to execute the protocol scripts. Compared to traditional heavyweight services, this significantly reduces the computational resource consumption and runtime latency of each message parsing. Especially for high-concurrency, small-data-packet IoT message streams, it can ensure the real-time and high-efficiency processing of data in the cloud, directly reducing operating costs. 2. Modularization and hot loading of the protocol script library: Each parsing or formatting script in the protocol script library is modularized and strictly named and stored according to the device's ProductKey. The cloud function executor has a built-in script caching mechanism (such as LRU strategy). The modular design ensures high precision and high maintainability of the protocol logic; the script caching mechanism can effectively eliminate the cold start latency of cloud function execution, especially in high-frequency message scenarios, ensuring the system's millisecond-level response speed to data reported by the device. 3. Failure tolerance and version control of protocol parsing: Each protocol script contains a version identifier, and the executor has an exception capture and timeout mechanism during parsing. When the latest version of the protocol script fails to execute, the system will automatically fall back to the parsing logic of the previous stable version (if available), or mark the raw binary data as an error and log it. This ensures high system robustness in the face of device firmware version differences or bugs in new protocol scripts, preventing protocol errors from a single device from causing message flow congestion or crashes throughout the entire system.

[0191] This application also provides the following embodiments:

[0192] 1. Scripting Language Extension: The "cloud function" in this application embodiment is not limited to a specific language. The cloud function executor can be configured to support multiple scripting languages ​​such as Java (Janino), Python, JavaScript (Node.js) or Groovy to adapt to different business needs and development teams.

[0193] 2. Hot Script Update: The cloud function executor can monitor changes to the protocol script library and achieve "hot updates". When a script is modified and saved, the executor can automatically load the new version of the script, enabling the protocol logic to take effect within seconds without any downtime.

[0194] 3. A / B Testing and Canary Release: The flexibility of cloud functions can be leveraged to distribute new versions of the parsing script to a specific small group of devices (such as internal test devices) or a specific user group, realizing the "canary release" and A / B testing of the protocol. After successful verification, a full replacement can be performed to further improve stability.

[0195] Reference Figure 6The diagram shown is a functional module schematic of the Internet of Things (IoT) device data transmission system 100 of this application.

[0196] The IoT device data transmission system 100 described in this application is installed in an electronic device (such as an electronic device of an IoT platform). Depending on the functions implemented, the IoT device data transmission system 100 includes a receiving module 110, a calling module 120, a conversion module 130, and a sending module 140. These modules can also be referred to as units, which are a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and are stored in the memory of the electronic device.

[0197] In this embodiment, the functions of each module / unit are as follows:

[0198] The receiving module 110 is used to receive raw data packets reported by IoT devices;

[0199] The module 120 is used to invoke the uplink parsing cloud function corresponding to the IoT device through the cloud function executor in response to receiving the original data packet.

[0200] The conversion module 130 is used to perform a stateful parsing operation using the uplink parsing cloud function to convert the original data packet into a preset uplink format data.

[0201] The sending module 140 is used to update the preset uplink format data to the device shadow service of the IoT platform, and send the preset uplink format data to the client subscribing to the IoT device.

[0202] The specific implementation of the IoT device data transmission system in this application is largely the same as the specific implementation of the IoT device data transmission method described above, and will not be repeated here.

[0203] Reference Figure 7 The diagram shown is a schematic representation of a preferred embodiment of the electronic device of this application.

[0204] The electronic device includes a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.

[0205] Memory 113 is used to store computer programs, such as data transmission programs for Internet of Things (IoT) devices;

[0206] In some embodiments, the processor 111 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 111 can be used to control the overall operation of the electronic device, such as performing data interaction or communication-related control and processing. In this embodiment, the processor 111 is used to run program code stored in the memory 113 or process data.

[0207] The communication interface 112 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The communication interface 112 may also be used to establish a communication connection between the electronic device and other electronic devices.

[0208] The memory 113 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 113 may be an internal storage unit of the electronic device, such as the hard disk or memory of the electronic device. In other embodiments, the memory 113 may also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. of the electronic device. Of course, the memory 113 may include both internal storage units and external storage devices of the electronic device. In this embodiment, the memory 113 can be used to store the operating system and various computer programs installed on the electronic device, such as the program code of the data transmission program for Internet of Things devices. In addition, the memory 113 can also be used to temporarily store various types of data that have been output or will be output.

[0209] Figure 7 Only an electronic device with components 111-114 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0210] In one embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the IoT device data transmission method provided in any of the foregoing method embodiments, including:

[0211] Receive raw data packets reported by IoT devices;

[0212] In response to receiving the original data packet, the uplink parsing cloud function corresponding to the IoT device is invoked through the cloud function executor;

[0213] The uplink parsing cloud function is used to perform a stateful parsing operation to convert the original data packet into a preset uplink format data;

[0214] The preset uplink format data is updated to the device shadow service of the IoT platform, and the preset uplink format data is sent to the clients that subscribe to the IoT devices.

[0215] For a detailed explanation of the above steps, please refer to the above. Figure 1 A flowchart illustrating an embodiment of a data transmission method for IoT devices.

[0216] Furthermore, this application also proposes a computer-readable storage medium that is both non-volatile and volatile. This computer-readable storage medium is any one or any combination of several of the following: hard disk, multimedia card, SD card, flash memory card, SMC, read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, etc. The computer-readable storage medium includes a data storage area and a program storage area. The program storage area stores a data transmission program for an Internet of Things (IoT) device. When executed by a processor, the IoT device data transmission program performs the following operations:

[0217] Receive raw data packets reported by IoT devices;

[0218] In response to receiving the original data packet, the uplink parsing cloud function corresponding to the IoT device is invoked through the cloud function executor;

[0219] The uplink parsing cloud function is used to perform a stateful parsing operation to convert the original data packet into a preset uplink format data;

[0220] The preset uplink format data is updated to the device shadow service of the IoT platform, and the preset uplink format data is sent to the clients that subscribe to the IoT devices.

[0221] The specific implementation of the computer-readable storage medium in this application is largely the same as the specific implementation of the data transmission method for IoT devices described above, and will not be repeated here.

[0222] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, system, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, system, article, or method. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, system, article, or method that includes that element.

[0223] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware simulation platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0224] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data transmission method for Internet of Things (IoT) devices, characterized in that, The method is applied to an Internet of Things (IoT) platform, and the method includes: Receive raw data packets reported by IoT devices; In response to receiving the original data packet, the uplink parsing cloud function corresponding to the IoT device is invoked through the cloud function executor; The uplink parsing cloud function is used to perform a stateful parsing operation to convert the original data packet into a preset uplink format data; The preset uplink format data is updated to the device shadow service of the IoT platform, and the preset uplink format data is sent to the clients subscribed to the IoT devices; The step of using the uplink parsing cloud function to perform a stateful parsing operation to convert the original data packet into a preset uplink format data includes: The uplink parsing cloud function is invoked to perform the following operations: The original data packet is parsed to obtain initial parsed data; Obtain at least one historical attribute value associated with the initial parsed data from the device shadow service of the IoT device, wherein the historical attribute value refers to past values ​​related to the state of the IoT device stored in the device shadow service; The initial parsed data is transformed based on the at least one historical attribute value to obtain the preset uplink format data; The process of transforming the initial parsed data based on the at least one historical attribute value to obtain the preset uplink format data includes: Based on the protocol header in the original data packet, determine the protocol type of the original data packet; Based on the protocol type, determine the parsing logic protocol corresponding to the protocol type; Based on the parsing logic protocol and the at least one historical attribute value, a target field corresponding to the initial parsing data is determined, wherein the target field refers to the field name or path in the preset uplink format data used to store the final parsing result; The initial parsed data is assigned to the target field to obtain the preset uplink format data; The step of determining the target field corresponding to the initial parsed data based on the parsing logic protocol and the at least one historical attribute value includes: Based on the parsing logic protocol, a context parsing rule set is determined; wherein, the context parsing rule set includes the mapping relationship between different historical attributes and potential fields, and potential fields refer to the set of field names or paths that can be used in the preset uplink format data; Match the value of the at least one historical attribute with the context parsing rule set; Based on the matching results, the target field corresponding to the initial parsed data is determined from the potential fields.

2. The data transmission method for IoT devices as described in claim 1, characterized in that, After sending the preset uplink format data to the client subscribing to the IoT device, the process includes: Receive instruction data packets from the client; In response to receiving the instruction data packet, the cloud function executor calls the downlink formatted cloud function corresponding to the IoT device; The downlink formatted cloud function is used to perform a stateful instruction extension operation to convert the instruction data packet into a target instruction packet corresponding to the IoT device; The target instruction packet is sent to the IoT device.

3. The data transmission method for IoT devices as described in claim 2, characterized in that, The step of using the downlink formatted cloud function to perform a stateful instruction extension operation to convert the instruction data packet into a target instruction packet corresponding to the IoT device includes: Perform the following operations using the downlink formatted cloud function: Parse the instruction data packet to obtain the upper-layer operation instructions; Based on the instruction type of the upper-layer operation instruction, at least one device parameter required to complete the operation corresponding to the instruction data packet is obtained from the device shadow service; Based on the at least one device parameter, the upper-layer operation instruction is extended into one or more lower-layer device instructions; The one or more underlying device instructions are converted into the target instruction package according to the protocol format corresponding to the IoT device.

4. The data transmission method for IoT devices as described in claim 3, characterized in that, The step of expanding the upper-layer operation instruction into one or more lower-layer device instructions based on the at least one device parameter includes: Based on the instruction type of the upper-level operation instruction, determine the instruction formatting type corresponding to the instruction type; Based on the instruction formatting type and the at least one device parameter, one or more underlying device instructions are generated; wherein, if there are multiple underlying device instructions, the multiple underlying device instructions are merged.

5. A data transmission system for Internet of Things (IoT) devices, characterized in that, The system is applied to an Internet of Things (IoT) platform, and the system includes: The receiving module is used to receive raw data packets reported by IoT devices; The calling module, in response to receiving the original data packet, invokes the uplink parsing cloud function corresponding to the IoT device through the cloud function executor; and uses the uplink parsing cloud function to perform a stateful parsing operation to convert the original data packet into a preset uplink format data, including: invoking the uplink parsing cloud function to perform the following operations: parsing the original data packet to obtain initial parsed data; obtaining at least one historical attribute value associated with the initial parsed data from the device shadow service of the IoT device; and converting the initial parsed data based on the at least one historical attribute value to obtain the preset uplink format data, wherein the historical attribute value refers to past values ​​related to the state of the IoT device stored in the device shadow service; The conversion module is used to perform a stateful parsing operation using the uplink parsing cloud function to convert the original data packet into a preset uplink format data; The sending module is used to update the preset uplink format data to the device shadow service of the IoT platform, and send the preset uplink format data to the client subscribing to the IoT device; The process of transforming the initial parsed data based on the at least one historical attribute value to obtain the preset uplink format data includes: Based on the protocol header in the original data packet, determine the protocol type of the original data packet; Based on the protocol type, determine the parsing logic protocol corresponding to the protocol type; Based on the parsing logic protocol and the at least one historical attribute value, a target field corresponding to the initial parsing data is determined, wherein the target field refers to the field name or path in the preset uplink format data used to store the final parsing result; The initial parsed data is assigned to the target field to obtain the preset uplink format data; The step of determining the target field corresponding to the initial parsed data based on the parsing logic protocol and the at least one historical attribute value includes: Based on the parsing logic protocol, a context parsing rule set is determined; wherein, the context parsing rule set includes the mapping relationship between different historical attributes and potential fields, and potential fields refer to the set of field names or paths that can be used in the preset uplink format data; Match the value of the at least one historical attribute with the context parsing rule set; Based on the matching results, the target field corresponding to the initial parsed data is determined from the potential fields.

6. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the data transmission method for an Internet of Things device as described in any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the data transmission method for IoT devices as described in any one of claims 1 to 4.

Images