Iot device message receiving method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present application disclose a kind of Internet of Things equipment message receiving method, device, electronic equipment and storage medium, involve Internet of Things communication technical field, wherein, the method includes: first start when equipment carries out security authentication, generates the temporary token of binding validity period and is issued to equipment and enters dormancy, with fixed interval, wake up equipment, through temporary token, initiate quick connection request to server and query the state flag to be received, if flag is invalid, immediately dormancy, when flag is valid, server takes out message from message queue and sends to equipment, equipment executes operation according to message type, reset timeout timer after receiving message each time, after timeout, enter dormancy, generate new token and discard old token after each communication is completed, if token is invalid, back to complete security authentication, realize the security rotation and abnormal recovery of token.The present application effectively solves the problems of high hardware cost, standby power consumption, long authentication time and lack of on-demand wake-up mechanism in the prior art.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and in particular to a method, apparatus, electronic device, and storage medium for receiving messages from IoT devices. Background Technology

[0002] In the field of battery-powered WiFi IoT devices (such as sensors, door sensors, thermometers, and hygrometers), these devices need to periodically receive downlink messages from the cloud. These devices are extremely sensitive to power consumption and are subject to cost constraints; how to ensure timely message reception while maintaining battery life has been a long-standing technical challenge.

[0003] There are three main types of existing solutions. The first type uses dedicated WiFi chips that support low-power modes, reducing power consumption by shutting down the RF front-end during idle periods and periodically waking up to listen for beacon frames. However, these chips are significantly more expensive than ordinary chips, and some do not support dual-band operation, making them difficult to adopt in cost-sensitive products. The second type uses a long-connection keep-alive scheme, where the device maintains a continuous connection to the server, using a power-saving polling mode to reduce idle power consumption. However, keep-alive heartbeats and beacon frame listening still consume power, failing to meet the battery life requirements of several months to several years, and prolonged online operation increases security risks. The third type uses a timed wake-up complete authentication scheme, where the device wakes up at relatively long intervals and performs the complete connection process (including scanning, association, address acquisition, security protocol handshake, certificate verification, and key negotiation), then checks if there are any messages to be sent. However, the complete security authentication process takes hundreds of milliseconds to several seconds on resource-constrained embedded devices, generating significant protocol interaction overhead with each wake-up, and causing unnecessary power waste when there are no messages.

[0004] Therefore, there is an urgent need for a message receiving method for IoT devices that can balance low cost, low power consumption, and low latency and can be implemented on ordinary chips. Summary of the Invention

[0005] The present invention provides a message receiving method for Internet of Things (IoT) devices to address the problems of high hardware cost, high standby power consumption, long single wake-up time, and lack of on-demand wake-up mechanism in existing technologies. The technical solution is as follows: According to one aspect of the present invention, a method for receiving messages from an Internet of Things (IoT) device includes: upon initial startup of the device, reading locally stored device certificate, device key, and product information and performing security authentication; after successful authentication, generating a temporary token with a binding validity period through a server based on the device's unique identifier and issuing it to the device; the device storing the temporary token and entering a sleep state; waking the device from deep sleep at set intervals; upon waking, reading the temporary token and initiating a fast connection request to the server; if the temporary token is valid and has not been used, querying the device's pending reception status flag; if the flag is invalid, immediately... The device connection is disconnected and enters a sleep state. If the flag is valid, the server retrieves the message to be sent from the device message queue and sends it to the device, so that the device performs the corresponding operation according to the message. After each message is received, the timeout timer is reset to a set duration. If the device does not receive a new message within the set duration, it enters a sleep state. After each communication is completed, the server regenerates a new temporary token with a binding validity period and sends it to the device along with the response message. At the same time, the temporary token is marked as invalid. The new temporary token is used for quick connection during the next wake-up. If an invalid token response is received, the token is re-obtained through security authentication.

[0006] In one embodiment, upon initial startup, the device reads its locally stored device certificate, device key, and product information for security authentication. After successful authentication, the server generates a temporary token with a binding validity period based on the device's unique identifier and issues it to the device. The device then stores the temporary token and enters a sleep state through the following steps: Upon initial power-on or restart, the device reads its local non-volatile memory from its device certificate, device key, and product information. The device certificate proves the device's legitimate identity; the device key verifies the authenticity of the device's identity; the product information is used by the server to confirm the product category to which the device belongs. The server performs digital signature chain verification and validity period checks on the device certificate, compares the device key with pre-stored device key records in the server database, and verifies the product information with the registration information of the corresponding product model in the database. After all verifications pass, a temporary token with a binding validity period is generated using a hash operation based on the device's physical address as input parameters, combined with the server's current timestamp and a random number. This token is then sent to the device for storage. The device's central processing unit is suspended, and the wireless radio frequency front-end is turned off, causing the device to enter a sleep state.

[0007] In one embodiment, waking the device from deep sleep at set intervals, reading the temporary token, and initiating a fast connection request to the server is achieved through the following steps: periodically waking the device from sleep at set intervals, initializing the wireless RF front end, reading the temporary token to parse its value and expiration time stamp, and obtaining the device's current time; the interval is driven by the device's internal low-speed clock; if the current time has not exceeded the expiration time stamp and the remaining valid time is greater than 3 seconds, the token is deemed valid, the device is associated with a router and obtains the network protocol address to establish a connection with the server's transmission control protocol, and sends a fast connection request to the server; the fast connection request carries the device's physical address and the temporary token value.

[0008] In one embodiment, if the temporary token is valid and has not been used, the device's pending reception status flag is queried. If the flag is invalid, the device connection is immediately disconnected and the device enters a sleep state. This is achieved through the following steps: checking whether the temporary token corresponding to the device's physical address matches the record in the server database, checking whether the temporary token is valid, checking whether the temporary token has been used, and returning an authentication success response after all checks pass, thus completing a fast connection; locating the pending reception status management record corresponding to the device through the server, reading the flag value of the pending reception status, and if the flag value is invalid, shutting down the wireless radio frequency front-end, disconnecting the transmission control protocol connection, suspending the central processing unit, and causing the device to enter a sleep mode, waiting for the next wake-up cycle.

[0009] In one embodiment, if the flag is valid, the server retrieves the message to be sent from the device message queue through the following steps: If the flag is valid, the device is controlled to enter an active state, and the active timeout time is read from the local configuration as the total duration setting value of the timeout timer, maintaining the transmission control protocol connection between the device and the server; the active timeout time is the maximum tolerable duration for which the device does not receive new data in the active state; the timeout timer is started to count down, and after detecting that the device is in an active state, the message to be sent is retrieved from the message queue corresponding to the device according to the device's physical address; the message queue follows the first-in, first-out principle; the message includes a message type field and message content data.

[0010] In one embodiment, the message is sent to the device, causing the device to perform a corresponding operation based on the message. Each time a message is received, the timeout timer is reset to a set duration. If the device does not receive a new message within the set duration, it enters a sleep state. This is achieved through the following steps: sending each message to the device via an established connection; parsing the type field in the message header; and calling the corresponding local processing function of the device to perform the operation based on the type field. The type field includes self-test instructions, configuration parameter update instructions, and firmware upgrade instructions. Each time the device successfully receives a message, it resets the timeout timer to zero and restarts the timer. When the timeout timer reaches zero, it is determined to have timed out, and the device is controlled to exit the active state, disconnect the transmission control protocol connection, and enter a sleep state.

[0011] In one embodiment, after each communication, a new temporary token with a binding validity period is regenerated by the server and sent to the device along with the response message. Simultaneously, the temporary token is marked as invalid. Upon the next wake-up, the new temporary token is used for quick connection. If an invalid token response is received, a new token is obtained through security authentication. This is achieved through the following steps: After each communication, a new temporary token is generated using a hash operation with the device's physical address, the server's current timestamp, and a new random number as input parameters. This token is then sent to the device, marked as invalid, and the timestamp of invalidation is recorded. The new temporary token is written to the device's record. If the temporary token has exceeded its expiration time, has been marked as invalid, or does not match the device's record in the server database, the temporary token data stored in the local non-volatile memory is cleared, and the token storage area is marked as invalid. The device certificate, device key, and product information stored locally are read again, and the device certificate's signature chain and validity period are re-verified. The device key and product information are then matched against the database. After all verifications are successful, a new temporary token with a binding validity period is generated and sent to the device.

