A device hibernation scheduling method and system

Abstract

The application discloses a device hibernation scheduling method and system, the method comprising: when a to-be-processed event is detected, performing device mode switching based on a target mode switching strategy according to the event priority of the to-be-processed event and the target mode switching strategy matched from the current device mode of the device; wherein the device mode comprises a deep hibernation mode, a light hibernation mode and an active mode, the Bluetooth radio of the slave device is turned off and only an interrupt wake-up is reserved in the deep hibernation mode, the slave device is in a Bluetooth broadcast mode and does not maintain a Bluetooth connection in the light hibernation mode, and the slave device is in a Bluetooth connection state in the active mode; when the slave device is in the active mode, a power consumption demand packet is sent to a master device, so that the master device calculates connection parameters based on the power consumption demand packet; the connection parameters sent by the master device are received, and data communication is performed with the master device based on the connection parameters. The application realizes dynamic scheduling of the hibernation depth of the slave device to reduce power consumption.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a device hibernation scheduling method and system. Background Technology

[0002] In Bluetooth Low Energy (BLE) device applications, to extend battery life, devices typically enter a sleep state when there is no data transmission. In related technologies, sleep scheduling for slave devices usually employs a fixed-period wake-up mechanism, checking for pending events upon wake-up. This approach means that even if only low-priority events need processing, the device will be frequently woken up at fixed intervals, leading to unnecessary energy consumption. Furthermore, existing BLE connection parameters are usually set unilaterally by the master device, and these parameters do not match the actual communication needs of the slave device, resulting in excessive communication latency or wasted power during wake-up.

[0003] Therefore, how to dynamically adjust the sleep depth of the device to reduce power consumption is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this application is to provide a device hibernation scheduling method and system, which realizes dynamic scheduling of the device's hibernation depth to reduce power consumption.

[0005] To achieve the above objectives, this application provides a device hibernation scheduling method applied to a slave device, the method comprising: When a pending event is detected, a target mode switching strategy is matched based on the event priority of the pending event and the current device mode of the slave device, and a device mode switch is performed based on the target mode switching strategy. The device modes include deep sleep mode, shallow sleep mode and active mode. In the deep sleep mode, the Bluetooth radio frequency of the slave device is turned off and only interrupt wake-up is retained. In the shallow sleep mode, the slave device is in Bluetooth broadcast mode and does not maintain Bluetooth connection. In the active mode, the slave device is in Bluetooth connected state. When the slave device is in active mode, it sends a power consumption requirement packet to the master device, so that the master device can calculate the connection parameters based on the power consumption requirement packet; wherein, the power consumption requirement packet includes the highest event priority among all the pending events, the size of the data to be transmitted, and the device status information of the slave device; Receive connection parameters sent by the master device, and perform data communication with the master device based on the connection parameters.

[0006] Optionally, the step of matching the target mode switching strategy based on the event priority of the event to be processed and the current device mode of the slave device includes: If the current device mode of the slave device is deep sleep mode, then when the event priority of the event to be processed is the first event priority, the matching target mode switching strategy is to switch from deep sleep mode to active mode; when the event priority of the event to be processed is the second event priority, the matching target mode switching strategy is to switch from deep sleep mode to shallow sleep mode. If the current device mode of the slave device is shallow sleep mode, then when the event priority of the event to be processed is the first event priority or the second event priority, the matching target mode switching strategy is to switch from shallow sleep mode to active mode.

[0007] Optionally, it also includes: When the slave device is in shallow sleep mode, the data collected by the sensor is written to the cache queue; In response to a timer interrupt, the processor is started while the Bluetooth device remains off. Check if the amount of data in the cache queue has reached a preset threshold; if yes, switch from shallow sleep mode to active mode; if no, maintain shallow sleep mode.

[0008] Optionally, after performing data communication with the master device based on the connection parameters, the method further includes: After data communication is completed, the device switches from active mode to shallow sleep mode according to the sleep permission command sent by the master device or the transmission timeout.

[0009] Optionally, it also includes: When the slave device is in shallow sleep mode, if no pending events of the first event priority and the second event priority are detected within a preset time period, it switches from shallow sleep mode to deep sleep mode.

[0010] Optionally, the connection parameters include a connection interval and a slave device delay, wherein the connection interval is positively correlated with the event priority of the event to be processed, and the slave device delay is positively correlated with the event priority of the event to be processed.

[0011] Optionally, after sending the power consumption requirement packet to the master device, the method further includes: The scanning interval is adjusted according to the event priority of the event to be processed; wherein the scanning interval is the time interval during which the slave device scans the broadcast of the master device, and the scanning interval is positively correlated with the event priority value of the event to be processed.

[0012] Optionally, it also includes: When the slave device is in active mode, it receives a batch instruction packet sent by the master device; wherein the batch instruction packet is generated by the master device by aggregating multiple control commands; The system executes multiple control commands in the batch instruction package sequentially, and enters shallow sleep mode according to the sleep permission instruction issued by the master device after execution.

[0013] To achieve the above objectives, this application provides a device hibernation scheduling method, applied to a main device, the method comprising: Receive a power consumption requirement packet sent by the slave device; wherein the power consumption requirement packet includes the highest event priority among all pending events, the size of the data to be transmitted, and the device status information of the slave device; The connection parameters are calculated based on the power consumption requirement package; wherein the connection parameters include the connection interval and the slave device delay; The connection interval and the slave device delay are sent to the slave device so that the slave device can communicate with the master device based on the connection interval and the slave device delay; After data communication is completed, a hibernation permission command is sent to the slave device to switch the slave device from active mode to shallow hibernation mode.

[0014] To achieve the above objectives, this application provides a device hibernation scheduling system, including slave devices and master devices; The slave device includes: The mode switching module is used to, when a pending event is detected, match a target mode switching strategy according to the event priority of the pending event and the current device mode of the slave device, and perform device mode switching based on the target mode switching strategy; wherein, the device modes include deep sleep mode, shallow sleep mode and active mode, in which the Bluetooth radio frequency of the slave device is turned off and only interrupt wake-up is retained, in which the slave device is in Bluetooth broadcast mode and does not maintain Bluetooth connection, and in which the slave device is in Bluetooth connected state in active mode; The first sending module is configured to send a power consumption requirement packet to the master device when the slave device is in an active mode, so that the master device can calculate the connection parameters based on the power consumption requirement packet; wherein, the power consumption requirement packet includes the highest event priority among all the pending events, the size of the data to be transmitted, and the device status information of the slave device; A communication module is used to receive connection parameters sent by the master device and to perform data communication with the master device based on the connection parameters; The main device includes: The receiving module is used to receive power consumption demand packets sent from the device; The calculation module is used to calculate the connection parameters according to the power consumption requirement package, and send the connection parameters to the slave device so that the slave device can communicate with the master device based on the connection parameters; The second sending module is used to send a hibernation permission command to the slave device after data communication is completed, so that the slave device switches from active mode to shallow hibernation mode.

