Terminal device and smart home control method

Abstract

This application discloses a control method for a terminal device and a smart home system. The terminal device is equipped with a communicator and a controller. The communicator is used to establish a communication connection with external devices and receive attribute values ​​reported by the external devices. The controller obtains the target attribute value reported by the external device, calculates the degree of convergence between the target attribute value and a preset rule threshold, and matches the corresponding target interval level based on the degree of convergence. When the target interval level is inconsistent with the currently effective interval level, the controller switches and updates the current interval level, and sends a subscription request to the external device based on the target interval level to instruct the external device to report attribute values ​​at the corresponding time interval. This application can adaptively adjust the device attribute reporting interval according to the urgency triggered by the scenario, taking into account both the power consumption of the external device and the response time of the smart home automation control, thereby improving device adaptability and system stability.

Description

Technical Field

[0001] This application relates to the field of terminal equipment technology, and in particular to a control method for a terminal equipment and a smart home. Background Technology

[0002] Terminal devices refer to intelligent devices that support user interaction. Taking smart TVs as an example, a smart TV is a television product that integrates multiple functions such as audio-visual, entertainment, and data, based on Internet application technology, with an open operating system and chip, and an open application platform. It can realize two-way human-computer interaction and is used to meet the diverse and personalized needs of users.

[0003] In home IoT scenarios, terminal devices can act as local controllers, establishing Matter-based communication connections with sensors and actuators throughout the home via their built-in communication modules to achieve smart home control. In related technologies, the terminal device, acting as a subscriber, sends subscription requests to the sensor device, which acts as a publisher, to establish a periodic data reporting channel. The sensor device actively reports attribute values ​​to the terminal device at a fixed frequency, according to the minimum and maximum reporting intervals specified in the subscription request. After receiving and caching the reported data, the terminal device compares the attribute values ​​with user-preset rule thresholds. When the conditions are met, it issues control commands to the actuator devices.

[0004] However, the reporting interval specified in the subscription request in the above implementation is a fixed value, which cannot be dynamically adjusted once set. Using a high-frequency reporting interval increases the power consumption of the sensor device and shortens the lifespan of battery-powered devices; using a low-frequency reporting interval results in an excessively large data sampling interval, preventing the terminal device from immediately detecting attribute values ​​exceeding the rule threshold, leading to delayed or failed automated responses. In other words, the above implementation cannot balance battery life and real-time response, resulting in a degraded user experience for smart home control. Summary of the Invention

[0005] This application provides a control method for a terminal device and a smart home, in order to solve the problem that the main control device of a smart home cannot simultaneously take into account battery life and real-time response.

[0006] In a first aspect, this application provides a terminal device, comprising: The communicator is configured to establish a communication connection with an external device and to receive attribute values ​​reported by the external device. A controller, electrically connected to the communicator, is configured to: Obtain the target attribute value reported by the external device; Calculate the degree of closeness between the target attribute value and the preset rule threshold, and determine the corresponding target interval level based on the degree of closeness; If the target interval is inconsistent with the current interval that is in effect, the current interval is switched to the target interval, and a subscription request is sent to the external device based on the target interval; the subscription request is used to instruct the external device to report attribute values ​​according to the time interval corresponding to the target interval.

[0007] The above technical solution has the following beneficial effects or advantages: It can dynamically adjust the attribute reporting frequency based on the distance of the attribute value from the rule threshold. When the attribute value is far from the threshold, a longer reporting interval is used to reduce the communication power consumption of external devices. When the attribute value is close to the threshold, the reporting interval is shortened to ensure the response speed of automated control. This solves the problem that a fixed reporting interval cannot take into account both device power consumption and control timeliness, adapts to the battery life requirements of IoT devices, and can improve the rationality of smart home automation rules.

[0008] In some embodiments of this application, the controller calculates the degree of closeness between the target attribute value and a preset rule threshold, specifically configured as follows: Calculate the absolute value of the difference between the target attribute value and the preset rule threshold to obtain the distance dimension parameter; Based on the changing trend of the target attribute value within the preset statistical window, the remaining time for the target attribute value to reach the preset rule threshold is predicted, and the trend dimension parameter is obtained. Calculate the remaining duration of the target attribute value relative to the total duration in the preset rule threshold to obtain the time window dimension parameter; Calculate the time difference between the system time and the reporting time corresponding to the target attribute value, and calculate the ratio of the time difference to the time interval corresponding to the current interval level to obtain the freshness dimension parameter; Calculate the degree values ​​corresponding to the distance dimension parameter, the trend dimension parameter, the time window dimension parameter, and the freshness dimension parameter; The maximum value of the degree value is determined as the degree of approach.

[0009] The above technical solution has the following beneficial effects or advantages: The urgency of rule triggering is comprehensively evaluated from four dimensions: numerical distance, trend of change, remaining duration of continuous conditions, and data freshness. This avoids the one-sidedness of judgment based on a single dimension, such as ignoring scenarios where attribute values ​​quickly approach the threshold based solely on numerical distance, or ignoring judgment bias caused by outdated data. This makes the determination of the degree of approach more in line with the actual triggering risk, thereby improving the accuracy of interval level matching.

[0010] In some embodiments of this application, the controller is further configured with at least two different interval levels, each interval level being associated with a different degree range and a corresponding time interval, the time interval including a maximum time interval and a minimum time interval; The controller determines the corresponding target interval level based on the degree of convergence, specifically configured as follows: Match the degree of proximity with the degree range associated with the interval level; The interval level corresponding to the degree range of the match is determined as the target interval level; The higher the degree of convergence, the smaller the time interval corresponding to the target interval level.

[0011] The above technical solution has the following beneficial effects or advantages: By pre-setting a mapping relationship between multi-level interval gears and degree ranges, continuous approach degree values ​​are transformed into discrete gear adjustments, simplifying the system's control logic. At the same time, each gear is configured with corresponding upper and lower time limits, which can adapt to external devices with different performance and power consumption requirements. The corresponding logic of higher approach degree and shorter reporting interval is achieved, thereby realizing a positive match between trigger urgency and reporting frequency, ensuring that the gear adjustment process is stable and controllable.

[0012] In some embodiments of this application, when the external device is an intermittently connected device, the controller is further configured to: Obtain the sleep cycle of the external device; The maximum time interval is adjusted to a first time interval that is greater than or equal to the sleep cycle, and the subscription request is sent to the external device based on the minimum time interval corresponding to the target interval level and the first time interval. The actual time interval at which the external device returns the attribute value based on the subscription request is used as the second time interval; If the second time interval is greater than the maximum time interval corresponding to the target interval level, then the external device is marked as a device to be compensated; In response to the device to be compensated switching from a dormant state to an active state, an active extension request for extending the active duration is sent to the device to be compensated, and a read request for obtaining the attribute value is sent within the active duration; The active duration refers to the duration during which the external device is in the active state.

[0013] The above technical solution has the following beneficial effects or advantages: For intermittently connected devices with hibernation features, the upper limit of the subscription reporting interval is adapted to the device's own hibernation cycle to avoid reporting failure caused by mismatch between the subscription interval and the device's hibernation cycle. When the actual reporting interval is detected to be outside the reasonable range, attribute data is actively read in the device's active window. This will not increase the power consumption of the device during the hibernation phase, but will also fill the data gap during the hibernation period.

[0014] In some embodiments of this application, the controller is further configured to: Monitor whether the target attribute value exceeds the preset rule threshold; In response to the target attribute value exceeding the preset rule threshold and all triggering conditions corresponding to the preset rule threshold being met, a corresponding control command is generated; The control command is sent to the corresponding execution device, and a cooling-off period of a preset duration is initiated. During the cooling period, the control command is prohibited from being sent, and the current interval setting is to be switched to the interval setting with the longest time interval.

[0015] The above technical solution has the following beneficial effects or advantages: When the attribute value meets the rule triggering condition, the control command can be issued in a timely manner. At the same time, a cooling period is started to avoid repeated triggering of control commands caused by attribute value fluctuations, reduce the frequent actions of the execution device, and automatically switch to the longest interval level during the cooling period to reduce the frequency of invalid data reporting after the rule is triggered, further reduce the communication power consumption of the device, and improve the operational stability of the automated control logic.

[0016] In some embodiments of this application, when the execution device is an intermittently connected device, the controller sends the control command to the execution device, specifically configured as follows: Query the wake-up prediction model of the execution device; Obtain the first moment and average wake-up interval of the most recent wake-up state of the execution device from the wake-up prediction model; Based on the first moment and the average wake-up interval, predict the second moment when the execution device will wake up next, and calculate the predicted waiting time to reach the second moment; The target delivery strategy is determined based on the first moment, the predicted waiting time, and the preset tolerance delay threshold, and the control command is sent to the execution terminal device based on the target delivery strategy.

[0017] The above technical solution has the following beneficial effects or advantages: For intermittently connected execution devices, a predictive model based on historical wake-up data is used to predict the next wake-up time of the device. Combined with a preset tolerance latency threshold, an appropriate instruction delivery method is selected. This can avoid instruction delivery failure during the device's sleep phase and eliminate the need for the device to remain in a constantly connected state, thus increasing power consumption. Under the premise of ensuring timely delivery of control instructions, it adapts to the low-power operation mode of intermittently connected devices.

[0018] In some embodiments of this application, the controller executes a target delivery strategy determined based on the first moment, the predicted waiting time, and a preset tolerance delay threshold, specifically configured as follows: If the system time interval from the first moment does not exceed the active duration of the execution device, then the first delivery strategy is determined as the target delivery strategy; the first delivery strategy is used to instruct that the control command be sent immediately after sending the active extension request to the execution device; If the predicted waiting time is less than or equal to the preset tolerance delay threshold, then the second delivery strategy is determined as the target delivery strategy; the second delivery strategy is used to indicate that the control command is added to the queue to be sent, and when the execution device is detected to be switched to the wake-up state, the control command is taken out from the queue to be sent and sent. If the predicted waiting time is greater than the preset tolerance delay threshold, then the third delivery strategy is determined as the target delivery strategy; the third delivery strategy is used to indicate that the control command is added to the queue to be sent, and the control command is sent periodically according to the polling interval of the execution terminal device.