[0012] According to one aspect of the present invention, an Internet of Things (IoT) device message receiving apparatus includes: a temporary token acquisition module, configured to read locally stored device certificate, device key, and product information and perform security authentication when the device is first started; after successful authentication, a server generates a temporary token with a binding validity period based on the device's unique identifier and issues it to the device; the device stores the temporary token and enters a sleep state; and a receiving status query module, configured to wake the device from deep sleep at set intervals, read the temporary token and initiate a fast connection request to the server after waking up; if the temporary token is valid and has not been used, the module queries the device's pending receiving status flag; if the flag is invalid, the module immediately... The device connection is disconnected and enters a sleep state; the downlink message receiving module is used to retrieve the message to be sent from the device message queue through the server if the flag is valid, and send it to the device so that the device can perform the corresponding operation according to the message. After each message is received, the timeout timer is reset to a set duration. If the device does not receive a new message within the set duration, it enters a sleep state; the temporary token rotation module is used to regenerate a new temporary token with a binding validity period through the server after each communication and send it to the device along with the response message. At the same time, the temporary token is marked as invalid. The new temporary token is used for quick connection during the next wake-up. If an invalid token response is received, the token is re-obtained through security authentication.

[0013] According to one aspect of the present invention, an electronic device includes at least one processor and at least one memory, wherein computer-readable instructions are stored on the memory; the computer-readable instructions are executed by one or more of the processors to cause the electronic device to implement the Internet of Things device message receiving method as described above.

[0014] According to one aspect of the present invention, a storage medium has computer-readable instructions stored thereon, which are executed by one or more processors to implement the Internet of Things device message receiving method as described above.

[0015] The beneficial effects of the technical solution provided by this invention are: In the above technical solution, this invention performs security authentication upon initial device startup. The server generates a temporary token with a binding validity period, issues it to the device, and the device enters sleep mode, achieving initial device registration and temporary credential acquisition. Based on this, the device is woken up at fixed intervals, initiates a rapid connection request to the server using the temporary token, and queries the pending status flag. If the flag is invalid, the device immediately enters sleep mode, implementing an on-demand sleep mechanism when there are no messages, significantly reducing standby power consumption. When the flag is valid, the server retrieves a message from the message queue and sends it to the device. The device performs operations according to the message type, resetting the timeout timer after each message received, and entering sleep mode after timeout, enabling continuous reception of multiple messages and automatic timeout exit. After each communication is completed, a new token is generated and the old token is invalidated. If the token is invalid, it reverts to full security authentication, achieving secure token rotation and anomaly recovery. By replacing the full security protocol certificate verification process with temporary token fast authentication, the authentication time is shortened, power consumption is reduced, and with the combination of immediate sleep when there is no message and timeout exit mechanism, the battery life of ordinary chip devices can reach more than 2.7 years with a 30-second wake-up interval. This effectively solves the problems of high hardware cost, high standby power consumption, long authentication time and lack of on-demand wake-up mechanism in the existing technology. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a message receiving method for an Internet of Things (IoT) device according to an exemplary embodiment; Figure 2 This is a schematic diagram of the system structure corresponding to the message receiving method of IoT devices in an application scenario; Figure 3 yes Figure 2 A flowchart illustrating the process of rapid authentication of temporary tokens in the corresponding application scenarios; Figure 4 yes Figure 2 A schematic diagram illustrating the device wake-up and message reception process in the corresponding application scenario; Figure 5 yes Figure 2 A flowchart illustrating the process of Pending pre-setting and message delivery on the APP side in the corresponding application scenario; Figure 6 This is a block diagram of an Internet of Things (IoT) device message receiving apparatus according to an exemplary embodiment; Figure 7 This is a hardware structure diagram of an electronic device according to an exemplary embodiment; Figure 8 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0018] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0019] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this disclosure means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0020] This invention provides a method for receiving messages in IoT devices. It replaces the full certificate verification process with rapid authentication using temporary tokens, reducing the single wake-up authentication time from hundreds of milliseconds to milliseconds. Through the detection of the pending status flag and immediate sleep mode when no message is received, it achieves on-demand wake-up and zero-power standby. Through automatic token rotation and timeout exit mechanisms, it achieves a balance between security and power consumption, effectively solving the problems of high hardware cost, high standby power consumption, and lack of on-demand wake-up mechanisms in existing technologies. This method is applicable to IoT device message receiving devices, which can be electronic devices. The IoT device message receiving method in this invention can be applied to various scenarios, such as receiving messages in IoT devices.

[0021] Please see Figure 1 This invention provides a method for receiving messages in an Internet of Things (IoT) device, which is applicable to electronic devices.

[0022] In the following method embodiments, for ease of description, the execution subject of each step of the method is an electronic device, but this does not constitute a specific limitation.

[0023] like Figure 1As shown, the method may include the following steps: Step 110: When the device is first started, it reads the device certificate, device key and product information stored locally and performs security authentication. After successful verification, the server generates a temporary token with a binding validity period based on the device's unique identifier and issues it to the device. The device stores the temporary token and then enters a dormant state.

[0024] In one possible implementation, after the device is powered on or restarted for the first time, it reads the device certificate, device key, and product information from its local non-volatile memory. The server verifies the device certificate using a digital signature chain and checks its validity period. The device key is compared with the device key record pre-stored in the server's database, and the product information is checked against the registration information of the corresponding product model in the database. After all verifications pass, a temporary token with a binding validity period is generated by hashing the device's physical address as input parameter, combined with the server's current timestamp and a random number. This token is then sent to the device for storage. The device's central processing unit is suspended, and the wireless radio frequency front-end is turned off, putting the device into a sleep state.

[0025] Among them, the device certificate is used to prove the legitimate identity of the device; the device key is used to verify the authenticity of the device identity; and the product information is used by the server to confirm the product category to which the device belongs.

[0026] Specifically, upon initial power-on or restart, the device reads three identity credential parameters from its local non-volatile memory: device certificate, device key, and product information. The device certificate is a digital certificate in X.509 format, used to prove the device's legitimate identity; the device key is a uniquely bound symmetric key used to verify the device's authenticity; and the product information includes the product model and manufacturer number, used by the server to confirm the device's product category. These three parameters together constitute the device's complete identity credentials, and none can be omitted.

[0027] Furthermore, the three identity credential parameters are sent to the server, which then executes a complete two-way authentication process using the Transport Layer Security (TLS) protocol. The server first verifies the digital signature chain and checks the validity of the device certificate to ensure it was issued by a trusted certificate authority and is not expired. Next, it compares the device key byte-by-byte with the pre-stored record of the same device key in the server's database to confirm they are identical. Finally, it checks the product information against the registration information of the corresponding product model in the database to confirm the device belongs to a legitimate product series and has been authorized for access. After all three verifications pass, the server and device complete key negotiation and establish an encrypted communication channel.

[0028] Furthermore, after successful authentication, the server uses the device's physical address as the core input parameter, combines it with the server's current timestamp and a random number, and generates a temporary token value through hash calculation. The server then combines the expiration timestamp with the token value to form a complete temporary token. The server distributes this temporary token to the device through an established encrypted channel. The token's validity period of 95 seconds is set to be more than three times the device wake-up interval, ensuring that the token remains valid during subsequent device wake-ups.

[0029] Furthermore, upon receiving a temporary token, the device persistently stores the token value and expiration timestamp in non-volatile memory, ensuring that the token data is not lost during deep sleep. It then suspends the central processing unit, shuts down the wireless RF front-end, and enters deep sleep mode, reducing the sleep current to the microamp level. The device only enters sleep mode after completing token storage, ensuring complete communication credentials upon the next wake-up.

[0030] In the above process, the embodiments of the present invention ensure the legitimacy and authenticity of the access device by jointly verifying the three credentials of device certificate, device key and product information on the server side, and prevent counterfeit devices from accessing the system; by generating a temporary token with a binding validity period by combining the physical address with the timestamp and random number, a reusable and fast authentication credential is provided for subsequent communication; by setting the token validity period to more than three times the wake-up interval, the token is ensured to remain valid in subsequent wake-ups, so that the device does not need to repeat the complete certificate verification and key negotiation process every time it wakes up, laying the foundation for the low-power operation of the overall solution.

[0031] Step 120: Wake up the device from deep sleep at set intervals. After waking up, read the temporary token and send a fast connection request to the server. If the temporary token is valid and has not been used, query the device's pending status flag. If the flag is invalid, immediately disconnect the device and enter sleep mode.