[0015] To achieve the above objectives, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is used to implement the steps of the device hibernation scheduling method described above when executing the computer program.

[0016] To achieve the above objectives, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the device hibernation scheduling method described above.

[0017] The device sleep scheduling method provided in this application, upon detecting an event to be processed, matches a target mode switching strategy based on the event priority and the current device mode, and executes a device mode switch. In deep sleep mode, Bluetooth radio frequency is turned off and only interrupt wake-up is retained; in shallow sleep mode, Bluetooth broadcast mode is maintained and Bluetooth connection is not maintained; and in active mode, Bluetooth is connected. Through this method, the slave device can completely turn off the radio frequency or only maintain broadcast mode when there are no high-priority events, avoiding frequent physical wake-ups triggered by low-priority events, thereby reducing power consumption. Simultaneously, when the slave device enters active mode, it sends a power requirement packet containing the highest event priority, the size of the data to be transmitted, and device status information to the master device. This allows the master device to calculate connection parameters adapted to the current communication requirements. After receiving these connection parameters, the slave device communicates with the master device. Through this bidirectional negotiation mechanism, the slave device can feed back its real-time status to the master device, ensuring that adjustments to the connection parameters reflect the actual needs of the slave device, avoiding the low communication efficiency or power waste caused by the master device unilaterally setting fixed parameters. Therefore, this application reduces the number of invalid wake-ups of slave devices in low-priority event scenarios and reduces the power consumption of slave devices by using event priority-driven sleep mode switching and parameter negotiation between master and slave devices. This application also discloses a device sleep scheduling device, an electronic device, and a computer-readable storage medium, which can achieve the same technical effects.

[0018] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. The drawings are used to provide a further understanding of this disclosure and constitute a part of the specification. They are used together with the following detailed description to explain this disclosure, but do not constitute a limitation of this disclosure. In the drawings: Figure 1 This is a flowchart illustrating a device hibernation scheduling method according to an exemplary embodiment; Figure 2 This is a flowchart illustrating another device hibernation scheduling method according to an exemplary embodiment; Figure 3 This is a structural diagram of a slave device in a device hibernation scheduling system according to an exemplary embodiment; Figure 4 This is a structural diagram of a master device in a device hibernation scheduling system according to an exemplary embodiment; Figure 5 This is a structural diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0021] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0022] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] The slave device in this application can be any IoT (Internet of Things) terminal device with BLE communication capabilities, such as smart water meters, smart sensors, and wearable devices. The master device can be a terminal device with BLE scanning and connection management capabilities, such as smartphones, handheld meter reading terminals, and gateway devices. Slave devices are typically powered by power sources with limited capacity, such as button batteries; power consumption optimization is key to extending device battery life.

[0024] In related technologies, the sleep scheduling of slave devices usually adopts a fixed-period timed wake-up mechanism. Regardless of the importance of the event to be processed, the device is woken up at the same frequency for processing. This causes low-priority events to frequently trigger RF activation and processor full-speed operation, resulting in energy waste. BLE connection parameters are set unilaterally by the master device and cannot be dynamically adjusted according to the real-time status of the slave device. Data cache reaches a threshold and is forcibly woken up, lacking fine-grained wake-up decision-making capabilities.

[0025] This application provides a device hibernation scheduling method, in which the execution subject is a slave device.

[0026] See Figure 1 , Figure 1 This is a flowchart illustrating a device hibernation scheduling method provided in an embodiment of this application. Figure 1 As shown, the method includes: S101: When a pending event is detected, a target mode switching strategy is matched according to the event priority of the pending event and the current device mode of the slave device, and a device mode switch is performed based on the target mode switching strategy; wherein, the device mode includes deep sleep mode, shallow sleep mode and active mode, in which the Bluetooth radio frequency of the slave device is turned off and only interrupt wake-up is retained, in which the slave device is in Bluetooth broadcast mode and does not maintain Bluetooth connection, and in which the slave device is in Bluetooth connected state in active mode; In this context, pending events refer to events that the device needs to respond to or process, such as sensor data reaching a threshold alarm, timed data reporting task triggering, and device status change notifications. Event priority refers to the priority level pre-assigned to various events based on their urgency and importance. In this embodiment, event priorities are divided from high to low into first event priority (e.g., urgent events such as sensor threshold alarms, denoted as P0 level), second event priority (e.g., important events such as timed data reporting, denoted as P1 level), and third event priority (e.g., regular events such as device status synchronization, denoted as P2 level). Deep sleep mode refers to a working mode in which the device turns off its Bluetooth RF transceiver and only retains the hardware interrupt wake-up pin in a listening state. In this mode, power consumption is extremely low, and it can only be woken up by the hardware interrupt corresponding to the first event priority. Shallow sleep mode refers to a working mode in which the device's Bluetooth module is in broadcast mode, and it can perform lightweight information interaction with the master device through broadcast packets but does not establish or maintain a Bluetooth connection. In this mode, the device can respond to pending events of first and second event priorities. Active mode refers to the working mode in which a slave device establishes and maintains a Bluetooth connection with a master device and can perform full-duplex data communication. In this mode, the slave device can respond to events of all priorities, but the power consumption is the highest.

[0027] In practice, the slave device maintains a mapping table between event priorities and mode switching policies. When the slave device detects an event to be processed, it first reads the event priority tag and the current device mode of the slave device, and then queries the mapping table to match the corresponding target mode switching policy. The target mode switching policy defines the switching path and triggering conditions from the current device mode to the target device mode. For example, if the slave device is currently in deep sleep mode, the corresponding mode switching will only be performed if the event priority of the event to be processed is the first or second event priority; if the event priority of the event to be processed is the third event priority, the slave device can remain in deep sleep mode and not respond.

[0028] As can be seen, this step achieves differentiated sleep scheduling by dynamically matching event priorities with device modes, enabling slave devices to remain sensitive to high-priority events while suppressing unnecessary wake-ups for low-priority events, thus reducing ineffective power consumption.

[0029] As a feasible implementation, the step of matching a target mode switching strategy based on the event priority of the event to be processed and the current device mode of the slave device includes: if the current device mode of the slave device is deep sleep mode, then when the event priority of the event to be processed is the first event priority, the matched target mode switching strategy is to switch from deep sleep mode to active mode; when the event priority of the event to be processed is the second event priority, the matched target mode switching strategy is to switch from deep sleep mode to shallow sleep mode; if the current device mode of the slave device is shallow sleep mode, then when the event priority of the event to be processed is the first event priority or the second event priority, the matched target mode switching strategy is to switch from shallow sleep mode to active mode.