[0019] The above technical solution has the following beneficial effects or advantages: For three different scenarios—active period, short-term wake-up, and long-term wake-up—delivery strategies are matched accordingly: immediate delivery, delivery upon wake-up, and periodic polling delivery. During the active period, control requirements are responded to quickly. In short-latency scenarios, the timeliness of instructions and device power consumption are taken into account. In long-latency scenarios, the instructions are reliably delivered in the end. This achieves differentiated adaptation of control instruction delivery under different levels of urgency.

[0020] In some embodiments of this application, at least one of a display and an audio output device is also included; when the controller sends the control command to the execution terminal device based on the target delivery strategy, it is further configured to: Start a timeout timer, the duration of which is equal to the preset tolerance delay threshold; If no confirmation response to the control command is received from the execution device before the timeout timer expires, the status of the control command is updated to an alarm status, and the alarm information corresponding to the alarm status is output through the display and / or the audio output device.

[0021] The above technical solution has the following beneficial effects or advantages: After a control command is issued, timeout monitoring is started simultaneously. If no confirmation response is received from the device after the tolerance delay period, an alarm is triggered. The abnormal status of the command is fed back to the user through multiple channels such as the display interface and audio output, so as to avoid the problem that the control command fails but the user cannot perceive it. This improves the transparency of the smart home control process and makes it easier for users to troubleshoot device connection or operation abnormalities in a timely manner.

[0022] In some embodiments of this application, the controller is further configured to: If a confirmation response to the control command is received from the execution device, the wake-up prediction model is updated based on the third moment when the execution device enters the wake-up state, and a notification that the control command has been executed is output through the display and / or the audio output device.

[0023] The above technical solution has the following beneficial effects or advantages: After the control command is successfully delivered to the execution end, the parameters of the wake-up prediction model are iteratively updated using the actual wake-up time data. This allows the prediction result of the wake-up time to be continuously optimized according to the device's operating status, thereby improving the prediction accuracy. At the same time, the command execution status is synchronously fed back to the user, allowing the user to keep abreast of the execution status of the automation rules and improve the interactive experience of using smart homes.

[0024] Secondly, this application also provides a smart home control method, applied to a terminal device, wherein the terminal device has a communication connection with an external device; the method includes: Obtain the target attribute value reported by the external device; Calculate the degree of closeness between the target attribute value and the preset rule threshold, and determine the corresponding target interval level based on the degree of closeness; If the target interval is inconsistent with the current interval that is in effect, the current interval is switched to the target interval, and a subscription request is sent to the external device based on the target interval; the subscription request is used to instruct the external device to report attribute values ​​according to the time interval corresponding to the target interval.

[0025] The above technical solution has the following beneficial effects or advantages: It can achieve adaptive dynamic adjustment of attribute subscription interval, adapt to various terminal devices, and provide complete execution logic for device attribute subscription management on the terminal side, so that the terminal can achieve a balance between low power consumption operation and control response speed, and can adapt to diverse IoT device access scenarios. Attached Figure Description

[0026] 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.

[0027] Figure 1 This is a schematic diagram of a smart home control scenario provided in some embodiments of this application; Figure 2 This is a schematic diagram of the hardware configuration of a terminal device provided in some embodiments of this application; Figure 3 This is a schematic diagram of the software configuration of a terminal device provided in some embodiments of this application; Figure 4 A flowchart illustrating a smart home control method provided in some embodiments of this application; Figure 5 A schematic flowchart illustrating the approximation calculation process provided for some embodiments of this application; Figure 6 A schematic diagram illustrating the interval gear matching process provided for some embodiments of this application; Figure 7 A flowchart illustrating the intermittent connection device compensation strategy provided in some embodiments of this application; Figure 8 A flowchart illustrating the rule triggering and cooling-off period provided for some embodiments of this application; Figure 9 A flowchart illustrating a command scheduling method provided in some embodiments of this application; Figure 10 This is a flowchart illustrating the delivery strategy selection process provided in some embodiments of this application; Figure 11 This is a schematic diagram illustrating the effect of alarm information provided in some embodiments of this application; Figure 12 This application provides schematic diagrams illustrating the effects of execution notifications in some embodiments. Figure 13 This application provides schematic diagrams illustrating the process of updating various commands in some embodiments; Figure 14 This application provides schematic diagrams illustrating the results of updating various commands in some embodiments. Figure 15 This is an interactive schematic diagram illustrating some embodiments of the smart home control method provided in this application. Detailed Implementation

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

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

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

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

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

[0033] In this embodiment, the terminal device 200 generally refers to a device with data processing capabilities. For example, the terminal device 200 includes, but is not limited to, smart speakers, smart TVs, mobile terminals, computers, monitors, advertising screens, wearable devices, virtual reality devices, augmented reality devices, etc.

[0034] Figure 1 These are schematic diagrams illustrating smart home control scenarios provided in some embodiments of this application. For example... Figure 1 As shown, the terminal device 200 can establish a linkage control relationship with various external devices 500 and the execution device 600 to realize adaptive data acquisition and automated control of smart homes. Among them, the external device 500 is a sensing acquisition device with attribute reporting capability, used to collect and report target attribute values ​​such as environmental status and device status in real time; the execution device 600 is a smart home device that can respond to control commands, used to receive control commands issued by the terminal device 200 and execute corresponding adjustment operations.

[0035] The mobile terminal 300 can serve as an interactive control terminal, used to complete human-computer interaction operations between the user and the smart home system. The mobile terminal 300 can establish a communication connection with the terminal device 200 and exchange data. By installing a supporting application, it can configure, view, and manually control all smart devices in the house, and can also synchronously transmit configuration parameters and control commands to the terminal device. In some embodiments, the mobile terminal 300 can also run a corresponding application to simulate some of the control and configuration functions of the terminal device 200.

[0036] like Figure 1 The diagram also shows that the terminal device 200 can communicate with the server 400 via various communication methods. The terminal device 200 can establish a communication connection through networks such as local area networks (LANs) and wireless LANs to achieve functions such as data uploading, model updates, and parameter synchronization. Based on the network architecture, the terminal device 200 can achieve intelligent functions such as adaptive adjustment of the reporting frequency of external devices 500, intermittent device connection adaptation, and intelligent delivery of control commands, meeting the needs of low-power, high-response smart home automation control.

[0037] Terminal device 200 can provide broadcast television reception function, and can also be equipped with intelligent network television function with computer support, including but not limited to network television, smart television, Internet Protocol television (IPTV), etc.

[0038] Figure 2 Provided for some embodiments of this application Figure 1 Hardware configuration block diagram of terminal device 200.

[0039] In some embodiments, the terminal device 200 may include at least one of a tuner 210, a communicator 220, a detector 230, a device interface 240, a controller 250, a display 260, an audio output device 270, a memory, a power supply, and a user input interface 280.

[0040] In some embodiments, detector 230 is used to acquire signals from the external environment or to interact with the outside world. For example, detector 230 includes a light receiver, a sensor for acquiring ambient light intensity; or, detector 230 includes an image acquisition device, such as a camera, which can be used to acquire external environmental scenes, user attributes, or user interaction gestures; or, detector 230 includes a sound acquisition device, such as a microphone, for receiving external sounds.

[0041] In some embodiments, the display 260 includes display function components for presenting images and driving components for driving image display. The display 260 is used to receive and display image signals output from the controller 250. For example, the display 260 can be used to display video content, image content, menu control interface components, and user control UI interfaces, etc.

[0042] In some embodiments, the communicator 220 is a component used to communicate with external devices 500 or servers 400 according to various communication protocol types. The terminal device 200 may have multiple communicators 220 depending on the supported communication methods. For example, when the terminal device 200 supports wireless network communication, it may have a communicator 220 with WiFi functionality. When the terminal device 200 supports Bluetooth connectivity, it needs to have a communicator 220 with Bluetooth functionality.

[0043] The communicator 220 enables the terminal device 200 to communicate with the external device 500 or the server 400 via wireless or wired connections. Wired connections utilize data cables, interfaces, or other components to link the terminal device 200 to the external device 500. Wireless connections can be established via wireless signals or wireless networks. The terminal device 200 can directly establish a connection with the external device 500, or indirectly through gateways, routers, or other connection devices.

[0044] In some embodiments, the controller 250 may include at least one of a central processing unit, a video processor, an audio processor, a graphics processor, and a power processor, and a first to an nth interface for input / output. The controller 250 controls the operation of the terminal device and responds to user operations through various software control programs stored in memory. The controller 250 controls the overall operation of the terminal device 200.

[0045] In some embodiments, the controller 250 and the tuner 210 may be located in different separate devices, that is, the tuner 210 may also be located in an external device of the main device where the controller 250 is located, such as an external set-top box.

[0046] In some embodiments, a user can input user commands through a graphical user interface (GUI) displayed on a display 260, and the user input interface 280 receives the user input commands through the graphical user interface (GUI).

[0047] In some embodiments, the audio output device 270 can be the built-in speaker of the terminal device 200 or an external audio output device connected to the terminal device 200. For the external audio output device connected to the terminal device 200, the terminal device 200 may also be provided with an external audio output terminal, through which the audio output device can be connected to the terminal device 200 to output sound from the terminal device 200.

[0048] In some embodiments, the user input interface 280 can be used to receive instructions from user input.

[0049] In order to perform user interaction, in some embodiments, the terminal device 200 may run an operating system. The operating system is a computer program used to manage and control the hardware and software resources in the terminal device 200. The operating system can control the terminal device to provide a user interface; for example, the operating system can directly control the terminal device to provide a user interface, or it can provide a user interface by running applications. The operating system also allows users to interact with the terminal device 200.

[0050] It should be noted that the operating system can be a native operating system based on a specific operating platform, a third-party operating system that is deeply customized based on a specific operating platform, or an independent operating system specifically developed for terminal devices.