[0032] In one possible implementation, the device is periodically woken from sleep mode at set intervals, initializes the wireless RF front end, reads the temporary token to parse out the value and expiration time stamp, and obtains the device's current time. If the current time has not exceeded the expiration time stamp and the remaining valid time is greater than 3 seconds, the token is deemed valid. The device is then associated with the router and obtains the network protocol address to establish a connection with the server's transmission control protocol, and sends a fast connection request to the server.

[0033] In one possible implementation, the system checks whether the temporary token corresponding to the device's physical address matches the record in the server database, whether the temporary token is valid, and whether the temporary token has been used. If all checks pass, it returns an authentication success response, completing the fast connection. The server locates the device's corresponding pending status management record, reads the value of the flag bit of the pending status, and if the flag bit value is invalid, it shuts down the wireless radio frequency front end, disconnects the transmission control protocol connection, suspends the central processing unit, and puts the device into sleep mode, waiting for the next wake-up cycle.

[0034] The interval is driven by the device's internal low-speed clock; the fast connection request carries the device's physical address and the value of the temporary token.

[0035] Specifically, the device wakes up from deep sleep at fixed intervals, driven by a low-speed clock inside the device. A wake-up interrupt is triggered when the count reaches a preset threshold. After waking up, the device first initializes the wireless RF front-end to enable WiFi communication. The value of the wake-up interval directly affects the upper limit of message response latency and the basic power consumption level.

[0036] Furthermore, after the device wakes up, it reads the previously stored temporary token from non-volatile memory, parses the token value and expiration timestamp, and obtains the device's current real-time clock. The device compares the current time with the expiration timestamp: if the current time has not exceeded the expiration timestamp and the remaining valid time is greater than 3 seconds, the token is considered valid; otherwise, the token is considered invalid. Performing the initial verification of token validity locally avoids wasting wireless communication power connecting to the server when the token has expired.

[0037] Furthermore, after the token is verified as valid, the device associates with the router via WiFi and obtains the network protocol address, then establishes a Transmission Control Protocol (TCP) connection with the server. Once the connection is established, the device sends a quick connection request to the server, which carries the device's physical address and the value of the temporary token. Unlike existing technologies that require full certificate verification and key negotiation for each wake-up, this quick connection request does not contain any certificate information, only the device identifier and the token value. Therefore, the request data packet is small, the processing speed is fast, and the authentication time for a single wake-up is reduced from hundreds of milliseconds to the millisecond level.

[0038] Furthermore, upon receiving a fast connection request, the server performs three verification operations: checking if the temporary token corresponding to the device's physical address matches the record in the server's database; checking if the temporary token is still valid; and checking if the temporary token has already been used. Once all three checks pass, the server returns an authentication success response, completing the fast connection. This triple verification mechanism effectively prevents forged tokens, expired tokens, and used tokens from passing verification, ensuring communication security.

[0039] Furthermore, after successful fast authentication, the device sends a pending message status query request to the server. Upon receiving the request, the server locates the pending message status management record corresponding to the device and reads the value of the pending message status flag. A valid flag indicates that there are messages waiting to be sent to the device in the server's message queue, while an invalid flag indicates that there are no messages waiting to be sent. The server then returns the flag value to the device.

[0040] Furthermore, after receiving the query result, if the pending status flag is invalid, indicating that the server currently has no messages to send to the device, the device immediately shuts down the wireless RF front-end, disconnects the transmission control protocol connection, suspends the central processing unit, and enters deep sleep mode, waiting for the next 30-second wake-up cycle. If the flag is valid, the process proceeds to step three to continue the message receiving process.

[0041] In the above process, the embodiments of the present invention realize the periodic switching between sleep and working states of the device through a timed wake-up mechanism driven by an internal low-speed clock; by pre-verifying the validity period of the token locally, it avoids the waste of power caused by invalid connections to the server when the token expires; by using a fast connection request that only carries the physical address and token value, it replaces the complete certificate verification process that needs to be executed every time the prior art is woken up, reducing the authentication time from hundreds of milliseconds to the millisecond level; by performing triple verification of token consistency, validity period and usage status on the server side, it completes the rapid authentication of the device while ensuring security; by querying and branching the pending status flag, it realizes an on-demand wake-up mechanism that completes the query in milliseconds and immediately goes into sleep when there is no message, avoiding the extra power waste caused by entering the complete message receiving process in the absence of messages.

[0042] Step 130: If the flag is valid, the server retrieves the message to be sent from the device message queue and sends it to the device, so that the device can perform the corresponding operation according to the message. After each message is received, the timeout timer is reset to the set duration. If the device does not receive a new message within the set duration, it enters a sleep state.

[0043] In one possible implementation, if the flag is valid, the control device enters an active state, reads the active timeout from the local configuration as the total duration setting value of the timeout timer, maintains the transmission control protocol connection between the device and the server, starts the timeout timer to begin counting down, and after detecting that the device is in an active state, retrieves the message to be sent from the message queue corresponding to the device according to the device's physical address.

[0044] In one possible implementation, messages are sent to the device one by one through the established connection. The type field in the message header is parsed, and the corresponding local processing function of the device is called to perform the operation based on the type field. When the device successfully receives a message each time, the timeout timer is reset to zero and restarted. When the timeout timer is zero, it is determined that a timeout has occurred, and the device is controlled to exit the active state, disconnect the transmission control protocol connection, and enter the sleep state.

[0045] The message queue follows the first-in, first-out (FIFO) principle; the active timeout is the maximum tolerable duration for a device to receive no new data while it is in an active state; messages include message type fields and message content data, etc. The type field includes self-test instructions, configuration parameter update instructions, firmware upgrade instructions, etc., none of which are specified here.

[0046] Specifically, when the pending data reception status flag is valid, the device enters an active state. The device reads the active timeout period from its local configuration as the total duration setting for the timeout timer. The default value for this timeout is 60 seconds, representing the maximum tolerable duration for no new data reception while the device is active. The device maintains a Transmission Control Protocol (TCP) connection with the server and starts the timeout timer to begin counting down, preventing the device from maintaining the connection indefinitely due to abnormal conditions. Further, after detecting that the device is in an active state, the server retrieves messages to be sent from the message queue corresponding to the device's physical address. The message queue is organized according to a first-in, first-out (FIFO) principle, ensuring that messages are sent to the devices in the order they arrive at the server. Each message contains two parts: a message type field and message content data. The message type field identifies the category to which the message belongs, and the message content data contains the parameters and payload of the specific instruction.

[0047] Furthermore, the server sends the retrieved messages to the device one by one through the established connection. Upon receiving a message, the device parses the message type field in the message header and calls the corresponding local processing function to perform the operation based on the type field. Message types include various types such as self-test commands, configuration parameter update commands, and firmware upgrade commands. After completing the corresponding operation, the device encapsulates the execution result into a response packet and sends it back to the server through the connection.

[0048] Furthermore, after each successful message reception, the device immediately resets the timeout timer to zero and restarts the countdown. When the timeout timer reaches zero, a timeout is detected, the device exits the active state, disconnects the transmission control protocol connection, and enters a deep sleep state. This mechanism of resetting the timer after each packet reception ensures that in batch configuration scenarios, as long as the user continues to send messages, the device remains active and continues receiving until all messages have been received or no new messages arrive for 60 consecutive seconds.

[0049] In the above process, the embodiments of the present invention achieve classified processing and orderly reception of various downlink commands through the first-in-first-out management of message queues and the parsing and distribution of message type fields, thus meeting the diverse needs of remote management and maintenance of devices. By resetting the timeout timer after each packet reception in the active state, it ensures that the device remains active until all messages are received in batch configuration scenarios, avoiding frequent sleep and wake-up of the device during continuous user operation. Through the automatic exit mechanism after 60 seconds of no data timeout, it ensures that the device can return to the sleep state in a timely manner after message reception is completed or when there is abnormally no data, balancing the flexibility of message reception and power consumption control.

[0050] Step 140: After each communication is completed, a new temporary token with a binding validity period is regenerated by the server and sent to the device along with the response message. At the same time, the temporary token is marked as invalid. The new temporary token is used for quick connection on the next wake-up. If an invalid token response is received, the token is obtained again through security authentication.

[0051] In one possible implementation, after each communication is completed, a new temporary token is generated by hashing the device's physical address, the server's current timestamp, and a new random number as input parameters and issued to the device. The temporary token is marked as invalid, the invalidation timestamp is recorded, and the new temporary token is written to the device's record. If the temporary token has exceeded its expiration time, has been marked as invalid, or does not match the device's record in the server database, the temporary token data stored in the local non-volatile memory is cleared, and the token storage area is marked as invalid.