[0030] In this embodiment, for deep sleep mode, since the Bluetooth radio frequency is turned off, only the first event priority and the second event priority can trigger the slave device to leave deep sleep mode. Emergency events of the first event priority require immediate reporting, so the device directly switches from deep sleep mode to active mode to establish a Bluetooth connection for real-time data transmission. Important events of the second event priority do not require real-time response but still need relatively timely communication; therefore, the device first switches from deep sleep mode to shallow sleep mode. In shallow sleep mode, it establishes a connection with the master device via BLE broadcast before deciding whether to further switch to active mode. This gradual wake-up strategy avoids the power waste caused by directly establishing a full-featured Bluetooth connection when the data volume is small. For shallow sleep mode, both the first and second event priorities can trigger the slave device to switch to active mode because the slave device is already in broadcast mode, the overhead of establishing a Bluetooth connection is relatively small, and the communication needs of both types of events must be completed through the connected state in active mode.

[0031] As a possible implementation, the method further includes: when the slave device is in a shallow sleep mode, writing the data collected by the sensor into a cache queue; in response to a timer interrupt trigger, controlling the processor to start while keeping the Bluetooth device in a turned-off state; checking whether the amount of data in the cache queue has reached a preset threshold; if so, switching from the shallow sleep mode to the active mode; if not, maintaining the shallow sleep mode.

[0032] Here, the buffer queue refers to the random access memory (RAM) buffer used by the slave device in shallow sleep mode to temporarily store sensor-acquired data. The timer interrupt refers to the interrupt signal generated by the slave device's real-time clock (RTC) timer according to a preset period, used to trigger the pre-wake-up decision process. The preset threshold is a threshold value for the amount of data in the buffer queue, such as 80% of the buffer queue capacity, used to determine whether it is necessary to trigger a physical wake-up to send the buffered data to the master device via Bluetooth.

[0033] In practical implementation, when the slave device is in shallow sleep mode, the Bluetooth module is only in broadcast mode and does not maintain a connection, but the sensor module continues to collect data and temporarily stores the collected data in a cache queue in RAM. Simultaneously, the RTC timer generates a timer interrupt at a preset period (e.g., every five minutes). In response to this timer interrupt, the slave device's Central Processing Unit (CPU) is woken up and started, but the Bluetooth RF transceiver remains off. This is the virtual wake-up process; the processor only performs lightweight logic checks and does not generate RF power consumption. The processor checks the number of data entries currently accumulated in the cache queue: if the data volume reaches or exceeds a preset threshold (e.g., 80% of the cache queue capacity), it determines that there is enough data to be reported, triggering a physical wake-up, i.e., switching from shallow sleep mode to active mode, turning on the Bluetooth RF, and establishing a connection with the master device for batch data transmission; if the data volume does not reach the preset threshold and there are no first or second priority events, the processor directly returns to sleep, skipping this physical wake-up.

[0034] As can be seen, this implementation introduces a virtual queue pre-wake-up decision mechanism, enabling the slave device to perform a lightweight data volume judgment in shallow sleep mode without turning on the Bluetooth radio frequency. Only when the data accumulates to a threshold worth transmitting will a physical wake-up and Bluetooth connection establishment be triggered, effectively reducing the radio frequency power consumption caused by frequent Bluetooth connection triggers due to a small amount of data.

[0035] S102: When the slave device is in active mode, it sends a power consumption requirement packet to the master device so that the master device can calculate the connection parameters based on the power consumption requirement packet; wherein, the power consumption requirement packet includes the highest event priority among all the pending events, the size of the data to be transmitted, and the device status information of the slave device; The power consumption requirement packet refers to a custom data packet sent by the slave device to the master device via the BLE Generic Attribute Profile (GATT) channel after entering active mode, at the beginning of establishing a Bluetooth connection with the master device, or during the connection process. This packet conveys the slave device's current data communication needs and power consumption constraints to the master device. The highest event priority refers to the highest priority among all events in the current set of events to be processed by the slave device. For example, if both a P0-level alarm event and a P2-level synchronization event exist simultaneously, the highest event priority is the first event priority. The size of data to be transmitted refers to the estimated total number of bytes of data currently cached or to be sent by the slave device. Device status information refers to the current hardware status parameters of the slave device, which may include indicators reflecting the slave device's current power consumption capacity and operating conditions, such as battery level, CPU load rate, and chip temperature.

[0036] In this step, after the slave device switches from shallow or deep sleep mode to active mode and establishes a Bluetooth connection with the master device, it does not immediately begin transmitting service data. Instead, it first constructs and sends a power consumption requirement packet to the master device. The slave device extracts the highest event priority from all pending events, calculates the estimated number of bytes of data to be transmitted in the buffer queue, and reads device status information such as battery level and device temperature. These fields are then encoded into a power consumption requirement packet according to a preset data packet format and sent. Upon receiving the power consumption requirement packet, the master device dynamically calculates the optimal connection parameters based on the real-time information carried within the packet.

[0037] As can be seen, this step realizes a mechanism for the slave device to actively transmit communication requirements and power consumption constraints to the master device through the power consumption requirement package. This enables the master device to dynamically calculate the connection parameters based on the actual state of the slave device rather than preset default values, thus avoiding the power consumption waste or communication delay problems caused by the mismatch between the connection parameters and the actual needs of the slave device in related technologies.

[0038] As one possible implementation, the connection parameters include a connection interval and a slave device delay, wherein the connection interval is positively correlated with the event priority of the event to be processed, and the slave device delay is positively correlated with the event priority of the event to be processed.

[0039] The connection interval, measured in milliseconds (ms), is the minimum time interval between two consecutive data communication attempts between a master and slave device. Within each connection interval, the master device opens a radio frequency (RF) communication window, allowing the master and slave devices to exchange data packets. If no data needs to be transmitted, the device immediately returns to sleep mode until the next connection interval arrives. Slave latency refers to the number of connection events the slave device is allowed to skip. When the slave latency is set to a positive integer N, it means the slave device can skip a maximum of N consecutive communication opportunities without waking up, only needing to listen for the master device's communication request on the Nth plus-one connection event. A longer connection interval results in fewer RF wake-ups per unit time and lower power consumption, but also higher data transmission latency. Conversely, a higher slave latency allows the slave device to skip more connection events without waking up, further reducing power consumption, but also increasing communication latency.

[0040] In practice, the higher the priority of the event to be processed (i.e., the more urgent), the smaller the value of the connection parameter: For the first event priority (P0 level), the connection interval can be set to the shortest (e.g., less than or equal to 15 milliseconds), and the slave device latency can be set to zero to ensure that the slave device is in a listening state for every connection event to achieve real-time data transmission; For the second event priority (P1 level), the connection interval can be set to a medium value (e.g., 50 to 100 milliseconds), and the slave device latency can be set to a small value (e.g., less than or equal to 3), to ensure low latency while also allowing for some sleep opportunities; For the third event priority (P2 level), the connection interval can be set to a longer value (e.g., greater than or equal to 1 second), and the slave device latency can be set to a larger value (e.g., greater than or equal to 10), to maximize the sleep time of the slave device to reduce average power consumption.

[0041] As can be seen, this implementation establishes a positive correlation between connection parameters and event priorities, enabling the values ​​of connection parameters to adaptively match the current communication urgency of the slave device: urgent events receive real-time communication guarantees with short intervals and zero latency, while regular events receive the benefits of low-power sleep with long intervals and high latency, thus achieving a dynamic balance between real-time performance and power consumption within the same communication framework.