[0051] An operating system can be divided into different modules or levels based on the functions it implements, for example... Figure 3 As shown, in some embodiments, the system is divided into three layers, from top to bottom: the Applications layer (referred to as the "application layer"), the middleware layer, and the hardware layer.

[0052] In some embodiments, the application layer provides services and interfaces for applications, enabling the terminal device 200 to run applications and interact with the user based on the applications. The application layer may contain at least one application, which may be a built-in Windows program, system settings program, or clock program of the operating system; or it may be an application developed by a third-party developer. In specific implementations, the application packages in the application layer are not limited to the examples above.

[0053] The framework layer provides application programming interfaces (APIs) and a programming framework for applications. The application framework layer includes predefined functions. It acts as a central processing unit, determining the actions taken by applications within the application layer. Through the API, applications can access system resources and obtain system services during execution.

[0054] like Figure 3 As shown, Figure 3 Provided for some embodiments of this application Figure 1 The diagram shows the software configuration of the terminal device. In some embodiments, the system of the terminal device 200 can be divided into three layers, from top to bottom: the application layer, the middleware layer, and the hardware layer.

[0055] The application layer mainly includes commonly used applications on TVs, as well as the application framework. The commonly used applications are mainly browser-based applications, such as HTML5 apps, and native apps. An application framework is a complete program model that has all the basic functions required by standard application software, such as file access, data exchange, and the user interface for these functions (toolbar, status bar, menu, dialog box).

[0056] Native apps can support online or offline access, push notifications, or access to local resources.

[0057] The middleware layer includes various television protocols, multimedia protocols, and system components. Middleware can use the basic services (functions) provided by system software to connect different parts of application systems or different applications on the network, achieving resource sharing and function sharing.

[0058] The hardware layer mainly includes the Hardware Abstraction Layer (HAL) interface, hardware, and drivers. The HAL interface is a unified interface for all TV chips, with the specific logic implemented by each individual chip. Drivers mainly include: audio drivers, display drivers, Bluetooth drivers, camera drivers, Wi-Fi drivers, USB drivers, HDMI drivers, sensor drivers (such as fingerprint sensors, temperature sensors, pressure sensors, etc.), and power drivers.

[0059] It should be noted that the above examples are merely a simple division of operating system functions and do not limit the specific form of the operating system of the terminal device 200 in this application embodiment. Depending on the functions of the terminal device, the type of operating system, and other factors, the number of layers and the specific type of the operating system may take other forms.

[0060] In some embodiments, the terminal device 200 can implement smart home control functions. As a local master control device, the terminal device 200 establishes a communication connection based on the Matter protocol with sensing and actuator devices in the home via the communicator 220, thereby realizing local automated control of the smart home.

[0061] In related technologies, terminal device 200, acting as a subscriber, sends a subscription request to sensor device, acting as a publisher, to establish a periodic data reporting channel. The sensor device actively reports attribute values ​​to terminal device 200 at a fixed frequency, according to the minimum and maximum reporting intervals specified in the subscription request. After receiving and caching the reported data, terminal device 200 compares the attribute values ​​with user-preset rule thresholds. When the condition is met, it sends a control command to the actuator device.

[0062] However, in the above implementation, the reporting interval specified in the subscription request is a fixed value, which cannot be dynamically adjusted once set. Using a high-frequency reporting interval increases the power consumption of the sensor device and shortens the lifespan of battery-powered devices; using a low-frequency reporting interval results in an excessively large data sampling interval, preventing the terminal device 200 from immediately detecting when the attribute value exceeds the rule threshold, leading to delayed or failed automated responses. For example, when the light sensor reports the light value at a maximum reporting interval of 120 seconds, if the user-preset automated rule is "close the curtains when the light level is below 100 lux," the light value may have already dropped from 130 lux to 80 lux between two sensor reports, but the terminal device 200 cannot detect this in time, causing a delay in issuing the curtain-closing command.

[0063] To address the aforementioned issues, this application provides a control method for a terminal device and a smart home system. The terminal device 200 serves as the local automation master control device for the smart home. It calculates the degree of convergence between the target attribute value reported by the external device 500 and a preset rule threshold. Based on this convergence, it dynamically matches a target interval level. When the target interval level is inconsistent with the currently effective interval level, it switches and updates the current interval level and resends the subscription request, ensuring that the external device 500 reports attribute values ​​at an adapted time interval. Simultaneously, for the intermittently connected execution device 600, a wake-up prediction model selects the optimal delivery strategy to ensure reliable delivery of control commands. Through the closed-loop coordination of uplink adaptive subscription and downlink intelligent scheduling, it balances the power consumption of the external device 500 with the response time of automation control, improving device adaptability and system operational stability.

[0064] In this embodiment, all types of data acquisition devices are uniformly referred to as external devices 500. External devices 500 are used to acquire or report corresponding attribute values. External devices 500 include, but are not limited to, data acquisition devices such as temperature sensors, humidity sensors, light sensors, human presence sensors, and door / window sensors.

[0065] In some embodiments, the terminal device 200 includes at least a communicator 220 and a controller 250. The communicator 220 is configured to establish a communication connection with an external device 500 and to receive attribute values ​​reported by the external device 500; the controller 250 is electrically connected to the communicator 220 and is used to execute the smart home control method provided in the embodiments of this application.

[0066] In some embodiments, the communicator 220 supports the Matter protocol and establishes a communication connection with the external device 500 via wireless communication methods such as Wi-Fi, Thread, or Bluetooth. For battery-powered intermittent connection devices, the communicator 220 interacts with the ICD device based on the subscription mechanism of the Matter protocol.

[0067] In some embodiments, the terminal device 200 further includes at least one of a display 260 and an audio output device 270. The display 260 is used to display a user interface, including an automation rule configuration interface, a device status interface, an alarm information interface, etc. The audio output device 270 is used to output audio signals such as voice prompts and alarm sounds.

[0068] Figure 4 This is a flowchart illustrating a smart home control method provided in some embodiments of this application. Figure 4 As shown, controller 250 is configured to perform the following steps: S401. Obtain the target attribute value reported by the external device.

[0069] The controller 250 receives attribute values ​​reported by the external device 500 via the communicator 220 and uses the received attribute values ​​as target attribute values. The target attribute values ​​are attribute data currently collected and reported by the external device 500, such as the light intensity value reported by the light sensor, the temperature value reported by the temperature sensor, and the human presence status reported by the human presence sensor.

[0070] In some embodiments, external devices 500 report attribute values ​​to terminal devices 200 at time intervals specified in the subscription request. Terminal devices 200 receive the attribute values ​​reported by each external device 500 through communicator 220, cache the attribute values ​​in local memory, and append the attribute values ​​to the historical records corresponding to the attribute for subsequent trend analysis.

[0071] S402. Calculate the degree of closeness between the target attribute value and the preset rule threshold, and determine the corresponding target interval level based on the degree of closeness.

[0072] The controller 250 calculates the degree of proximity between the target attribute value and a user-preset rule threshold. The rule threshold is the trigger condition threshold set by the user in the automation rule, such as 100 lux in "light intensity below 100 lux" or 28℃ in "temperature above 28℃". The degree of proximity characterizes how close the target attribute value is to triggering the rule threshold; the higher the degree of proximity, the closer the target attribute value is to the rule threshold, and the higher the urgency of triggering the rule.

[0073] Based on the calculated degree of convergence, the controller 250 matches the corresponding target interval from at least two preset interval levels. Each interval level is associated with a different degree range and a corresponding time interval, which includes a maximum time interval and a minimum time interval.

[0074] S403. If the target interval is inconsistent with the current interval that is in effect, the current interval is switched to the target interval, and a subscription request is sent to the external device based on the target interval.

[0075] The controller 250 compares the target interval with the current interval that is currently in effect. If they match, it means that the current reporting interval is already adapted to the urgency of the target attribute value and no adjustment is needed. The controller 250 skips the resubscription (i.e., resending the subscription request) process to avoid the communication overhead caused by frequent subscription rebuilding.

[0076] If the two are inconsistent, the controller 250 will switch the current interval level to the target interval level and send a new subscription request to the external device 500 based on the time interval corresponding to the target interval level. The subscription request is used to instruct the external device 500 to report attribute values ​​according to the time interval corresponding to the target interval level.

[0077] In some embodiments, the subscription request carries the minimum and maximum time intervals corresponding to the target interval level. After receiving the subscription request, the external device 500 destroys the old subscription session and establishes a new subscription session with the new time interval parameters, and reports the attribute values ​​to the terminal device 200 according to the new time interval.

[0078] This embodiment dynamically adjusts the attribute reporting frequency based on the distance of the attribute value from the rule threshold. When the attribute value is far from the threshold, a longer reporting interval is used to reduce the communication power consumption of the external device 500. When the attribute value is close to the threshold, the reporting interval is shortened to ensure the response speed of the automated control. This solves the problem that a fixed reporting interval cannot take into account both device power consumption and control timeliness, adapts to the battery life requirements of IoT devices, and improves the operational rationality of smart home automation rules.

[0079] In some embodiments, the controller 250 calculates the degree of closeness between the target attribute value and a preset rule threshold, achieved through a multi-dimensional comprehensive evaluation. For example... Figure 5 As shown, Figure 5 This is a schematic flowchart of a convergence calculation provided in some embodiments of this application. The controller 250 is configured to perform the following steps: S501. Calculate the absolute value of the difference between the target attribute value and the preset rule threshold to obtain the distance dimension parameter.

[0080] The distance dimension parameter characterizes how closely the target attribute value is numerically close to the rule threshold. In some implementations, the distance dimension parameter can be obtained through normalization, for example, by calculating the ratio of the absolute value of the difference to the reference range of the rule threshold, thus normalizing the range of the distance dimension parameter to between 0 and 1. The closer the distance dimension parameter is to 1, the closer the target attribute value is to the rule threshold.