[0052] In one possible implementation, the device certificate, device key, and product information stored locally on the device are read again, and the device certificate is re-verified for signature chain and validity period. The device key and product information are also verified by database matching. After all verifications are successful, a new temporary token with a binding validity period is generated and issued to the device.

[0053] Specifically, after each communication, the server uses the device's physical address, the current timestamp, and a new random number as input parameters to regenerate a new temporary token through a hash operation, and sends it to the device along with the response message. While generating and issuing the new token, the server marks the currently used old token as invalid and records the invalidation timestamp. Any subsequent connection requests initiated using the old token will be rejected by the server.

[0054] Furthermore, after receiving a new temporary token from the server, the device overwrites the original token storage area in its local non-volatile memory with the new token, replacing the old token, and simultaneously clears the old token data from memory. The device will then use the newly stored temporary token to initiate a fast connection request upon its next wake-up.

[0055] Furthermore, if the server detects any of the following situations when the device initiates a quick connection using a token: the token has expired, the token has been marked as invalid, or the token does not match the device's record in the server's database, the server returns an invalid token error response to the device. Upon receiving the invalid token response, the device clears the temporary token data stored in its local non-volatile memory, sets the token storage area to invalid, and then reverts to step one to re-perform the full security authentication to obtain a new temporary token.

[0056] In the above process, the embodiments of the present invention achieve automatic and secure token rotation by regenerating a new token after each communication and immediately invalidating the old token. This ensures that each token can only be used once within its validity period, effectively preventing replay attacks. The 95-second short validity period further reduces the security impact window after token leakage. Even if the token is intercepted, attackers can only use it for a very short time, significantly reducing security risks. The automatic rollback to full authentication mechanism when the token is invalid ensures that the device can automatically restore communication capabilities when the token expires, is invalidated, or has abnormal data, without manual intervention, thus guaranteeing the long-term reliability and self-healing capability of the system.

[0057] Through the above process, this embodiment of the invention obtains a temporary token through complete security authentication upon device startup, achieving initial device registration and security credential acquisition. By using timed wake-up in conjunction with the temporary token for rapid connection, it replaces the complete transport layer security protocol certificate verification process, reducing the single wake-up authentication time from hundreds of milliseconds to the millisecond level, and lowering authentication power consumption by approximately 80%. Through on-demand querying of the pending status flag and immediate sleep mode when no message is received, it achieves zero-extra-power standby in message-free scenarios, avoiding power waste caused by the device only discovering the absence of a message after completing the entire message receiving process. Through automatic token rotation after each communication and an automatic exit mechanism after 60 seconds of no data timeout, it ensures communication security and controllable power consumption. These four steps work together to enable battery-powered devices using ordinary WiFi chips to achieve a battery life of over 2.7 years with a 30-second wake-up interval, effectively solving the problems of high hardware cost, high standby power consumption, long authentication time, and lack of on-demand wake-up mechanisms in existing technologies.

[0058] In one application scenario, the IoT device message receiving system constructed using the IoT device message receiving method of the present invention receives IoT device messages in a scenario where the user performs a self-test operation on the sensor through an APP.

[0059] like Figure 2 The diagram illustrates the system's structure, which comprises three components: a battery-powered temperature and humidity sensor using a standard WiFi chip, containing six functional modules; a timed wake-up module that wakes the sensor from deep sleep at 30-second intervals to trigger subsequent processes; a connection management module responsible for establishing a communication connection with the server after wake-up, performing full authentication on the first connection, and using temporary tokens for quick authentication on subsequent connections, querying the pending data status after successful connection and deciding whether to enter an active state or immediately go into sleep mode; a message processing module receiving and executing downlink commands pushed by the server when the sensor is in an active state; a sleep control module controlling sensor power consumption based on the pending data status detection results, immediately triggering sleep mode when no messages are received, monitoring data reception timeouts when messages are received, and exiting the active state after timeouts; and a temporary token management module storing temporary tokens issued by the server and updating the tokens after each communication.

[0060] The server-side comprises five functional modules. The full authentication module handles two-way certificate verification, device key verification, and product information confirmation during the initial sensor connection. The temporary token generation module generates a temporary token with a 95-second validity period based on the sensor's physical address and issues it to the device after successful full authentication. The message waiting status management module maintains a message waiting status flag for each sensor, receives setting requests from the app, returns the status when the sensor queries, and clears the flag after message reception or timeout. The message queue module stores messages to be sent according to sensor identifiers. The message push module pushes cached messages to the device when a sensor enters an active state.

[0061] The app includes two functional modules. The user interface provides the entry point for users to interact with the sensors, allowing them to browse configuration items and issue self-test commands. The pending status preset module automatically notifies the server to set the pending status flag of the corresponding sensor to active status when the user enters the configuration page.

[0062] Specifically, the use of this system to receive IoT device messages in scenarios where users perform self-test operations on sensors via an app can include the following steps: Step 1: Obtain a token upon initial device startup.

[0063] When the sensor powers on for the first time, the connection management module reads the device certificate, device key, and product information locally and initiates a full two-way authentication request using the Transport Layer Security (TLS) protocol to the server-side full authentication module. The full authentication module verifies the digital signature chain and checks the validity period of the device certificate, compares the device key with pre-stored records in the database, and verifies the product information against the registration information. After all verifications pass, the temporary token generation module uses the sensor's physical address, the current timestamp, and a random number to generate a temporary token with a 95-second validity period through hash calculation, and sends it to the device via an encrypted channel. The temporary token management module persistently saves the token to non-volatile memory. Subsequently, the sleep control module suspends the sensor's central processing unit, shuts down the wireless RF front-end, and enters deep sleep mode.

[0064] Step 2: Periodically wake up and query the status.

[0065] The timed wake-up module, driven by an internal low-speed clock, triggers the sensor to wake from deep sleep every 30 seconds and initializes the wireless RF front-end. Upon wake-up, the connection management module reads the stored temporary token from the temporary token management module, associates with the router via WiFi and obtains the network protocol address, establishes a transmission control protocol connection with the server, and sends a fast connection request carrying the physical address and token value to the server. After the server verifies the token's validity, the connection management module queries the sensor's pending reception status flag from the pending reception status management module. If the flag is invalid, the sleep control module immediately shuts down the RF front-end, disconnects the connection, suspends the central processing unit, and puts the sensor into deep sleep to await the next cycle.

[0066] Step 3: APP preset status and message reception.

[0067] When a user opens the app and enters the sensor self-test page, the pending reception status preset module automatically notifies the pending reception status management module on the server, setting the pending reception status flag of the corresponding sensor to valid. The user browses the self-test options for approximately 5 to 10 seconds, during which time the sensor completes at least one 30-second wake-up cycle. After the timed wake-up module triggers the wake-up, the connection management module checks that the pending reception status flag is valid, the sleep control module controls the sensor to enter an active state, maintains the connection with the server, and the timeout timer starts a 60-second countdown. After the user clicks "Execute Self-Test," the app sends the self-test command to the server. The message queue module retrieves the self-test command according to the sensor's physical address, and the message push module pushes the command to the sensor through the established connection. The message processing module parses the message type field, calls the self-test processing function to perform the operation, and sends the self-test result back to the server. The timeout timer resets to zero after each message is received. If no new message is received within 60 seconds after the self-test is completed, the sleep control module determines that a timeout has occurred, the sensor exits the active state, disconnects, and enters deep sleep.

[0068] Step 4: Token rotation and anomaly recovery.

[0069] After each communication, the temporary token generation module uses the sensor's physical address, current timestamp, and a new random number as input to generate a new temporary token through hash calculation. This new token is sent to the device along with the response, while the old token is marked as invalid. The temporary token management module overwrites the local storage with the new token. If the token expires due to excessive time, the server returns an invalid token response to the sensor. The sensor clears its local token data and reverts to the full authentication module to re-perform full security authentication to obtain a new token, ensuring reliable long-term operation.

[0070] Through the above process, in this embodiment of the invention, the sensor's response time from the user clicking "Perform Self-Test" is within 1 to 2 seconds, achieving a near real-time message delivery experience. When there is no self-test message, the sensor completes the query within milliseconds after each wake-up and then goes into sleep mode, with minimal power consumption increase. By replacing full certificate verification with a temporary token, the authentication time for a single wake-up is shortened to the millisecond level, and authentication power consumption is reduced by approximately 80%. Based on a 30-second wake-up interval, the sensor using a CR2450 button cell battery consumes approximately 0.51 mAh per day, and the battery life can reach over 2.7 years.