[0042] S103: Receive connection parameters sent by the master device, and perform data communication with the master device based on the connection parameters.

[0043] In this step, the slave device receives connection parameters from the master device via a BLE Connection Parameter Update Request command. These connection parameters are calculated by the master device based on the information carried in the power consumption requirement packet sent by the slave device in the previous step. After receiving the connection parameter update request, the slave device returns an acknowledgment response to the master device, and both parties execute subsequent data communication according to the updated connection interval and the slave device's delay. During the data communication phase, the slave device sends the data to be sent from its buffer queue to the master device packet by packet according to the packet segmentation mechanism of the BLE protocol stack, and enters sleep mode between data packet transmissions according to the rhythm of the connection interval to save power.

[0044] As a possible implementation, after data communication with the master device based on the connection parameters, the method further includes: after the data communication is completed, switching from active mode to shallow sleep mode according to the sleep permission command or transmission timeout sent by the master device.

[0045] The hibernation permission command is a specific instruction sent by the master device to the slave device via the BLE control channel after confirming that the current data communication has been completed and no further data needs to be exchanged. This command grants the slave device the permission to exit active mode. Transmission timeout refers to the mechanism by which the slave device automatically determines that the communication has ended if it has not received any data or instructions from the master device within a preset continuous idle period. This preset period can be configured according to the actual application scenario, for example, three seconds.

[0046] In practice, after the slave device completes the transmission of all data based on the negotiated connection parameters and receives confirmation from the master device, it waits for further instructions from the master device. If the master device determines that the communication task is complete, it proactively sends a sleep permission command to the slave device. Upon receiving this command, the slave device immediately switches from active mode to shallow sleep mode, disables the Bluetooth connection, and retains only the broadcast function to maintain a lightweight connection with the master device. If the master device experiences a communication failure or fails to send the sleep permission command in a timely manner, the slave device starts a transmission timeout timer after the data communication is completed. If the timer reaches the preset timeout period without receiving any data or instructions from the master device, the slave device automatically determines that the communication has ended and also switches from active mode to shallow sleep mode.

[0047] As can be seen, this implementation ensures that the active mode is maintained only during necessary communication by using the dual exit of master device hibernation permission command and slave device transmission timeout. Once communication is completed, the high-power active mode is exited in a timely manner, avoiding unnecessary power waste caused by the slave device remaining in the active mode for a long time after the communication task is completed.

[0048] As a possible implementation method, it further includes: when the slave device is in shallow sleep mode, if no pending events of first event priority and second event priority are detected within a preset time period, it enters deep sleep mode.

[0049] The preset time period refers to the threshold of continuous idle time used to determine whether a slave device can enter deep sleep mode. This threshold can be set according to specific application scenarios and power consumption requirements. If the slave device has not detected any first-priority or second-priority events after the preset time period in shallow sleep mode, it indicates that there are currently no pending tasks that require the slave device to respond in broadcast mode or connection mode. Therefore, the slave device can further reduce its power consumption level, enter deep sleep mode from shallow sleep mode, disable Bluetooth broadcast function, retain only the hardware interrupt wake-up pin, and wait for the next first-priority or second-priority event to be triggered.

[0050] As can be seen, this implementation method enables the device to automatically enter the deep sleep mode with the lowest power consumption when there are no critical events for a long time by timed downgrading from shallow sleep to deep sleep, which further extends the battery life, while retaining the ability to respond to high-priority emergency events through hardware interrupts.

[0051] Based on the above embodiments, as a preferred implementation, after sending the power consumption requirement packet to the master device, the method further includes: adjusting the scanning interval according to the event priority of the event to be processed; wherein, the scanning interval is the time interval for the slave device to scan the broadcast of the master device, and the scanning interval is positively correlated with the event priority value of the event to be processed.

[0052] The scan interval, measured in milliseconds, refers to the time interval between two consecutive scan window activations by a slave device in BLE scanning mode. It determines the frequency at which the slave device listens for broadcast packets from nearby master devices. A smaller scan interval allows the slave device to discover master devices faster, but results in more frequent RF wake-ups and higher power consumption. Conversely, a larger scan interval allows for longer sleep times and lower power consumption, but significantly increases the latency in discovering master devices. In this implementation, the scan interval is positively correlated with the event priority of the event to be processed: higher event priority (i.e., more urgent) requires a smaller scan interval to promptly discover master devices and establish connections; lower event priority (i.e., less urgent) requires a larger scan interval to save power.

[0053] In practice, after sending a power consumption requirement packet to the master device, the slave device dynamically adjusts its BLE scanning parameters based on the event priority of the current pending event. For example, when the pending event is an emergency alarm of the first event priority (P0 level), the slave device sets the scanning interval to the minimum value (e.g., 100 milliseconds) to scan the master device's broadcast signal at the highest frequency, ensuring that the master device is discovered and a connection is established in the shortest possible time. When the pending event is a timed report of the second event priority (P1 level), the slave device sets the scanning interval to a medium value (e.g., one to several seconds) to reduce scanning power consumption within an acceptable discovery delay range. When the pending event is the third event priority (P2 level) or there is no pending event, the slave device can set the scanning interval to a longer value (e.g., several seconds or more) to maximize the sleep time. This dynamic adjustment of the scanning interval is linked with the dynamic adjustment of the connection parameters mentioned above: the scanning interval is responsible for power consumption optimization during the device discovery phase, and the connection interval is responsible for power consumption optimization during the connected phase. Together, they cover the power consumption control of the entire BLE communication process.

[0054] As can be seen, by associating the scanning interval with the event priority, this implementation enables the slave device to adaptively adjust the scanning power consumption according to the urgency of the event during the device discovery phase before establishing a Bluetooth connection, thereby further reducing the average power consumption of the slave device from the perspective of the entire communication process.

[0055] Based on the above embodiments, as a preferred implementation, it further includes: when the slave device is in active mode, receiving a batch instruction package issued by the master device; wherein the batch instruction package is generated by the master device by aggregating multiple control commands; executing multiple control commands in the batch instruction package in sequence, and entering a shallow sleep mode according to the sleep permission instruction issued by the master device after execution.

[0056] In this context, a batch command packet refers to a set of commands that the master device would otherwise need to send through multiple independent communication interactions (such as firmware configuration commands, sensor read requests, parameter setting commands, etc.) into a single data packet, which is then sent to the slave device in a single Bluetooth connection event. Through batch aggregation, the master device can combine multiple independent communications into a single communication, reducing the number of times and the duration the slave device needs to maintain an active mode due to receiving multiple scattered commands.

[0057] In practice, after the master device and slave device establish a Bluetooth connection, the master device does not send control commands one by one. Instead, it first aggregates multiple control commands that need to be sent to the slave device locally and encodes them into a batch command packet according to a preset instruction format. During a connection event with the slave device, the master device sends this batch command packet to the slave device all at once. After receiving the batch command packet, the slave device parses the multiple control commands encoded in the packet, executes each command in sequence, and summarizes the execution results after all commands have been executed, returning them to the master device in the next data packet. After confirming that all commands have been successfully executed, the master device sends a hibernation permission command to the slave device, which then enters a shallow hibernation mode.