[0081] For example, when the rule threshold is "light intensity below 100 lux", if the current light intensity is 130 lux and the preset light intensity reference range is 0 to 200 lux, then the distance dimension parameter is (130-100) / (200-0) = 0.15, indicating that the light intensity is far from the threshold and the urgency level is low. If the current light intensity is 105 lux, then the distance dimension parameter is (105-100) / 200 = 0.025, indicating that the light intensity is very close to the threshold and the urgency level is high.

[0082] S502. Based on the changing trend of the target attribute value within the preset statistical window, predict the remaining time for the target attribute value to reach the preset rule threshold, and obtain the trend dimension parameter.

[0083] The trend dimension parameter characterizes the urgency of the time required for the target attribute value to reach the rule threshold according to its current trend. In some implementations, the controller 250 uses a linear regression algorithm to fit the trend of the target attribute value within a preset statistical window (such as the attribute values ​​reported in the last 5 times), and predicts the remaining time required for the target attribute value to reach the rule threshold based on the slope of the fitted line. The trend dimension parameter can be normalized according to the length of the remaining time; the shorter the remaining time, the larger the trend dimension parameter, indicating a higher degree of urgency.

[0084] For example, if the illuminance value gradually decreases from 160 lux to 130 lux in the last 5 reports, the linear regression fit shows a decrease rate of 7.5 lux / report. Based on this rate, it is predicted that the illuminance value will need 4 more reports to drop to 100 lux, indicating a high trend dimension parameter. Conversely, if the illuminance value remains basically unchanged in the last 5 reports, the trend dimension parameter is low.

[0085] S503. Calculate the remaining duration of the target attribute value compared to the total duration in the preset rule threshold to obtain the time window dimension parameter.

[0086] Some automation rules include duration conditions, such as "human presence sensor = no one for 30 minutes," where the time window dimension parameter characterizes the urgency of the remaining time for the duration condition. In some implementations, the controller 250 calculates the duration for which the target attribute value has continuously met a certain condition, subtracts the duration from the total duration specified in the rule threshold, and obtains the remaining duration. The time window dimension parameter can be normalized based on the ratio of the remaining duration to the total duration; the shorter the remaining duration, the larger the time window dimension parameter, indicating a higher degree of urgency.

[0087] For example, when the rule condition is "human presence sensor = no one for 30 minutes", and the sensor reports that the "no one" state has lasted for 25 minutes, the remaining time is 5 minutes, and the time window dimension parameter is 1-5 / 30=0.83, indicating a high degree of urgency.

[0088] S504. Calculate the time difference between the system time and the reporting time corresponding to the target attribute value, and calculate the ratio of the time difference to the time interval corresponding to the current interval level to obtain the freshness dimension parameter.

[0089] The freshness dimension parameter characterizes the freshness of the currently cached target attribute value; the older the data, the more timely the update is required. In some implementations, the controller 250 calculates the time difference between the current system time and the most recent reporting time of the target attribute value, and uses the ratio of this time difference to the maximum time interval corresponding to the current interval level as the freshness dimension parameter. The closer the freshness dimension parameter is to 1, the older the data, and the more the reporting frequency needs to be increased to obtain the latest data.

[0090] For example, if the maximum time interval corresponding to the current interval level is 120 seconds, and the target attribute value was last reported 90 seconds ago, the freshness dimension parameter is 90 / 120=0.75, indicating that the data is relatively old and the reporting frequency needs to be increased.

[0091] S505. Calculate the degree values ​​corresponding to the distance dimension parameter, trend dimension parameter, time window dimension parameter, and freshness dimension parameter.

[0092] After calculating the distance, trend, time window, and freshness dimensions, the controller 250 calculates the degree value corresponding to each dimension. In some implementations, the degree value corresponding to each dimension is the normalized value of the respective dimension parameter. In other implementations, the dimension parameters can be weighted and summed according to preset weight coefficients to obtain a comprehensive degree value.

[0093] S506. The maximum value of the degree value is determined as the degree of approach.

[0094] The controller 250 determines the maximum value among the degree values ​​corresponding to the above-mentioned dimension parameters as the degree of approach. By taking the maximum value, it can ensure that as long as the urgency of any dimension is high, the interval level will be increased, thus avoiding the one-sidedness of judging from a single dimension.

[0095] It should be noted that when calculating the trend of the target attribute value, the controller 250 uses a linear regression algorithm to fit the trend of the target attribute value within a preset statistical window. The size of the preset statistical window can be configured according to actual needs. In some embodiments, the preset statistical window is the attribute value of the most recent 5 reports; in other embodiments, if the attribute value changes drastically, the attribute value of the most recent 3 reports can be used to improve the response speed; if the attribute value changes relatively smoothly, the attribute value of the most recent 10 reports can be used to improve the fitting accuracy. The linear regression algorithm performs least-squares fitting on the attribute value and timestamp within the window to obtain the slope of the fitted line, and predicts the remaining time required for the target attribute value to reach the rule threshold based on the slope.

[0096] In other embodiments, the controller 250 may calculate the overall convergence level using a weighted summation method. This involves weighting and summing the distance dimension parameter, trend dimension parameter, time window dimension parameter, and freshness dimension parameter according to preset weight coefficients to obtain an overall convergence value. The weight coefficients for each dimension can be configured according to the actual application scenario. For example, for attributes that change relatively slowly, such as temperature and humidity, the weight of the trend dimension can be appropriately increased; for attributes that change relatively quickly, such as light intensity and human presence, the weight of the distance dimension can be appropriately increased.

[0097] This embodiment comprehensively evaluates the urgency of rule triggering from four dimensions: numerical distance, trend of change, remaining duration of continuous conditions, and data freshness. This avoids the one-sidedness of judgment based on a single dimension, such as ignoring scenarios where attribute values ​​quickly approach the threshold based solely on numerical distance, or ignoring judgment bias caused by outdated data. This makes the determination of the degree of approach more in line with the actual triggering risk, thereby improving the accuracy of interval level matching.

[0098] It should be noted that, in the embodiments of this application, one or more of the dimensions shown in steps S501-S504 above can be executed, or all dimensions can be calculated simultaneously, depending on the type of automation rule. For example, for rules that do not include duration conditions, the calculation of the time window dimension parameter can be omitted, and the degree of convergence can be comprehensively evaluated based on the remaining dimensions, avoiding invalid calculations and saving 200 units of computing resources on the terminal device.

[0099] It should be noted that in practical applications, automation rules may contain logical combinations of multiple triggering conditions. For example, a complete automation rule could be "(light intensity < 100 lux) AND (human presence sensor = someone is present) AND (terminal device status = playing) → close curtains + adjust lights to 20%". Such a rule contains three triggering conditions: two sensor conditions (light intensity sensor and human presence sensor) and one local condition (terminal device status).

[0100] For rules containing multiple AND conditions, this application embodiment determines the overall urgency by taking the minimum urgency value of each condition. In some implementations, the controller 250 calculates the urgency of each condition in the automation rule that depends on the target attribute value, and then takes the minimum urgency value of all conditions as the convergence degree of the joint evaluation. Since the AND logic requires all conditions to be met simultaneously to trigger the rule, the triggering time of the rule depends on the latest condition to be met (i.e., the condition with the lowest urgency). Taking the minimum value can accurately reflect the true triggering urgency of the rule and avoid unnecessary increases in subscription frequency due to a single high-urgency condition.

[0101] For example, for the above rule, the urgency of the lighting condition "light < 100 lux" is 0.94 (light value 130 lux, close to the threshold), the urgency of the human presence sensor condition is 1.0 (sensor cache value is already "someone is here", the condition is met), and the terminal device status condition is a local condition (no subscription required). The minimum value of the three urgency, 0.94, is taken as the joint proximity degree.

[0102] Furthermore, for local conditions (such as terminal device status, current time, etc.), since these conditions do not depend on subscriptions, there is no need to calculate urgency; they are only checked for compliance during rule triggering and do not participate in the joint evaluation of convergence. This approach avoids unnecessary interference from local conditions on the sensor subscription frequency, ensuring that the adaptive subscription mechanism is driven solely by the urgency of sensor data.

[0103] In some embodiments, the controller 250 is configured with at least two different interval levels, each interval level being associated with a different degree range and a corresponding time interval. For example... Figure 6 As shown, Figure 6 This is a schematic diagram of the interval matching process provided in some embodiments of this application. The controller 250 determines the corresponding target interval based on the degree of proximity, and is specifically configured to perform the following steps: S601, Match the degree range associated with the degree of approach with the interval level.

[0104] In some implementations, the interval levels include four levels: low-frequency, mid-frequency, high-frequency, and ultra-high-frequency. The low-frequency level has an association level range of 0 to 0.25, corresponding to a maximum time interval of 120 seconds and a minimum time interval of 60 seconds; the mid-frequency level has an association level range of 0.25 to 0.5, corresponding to a maximum time interval of 30 seconds and a minimum time interval of 10 seconds; the high-frequency level has an association level range of 0.5 to 0.75, corresponding to a maximum time interval of 10 seconds and a minimum time interval of 5 seconds; and the ultra-high-frequency level has an association level range of 0.75 to 1.0, corresponding to a maximum time interval of 5 seconds and a minimum time interval of 2 seconds.

[0105] S602. Determine the interval level corresponding to the degree range of the match hit as the target interval level.

[0106] For example, when the calculated approximation level is 0.6, and the matching hits the corresponding high-frequency level range (0.5 to 0.75), then the high-frequency level is determined as the target interval level.

[0107] The higher the degree of proximity, the smaller the time interval corresponding to the target interval level. That is, the closer the attribute value is to the rule threshold, the higher the reporting frequency, in order to ensure the response speed of automatic control; when the attribute value is far from the rule threshold, the reporting frequency is lower, in order to reduce the communication power consumption of external devices.

[0108] It should be noted that the number of interval levels, the division of intensity ranges, and the corresponding time intervals described above are merely illustrative examples and do not constitute a limitation on this application. In specific implementations, the number and parameters of interval levels can be flexibly configured according to factors such as the type of external device 500, power consumption requirements, and rule response needs.