[0071] like Figure 3 The diagram illustrates a flowchart for rapid authentication using temporary tokens. This embodiment follows the aforementioned scenario of issuing self-test commands from temperature and humidity sensors, and combines... Figure 3 The flowchart shown illustrates the rapid authentication process using temporary tokens, detailing the complete interaction between the device and server during the initial connection and subsequent periodic wake-ups. Figure 3 The message exchange sequence between the device and the server is displayed in a vertical timeline format.

[0072] Here, "secret key" refers to the device key, which works in conjunction with the device certificate in a complete TLS two-way authentication process to verify the device's identity and legitimacy on the server side. "Product information" refers to the product information used by the server to confirm the device's product model and configuration parameters during the complete authentication process. "AccessID" refers to a temporary fast token; "Pending" is a message waiting status flag; "WiFi" refers to a wireless network connection; and "TLS" refers to the Transport Layer Security protocol. "APP" refers to a mobile application; and "Server" refers to the server.

[0073] Specifically, it may include the following steps: Step S1, Initial Connection (after device restart).

[0074] When the sensor is powered on or restarted for the first time, there is no valid token in the local temporary token management module, so the connection management module starts the full authentication process.

[0075] First, the sensor connection management module initiates a connection request using the Transport Layer Security (TLS) protocol to the server. Upon receiving the request, the server sends a response requesting a device certificate to the sensor. The sensor connection management module then reads three identity credentials—the device certificate, the device key, and the product information—from its local non-volatile memory and submits them to the server.

[0076] Upon receiving the three credentials, the server-side authentication module performs a joint verification. The module verifies the digital signature chain and checks the validity of the device certificate to ensure it was issued by a trusted authority and is not expired. It then compares the device key byte-by-byte with the pre-stored record of the same device key in the server database. Finally, it verifies the product information against the registration information of the corresponding product model in the database. Once all verifications pass, the server and sensor complete key negotiation for the transport layer security protocol, establishing an encrypted communication channel.

[0077] After key negotiation is complete, the server-side temporary token generation module uses the sensor's physical address as the core input parameter, combines it with the server's current timestamp and a random number, and generates a temporary token value through hash calculation. The expiration timestamp (current time plus 95 seconds) is then combined with the token value to form a complete token. The temporary token generation module sends the generated temporary token to the sensor through the established encrypted channel. Upon receiving the token, the sensor's temporary token management module persistently saves the token value and expiration timestamp to non-volatile memory. Afterward, the sensor's sleep control module suspends the central processing unit, shuts down the wireless RF front-end, and enters deep sleep mode.

[0078] Step S2, subsequent wake-up (30 seconds later).

[0079] The sensor timed wake-up module triggers the sensor to wake up from deep sleep at fixed intervals of 30 seconds. After waking up, the connection management module reads the temporary token stored in step S1 from the temporary token management module. The connection management module parses the token value and expiration time stamp, and compares it with the device's current real-time clock. Since the token's validity period is 95 seconds, and the current time is far from exceeding the expiration time stamp, the token is determined to be valid.

[0080] The connection management module then associates with the router via WiFi and obtains the network protocol address, establishing a Transmission Control Protocol (TCP) connection with the server. Once the connection is established, the connection management module sends a quick connection request to the server, which carries the sensor's physical address and a temporary token value. This quick connection request does not contain any certificate information, only the device identifier and the token value.

[0081] Upon receiving a fast connection request, the server performs three verification operations. First, the server checks if the temporary token corresponding to the sensor's physical address matches the record in the server's database, confirming the correct binding relationship between the token and the device. Second, the server checks if the temporary token is still valid, confirming that the current server time is less than the expiration timestamp. Finally, the server checks if the temporary token has already been used, confirming that it is not in the list of used tokens. Once all three checks pass, the server returns an authentication success response to the sensor, along with the query result for the pending status flag, completing the fast connection.

[0082] Meanwhile, the server-side temporary token generation module uses the sensor's physical address, the current timestamp, and a new random number as input parameters to generate a new temporary token through hash calculation, binding it to a new expiration timestamp (current time plus 95 seconds). The temporary token generation module sends the new temporary token as an additional field in the response message, along with the successful authentication response, to the sensor. While generating and issuing the new token, the server marks the currently used old temporary token as invalid and records the invalidation timestamp. Any subsequent connection requests using the old token will be rejected by the server.

[0083] Upon receiving a response, the sensor connection management module determines whether to enter an active state based on the value of the pending status flag. Simultaneously, it hands over the new temporary token carried in the response to the temporary token management module for processing. The temporary token management module overwrites the original token storage area in the non-volatile memory with the new token, replacing the old token, and simultaneously clears the old token data from memory.

[0084] At this point, the sensor has completed a full wake-up cycle, and the token has been automatically replaced with a new valid token. The sleep control module then determines whether to enter sleep mode or remain active to receive messages based on the pending message status flag.

[0085] Step S3, then wake up again (after 30 seconds).

[0086] The timed wake-up module triggers sensor wake-up again. The connection management module reads the new temporary token updated in step S2 from the temporary token management module; this token is now the currently valid token. The connection management module parses the token value and expiration timestamp, confirming that the current time has not exceeded the expiration timestamp and that there is sufficient remaining valid time; the token is therefore deemed valid. Subsequently, the connection management module establishes a transmission control protocol connection with the server via WiFi connection to the router, sending a fast connection request carrying the sensor's physical address and the new temporary token value to the server.

[0087] Upon receiving the request, the server follows the same verification process as the previous wake-up cycle, performing consistency checks, validity checks, and usage status checks on the new token. Since this token is a newly generated valid token from the previous communication round and has not been used before, all three verifications pass. The server returns an authentication success response to the sensor, and the temporary token generation module regenerates an updated token and sends it to the sensor along with the response, while simultaneously marking the current token as invalid. The sensor's temporary token management module then overwrites its local storage with the updated token.

[0088] The aforementioned token rotation mechanism is executed automatically after each communication, and each token is used only once within its validity period, effectively preventing replay attacks. The 95-second validity period is more than three times the wake-up interval (30 seconds), ensuring the token remains valid in subsequent wake-ups and minimizing the security impact window in the event of token leakage.

[0089] Step S4, handling abnormal situations.

[0090] If the sensor's token expires due to prolonged inactivity (e.g., not waking up for more than 95 seconds, or the server-side token being marked as invalid), the server will fail to verify the quick connection request if it finds that the current server time has exceeded the expiration time stamp or the token has been marked as invalid. The server will then return an invalid token error response to the sensor.

[0091] Upon receiving an invalid token response, the connection management module instructs the temporary token management module to clear the temporary token data stored in its local non-volatile memory and mark the token storage area as invalid. The sensor then reverts to the initial connection process and re-executes the complete Transport Layer Security (TLS) protocol two-way authentication. The server's full authentication module re-verifies the device certificate's signature chain and validity period, and performs database matching verification of the device key and product information. After all verifications pass, the temporary token generation module generates a new temporary token and issues it to the sensor, restoring normal operation.

[0092] In the above process, this embodiment of the invention obtains a temporary token through bidirectional authentication of the complete transport layer security protocol during the initial connection, establishing a secure foundation for subsequent rapid connections. In subsequent 30-second wake-up cycles, the device only needs to carry its physical address and the temporary token value to complete authentication. After successful verification by the server, it returns to a pending state, automatically generating a new token and invalidating the old one, ensuring that each token is used only once within its validity period. By configuring the token validity period to be 95 seconds, which is more than three times the wake-up interval, the token remains valid throughout multiple wake-ups. When the token expires or becomes invalid, the device automatically reverts to complete authentication to re-obtain the token, ensuring long-term reliable system operation. This process completes each rapid connection in milliseconds, reducing the single wake-up authentication time from hundreds of milliseconds to the millisecond level, and reducing authentication power consumption by approximately 80%.

[0093] like Figure 4 The diagram illustrates the process of device wake-up and message reception. This embodiment follows the aforementioned scenario of temperature and humidity sensor self-test command issuance, and combines... Figure 4 The flowchart shown illustrates the device wake-up and message reception process, detailing the complete decision-making and execution process from sensor wake-up from deep sleep to message reception completion or re-entry into sleep mode. Here, accessID refers to a temporary quick token; Pending indicates a message waiting status; WiFi refers to a wireless network connection; APP refers to a mobile application; and Server refers to a server.