[0058] As can be seen, this implementation method aggregates multiple control commands into a batch instruction package and sends it out at once by the master device, which reduces the radio frequency power consumption caused by the slave device repeatedly maintaining the active mode due to multiple independent instruction interactions, and at the same time shortens the overall active time of the slave device, further optimizing the power consumption performance.

[0059] The device sleep scheduling method provided in this application, upon detecting an event to be processed, matches a target mode switching strategy based on the event priority and the current device mode, and executes a device mode switch. In deep sleep mode, Bluetooth radio frequency is turned off and only interrupt wake-up is retained; in shallow sleep mode, Bluetooth broadcast mode is in operation and Bluetooth connection is not maintained; and in active mode, Bluetooth connection is maintained. Through this method, the slave device can completely turn off the radio frequency or only maintain broadcast mode when there are no high-priority events, avoiding frequent physical wake-ups triggered by low-priority events, thereby reducing power consumption. Simultaneously, when the slave device enters active mode, it sends a power requirement packet containing the highest event priority, the size of the data to be transmitted, and device status information to the master device. This allows the master device to calculate connection parameters adapted to the current communication requirements. After receiving these connection parameters, the slave device communicates with the master device. Through this bidirectional negotiation mechanism, the slave device can feed back its real-time status to the master device, ensuring that adjustments to the connection parameters reflect the actual needs of the slave device, avoiding the low communication efficiency or power waste caused by the master device unilaterally setting fixed parameters. Therefore, the embodiments of this application reduce the number of invalid wake-ups of the slave device in low-priority event scenarios and reduce the power consumption of the slave device by switching the sleep mode driven by event priority and negotiating parameters between the master and slave devices.

[0060] This application discloses a device hibernation scheduling method, in which the main device is the executing entity.

[0061] See Figure 2 , Figure 2 A flowchart illustrating another device hibernation scheduling method provided in this application embodiment. For example... Figure 2 As shown, the method includes: S201: Receive a power consumption requirement packet sent by the slave device; wherein, the power consumption requirement packet includes the highest event priority among all pending events, the size of the data to be transmitted, and the device status information of the slave device; In this step, after establishing a Bluetooth connection with the slave device, the master device receives a power consumption requirement packet sent by the slave device via the BLE GATT channel. The master device parses the power consumption requirement packet, extracting the highest event priority field, the data size to be transmitted field, and the device status information field. The highest event priority reflects the urgency of the slave device's current communication, the data size to be transmitted reflects the amount of data the slave device needs to send, and the device status information (such as battery level) reflects the slave device's current power consumption capacity. The master device temporarily stores the parsing results in memory for use in subsequent connection parameter calculation steps.

[0062] S202: Calculate the connection parameters based on the power consumption requirement package; wherein the connection parameters include the connection interval and the slave device delay; In this step, the master device takes the highest event priority, the size of the data to be transmitted, and the device status information carried in the power consumption requirement packet as input, and dynamically calculates the optimal connection interval and slave device latency according to the preset connection parameter calculation algorithm.

[0063] As a feasible implementation, the calculation of connection parameters based on the power consumption requirement package includes: when the highest event priority is a first event priority, determining the connection interval as a first connection interval and the slave delay as a first slave delay; when the highest event priority is a second event priority, determining the connection interval as a second connection interval based on the size of the data to be transmitted and determining the slave delay as a second slave delay based on the battery level; wherein, the second connection interval is positively correlated with the size of the data to be transmitted, and the second slave delay is negatively correlated with the battery level; when the highest event priority is a third event priority, determining the connection interval as a third connection interval and the slave delay as a third slave delay; wherein, the first connection interval is less than the second connection interval, which is less than the third connection interval, and the first slave delay is less than the second slave delay, which is less than the third slave delay.

[0064] In this implementation, for the first event priority (P0 level emergency event), since real-time performance is the primary requirement, regardless of the size of the data to be transmitted or the battery level, the first connection interval (e.g., 10 milliseconds) and the first slave delay (e.g., 0) are directly adopted to sacrifice power consumption for the lowest possible communication latency, ensuring that emergency alarm data is transmitted as quickly as possible. For the second event priority (P1 level important event), a balance needs to be struck between communication latency and power consumption. Specifically, the master device first calculates the transmission time required for this batch of data transmission based on the number of data packets to be transmitted from the slave device, that is, the time required to completely transmit all the data to be transmitted at the current data rate. Then, based on the relationship between the transmission time and a preset time threshold (100 milliseconds), the connection interval is determined in different tiers: when the transmission time is less than 100 milliseconds, it indicates that the data volume is small, and the second connection interval is a fixed value of 80 milliseconds; when the transmission time is greater than or equal to 100 milliseconds, it indicates that the data volume is large, and the second connection interval is 100 milliseconds. It can be seen that the larger the data volume, the longer the required transmission time, and the connection interval is increased accordingly, reserving sufficient communication window for the transmission of larger data volumes. After determining the connection interval, the slave latency is further determined based on the battery level: when the battery is high, the slave latency is set to 0 to fully utilize each connection event and ensure timely communication; when the battery is medium, the slave latency is set to 2, striking a balance between timeliness and power consumption; when the battery is low, the slave latency is set to 4, allowing the slave device to skip more connection events and maximize sleep time to protect battery life. It is evident that the lower the battery level, the higher the slave latency, showing a negative correlation with battery level. In low-battery scenarios, some real-time performance is sacrificed for longer battery life. For the third event priority (P2 level regular events), power consumption control is the primary objective. A configuration maximizing sleep parameters with a third connection interval greater than or equal to 2 seconds and a third slave latency greater than or equal to 10 is adopted. This allows the slave device to obtain the longest possible sleep window between two connection events, completing non-real-time data transmission tasks such as device state synchronization with extremely low average power consumption.

[0065] S203: The connection interval and the slave device delay are sent to the slave device so that the slave device can perform data communication with the master device based on the connection interval and the slave device delay; In this step, after the master device calculates the connection interval and slave device delay, it sends the calculated connection interval and slave device delay to the slave device through a BLE connection parameter update request. After the slave device confirms, both parties will conduct subsequent data communication with the new connection interval and slave device delay.

[0066] S204: After data communication is completed, a hibernation permission command is sent to the slave device to switch the slave device from active mode to shallow hibernation mode.

[0067] In this step, after confirming that the data communication task between the master device and the slave device has been completed (e.g., having received all the data to be transmitted from the slave device, having sent all the necessary control commands and received execution confirmation from the slave device), the master device proactively sends a sleep permission command to the slave device through the BLE control channel. Upon receiving this command, the slave device immediately releases Bluetooth connection resources, switches from active mode to shallow sleep mode, and retains only broadcast functionality. After sending the sleep permission command, the master device can also release its own connection resources related to the slave device or enter a low-power standby state.