[0109] In this embodiment, by pre-setting a mapping relationship between multi-level interval gears and degree ranges, continuous approach degree values ​​are transformed into discrete gear adjustments, simplifying the system's control logic. At the same time, each gear is configured with corresponding upper and lower limits of time intervals (i.e., maximum and minimum time intervals), which can adapt to external devices 500 with different performance and power consumption requirements. The corresponding logic of higher approach degree and shorter reporting interval achieves a positive match between trigger urgency and reporting frequency, ensuring that the gear adjustment process is stable and controllable.

[0110] In related technologies, when a rule is triggered and a control command needs to be sent to an Intermittently Connected Device (ICD), the retry mechanism of the Matter protocol's Message Reliability Protocol (MRP) (which abandons after about 30 seconds) cannot cover the device's sleep cycle because the ICD device is in a sleep state for a long period of time. This results in the control command being lost due to the device being in sleep, leading to silent failure and failing to meet the requirements of high reliability scenarios such as security.

[0111] Furthermore, the uplink data subscription and downlink command scheduling are independent of each other, making it impossible to optimize command delivery strategies based on device perception status; the command execution status lacks visual feedback and degradation paths, users cannot perceive when commands are not delivered, and there are no backup execution plans, resulting in poor stability and user experience of smart home control.

[0112] To address the aforementioned issues, in some embodiments, when the external device 500 is an intermittently connected device, the subscription interval needs to be adapted and adjusted because the ICD device has a sleep characteristic and cannot receive subscription requests or report attribute values ​​during the sleep period.

[0113] like Figure 7 As shown, Figure 7 This is a flowchart illustrating the intermittent connection device compensation strategy provided in some embodiments of this application. The controller 250 also acquires the sleep cycle of the external device 500 (S701). The sleep cycle is the IdleModeDuration parameter of the ICD device, representing the time interval between two wake-ups of the device. For example, the sleep cycle of a battery-powered light sensor is 120 seconds, and the sleep cycle of a door / window sensor is 300 seconds.

[0114] After obtaining the sleep cycle, the controller 250 adjusts the maximum time interval to a first time interval greater than or equal to the sleep cycle, and sends a subscription request to the external device 500 based on the minimum time interval corresponding to the target interval level and the first time interval (S702). Since the ICD device cannot report data during sleep, if the maximum time interval in the subscription request is less than the device's sleep cycle, the device cannot report at the specified frequency. Therefore, the maximum time interval needs to be adjusted to be no less than the sleep cycle. For example, when the target interval level is an extremely high frequency level (corresponding to a maximum time interval of 5 seconds), and the sleep cycle of the external device 500 is 120 seconds, the maximum time interval is adjusted to 120 seconds, and the subscription request parameters are a minimum time interval of 2 seconds and a maximum time interval of 120 seconds.

[0115] After the controller 250 completes the subscription request sending in step S702, it obtains the actual time interval at which the external device 500 returns attribute values ​​based on the subscription request, as the second time interval (S703). Due to the sleep constraint of the ICD device, the actual time interval for returning attribute values ​​may be greater than the minimum time interval specified in the subscription request. The controller 250 monitors the time interval at which the external device 500 actually reports attribute values, as the second time interval.

[0116] If the second time interval is greater than the maximum time interval corresponding to the target interval level, then the external device 500 is marked as a device to be compensated (S704). For example, when the target interval level is a high-frequency level (corresponding to a maximum time interval of 10 seconds), and the external device 500 actually reports an interval of 120 seconds (constrained by the sleep cycle), 120 seconds is greater than 10 seconds, then this external device 500 is marked as a device to be compensated. In response to the device to be compensated switching from a sleep state to an active state, the controller 250 sends an active extension request to the device to be compensated to extend the active duration, and sends a read request to obtain attribute values ​​within the active duration (S705). Here, the active duration is the duration for which the external device 500 is in an active state.

[0117] In some implementations, the controller 250 determines that the device has switched from a sleep state to an active state by detecting the arrival of the attribute value reporting message (ReportData) from the device to be compensated. The controller 250 immediately sends an active extension request (StayActiveRequest) to the device to be compensated, requesting that the device's active duration be extended to a preset duration (e.g., 3000 milliseconds). After the device confirms the extended active duration, the controller 250 sends a read request (ReadRequest) within the active duration to actively read the latest attribute values ​​of the device to compensate for the data gaps during the sleep period.

[0118] For example, after a light sensor (ICD device, sleep cycle 120 seconds) is marked as a device to be compensated, when the controller 250 detects the arrival of the ReportData reported by the sensor, it immediately sends a StayActiveRequest to extend the active window by 3000 milliseconds. After receiving confirmation from the device, it sends a ReadRequest to read the latest light value. The reading operation is repeated within the active window at preset intervals to increase the data acquisition frequency and achieve equivalent high-frequency monitoring.

[0119] It should be noted that the IdleModeDuration of the ICD sensor is an inherent attribute reported by the device in the Matter protocol. The terminal device 200 obtains this parameter by reading the device descriptor when establishing a communication connection. Different ICD sensors have different IdleModeDurations. For example, the IdleModeDuration of a battery-powered human presence sensor is 60 seconds, while that of a door / window sensor is 300 seconds. In ICD constraint processing, the terminal device 200 constrains the desired MaxInterval parameter to be no less than the sensor's IdleModeDuration. This is because the ICD sensor cannot send ReportData messages during its sleep period, and the MaxInterval in the subscription request must be greater than or equal to the sleep period; otherwise, the sensor cannot report data according to the specified upper limit of the interval (i.e., the maximum time interval).

[0120] During the compensation strategy implementation, the controller 250 continuously monitors the data reporting status of devices marked as requiring compensation. When a ReportData message from a device requiring compensation arrives at the communicator 220, the controller 250 determines that the device has switched from a sleep state to an active state and immediately sends a StayActiveRequest to the device via the communicator 220, requesting an extension of the device's active duration. After the device receives and acknowledges the StayActiveRequest, the controller 250 sends a ReadRequest via the communicator 220 within the extended active window to actively read the latest attribute values ​​of the device and update the local cache with the read results, thereby compensating for data gaps during the sleep period and achieving the effect of equivalent high-frequency monitoring.

[0121] In this embodiment of the disclosure, for intermittently connected devices with hibernation characteristics, the upper limit of the subscription reporting interval is adapted to the device's own hibernation cycle to avoid the reporting failure problem caused by the mismatch between the subscription interval and the device's hibernation cycle. When the actual reporting interval is detected to exceed the reasonable range, attribute data is actively read in the device's active window. This will not increase the power consumption of the device during the hibernation phase, and can fill the data gap during the hibernation period.

[0122] In some embodiments, the controller 250 also monitors whether the target attribute value exceeds a preset rule threshold. For example... Figure 8 As shown, Figure 8 As shown in the flowchart of rule triggering and cooling-off period provided in some embodiments of this application, the controller 250 is also configured to perform the following steps: S801. Monitor whether the target attribute value exceeds the preset rule threshold.

[0123] The controller 250 continuously monitors the target attribute values ​​reported by the external device 500 and determines whether the target attribute values ​​exceed the user-preset rule thresholds. For example, when the rule threshold is "illuminance below 100 lux", the controller 250 determines whether the current illuminance value is below 100 lux.

[0124] S802. In response to the target attribute value exceeding the preset rule threshold and all triggering conditions corresponding to the preset rule threshold being met, a corresponding control command is generated.

[0125] The automation rule may contain a logical combination of multiple triggering conditions (such as "light intensity below 100 lux AND human presence sensor = someone is present"). When the target attribute value exceeds the rule threshold and all triggering conditions are met, the controller 250 generates the corresponding control command. For example, it generates the control command "close the curtains".

[0126] S803: Send the control command to the corresponding execution device and start the preset cooling period.

[0127] The controller 250 sends control commands to the execution device 600 (such as smart curtains, smart lights, etc.) and simultaneously starts a preset cooling period (such as 30 seconds) to prevent the control commands from being repeatedly triggered due to fluctuations in attribute values ​​at threshold boundaries.

[0128] S804. During the cooling period, it is prohibited to send control commands and switch the current interval gear to the interval gear with the longest time interval.

[0129] During the cooling period, the controller 250 prohibits the retransmission of the same control command and switches the current interval level to a low-frequency level (i.e., the interval level with the longest time interval) to reduce the frequency of invalid data reporting after the rule is triggered, thereby further reducing the communication power consumption of the device.

[0130] For example, when the illuminance drops to 95 lux (below the 100 lux threshold) and all triggering conditions are met, the controller 250 sends a closing command to the curtains and initiates a 30-second cooling-off period. During the cooling-off period, even if the illuminance fluctuates between 95 lux and 105 lux, the command to close the curtains will not be triggered repeatedly, and the reporting interval of the illuminance sensor will return to a low frequency setting to reduce sensor power consumption.

[0131] In this embodiment, control commands can be issued in a timely manner when the attribute value meets the rule triggering conditions. At the same time, a cooling period is initiated to avoid repeated triggering of control commands caused by attribute value fluctuations, thereby reducing the frequent actions of the execution device 600. During the cooling period, the device automatically switches to the longest interval level, reducing the frequency of invalid data reporting after rule triggering, further reducing the communication power consumption of the device, and improving the operational stability of the automated control logic.

[0132] When a rule is triggered and a control command needs to be sent to the execution device 600, if the execution device 600 is a continuously powered device (such as a smart lighting fixture or air conditioner controller), the controller 250 directly sends an InvokeRequest through the communicator 220, and the device responds immediately. However, when the execution device 600 is an intermittently connected device, the control command may not be delivered directly because the ICD device may be in a sleep state.

[0133] Therefore, such as Figure 9 As shown, Figure 9 This is a flowchart illustrating a command scheduling method provided in some embodiments of this application. The controller 250 sends a control command to the execution device 600, specifically configured to perform the following steps: S901, Query the wake-up prediction model of the execution terminal device.