[0094] Figure 4 The entire processing path of the sensor within a single wake-up cycle is shown in a top-down vertical flowchart format, as detailed below: Wake-up and Connection Phase: The sensor wakes up from deep sleep mode, triggered by a timed wake-up module. This module counts at fixed intervals of 30 seconds, driven by an internal low-speed clock. When the count reaches a preset threshold, a wake-up interrupt is generated, waking the sensor from deep sleep. After waking up, the sensor initializes its wireless RF front-end, preparing for network communication.

[0095] The connection management module initiates the WiFi connection process. First, it associates with the router via WiFi and obtains the network protocol address, establishing a Transmission Control Protocol (TCP) connection with the server. After the connection is established, it proceeds to the token validity verification node.

[0096] Token validity check and branching: The connection management module determines whether the current device holds a valid temporary token. This determination is performed as follows: The connection management module reads the temporary token from non-volatile memory, parses the token value and expiration timestamp, obtains the device's current real-time clock time, and compares the current time with the expiration timestamp. If the current time has not exceeded the expiration timestamp and the remaining valid time is greater than 3 seconds, it is determined that the device holds a valid token and enters the fast authentication path. If the current time has exceeded the expiration timestamp or the remaining valid time is less than 3 seconds, it is determined that this is the first connection or the token has expired, and the device enters the full authentication path.

[0097] If the connection is determined to be the first time or the token has expired, the connection management module performs a full Transport Layer Security (TLS) two-way authentication. This process includes: the sensor submitting three identity credentials to the server: a device certificate, a device key, and product information. The server's full authentication module verifies the device certificate's digital signature chain and checks its validity period, compares the device key with pre-stored records in the database, and verifies the product information with registration information. After all verifications pass, key negotiation is completed. Upon authentication, the server's temporary token generation module uses the sensor's physical address, the current timestamp, and a random number to generate a temporary token with a 95-second validity period through hash calculation, and sends it to the sensor via an encrypted channel. Upon receiving the temporary token, the sensor's temporary token management module writes the token value and the expiration timestamp into non-volatile memory for persistent storage, and then proceeds to the subsequent fast authentication process.

[0098] If a valid token is determined to be in possession, the connection management module directly uses that token for rapid authentication, skipping the full certificate verification process. The connection management module sends a rapid connection request to the server via the established Transmission Control Protocol (TCP) connection, carrying the sensor's physical address and the temporary token value. Upon receiving the request, the server checks whether the token matches the database record, is within its validity period, and has not already been used. If all checks pass, it returns a successful authentication response. This rapid authentication process does not involve any certificate exchange or key negotiation, reducing the authentication time to the millisecond level.

[0099] Receive status query and branch processing: After successful fast authentication, the connection management module queries the server for the receive status flag. The server locates the receive status management record corresponding to the sensor, reads the value of the receive status flag, and returns the result to the sensor.

[0100] If the server returns "No message to be received," meaning the "to be received" status flag is invalid, it indicates that there are no messages in the server's message queue to be sent to the sensor. In this case, the connection management module instructs the sleep control module to execute an immediate sleep procedure. The sleep control module shuts down the wireless RF front-end, disconnects the transmission control protocol connection, suspends the central processing unit, and puts the sensor into deep sleep mode, waiting for the next 30-second wake-up cycle. In this path, the total time from wake-up to sleep again is only the sum of the WiFi connection time and the status query time; it does not enter an active message receiving state, thus minimizing power consumption when there are no messages. If the server returns "Message to be received," meaning the "to be received" status flag is valid, the sensor enters an active state, ready to receive downlink messages.

[0101] Message Reception and Timeout Management Phase: After the sensor enters active state, the sleep control module controls the sensor to maintain a transmission control protocol connection with the server, with an active maintenance time of 25 seconds. The server-side message queue module retrieves messages to be sent from the message queue corresponding to the sensor based on the sensor's physical address. The message push module pushes the messages to the sensor one by one through the established connection. The sensor message processing module receives and processes the downlink messages.

[0102] Once the sensor enters active mode, a timeout timer is started, with a timeout period set to 60 seconds. During the active period, the sensor continuously listens for new messages. If a new message is received during active mode, the message processing module parses the message type field in the message header and calls the corresponding local processing function on the sensor to perform the operation based on the type field. Message types include self-test commands, configuration parameter update commands, and firmware upgrade commands, etc. After the sensor completes the corresponding operation, it encapsulates the execution result into a response packet and sends it back to the server via the connection. At the same time, the sleep control module resets the active timeout timer to zero and restarts the timing.

[0103] If no new messages are received during the active period, the sleep control module continuously monitors the timeout timer. When the active timeout timer reaches 60 seconds without data (i.e., no new messages are received for 60 consecutive seconds), the sleep control module determines that a timeout has occurred. At this time, the sleep control module controls the sensor to exit the active state, disconnects the transmission control protocol connection, shuts down the wireless RF front end, suspends the central processing unit, and puts the sensor into deep sleep mode, waiting for the next 30-second wake-up cycle.

[0104] Through the above process, in this embodiment of the invention, the sensor immediately disconnects and enters deep sleep when there are no messages to be received; when there are messages to be received, it remains active for 25 seconds to wait for message reception. If a message is received within the active window, the timeout timer is reset, and the sensor remains active for a maximum of 60 seconds without data before exiting the active state. By using a token validity determination branch, full authentication is performed to obtain a token upon first connection or when the token expires. Subsequent wake-ups skip the certificate verification process, achieving rapid authentication.

[0105] like Figure 5 The diagram illustrates the process of Pending pre-setting and message delivery on the APP side. This embodiment follows the aforementioned scenario of issuing self-test commands from the temperature and humidity sensor, and combines... Figure 5 The flowchart shown illustrates the pre-setting of the pending message status and the message delivery process on the APP side, detailing the complete interaction sequence between the user, the APP, the server, and the device. Here, "Pending" refers to the message waiting-to-receive status flag; "APP" refers to the mobile application.

[0106] Figure 5 The entire process, from the user entering the configuration page to the device receiving the message and finally going to sleep, is displayed in a vertical timeline format. The details are as follows: Preset Pre-received Status Phase: The user opens the app and enters the sensor self-test page. The pre-received status preset module on the app automatically triggers the preset process when it detects the user entering the configuration or control page. The module sends a pre-received status setting request to the server via the network connection between the app and the server. This request carries the device identifier of the target sensor. This step requires no manual user intervention and is completed automatically while the user browses the page content.

[0107] After receiving a request to set the pending status, the pending status management module locates the management record corresponding to the sensor, sets the pending status flag to valid, and records the setting timestamp. Subsequently, when the sensor initiates a pending status query, the server will return a query result showing the flag as valid.

[0108] Device Wake-up and Ready Phase: During the approximately 5 to 10 seconds that the user browses the self-test options, the sensor operates according to its inherent 30-second wake-up cycle. The timed wake-up module triggers the sensor to wake up from deep sleep and executes the complete wake-up and quick connection process. The connection management module reads the temporary token, associates with the router via WiFi and obtains the network protocol address, establishes a transmission control protocol connection with the server, and sends a quick connection request carrying the physical address and token value to the server. After the server verifies the token's validity, the connection management module queries the server for the pending reception status flag. At this time, since the APP has already preset the sensor's pending reception status flag to valid in step one, the pending reception status management module returns a query result indicating that the flag is valid. After the sensor connection management module receives the valid flag, the sleep control module controls the sensor to enter the active state, maintains the transmission control protocol connection with the server, and waits to receive downlink messages.

[0109] The core mechanism in this phase leverages the time difference between when a user browses the configuration page. It typically takes several seconds to tens of seconds from when a user enters the page to when they actually click to perform an action. The sensor wakes up every 30 seconds, and it's highly likely that it will complete at least one wake-up and detect the pending status flag within this timeframe, thus entering an active-ready state ahead of time. The device doesn't need to know the user's intentions in advance; it responds passively entirely based on the pending status flag from the server.

[0110] Message delivery and execution phase: After browsing the self-check options, the user clicks the "Execute Self-Check" button. The app encapsulates the user-triggered self-check command into a downlink message and sends it to the server via the network connection between the app and the server. This message contains a message type field (identified as a self-check command) and message content data.