[0068] Based on the above embodiments, as a preferred implementation, it further includes: aggregating multiple control commands into a batch instruction packet; and sending the batch instruction packet to the slave device after connecting to the slave device via Bluetooth.

[0069] In practice, the master device maintains a queue of pending commands to cache various control commands (such as firmware upgrade commands, parameter configuration commands, sensor calibration commands, etc.) generated before establishing a Bluetooth connection with the slave device. Once the master and slave devices establish a Bluetooth connection, the master device checks the queue for any unsent control commands. If any exist, these commands are serialized and encoded according to a preset batch command packet format, aggregated into a single batch command packet, and sent to the slave device all at once in a subsequent connection event, rather than being sent one command at a time. The batch command packet encoding format may include a command quantity field, the type identifier of each command, and command parameters, ensuring the slave device can correctly parse and execute them sequentially.

[0070] Based on the above embodiments, as a preferred implementation, the method further includes: recording the sleep cycle information of the slave device, predicting the next wake-up time of the slave device based on the sleep cycle information, and adjusting the broadcast window of the master device based on the predicted next wake-up time, so that the slave device can receive the broadcast signal of the master device in a timely manner during the scanning phase after wake-up, thereby reducing the invalid scanning of the slave device.

[0071] The sleep cycle information refers to the typical duration pattern between the slave device entering sleep mode and the next wake-up, recorded in the master device's history during multiple Bluetooth interactions with the slave device. Examples include the real-time clock (RTC) trigger cycle (e.g., every five minutes) set by the slave device in shallow sleep mode, the idle time from data transmission completion to entering deep sleep, and the average duration of deep sleep. The next wake-up time refers to the estimated time when the slave device might next end sleep mode and start Bluetooth scanning, calculated by the master device based on the slave device's sleep cycle pattern, current device mode, and the cumulative time since the last communication.

[0072] In practice, after each data communication with the slave device and receiving the device status information reported by the slave device, the master device records the timestamp of this communication, the current device mode of the slave device, and the sleep duration of the slave device before this data transmission in its local sleep cycle database. After multiple interactions, the master device establishes a sleep cycle prediction model for the slave device by statistically analyzing the sleep mode patterns of the slave device (e.g., calculating the average or median sleep duration of each device mode). When the master device needs to communicate with the slave device again, it uses this prediction model to estimate the next wake-up time of the slave device. The master device only starts its own Bluetooth broadcast within the window adjacent to the estimated wake-up time of the slave device; otherwise, the master device can put its own Bluetooth broadcast module into a low-power standby state. Since the broadcast window of the master device is aligned with the predicted scan window of the slave device, the slave device can receive the broadcast signal of the master device in a timely manner and establish a connection when performing Bluetooth scanning after waking up, without having to perform a long continuous scan to search for the master device, thus effectively reducing the invalid scanning time of the slave device.

[0073] As can be seen, this implementation method enables the master device to learn and predict the sleep cycle of the slave device, thereby allowing the master device to accurately align the broadcast window with the expected scanning time of the slave device. This effectively reduces the invalid radio frequency power consumption caused by the slave device continuously scanning and searching for the master device's broadcast for a long time, and achieves collaborative power consumption optimization between the master and slave devices.

[0074] The device hibernation scheduling method provided in this application embodiment allows the master device to receive and parse the power consumption demand packet of the slave device, and dynamically calculate the optimal BLE connection parameters based on multi-dimensional information such as the highest event priority, the amount of data to be transmitted, and the battery status. This enables bidirectional parameter negotiation between the master and slave devices, making the connection parameters adapt to the actual needs of the slave device, thereby reducing the power consumption of the slave device.

[0075] To make the technical solution of this application clearer, the following uses a smart water meter as an example of the application scenario of the device to specifically explain the technical solution of this application.

[0076] In this embodiment, the slave device is a smart water meter, equipped with a built-in BLE 5.0 communication module, a water flow sensor, and a button battery; the master device is a handheld meter reading terminal, equipped with BLE scanning and connection management functions. The event priorities and event types defined in the smart water meter are as follows: P0 level (first event priority) corresponds to a pipe burst alarm, triggered when the water flow rate is greater than 100 liters / minute for 2 seconds; P1 level (second event priority) corresponds to daily water consumption reporting, triggered at midnight every day; P2 level (third event priority) corresponds to battery status synchronization, triggered when the battery level drops by 10%.

[0077] Phase 1 (Deep Sleep Normal): During periods without events, the smart water meter is in deep sleep mode, with BLE radio frequency disabled and only the P0 interrupt wake-up circuit of the water flow sensor powered. When the water flow sensor detects a sudden change in flow rate (e.g., 120 liters / minute), a hardware interrupt is triggered. The smart water meter determines this as a P0 level event and immediately wakes up from deep sleep mode.

[0078] Phase Two (Emergency Wake-up and Parameter Negotiation): The smart water meter enters active mode and broadcasts a BLE connection request containing the P0 identifier. Upon scanning the broadcast, the handheld meter reading terminal establishes a BLE connection with the smart water meter (initial connection parameters are default values, such as a connection interval of 30 milliseconds). The smart water meter sends a power consumption requirement packet to the handheld meter reading terminal, containing an event level of P0, one data packet to be transmitted, and a medium battery level. The handheld meter reading terminal calculates the optimal connection parameters based on the power consumption requirement packet: since the event level is P0, the connection interval is determined to be 10 milliseconds, and the slave latency is 0. The handheld meter reading terminal sends a parameter update command to the smart water meter, which takes effect upon confirmation. Subsequently, it sends pipe burst alarm data at a 10-millisecond connection interval, taking approximately 8 milliseconds. After data transmission is complete, the handheld meter reading terminal sends a sleep permission command to the smart water meter, and the smart water meter enters a shallow sleep mode.

[0079] Phase Three (Shallow Sleep and Pre-Wake-up Decision): The smart water meter enters shallow sleep mode, records daily water consumption data and writes it to the RAM cache queue. The BLE radio frequency remains in broadcast mode but does not maintain a connection. The RTC timer is set to trigger a virtual wake-up at midnight each day. When midnight arrives the next day, a timer interrupt triggers a virtual wake-up: the processor starts but the BLE radio frequency remains off, the cache queue is checked, and it is found that there are 3 water consumption records for the day, which is less than the preset threshold (5 records). The decision is to skip the physical wake-up, the processor shuts down again, and the smart water meter returns to shallow sleep. Subsequently, the smart water meter continues to record water consumption data during shallow sleep. When the cumulative daily water consumption records reach 6 records, the midnight virtual wake-up is triggered again. The queue data volume is checked to be greater than or equal to the threshold, triggering a physical wake-up.