[0134] The controller 250 maintains a wake-up prediction model for each ICD execution device to predict when the device will next wake up from hibernation. The wake-up prediction model is built based on the device's historical check-in timestamp data, recording the time when the device last entered the wake-up state and statistical information on historical wake-up intervals.

[0135] S902. Obtain the first moment when the execution device last entered the wake-up state and the average wake-up interval from the wake-up prediction model.

[0136] The first moment is the timestamp of the device's most recent check-in, and the average wake-up interval is the average wake-up interval calculated based on historical check-in records. After the controller 250 queries the wake-up prediction model corresponding to the ICD device, it obtains the timestamp of the device's most recent check-in from the wake-up prediction model as the first moment; and obtains the average wake-up interval calculated based on historical check-in records.

[0137] S903. Based on the first moment and the average wake-up interval, predict the second moment when the execution device will wake up next, and calculate the predicted waiting time to reach the second moment.

[0138] The controller 250 uses the sum of the first moment and the average wake-up interval as the predicted second moment, and subtracts the current system time from the second moment to obtain the predicted waiting time. For example, if the execution device 600 last checked-in 5 minutes ago and the average wake-up interval is 30 minutes, then the predicted next wake-up time is 25 minutes later, and the predicted waiting time is 25 minutes.

[0139] S904. Determine the target delivery strategy based on the first moment, the predicted waiting time, and the preset tolerance delay threshold, and send control commands to the execution device based on the target delivery strategy.

[0140] The preset tolerance latency threshold is the maximum command delay time that the system can accept, such as 30 seconds. The controller 250 selects the most suitable delivery strategy based on the device's current wake-up state and the predicted waiting time.

[0141] In this embodiment of the disclosure, for the intermittently connected execution device 600, a prediction model established by historical wake-up data is used to predict the next wake-up time of the device. Combined with a preset tolerance delay threshold, an appropriate instruction delivery method is selected. This can avoid instruction delivery failure during the device's sleep phase and eliminate the need for the device to remain in a constantly connected state, thus increasing power consumption. Under the premise of ensuring timely delivery of control instructions, it adapts to the low-power operation mode of the intermittently connected device.

[0142] In some embodiments, such as Figure 10 As shown, Figure 10 This is a flowchart illustrating the delivery strategy selection process provided in some embodiments of this application. The controller 250 determines the target delivery strategy based on a first moment, a predicted waiting time, and a preset tolerance delay threshold, specifically configured as follows: If the system time elapsed since the first moment does not exceed the active duration of the execution device 600, then the first delivery strategy is determined as the target delivery strategy (S1001). Here, the active duration is the ActiveModeDuration parameter of the ICD device, representing the duration the device remains active after each wake-up, typically 300 milliseconds. If the current system time elapsed since the device's most recent check-in does not exceed the active duration, it indicates that the device may still be active. The first delivery strategy is used to instruct the controller 250 to send a control command immediately after sending an active extension request to the execution device 600. That is, the controller 250 first sends a StayActiveRequest to extend the device's active duration (e.g., to 3000 milliseconds) to ensure the device remains online, and then immediately sends a control command (InvokeRequest).

[0143] If the predicted waiting time is less than or equal to the preset tolerance delay threshold, the second delivery strategy is determined as the target delivery strategy (S1002). If the device is about to wake up (the predicted waiting time does not exceed the tolerance delay threshold), waiting is more efficient than blindly retrying. The second delivery strategy is used to indicate that control commands are added to the queue to be sent, and when the execution device 600 is detected to switch to the wake-up state, the control commands are retrieved from the queue and sent. The controller 250 registers the check-in callback function for the device, and when the device check-in is detected, the callback is triggered to retrieve the command from the queue and send it immediately.

[0144] If the predicted waiting time exceeds the preset tolerance delay threshold, the third delivery strategy is determined as the target delivery strategy (S1003). If the device wake-up time is long (the predicted waiting time exceeds the tolerance delay threshold), continuous attempts are required. The third delivery strategy is used to instruct the addition of control commands to the queue to be sent and to periodically send control commands according to the polling interval of the execution device 600. The controller 250 periodically sends control commands through the MRP mechanism according to the device's slow polling interval (slowPollInterval), and registers a check-in callback as a backup mechanism to ensure that the commands are eventually delivered.

[0145] For example, when the curtain motor (ICD device, sleep cycle 30 minutes) needs to receive a closing command, the controller 250 queries the wake-up prediction model and learns that the curtain last checked in 5 minutes ago and predicts that the next check-in will be in 25 minutes. The predicted waiting time of 25 minutes is greater than the tolerance delay threshold of 30 seconds. The third delivery strategy (continuous retry) is selected, the command enters the queue and is sent periodically according to the polling interval, while waiting for the device to check in and then delivering it immediately.

[0146] In this embodiment, for three different scenarios—the execution device 600 being in an active period, being woken up in a short time, and being woken up after a long time—delivery strategies are matched respectively: immediate delivery, delivery upon waiting for wake-up, and delivery through periodic polling. During the active period, control requirements are responded to quickly; in short-latency scenarios, the timeliness of instructions and device power consumption are taken into account; and in long-latency scenarios, the instructions are ensured to be delivered reliably in the end. This achieves differentiated adaptation of control instruction delivery under different levels of urgency.

[0147] In some embodiments, the terminal device 200 further includes at least one of a display 260 and an audio output device 270. When the controller 250 sends a control command to the execution terminal device 600 based on the target delivery strategy, it also starts a timeout timer, the duration of which is equal to a preset tolerance delay threshold. Regardless of the delivery strategy selected, the controller 250 starts the timeout timer at the same time as sending the control command, and the timer duration is set to the preset tolerance delay threshold (e.g., 30 seconds).

[0148] If no confirmation response to the control command is received from the execution device 600 before the timeout expires, the status of the control command will be updated to an alarm status, and the alarm information corresponding to the alarm status will be output through the display 260 and / or the audio output device 270. That is, the corresponding alarm information will be output through one of the display 260 and the audio output device 270.

[0149] For example, when the timeout timer expires and no acknowledgment response is received from the device, the command status transitions to an alarm status. The controller 250 displays the alarm information via the display 260, such as... Figure 11 As shown, the display 260 shows "The curtain control command has not been delivered. Please check the device status" and at the same time plays an alarm prompt sound through the audio output device 270.

[0150] In some implementations, if the terminal device 200 is in standby mode, the controller 250 wakes up the display 260 via High Definition Multimedia Interface Consumer Electronics Control (HDMI-CEC) or Wake-on-LAN technology to display alarm information. The controller 250 can also send alarm commands to a standby alarm device that is always powered, enabling multi-channel alarms.

[0151] For example, in a security scenario, when a door or window sensor detects that the door or window is open, it triggers the rule to "close the curtains." The curtain motor (ICD device) enters a sleep state, and the control command selects the third delivery strategy (continuous retry). After a 30-second timeout, the command status upgrades to an alarm status, and the terminal device displays a full-screen red warning interface: "Door or window detected open! Curtain command pending delivery, alarm triggered," while the speaker emits an alarm sound.

[0152] In this embodiment, after the control command is issued, timeout monitoring is started simultaneously. If no confirmation response is received from the device after the tolerance delay time is exceeded, an alarm state is triggered. The abnormal status of the command is fed back to the user through multiple channels such as the display interface and audio output, so as to avoid the problem that the control command fails but cannot be perceived by the user, improve the transparency of the smart home control process, and facilitate the user to check the device connection or operation abnormalities in a timely manner.

[0153] In some embodiments, if an acknowledgment response to the control command is received from the execution device 600, the wake-up prediction model is updated based on the third moment when the execution device 600 enters the wake-up state, and a notification that the control command has been executed is output through the display 260 and / or the audio output device 270.

[0154] In other words, when the controller 250 receives the confirmation response from the execution device 600, the command status changes to the confirmed status. The controller 250 uses the device's actual check-in timestamp (the third moment) to update the statistical information of the wake-up prediction model, correcting parameters such as the average wake-up interval, so that the prediction results are continuously optimized according to the device's operating status. Simultaneously, the controller 250 displays command execution notifications on the display 260, such as... Figure 12 As shown, the display 260 shows "The curtains are closed" and plays a voice prompt through the audio output device 270.

[0155] For example, when the curtain motor wakes up after 25 minutes and executes the closing command, the controller 250 updates the wake-up prediction model with the actual check-in timestamp, correcting the estimate of the mean wake-up interval.

[0156] In this embodiment of the disclosure, after the control command is successfully delivered to the execution end, the parameters of the wake-up prediction model are iteratively updated using the actual wake-up time data. This allows the prediction result of the wake-up time to be continuously optimized according to the device's operating status, thereby improving the prediction accuracy. At the same time, the command execution status is synchronously fed back to the user, allowing the user to keep abreast of the execution status of the automation rules and improve the interactive experience of using smart homes.

[0157] It should be noted that the smart home control system provided in this application embodiment is built on the operating system of the terminal device 200, and mainly includes four core parts: TV UI layer, subscription management module, subsystem A (urgency-driven adaptive subscription engine) and subsystem B (wake-up prediction-driven command scheduling engine).

[0158] The TV UI layer is used to configure automation rules, view real-time data from various sensors and the running status of rules, and receive command delivery and upgrade notifications on the large TV screen via the remote control of the terminal device 200. When the terminal device 200 is in standby mode, emergency notifications can wake up the TV screen to display an alarm pop-up window via Wake-on-LAN or High Definition Multimedia Interface Consumer Electronics Control (HDMI-CEC) technology.

[0159] The subscription management module runs on the Matter protocol stack of the terminal device 200. It uses the Wi-Fi, Ethernet module or Thread Border Router module of the terminal device 200 to communicate with the sensors and execution devices. It is responsible for establishing, canceling and re-establishing Matter subscriptions, receiving attribute reporting messages (ReportData), sending StayActiveRequest and ReadRequest, and sending InvokeRequest to the executor.