[0111] After receiving the self-test command from the APP, the server stores the command in the corresponding message queue according to the sensor's physical address. Since the sensor is currently active and maintaining a transmission control protocol connection with the server, the message push module, upon detecting the device's active state, immediately retrieves the self-test command from the message queue and pushes the command to the sensor through the established connection.

[0112] After receiving a self-test command, the sensor message processing module parses the message type field in the message header and identifies the command as a self-test command. Based on the type field, the message processing module calls the corresponding local self-test processing function on the sensor to perform the operation. The sensor performs the self-test, encapsulates the self-test result into a response packet, and sends it back to the server via the connection. Upon receiving the execution result, the server forwards it to the app, which then displays the self-test completion status and result information to the user on the user interface.

[0113] During the continuous message delivery phase: If the user needs to send another message, such as adjusting the sensor's reporting interval configuration after self-testing, the app sends the new configuration command to the server again. The server's message queue module stores the new command in the message queue according to the sensor's physical address, and the message push module pushes the new command to the sensor through the currently maintained connection. The sensor message processing module also parses the message type field, calls the corresponding configuration update processing function to perform the operation, and sends the execution result back to the server. Each time the sensor successfully receives a message, the sensor's internal timeout timer resets to zero and restarts its 60-second countdown, ensuring that the connection remains open throughout the user's continuous operations.

[0114] Through the above process, this embodiment of the invention automatically notifies the server to set the pending reception status flag to valid when the user enters the configuration page via the APP-side pending reception status preset module. Utilizing the time window of several seconds to tens of seconds during the user's page browsing, the device detects the valid flag during periodic wake-ups and enters the active ready state ahead of time. This reduces the latency from user click to device response from a worst-case scenario of waiting for a full wake-up interval (30 seconds) to within 1 to 2 seconds. After entering the active state, the device maintains its connection with the server. The APP can continuously send multiple messages such as self-test commands and configuration updates. The device resets the 60-second timeout timer after each packet reception, ensuring uninterrupted connection during batch operations. After all operations are completed and there are no new messages for 60 consecutive seconds, the device automatically exits the active state and enters deep sleep, balancing message reception flexibility and power consumption control.

[0115] The following are embodiments of the apparatus of the present invention, which can be used to execute the message receiving method for IoT devices involved in the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the method embodiments of the message receiving method for IoT devices involved in the present invention.

[0116] Please see Figure 6 This invention provides an Internet of Things (IoT) device message receiving device 800.

[0117] The IoT device message receiving device 800 includes, but is not limited to: a temporary token acquisition module 810, a receiving status query module 830, a downlink message receiving module 850, and a temporary token rotation module 870.

[0118] The temporary token acquisition module 810 is used to read the device certificate, device key and product information stored locally and perform security authentication when the device is first started. After successful verification, the server generates a temporary token with a binding validity period based on the device's unique identifier and issues it to the device. The device stores the temporary token and then enters a dormant state.

[0119] The receiving status query module 830 is used to wake up the device from deep sleep at set intervals. After waking up, it reads the temporary token and sends a fast connection request to the server. If the temporary token is valid and has not been used, it queries the device's pending receiving status flag. If the flag is invalid, it immediately disconnects the device and enters sleep mode.

[0120] The downlink message receiving module 850 is used to retrieve the message to be sent from the device message queue through the server and send it to the device if the flag is valid, so that the device can perform the corresponding operation according to the message. After each message is received, the timeout timer is reset to the set duration. If the device does not receive a new message within the set duration, it enters a sleep state.

[0121] The temporary token rotation module 870 is used to regenerate a new temporary token with a binding validity period after each communication and send it to the device along with the response message. At the same time, the temporary token is marked as invalid. The new temporary token is used for quick connection on the next wake-up. If an invalid token response is received, the token is obtained again through security authentication.

[0122] It should be noted that the IoT device message receiving method provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the IoT device message receiving device will be divided into different functional modules to complete all or part of the functions described above.

[0123] Furthermore, the IoT device message receiving device and the IoT device message receiving method provided in the above embodiments belong to the same concept, and the specific way in which each module performs its operation has been described in detail in the method embodiments, and will not be repeated here.

[0124] Figure 7 A schematic diagram of the structure of an electronic device according to an exemplary embodiment is shown.

[0125] It should be noted that this electronic device is merely an example adapted to the present invention and should not be construed as providing any limitation on the scope of use of the present invention. Furthermore, this electronic device should not be interpreted as requiring or depending on any particular feature. Figure 7 One or more components of the exemplary electronic device 2000 shown.

[0126] The hardware structure of electronic devices 2000 can vary significantly due to differences in configuration or performance, such as... Figure 7 As shown, the electronic device 2000 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0127] Specifically, power supply 210 is used to provide operating voltage for various hardware devices on electronic device 2000.

[0128] Interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. Of course, in other examples adapted to this invention, interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc. Figure 7 As shown, this does not constitute a specific limitation.

[0129] The memory 250 serves as a carrier for resource storage and can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it include the operating system 251, application programs 253, and data 255, etc., and the storage method can be temporary storage or permanent storage.

[0130] The operating system 251 is used to manage and control the various hardware devices and application programs 253 on the electronic device 2000, so as to enable the central processing unit 270 to perform calculations and processing on the massive data 255 in the memory 250. It can be Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0131] Application 253 is a computer-readable instruction based on operating system 251 that performs at least one specific task, and may include at least one module ( Figure 7 (Not shown), each module may contain computer-readable instructions for electronic device 2000. For example, the Internet of Things (IoT) device message receiving device can be considered as application 253 deployed on electronic device 2000.

[0132] Data 255 may be signal information, etc., and is stored in memory 250.

[0133] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read computer-readable instructions stored in the memory 250, thereby performing operations and processing on massive amounts of data 255 stored in the memory 250. For example, an IoT device message receiving method may be implemented by the central processing unit 270 reading a series of computer-readable instructions stored in the memory 250.

[0134] Furthermore, the present invention can also be implemented through hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of the present invention is not limited to any specific hardware circuit, software, or combination thereof.

[0135] Please see Figure 8 This invention provides an electronic device 4000, which may include: a desktop computer, a laptop computer, a server, etc., with sensor recognition capabilities.

[0136] exist Figure 8 In this context, the electronic device 4000 includes at least one processor 4001 and at least one memory 4003.

[0137] The data interaction between the processor 4001 and the memory 4003 can be achieved through at least one communication bus 4002. This communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0138] Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0139] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0140] The memory 4003 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program instructions or code in the form of instructions or data structures and accessible by the electronic device 4000, but not limited thereto.

[0141] The memory 4003 stores computer-readable instructions, and the processor 4001 can read the computer-readable instructions stored in the memory 4003 through the communication bus 4002.

[0142] The computer-readable instructions are executed by one or more processors 4001 to implement the IoT device message receiving method in the above embodiments.

[0143] Furthermore, this embodiment of the invention provides a storage medium storing computer-readable instructions, which are executed by one or more processors to implement the IoT device message receiving method described above.

[0144] This invention provides a computer program product, which includes computer-readable instructions stored in a storage medium. One or more processors of an electronic device read the computer-readable instructions from the storage medium, load and execute the computer-readable instructions, thereby enabling the electronic device to implement the IoT device message receiving method as described above.

[0145] Compared with related technologies, the beneficial effects of the present invention are: 1. This invention eliminates the need for expensive dedicated low-power WiFi chips. Through software-level temporary token fast authentication, periodic short-term wake-up, and waiting-to-receive status detection mechanisms, low-power cloud message reception for battery-powered devices can be achieved on ordinary WiFi chips, significantly reducing hardware costs. It also supports 2.4G and 5G dual-band, making it suitable for cost-sensitive consumer-grade IoT sensor products.

[0146] 2. This invention replaces the complete two-way certificate verification and key negotiation process of the transport layer security protocol with a temporary token, so that the device only needs to carry the physical address and token value to complete the server authentication each time it wakes up. The authentication time of a single wake-up is shortened from hundreds of milliseconds to the millisecond level, the authentication power consumption is reduced, the protocol interaction overhead of a single wake-up is significantly reduced, and the service life of battery-powered devices is extended.

[0147] 3. This invention uses a query and branching mechanism for the pending status flag to enable the device to enter sleep mode after completing only the connection and status query when there are no pending messages, without entering the full message receiving active process. The time taken for a single wake-up without a message is only the time required for WiFi connection and status query, thus achieving minimal power consumption standby in the absence of messages and avoiding the waste of power when the device performs the full message receiving process every time it wakes up and finds that there are no messages.