[0080] Phase Four (P1 Event Triggered Physical Wake-up and Batch Data Transmission): The smart water meter switches from shallow sleep to active mode and broadcasts a connection request. After the handheld meter reading terminal scans and establishes a BLE connection, the smart water meter sends a power consumption requirement packet, including an event level of P1, 6 data packets to be transmitted, and a medium battery level. The handheld meter reading terminal calculates the connection parameters: due to the P1 event, the large number of data packets, and the medium battery level, the connection interval is determined to be 80 milliseconds, and the slave latency is 2. Within the 80-millisecond connection interval, the smart water meter packages and sends 6 water usage records, taking approximately 52 milliseconds. After data communication is completed, the handheld meter reading terminal issues a sleep permission command, and the smart water meter returns to shallow sleep. Since no new P0 or P1 events are detected within the preset shallow sleep period, the smart water meter automatically degrades from shallow sleep to deep sleep, returning to the normal low-power state.

[0081] As can be seen, this embodiment, by applying an event priority-driven dynamic sleep scheduling method in the smart water meter scenario, has significantly reduced the number of daily wake-up calls from hundreds to dozens, significantly shortened the response delay of P0-level emergency events, and multiplied the battery life of button batteries.

[0082] The following describes a device hibernation scheduling system provided in an embodiment of this application. The device hibernation scheduling system includes slave devices and master devices.

[0083] See Figure 3 A structural diagram of a slave device in a device hibernation scheduling system according to an exemplary embodiment is shown, such as... Figure 3 As shown, it includes: The mode switching module 101 is used to, when a pending event is detected, match a target mode switching strategy according to the event priority of the pending event and the current device mode of the slave device, and perform device mode switching based on the target mode switching strategy; wherein, the device modes include deep sleep mode, shallow sleep mode and active mode, in which the Bluetooth radio frequency of the slave device is turned off and only interrupt wake-up is retained, in which the slave device is in Bluetooth broadcast mode and does not maintain Bluetooth connection, and in which the slave device is in Bluetooth connected state in active mode; The first sending module 102 is used to send a power consumption requirement packet to the master device when the slave device is in an active mode, so that the master device can calculate the connection parameters based on the power consumption requirement packet; wherein, the power consumption requirement packet includes the highest event priority among all the pending events, the size of the data to be transmitted, and the device status information of the slave device; The communication module 103 is used to receive connection parameters sent by the master device and to perform data communication with the master device based on the connection parameters.

[0084] See Figure 4 A structural diagram of a master device in a device hibernation scheduling system according to an exemplary embodiment is shown below. Figure 4 As shown, it includes: The receiving module 201 is used to receive a power consumption demand packet sent by the slave device; wherein, the power consumption demand packet includes the highest event priority among all pending events, the size of the data to be transmitted, and the device status information of the slave device; The calculation module 202 is used to calculate the connection parameters according to the power consumption requirement package, and send the connection parameters to the slave device so that the slave device can perform data communication with the master device based on the connection parameters; The second sending module 203 is used to send a hibernation permission command to the slave device after data communication is completed, so that the slave device switches from active mode to shallow hibernation mode.

[0085] The device sleep scheduling system provided in this application embodiment allows the slave device to match a target mode switching strategy based on the event priority and the current device mode when it detects an event to be processed, and then execute a device mode switch. In deep sleep mode, Bluetooth radio frequency is turned off and only interrupt wake-up is retained; in shallow sleep mode, Bluetooth broadcast mode is maintained and Bluetooth connection is not maintained; and in active mode, Bluetooth connection is maintained. Through this method, the slave device can completely turn off the radio frequency or only maintain broadcast mode when there are no high-priority events, avoiding frequent physical wake-ups triggered by low-priority events, thereby reducing power consumption. Simultaneously, when the slave device enters active mode, it sends a power demand packet containing the highest event priority, the size of the data to be transmitted, and device status information to the master device. This allows the master device to calculate connection parameters adapted to the current communication needs. After receiving these connection parameters, the slave device communicates with the master device. Through this bidirectional negotiation mechanism, the slave device can feed back its real-time status to the master device, ensuring that adjustments to the connection parameters reflect the actual needs of the slave device, avoiding the low communication efficiency or power waste caused by the master device unilaterally setting fixed parameters. Therefore, the embodiments of this application reduce the number of invalid wake-ups of the slave device in low-priority event scenarios and reduce the power consumption of the slave device by switching the sleep mode driven by event priority and negotiating parameters between the master and slave devices.

[0086] Based on the above embodiments, as a preferred implementation, the mode switching module 101 is specifically configured to include: if the current device mode of the slave device is deep sleep mode, then when the event priority of the event to be processed is the first event priority, the matching target mode switching strategy is to switch from deep sleep mode to active mode; when the event priority of the event to be processed is the second event priority, the matching target mode switching strategy is to switch from deep sleep mode to shallow sleep mode; if the current device mode of the slave device is shallow sleep mode, then when the event priority of the event to be processed is the first event priority or the second event priority, the matching target mode switching strategy is to switch from shallow sleep mode to active mode.

[0087] Based on the above embodiments, as a preferred embodiment, the slave device further includes: The write module is used to write the data collected by the sensor into the cache queue when the slave device is in a shallow sleep mode; The response module is used to respond to timer interrupt triggers, control the processor to start, and keep the Bluetooth device in a turned-off state. The detection module is used to check whether the amount of data in the cache queue has reached a preset threshold; if so, it switches from shallow sleep mode to active mode; if not, it maintains shallow sleep mode.

[0088] Based on the above embodiments, as a preferred embodiment, the slave device further includes: The first switching module is used to switch from active mode to shallow sleep mode after data communication is completed, based on the sleep permission instruction or transmission timeout sent by the master device.

[0089] Based on the above embodiments, as a preferred embodiment, the slave device further includes: The second switching module is used to switch from shallow sleep mode to deep sleep mode when the slave device is in shallow sleep mode and no pending events of first event priority and second event priority are detected within a preset time period.

[0090] Based on the above embodiments, as a preferred embodiment, the connection parameters include connection interval and slave device delay, wherein the connection interval is positively correlated with the event priority of the event to be processed, and the slave device delay is positively correlated with the event priority of the event to be processed.

[0091] Based on the above embodiments, as a preferred embodiment, the slave device further includes: An adjustment module is used to adjust the scanning interval according to the event priority of the event to be processed; wherein the scanning interval is the time interval during which the slave device scans the broadcast of the master device, and the scanning interval is positively correlated with the event priority value of the event to be processed.

[0092] Based on the above embodiments, as a preferred embodiment, the slave device further includes: The execution module is used to receive a batch instruction package issued by the master device when the slave device is in active mode; wherein the batch instruction package is generated by the master device by aggregating multiple control commands; the multiple control commands in the batch instruction package are executed sequentially, and after execution is completed, the slave device enters a shallow sleep mode according to the sleep permission instruction issued by the master device.