[0160] Subsystem A is an uplink urgency-driven adaptive subscription engine that dynamically adjusts the subscription frequency based on the multidimensional urgency relationship between the current sensor data and the rule threshold: low-frequency subscription is used when the attribute value is far from the threshold to save sensor power consumption, and high-frequency subscription is switched when the attribute value is close to the threshold to ensure timely capture of threshold-crossing events. For intermittently connected device (ICD) sensors, compensatory monitoring is achieved by extending the active window through StayActiveRequest and actively reading data through ReadRequest.

[0161] Subsystem B is a command scheduling engine driven by wake-up prediction for the downlink. It maintains the wake-up prediction model of the ICD executor, selects the optimal delivery strategy (immediate delivery, predictive waiting delivery, or continuous retry delivery) based on the device's wake-up state when a rule is triggered, and provides delivery confirmation and timeout escalation mechanisms to ensure that control commands are reliably delivered when the device wakes up.

[0162] Subsystem A and Subsystem B form a closed-loop collaboration through rule-triggered events. Subsystem A promptly acquires sensor data and determines whether the rule triggering conditions are met. When a rule is triggered, Subsystem A transmits the generated action command to Subsystem B, which ensures the command is reliably delivered to the execution device 600. The delivery result is then fed back to the user through the TV UI layer. This closed-loop collaboration mechanism, combining uplink adaptive subscription and downlink intelligent scheduling, can balance the power consumption of external device 500 with the response time of automated control, adapting to the diverse power consumption and response requirements of IoT devices.

[0163] It should be noted that subsystem B only processes control commands targeting ICD execution devices. For control commands of continuously powered execution devices, such as smart lighting fixtures and air conditioner controllers (continuously powered type), the subscription management module directly sends an InvokeRequest through communicator 220 after the rule is triggered, and the device responds immediately without going through the processing flow of subsystem B.

[0164] The technical solutions of this application embodiment are further illustrated below with examples of four smart home usage scenarios.

[0165] Viewing scene: The automation rule is: "(Light intensity < 100 lux) AND (Human presence sensor = Someone is present) AND (Terminal device status = Movie playing) → Close curtains + Adjust lights to 20%". Terminal device 200 subscribes to the light sensor and human presence sensor at a low frequency. The light sensor is an ICD device with a sleep cycle of 120 seconds, and the human presence sensor is also an ICD device with a sleep cycle of 60 seconds. After the user starts playing the movie, the internal status of terminal device 200 changes to "Playing".

[0166] As evening light intensity gradually decreases from 160 lux, subsystem A calculates a distance dimension parameter of (130-100) / (200-0) = 0.15 when the light intensity drops to 130 lux, indicating a relatively low urgency of the light conditions. As the light intensity continues to decrease to 110 lux, the distance dimension parameter increases to (110-100) / 200 = 0.05. Considering the trend dimension: the last five reports show a linear decrease from 160 lux to 110 lux at a rate of 10 lux per report, indicating that one more report is needed to reach the threshold, the overall urgency increases to 0.94. Subsystem A determines that it has entered an extremely high frequency range and resubscribes to the light sensor for extremely high frequency parameters (expected Max = 5 seconds, actual Max = 120 seconds due to ICD constraints). Simultaneously, a compensation strategy is initiated, extending the active window via StayActiveRequest and actively reading the latest light intensity value via ReadRequest each time the sensor is woken up.

[0167] The presence sensor continuously reports a "person present" status with a urgency level of 1.0 (condition met). The terminal device's "playing" status is a local condition, also met. A joint evaluation takes the minimum urgency level of each condition, with the overall urgency determined by lighting conditions. When the lighting value drops to 95 lux (below the 100 lux threshold), all three conditions are met, and the rule is triggered. Both curtains and lights are constantly powered devices; terminal device 200 directly sends an InvokeRequest, which is immediately acknowledged. Terminal device 200 overlays a message "Movie mode is enabled, curtains closed, lights dimmed" onto the playback screen displayed on monitor 260, while simultaneously resuming low-frequency subscription to protect sensor battery life.

[0168] Sleep scenarios: The automation rule is: "Terminal device state = just entered standby (within 5 minutes) AND current time 21:00-01:00 AND human presence sensor = someone is here → turn off lights + close curtains + set air conditioner to sleep mode (26°C)". Terminal device 200 senses the change from "power on" to "standby" state, using this as the trigger condition. After terminal device 200 enters standby, the controller 250's on-chip system reduces its frequency, but background services continue to run. The subscription management module and the two subsystems still function normally to execute the automation rule.

[0169] When the user presses the power button on the remote control, terminal device 200 enters standby mode. After detecting a change in standby status, terminal device 200 checks the aforementioned rules, confirming that the current time is between 21:00 and 01:00 and that the human body sensor reports "occupant." If all three conditions are met, the rule is triggered. If the air conditioner and curtains are constantly powered devices, the command is delivered directly; if the curtain motor is an ICD device (with a 30-minute sleep cycle), the control command enters subsystem B. Subsystem B selects the corresponding delivery strategy based on the wake-up prediction model and completes the command delivery. Since the screen of terminal device 200 is off, the execution result notification is pushed via mobile terminal 300 or recorded in a log for viewing upon the next power-on. When the user powers on the device again, the user interface of terminal device 200 displays a process summary, informing the user of the automated execution status of the sleep scenario.

[0170] Scenes of leaving home: The automation rule is: "Human presence sensor = no one for 30 minutes AND current time 08:00-18:00 → turn off air conditioning + turn off lights + curtains half open (ventilation)". Specifically, the human presence sensor is a battery-powered ICD device (IdleModeDuration = 60 seconds), the air conditioning controller is an ICD device (IdleModeDuration = 10 minutes), the lights are constantly powered, and the curtains are an ICD device (IdleModeDuration = 30 minutes).

[0171] Terminal device 200 subscribes to a human presence sensor (ICD device, IdleModeDuration=60 seconds). When the sensor reports an "unoccupied" state, terminal device 200 starts timing. As the timer approaches 30 minutes, the urgency of the time window dimension increases (remaining time is insufficient; for example, if the "unoccupied" state has lasted for 25 minutes, the time window dimension parameter = 1-5 / 30=0.83). Subsystem A initiates a compensation strategy: when the human presence sensor wakes up, it sends a StayActiveRequest to extend the active window and actively reads the latest attribute values ​​via ReadRequest to confirm that the state is still "unoccupied." After 30 minutes of continuous "unoccupied" status, a rule is triggered, generating three commands corresponding to turning off the air conditioner, turning off the lights, and partially opening the curtains.

[0172] The lighting fixtures are constantly powered devices. Terminal device 200 directly sends an InvokeRequest, the lighting fixtures turn off, and an immediate confirmation is returned. The air conditioner controller is an ICD device. The command enters subsystem B. Subsystem B queries the wake-up prediction model and selects the third delivery strategy (continuous retry). Approximately 10 minutes later, the air conditioner controller checks in and wakes up, the command is delivered and executed. The curtains are also an ICD device. The command enters subsystem B, similarly selecting the third delivery strategy, and simultaneously starts a timeout timer (30 seconds). After the timeout, the command status is upgraded to an alarm status. Approximately 30 minutes later, the curtains check in and wake up, the command is finally delivered and executed to turn off. Throughout the entire process, if terminal device 200 is powered on, display 260 updates the execution status of each command in real time, as shown below. Figure 13 The content shown will be updated item by item. Figure 14 The displayed information allows users to monitor the progress of automated execution at any time.

[0173] Security scenarios: The automation rule is: "Door and window sensor = open AND current time 22:00-06:00 AND human presence sensor = no one → close curtains + terminal device sounds alarm + terminal device screen flashes red warning". The terminal device 200 itself has a large screen display, constant power supply and speaker functions, and can be used as a visual and auditory alarm device in security incidents without relying on external independent alarm devices.

[0174] At night, the door and window sensors detect an "open" state, fulfilling the rule trigger condition. Terminal device 200 executes an alarm action, first waking the TV screen via HDMI-CEC, then emitting an alarm sound through the speaker, and displaying a full-screen red warning interface on the screen, including intrusion alarm text, trigger time, and sensor information, providing immediate audio-visual alarm. Simultaneously, it generates a "close curtains" command and enters subsystem B.

[0175] Subsystem B queries the wake-up prediction model of the curtain motor (ICD device, sleep cycle 30 minutes): The curtain last checked in 5 minutes ago, Interval mean The next wake-up time is predicted to be 30 minutes from now. predicted =Current time + 25 minutes, predicted waiting time T wait =25 minutes. Since 25 minutes is much larger than the tolerable delay threshold (30 seconds) for security scenarios, subsystem B chooses the third delivery strategy (continuous retry), enqueues the command and sends it periodically through the MRP mechanism with the slow polling interval (slowPollInterval) of the curtain as the period.

[0176] Simultaneously, subsystem B starts a timeout timer (30 seconds). After 30 seconds, the timer expires, and if the control command still has not received a confirmation response, the command status is upgraded to an alarm status. The display 260 on terminal device 200 updates the display to show: "Door / window open detected! Curtain command pending delivery, alarm triggered," adding command delivery status information to the original red warning interface. If terminal device 200 was in standby mode before the upgrade, HDMI-CEC will wake the screen before displaying the alarm.

[0177] Approximately 25 minutes later, the curtain motor check-in is activated, the command is retrieved from the queue and sent immediately, and the curtains close successfully. After receiving the confirmation response, the terminal device 200 updates the statistics of the wake-up prediction model using the actual check-in timestamp, and the display 260 updates the display to show "Curtains closed, intrusion alarm ongoing," completing the state loop from alarm triggering to command execution.