[0148] 4. This invention uses a mechanism that pre-sets a pending status flag on the APP side. When the user enters the configuration page, the server is automatically notified to set the device's pending status flag to valid. By utilizing the time difference when the user browses the configuration items, the device can detect the valid flag in the next wake-up cycle and enter the active state in advance. When the user actually sends a message, the device is already in a ready state, which reduces the perceived message delivery delay and significantly improves the user experience.

[0149] 5. This invention employs an automatic rotation mechanism where the server automatically regenerates a new temporary token with a binding validity period after each communication and immediately invalidates the old token. This ensures that each token is used only once within its validity period, effectively preventing replay attacks. Furthermore, the short validity period of the token further reduces the security impact window after token leakage. Combined with the device's ability to automatically revert to full authentication when the token is invalid, this invention ensures communication security while guaranteeing long-term system operation without manual intervention.

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

[0151] The above description is only a partial embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for receiving messages in an Internet of Things (IoT) device, characterized in that, The method includes: When the device is first started, it reads the device certificate, device key and product information stored locally and performs security authentication. After successful verification, the server generates a temporary token with a binding validity period based on the device's unique identifier and issues it to the device. The device stores the temporary token and then enters a dormant state. The device is woken up from deep sleep at set intervals. After waking up, the temporary token is read and a fast connection request is sent to the server. If the temporary token is valid and has not been used, the device's pending status flag is queried. If the flag is invalid, the device connection is immediately disconnected and the device enters sleep mode. If the flag is valid, the server retrieves the message to be sent from the device message queue and sends it to the device, so that the device performs the corresponding operation according to the message. After each message is received, the timeout timer is reset to the set duration. If the device does not receive a new message within the set duration, it enters a sleep state. After each communication is completed, a new temporary token with a binding validity period is regenerated by the server and sent to the device along with the response message. At the same time, the temporary token is marked as invalid. The new temporary token is used for quick connection on the next wake-up. If an invalid token response is received, the token is obtained again through security authentication.

2. The IoT device message receiving method as described in claim 1, characterized in that, Upon initial startup, the device reads the locally stored device certificate, device key, and product information for security authentication. After successful verification, the server generates a temporary token with a binding validity period based on the device's unique identifier and issues it to the device. The device then stores the temporary token and enters a dormant state, including: Upon initial power-on or restart, the device reads its device certificate, device key, and product information from its local non-volatile memory. The device certificate is used to prove the device's legitimate identity; the device key is used to verify the authenticity of the device's identity; and the product information is used by the server to confirm the product category to which the device belongs. The server verifies the digital signature chain and checks the validity period of the device certificate, compares the device key with the device key record pre-stored in the server database, and verifies the product information with the registration information of the corresponding product model in the database. After all verifications pass, a temporary token with a binding validity period is generated by hashing the device's physical address as input parameter, combined with the server's current timestamp and a random number, and sent to the device for storage. The device's central processing unit is then suspended, the wireless radio frequency front-end is turned off, and the device enters a sleep state.

3. The IoT device message receiving method as described in claim 1, characterized in that, The step of waking the device from deep sleep at set intervals, reading the temporary token after waking, and initiating a fast connection request to the server includes: The device is periodically woken from sleep mode at set intervals, initializes the wireless radio frequency front end, reads the temporary token to parse out the value and expiration time stamp, and obtains the current time of the device; the interval is driven by the device's internal low-speed clock. If the current time has not exceeded the expiration timestamp and the remaining valid time is greater than 3 seconds, the token is deemed valid, the router is associated, the network protocol address is obtained, and a connection is established with the server's transmission control protocol. A fast connection request is sent to the server; the fast connection request carries the device's physical address and the temporary token value.

4. The IoT device message receiving method as described in claim 1, characterized in that, If the temporary token is valid and has not been used, the device's pending status flag is queried. If the flag is invalid, the device connection is immediately disconnected and the device enters a sleep state, including: Check if the temporary token corresponding to the physical address of the device matches the record in the server database, check if the temporary token is within its validity period, check if the temporary token has been used, and return an authentication success response after all checks pass, completing the fast connection; The server locates the corresponding pending status management record of the device, reads the value of the flag bit of the pending status, and if the value of the flag bit is invalid, the wireless radio frequency front end is turned off, the transmission control protocol connection is disconnected, the central processing unit is suspended, and the device enters sleep mode, waiting for the next wake-up cycle.

5. The IoT device message receiving method as described in claim 1, characterized in that, If the flag is valid, the process of retrieving the message to be sent from the device message queue via the server includes: If the flag is valid, the device is controlled to enter an active state, and the active timeout time is read from the local configuration as the total duration setting value of the timeout timer, maintaining the transmission control protocol connection between the device and the server; the active timeout time is the maximum tolerable duration for which the device does not receive new data in the active state; The timeout timer is started to count down. After detecting that the device is in an active state, the message to be sent is retrieved from the message queue corresponding to the device according to the device's physical address. The message queue follows the first-in, first-out principle. The message includes a message type field and message content data.

6. The IoT device message receiving method as described in claim 1, characterized in that, The message is sent to the device, causing the device to perform a corresponding operation based on the message. Each time a message is received, the timeout timer is reset to a set duration. If the device does not receive a new message within the set duration, it enters a sleep state, including: The messages are sent to the device one by one through the established connection. The type field in the message header is parsed, and the corresponding local processing function of the device is called to perform the operation according to the type field. The type field includes self-test instructions, configuration parameter update instructions, and firmware upgrade instructions. Each time the device successfully receives a message, it resets the timeout timer to zero and restarts the timer. When the timeout timer reaches zero, it is determined that a timeout has occurred, and the device is controlled to exit the active state, disconnect the transmission control protocol connection, and enter the sleep state.

7. The IoT device message receiving method as described in claim 1, characterized in that, After each communication is completed, a new temporary token with a binding validity period is regenerated by the server and sent to the device along with the response message. Simultaneously, the temporary token is marked as invalid. The new temporary token is used for quick connection upon the next wake-up. If an invalid token response is received, the token is re-obtained through security authentication, including: After each communication is completed, a new temporary token is generated by hashing the device's physical address, the server's current timestamp, and a new random number as input parameters. The token is then sent to the device, marked as invalid, the timestamp of invalidation is recorded, and the new temporary token is written to the device. If the temporary token has expired, the temporary token has been marked as invalid, or the temporary token does not match the device record in the server database, then the temporary token data stored in the local non-volatile memory is cleared, and the token storage area is marked as invalid. The process re-executes the reading of the device certificate, device key, and product information stored locally on the device, and re-verifies the signature chain and validity period of the device certificate, and performs database matching verification on the device key and product information. After all verifications are successful, a new temporary token with a bound validity period is generated and issued to the device.

8. A message receiving device for Internet of Things (IoT) devices, characterized in that, The device includes: The temporary token acquisition module is used to read the device certificate, device key and product information stored locally and perform security authentication when the device is first started. After successful verification, the server generates a temporary token with a binding validity period based on the unique identifier of the device and issues it to the device. The device stores the temporary token and then enters a dormant state. The receiving status query module is used to wake up the device from deep sleep at set intervals. After waking up, it reads the temporary token and sends a fast connection request to the server. If the temporary token is valid and has not been used, it queries the receiving status flag of the device. If the flag is invalid, it immediately disconnects the device connection and enters sleep state. The downlink message receiving module is used to retrieve the message to be sent from the device message queue through the server and send it to the device if the flag is valid, so that the device can perform corresponding operations according to the message. After each message is received, the timeout timer is reset to a set duration. If the device does not receive a new message within the set duration, it enters a sleep state. The temporary token rotation module is used to regenerate a new temporary token with a binding validity period after each communication and send it to the device along with the response message. At the same time, the temporary token is marked as invalid. The new temporary token is used for quick connection on the next wake-up. If an invalid token response is received, the token is obtained again through security authentication.

9. An electronic device, characterized in that, include: At least one processor and at least one memory, wherein, The memory stores computer-readable instructions; The computer-readable instructions are executed by one or more of the processors, causing the electronic device to implement the IoT device message receiving method as described in any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that, The computer-readable instructions are executed by one or more processors to implement the IoT device message receiving method as described in any one of claims 1 to 7.

Images