[0093] Based on the above embodiments, as a preferred implementation, the calculation module 202 is specifically used for: when the highest event priority is a first event priority, determining the connection interval as a first connection interval and the slave delay as a first slave delay; when the highest event priority is a second event priority, determining the connection interval as a second connection interval based on the size of the data to be transmitted and determining the slave delay as a second slave delay based on the battery level; wherein, the second connection interval is positively correlated with the size of the data to be transmitted, and the second slave delay is negatively correlated with the battery level; when the highest event priority is a third event priority, determining the connection interval as a third connection interval and the slave delay as a third slave delay; wherein, the first connection interval is less than the second connection interval and less than the third connection interval, and the first slave delay is less than the second slave delay and less than the third slave delay.

[0094] Based on the above embodiments, as a preferred embodiment, the main device further includes: An aggregation module is used to aggregate multiple control commands into a batch instruction package; after connecting to the slave device via Bluetooth, the batch instruction package is sent to the slave device.

[0095] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0096] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 5 This is a structural diagram of an electronic device according to an exemplary embodiment, such as... Figure 5 As shown, the electronic device includes: Communication interface 1 enables information exchange with other devices, such as network devices; Processor 2 is connected to communication interface 1 to enable information exchange with other devices. When running a computer program, it executes the device hibernation scheduling method provided by one or more of the above-mentioned technical solutions. The computer program is stored in memory 3.

[0097] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 5 The general will label all buses as Bus System 4.

[0098] The memory 3 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0099] It is understood that memory 3 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 3 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0100] The methods disclosed in the embodiments of this application can be applied to processor 2, or implemented by processor 2. Processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 2 or by instructions in the form of software. The processor 2 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 3. Processor 2 reads the program in memory 3 and completes the steps of the aforementioned method in combination with its hardware.

[0101] When processor 2 executes the program, it implements the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0102] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 3 that stores a computer program, which can be executed by a processor 2 to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0103] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0104] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0105] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A device hibernation scheduling method, characterized in that, Applied to a slave device, the method includes: When a pending event is detected, a target mode switching strategy is matched based on the event priority of the pending event and the current device mode of the slave device, and a device mode switch is performed based on the target mode switching strategy. The device modes include deep sleep mode, shallow sleep mode and active mode. In the deep sleep mode, the Bluetooth radio frequency of the slave device is turned off and only interrupt wake-up is retained. In the shallow sleep mode, the slave device is in Bluetooth broadcast mode and does not maintain Bluetooth connection. In the active mode, the slave device is in Bluetooth connected state. When the slave device is in active mode, it sends a power consumption requirement packet to the master device, so that the master device can calculate the connection parameters based on the power consumption requirement packet; wherein, the power consumption requirement packet includes the highest event priority among all the pending events, the size of the data to be transmitted, and the device status information of the slave device; Receive connection parameters sent by the master device, and perform data communication with the master device based on the connection parameters.

2. The device hibernation scheduling method according to claim 1, characterized in that, The step of matching the target mode switching strategy based on the event priority of the event to be processed and the current device mode of the slave device includes: If the current device mode of the slave device is deep sleep mode, then when the event priority of the event to be processed is the first event priority, the matching target mode switching strategy is to switch from deep sleep mode to active mode; when the event priority of the event to be processed is the second event priority, the matching target mode switching strategy is to switch from deep sleep mode to shallow sleep mode. If the current device mode of the slave device is shallow sleep mode, then when the event priority of the event to be processed is the first event priority or the second event priority, the matching target mode switching strategy is to switch from shallow sleep mode to active mode.

3. The device hibernation scheduling method according to claim 2, characterized in that, Also includes: When the slave device is in shallow sleep mode, the data collected by the sensor is written to the cache queue; In response to a timer interrupt, the processor is started while the Bluetooth device remains off. Check if the amount of data in the cache queue has reached a preset threshold; if yes, switch from shallow sleep mode to active mode; if no, maintain shallow sleep mode.

4. The device hibernation scheduling method according to claim 3, characterized in that, After communicating with the master device based on the connection parameters, the process further includes: After data communication is completed, the device switches from active mode to shallow sleep mode according to the sleep permission command sent by the master device or the transmission timeout.

5. The device hibernation scheduling method according to claim 4, characterized in that, Also includes: When the slave device is in shallow sleep mode, if no pending events of the first event priority and the second event priority are detected within a preset time period, it switches from shallow sleep mode to deep sleep mode.

6. The device hibernation scheduling method according to claim 1, characterized in that, The connection parameters include connection interval and slave device delay. The connection interval is positively correlated with the event priority of the event to be processed, and the slave device delay is positively correlated with the event priority of the event to be processed.

7. The device hibernation scheduling method according to claim 1, characterized in that, After sending the power consumption requirement packet to the master device, the process also includes: The scanning interval is adjusted according to the event priority of the event to be processed; wherein the scanning interval is the time interval during which the slave device scans the broadcast of the master device, and the scanning interval is positively correlated with the event priority value of the event to be processed.

8. The device hibernation scheduling method according to claim 1, characterized in that, Also includes: When the slave device is in active mode, it receives a batch instruction packet sent by the master device; wherein the batch instruction packet is generated by the master device by aggregating multiple control commands; The system executes multiple control commands in the batch instruction package sequentially, and enters shallow sleep mode according to the sleep permission instruction issued by the master device after execution.

9. A method for scheduling equipment hibernation, characterized in that, Applied to a master device, the method includes: Receive a power consumption requirement packet sent by the slave device; wherein the power consumption requirement packet includes the highest event priority among all pending events, the size of the data to be transmitted, and the device status information of the slave device; The connection parameters are calculated based on the power consumption requirement package; wherein the connection parameters include the connection interval and the slave device delay; The connection interval and the slave device delay are sent to the slave device so that the slave device can communicate with the master device based on the connection interval and the slave device delay; After data communication is completed, a hibernation permission command is sent to the slave device to switch the slave device from active mode to shallow hibernation mode.

10. A device hibernation scheduling system, characterized in that, Includes slave devices and master devices; The slave device includes: The mode switching module is used to, when a pending event is detected, match a target mode switching strategy according to the event priority of the pending event and the current device mode of the slave device, and perform device mode switching based on the target mode switching strategy; wherein, the device modes include deep sleep mode, shallow sleep mode and active mode, in which the Bluetooth radio frequency of the slave device is turned off and only interrupt wake-up is retained, in which the slave device is in Bluetooth broadcast mode and does not maintain Bluetooth connection, and in which the slave device is in Bluetooth connected state in active mode; The first sending module is configured to send a power consumption requirement packet to the master device when the slave device is in an active mode, so that the master device can calculate the connection parameters based on the power consumption requirement packet; wherein, the power consumption requirement packet includes the highest event priority among all the pending events, the size of the data to be transmitted, and the device status information of the slave device; A communication module is used to receive connection parameters sent by the master device and to perform data communication with the master device based on the connection parameters; The main device includes: The receiving module is used to receive power consumption demand packets sent from the device; The calculation module is used to calculate the connection parameters according to the power consumption requirement package, and send the connection parameters to the slave device so that the slave device can communicate with the master device based on the connection parameters; The second sending module is used to send a hibernation permission command to the slave device after data communication is completed, so that the slave device switches from active mode to shallow hibernation mode.

Images