[0178] Figure 15 These are interactive schematic diagrams illustrating some embodiments of the smart home control method provided in this application. Figure 15 As shown, the communicator 220 establishes communication connections with external devices 500 and various execution devices 600. After completing the initial subscription, the controller 250 reports attribute values ​​according to the time interval corresponding to the initial subscription interval level. The controller 250 then obtains the target attribute value reported by the external device 500, calculates the degree of convergence between the target attribute value and the preset rule threshold, and matches the target interval level based on the degree of convergence. When the target interval level is inconsistent with the current interval level, the controller 250 sends a new subscription request to the external device 500, instructing the external device 500 to report attribute values ​​according to the time interval corresponding to the target interval level. When the target attribute value exceeds the rule threshold and all triggering conditions are met, the controller 250 generates a control command and sends it to the execution device 600. For ICD execution devices, the controller 250 selects the optimal delivery strategy through a wake-up prediction model to ensure reliable delivery of control commands, and provides feedback on the execution status to the user through at least one of the display 260 and audio output device 270 after the command is delivered or times out.

[0179] In some embodiments, when executing a timeout alarm, the controller 250 is further configured with a multi-level alarm handling mechanism. When a command times out, if the terminal device 200 is powered on, the controller 250 displays an alarm interface in full screen on the display 260. The interface content includes the trigger rule name, target device information of the undelivered command, alarm trigger time, and suggested operation prompts for the user to check. Simultaneously, the controller 250 plays a preset alarm tone through the audio output device 270. If the terminal device 200 is in standby mode, the controller 250 first wakes up the display 260 via HDMI-CEC or Wake-on-LAN mechanism before displaying the alarm information.

[0180] In some embodiments, the controller 250 can also send alarm commands to other standby alarm devices that are always powered, thereby achieving multi-channel redundant alarms. For example, the controller 250 can send flashing commands to smart lights that are always powered, or send voice broadcast commands to smart speakers, ensuring that alarm information is delivered to users through multiple channels and improving alarm coverage in high-reliability scenarios such as security.

[0181] After a command timeout escalation, the controller 250 retains the control command in the pending transmission queue, preventing it from being discarded due to timeout. When the target ICD execution device finally wakes up and checks in, the controller 250 immediately retrieves the command from the queue and sends it. After successful command delivery, the controller 250 updates the notification status via the display 260 and / or audio output device 270, providing feedback to the user on the final command execution result.

[0182] Based on the aforementioned terminal device 200, some embodiments of this application also provide a smart home control method, which can be applied to the terminal device 200. The terminal device 200 has a communication connection with the external device 500, such as... Figure 4 As shown, the method includes the following steps: S401. Obtain the target attribute value reported by the external device.

[0183] The target attribute value is the attribute data currently collected and reported by the external device.

[0184] S402. Calculate the degree of closeness between the target attribute value and the preset rule threshold, and determine the corresponding target interval level based on the degree of closeness.

[0185] The controller 250 calculates the degree of proximity from the dimensions of distance, trend, time window and freshness, and matches the degree of proximity with the degree range associated with the preset interval level to determine the target interval level.

[0186] S403. If the target interval is inconsistent with the current interval that is in effect, the current interval is switched to the target interval, and a subscription request is sent to the external device based on the target interval.

[0187] The subscription request is used to instruct external devices to report attribute values ​​according to the time interval corresponding to the target interval level.

[0188] Based on the aforementioned smart home control method, the attribute reporting frequency can be dynamically adjusted according to the distance of attribute values ​​from a rule threshold. When attribute values ​​are far from the threshold, a longer reporting interval is used to reduce the communication power consumption of external devices; when attribute values ​​are close to the threshold, the reporting interval is shortened to ensure the response speed of automated control. Simultaneously, for the intermittently connected execution device 600, a wake-up prediction model selects the optimal delivery strategy to ensure reliable delivery of control commands. Through closed-loop coordination of uplink adaptive subscription and downlink intelligent scheduling, balancing the power consumption of external devices with the response time of automated control, it can adapt to diverse IoT device access scenarios, improving the stability and user experience of smart home control.

[0189] It should be noted that the smart home control method described in this application embodiment can adopt the same principle and implementation method as the embodiment of the terminal device 200 described above, and will not be repeated here.

[0190] The same or similar parts among the various embodiments in this specification can be referred to mutually, and will not be repeated here.

[0191] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or certain parts of the embodiments of the present invention.

[0192] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0193] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

Claims

1. A terminal device, characterized in that, include: The communicator is configured to establish a communication connection with an external device and to receive attribute values ​​reported by the external device. A controller, electrically connected to the communicator, is configured to: Obtain the target attribute value reported by the external device; Calculate the degree of closeness between the target attribute value and the preset rule threshold, and determine the corresponding target interval level based on the degree of closeness; If the target interval is different from the current interval that is in effect, the current interval is switched to the target interval, and a subscription request is sent to the external device based on the target interval. The subscription request is used to instruct the external device to report attribute values ​​according to the time interval corresponding to the target interval level.

2. The terminal device according to claim 1, characterized in that, The controller calculates the degree of closeness between the target attribute value and a preset rule threshold, specifically configured as follows: Calculate the absolute value of the difference between the target attribute value and the preset rule threshold to obtain the distance dimension parameter; Based on the changing trend of the target attribute value within the preset statistical window, the remaining time for the target attribute value to reach the preset rule threshold is predicted, and the trend dimension parameter is obtained. Calculate the remaining duration of the target attribute value relative to the total duration in the preset rule threshold to obtain the time window dimension parameter; Calculate the time difference between the system time and the reporting time corresponding to the target attribute value, and calculate the ratio of the time difference to the time interval corresponding to the current interval level to obtain the freshness dimension parameter; Calculate the degree values ​​corresponding to the distance dimension parameter, the trend dimension parameter, the time window dimension parameter, and the freshness dimension parameter; The maximum value of the degree value is determined as the degree of approach.

3. The terminal device according to claim 1, characterized in that, The controller is also configured with at least two different interval levels, each interval level being associated with a different degree range and a corresponding time interval, the time interval including a maximum time interval and a minimum time interval; The controller determines the corresponding target interval level based on the degree of convergence, specifically configured as follows: Match the degree of proximity with the degree range associated with the interval level; The interval level corresponding to the degree range of the match is determined as the target interval level; The higher the degree of convergence, the smaller the time interval corresponding to the target interval level.

4. The terminal device according to claim 3, characterized in that, When the external device is an intermittently connected device, the controller is further configured to: Obtain the sleep cycle of the external device; The maximum time interval is adjusted to a first time interval that is greater than or equal to the sleep cycle, and the subscription request is sent to the external device based on the minimum time interval corresponding to the target interval level and the first time interval. The actual time interval at which the external device returns the attribute value based on the subscription request is used as the second time interval; If the second time interval is greater than the maximum time interval corresponding to the target interval level, then the external device is marked as a device to be compensated; In response to the device to be compensated switching from a dormant state to an active state, an active extension request for extending the active duration is sent to the device to be compensated, and a read request for obtaining the attribute value is sent within the active duration; The active duration refers to the duration during which the external device is in the active state.

5. The terminal device according to claim 1, characterized in that, The controller is also configured to: Monitor whether the target attribute value exceeds the preset rule threshold; In response to the target attribute value exceeding the preset rule threshold and all triggering conditions corresponding to the preset rule threshold being met, a corresponding control command is generated; The control command is sent to the corresponding execution device, and a cooling-off period of a preset duration is initiated. During the cooling period, the control command is prohibited from being sent, and the current interval setting is to be switched to the interval setting with the longest time interval.

6. The terminal device according to claim 5, characterized in that, When the execution device is an intermittently connected device, the controller sends the control command to the execution device, specifically configured as follows: Query the wake-up prediction model of the execution device; Obtain the first moment and average wake-up interval of the most recent wake-up state of the execution device from the wake-up prediction model; Based on the first moment and the average wake-up interval, predict the second moment when the execution device will wake up next, and calculate the predicted waiting time to reach the second moment; The target delivery strategy is determined based on the first moment, the predicted waiting time, and the preset tolerance delay threshold, and the control command is sent to the execution terminal device based on the target delivery strategy.

7. The terminal device according to claim 6, characterized in that, The controller executes a target delivery strategy based on the first time point, the predicted waiting time, and a preset tolerance delay threshold, specifically configured as follows: If the system time interval from the first moment does not exceed the active duration of the execution device, then the first delivery strategy is determined as the target delivery strategy; the first delivery strategy is used to instruct that the control command be sent immediately after sending the active extension request to the execution device; If the predicted waiting time is less than or equal to the preset tolerance delay threshold, then the second delivery strategy is determined as the target delivery strategy. The second delivery strategy is used to instruct the control command to be added to the queue to be sent, and to retrieve and send the control command from the queue to be sent when the execution device is detected to be switched to the wake-up state; If the predicted waiting time is greater than the preset tolerance delay threshold, then the third delivery strategy is determined as the target delivery strategy. The third delivery strategy is used to instruct the control command to be added to the queue to be sent, and to periodically send the control command according to the polling interval of the execution terminal device.

8. The terminal device according to claim 7, characterized in that, It also includes at least one of a display and an audio output device; when the controller sends the control command to the execution terminal device based on the target delivery strategy, it is further configured to: Start a timeout timer, the duration of which is equal to the preset tolerance delay threshold; If no confirmation response to the control command is received from the execution device before the timeout timer expires, the status of the control command is updated to an alarm status, and the alarm information corresponding to the alarm status is output through the display and / or the audio output device.

9. The terminal device according to claim 8, characterized in that, The controller is also configured to: If a confirmation response to the control command is received from the execution device, the wake-up prediction model is updated based on the third moment when the execution device enters the wake-up state, and a notification that the control command has been executed is output through the display and / or the audio output device.

10. A control method for smart homes, characterized in that, The method is applied to a terminal device, which has a communication connection with an external device; the method includes: Obtain the target attribute value reported by the external device; Calculate the degree of closeness between the target attribute value and the preset rule threshold, and determine the corresponding target interval level based on the degree of closeness; If the target interval is inconsistent with the current interval that is in effect, the current interval is switched to the target interval, and a subscription request is sent to the external device based on the target interval; the subscription request is used to instruct the external device to report attribute values ​​according to the time interval corresponding to the target interval.

Images