Equipment consumable alarm pushing method based on real-time state monitoring and electronic equipment

Abstract

The invention relates to the technical field of smart home, and provides an equipment consumable alarm pushing method based on real-time state monitoring and electronic equipment, and the method comprises the steps: loading a pre-configured consumable alarm rule; receiving and analyzing consumable state report data from the equipment in real time; querying a previous state value corresponding to the equipment for each piece of received consumable state report data; detecting whether a currently reported state value in the consumable state report data is changed relative to a previous state value or not; if the consumable state report data is changed, judging whether the changed state value meets an alarm triggering condition or not based on a consumable alarm rule associated with the equipment model included in the consumable state report data; and if yes, calling a template rendering engine, and generating and pushing an alarm message matched with the consumable alarm rule. The problems that in the prior art, consumable alarm delay is high, and the state change cannot be responded in real time are solved, and real-time and accurate alarm pushing based on the equipment state change is achieved.

Description

Technical Field

[0001] This invention relates to the field of smart home technology, and in particular to a method and electronic device for sending alarms for device consumables based on real-time status monitoring. Background Technology

[0002] With the rapid development of IoT and smart home technologies, various smart devices have been widely used in home and commercial settings. These devices typically rely on various consumables to maintain their normal operation and performance. Timely monitoring of the remaining status of consumables and timely replacement are crucial to ensuring the effectiveness of device functionality and user experience.

[0003] Currently, most common consumable management solutions in the industry rely on local device-side detection or cloud-based periodic batch calculations. Device-side detection typically only triggers local alerts when consumables are depleted, failing to provide remote real-time notifications. Cloud-based solutions often employ offline batch processing, periodically polling device status, calculating remaining consumables, and determining whether an alarm is necessary. These solutions suffer from significant real-time limitations: a substantial delay exists between the consumable status reaching the alarm threshold and the user receiving the notification, preventing timely user response and potentially leading to device performance degradation or even damage due to consumable depletion. Furthermore, existing solutions are usually designed independently for single-category devices, resulting in fragmented consumable status query interfaces for different device categories. This leads to complex system architecture, high network and computing resource consumption, and high maintenance costs. Alarm rules are also often relatively simple, making it difficult to personalize configurations based on device type, consumable characteristics, and user habits. Moreover, alarm content is usually limited to status notifications, lacking a one-stop service capability that integrates consumable purchase and replacement guidance.

[0004] Therefore, how to achieve real-time monitoring and alarm push of whole-house equipment consumables with low latency, high accuracy, high resource efficiency and user-friendly experience in an environment where multiple types of smart devices coexist has become an important technical problem that the industry urgently needs to solve. Summary of the Invention

[0005] This invention provides a device consumable alarm push method based on real-time status monitoring, which solves the problems of high alarm delay and inability to respond to status changes in the prior art, and realizes real-time and accurate alarm push based on device status changes.

[0006] This invention provides a method for pushing device consumable alarms based on real-time status monitoring, comprising: Load pre-configured consumable alarm rules, which are associated with the device model; The consumable status report data from the device is received and parsed in real time through the message middleware. The consumable status report data includes the device model and status value. For each received consumable status report, query the previous status value of the device in the memory cache; Detect whether the current reported status value in the consumable status reporting data has changed relative to the previous status value; If a change in status value is detected, the alarm rule associated with the device model included in the consumable status reporting data is used to determine whether the changed status value meets the alarm triggering condition. If the alarm triggering conditions are met, the template rendering engine is invoked to generate and push an alarm message that matches the consumable alarm rule.

[0007] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided. The loading of pre-configured consumable alarm rules specifically includes: retrieving consumable alarm rule configuration information from a preset rule database according to various device models, wherein the consumable alarm rule configuration information includes at least one consumable alarm triggering condition and its corresponding alarm rule identifier; converting the consumable alarm rule configuration information into a Flink pattern sequence; loading the Flink pattern sequence into memory for pre-compilation processing to form a rule expression that can be calculated in real time.

[0008] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided. The real-time reception and parsing of consumable status reporting data from the device specifically includes: subscribing to a consumable status reporting data stream from the device in real time via a message middleware; the data stream being encapsulated in a serialized format and transmitted via a unified Kafka topic; deserializing and decoding the received consumable status reporting data stream, and verifying whether it conforms to a predefined basic message format, which at least includes a message header and a message body; extracting key information from the verified message body, the key information including device model identifier, consumable attribute identifier, and corresponding status value; and converting the key information into consumable status reporting data in a unified format.

[0009] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided. The step of detecting whether the currently reported status value in the consumable status reporting data has changed relative to the previous status value specifically includes: for each received consumable status reporting data, querying the historical status value corresponding to the device and consumable attributes from the cache; comparing the current status value in the consumable status reporting data with the historical status value; if the current status value is different from the historical status value, determining that the status value has changed, and updating the current status value in the cache.

[0010] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided. The step of determining whether a changed status value meets the alarm triggering condition based on consumable alarm rules associated with the device model included in the consumable status reporting data specifically includes: filtering all consumable alarm rules associated with the device model from pre-loaded alarm rules according to the device model identifier in the consumable status reporting data, generating a target rule subset to be evaluated; extracting the pre-compiled rule expression logic for each consumable alarm rule in the target rule subset; dynamically binding the changed status value and the associated attribute value extracted from the reporting data as input parameters to the corresponding variable of the rule expression to form an executable condition judgment instance; traversing the target rule subset according to a preset rule priority order, executing the corresponding condition judgment instance for each rule; and determining that the triggering condition of the consumable alarm rule is met when the evaluation result of the condition judgment instance of any rule is true.

[0011] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided, which generates an alarm message matching the consumable alarm rule. Specifically, the method includes: obtaining a predefined message template associated with the triggered consumable alarm rule, wherein the message template contains a notification text corresponding to the consumable type; and generating an alarm notification message containing a consumable details access entry based on the message template, the consumable information corresponding to the triggering rule, and user information.

[0012] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided. The method further includes: recording key event logs during the alarm triggering process, wherein the key event logs include status change events, rule matching events, and message push events; and writing the key event logs into a preset log storage and analysis system.

[0013] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided, wherein the consumable alarm rules include at least one of the following types: warning rules, alarm rules, and recovery rules; wherein, the warning rules are used to trigger a warning message when the remaining amount of consumables drops to a preset warning threshold, the alarm rules are used to trigger an alarm message when the remaining amount of consumables drops to a preset alarm threshold, and the recovery rules are used to trigger a status recovery message when the status of consumables returns to normal from an alarm or warning state.

[0014] The present invention also provides a device for pushing alarms for equipment consumables based on real-time status monitoring, comprising: The rule loading module is used to load pre-configured consumable alarm rules, which are associated with the device model; The data receiving module is used to receive and parse consumable status reporting data from the device in real time through a message middleware. The consumable status reporting data includes the device model and status value. The status detection module is used to query the previous status value of the device in the memory cache for each received consumable status report data; and to detect whether the current reported status value in the consumable status report data has changed relative to the previous status value. The alarm triggering module is used to determine whether the changed status value meets the alarm triggering conditions based on the consumable alarm rules associated with the device model included in the consumable status reporting data if a change in status value is detected. The alarm module is used to call the template rendering engine to generate and push alarm messages that match the consumable alarm rules if the alarm triggering conditions are met.

[0015] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the device consumable alarm push method based on real-time status monitoring as described above.

[0016] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the device consumable alarm push method based on real-time status monitoring as described above.

[0017] The device consumable alarm push method and electronic device based on real-time status monitoring provided by this invention achieves device-level personalized configuration of alarm rules by pre-associating alarm rules with specific device models. This allows different types and models of devices to adapt to their unique consumable alarm logic, enhancing the system's applicability and flexibility. By receiving and parsing consumable status reporting data from various types of devices in real time and detecting changes in the currently reported status value, the system effectively filters invalid reports where the status has not actually changed, avoiding redundant processing of duplicate or invalid status data and significantly reducing unnecessary consumption of computing resources. Furthermore, the matching judgment based on the corresponding device model alarm rule is triggered only when a change in the status value is detected. This ensures that the alarm triggering mechanism accurately focuses on the actual status transition process, guaranteeing the immediacy of the alarm response and fundamentally overcoming the inherent latency problem of traditional polling or timed batch processing methods. By generating and pushing alarm messages that match the triggering rules, the system can provide users with timely, accurate alarm information closely related to the device and consumable status, effectively improving users' perception and response efficiency regarding device and consumable status. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this invention 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 some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the hardware environment for a device consumable alarm push method based on real-time status monitoring according to an embodiment of this application.

[0020] Figure 2 This is a flowchart illustrating the device consumable alarm push method based on real-time status monitoring provided by the present invention.

[0021] Figure 3 This is a schematic diagram of the core data flow and module interaction relationship of the whole-house equipment consumable alarm push system based on real-time status monitoring provided by the present invention.

[0022] Figure 4 This is a schematic diagram of the internal processing flow and component collaboration relationship of the device consumable alarm push system based on the rule engine provided by the present invention.

[0023] Figure 5 This is a schematic diagram of the device consumable alarm push device based on real-time status monitoring provided by the present invention.

[0024] Figure 6 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] According to one aspect of the embodiments of this application, a method for pushing device consumable alarms based on real-time status monitoring is provided. This method is widely used in whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and intelligence house ecosystems. Optionally, in this embodiment, the above-mentioned method for pushing device consumable alarms based on real-time status monitoring can be applied to, for example... Figure 1 The hardware environment shown consists of terminal device 102 and server 104. For example... Figure 1 As shown, server 104 is connected to terminal device 102 via a network and can be used to provide services (such as application services) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data processing services for server 104.

[0028] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The terminal device 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0029] The following is combined with Figures 2 to 5 Embodiments of the present invention are described.

[0030] Figure 2 A schematic flowchart of a device consumable alarm push method based on real-time status monitoring provided by the present invention includes the following steps: S210: Load pre-configured consumable alarm rules. Consumable alarm rules are associated with the device model.

[0031] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided, which loads pre-configured consumable alarm rules, specifically including: pulling consumable alarm rule configuration information from a preset rule database according to various device models, wherein the consumable alarm rule configuration information includes at least one consumable alarm triggering condition and its corresponding alarm rule identifier; converting the consumable alarm rule configuration information into a Flink pattern sequence; loading the Flink pattern sequence into memory for pre-compilation processing to form a rule expression that can be calculated in real time.

[0032] Specifically, the rules database is a MySQL instance deployed on the system backend. The structured configuration tables stored within it use the device model as the primary key, and each record contains one or more consumable alarm rules for that specific model. Each rule configuration includes at least: a unique rule identifier, the associated device model, the consumable attribute identifier, the rule type, the trigger threshold or status expression, the corresponding message template identifier, and the rule's priority weight. The system provides a visual operation interface through a separate backend configuration service. Maintenance personnel or business users can use this interface to add, modify, or enable / disable consumable alarm rules for different device models (e.g., a water purifier with the model number "KS-001" or an air conditioner with the model number "AC-202"). All changes are persisted to the MySQL database in real time.

[0033] To support dynamic activation and efficient execution of rules, the system includes a rule loading and preprocessing module. This module runs as a scheduled task (default hourly), actively scanning and fetching all enabled rule records from the MySQL database. After fetching, the module first performs syntax validation and dependency resolution on the original configuration information to ensure the validity of the rule expressions and that the referenced device attributes exist in the metadata system. Next, the module converts each validated rule configuration into a "Pattern" sequence or state machine definition recognizable by Flink CEP (Complex Event Processing).

[0034] During this conversion process, for example, for an alarm rule like "Air conditioner formaldehyde removal module remaining amount ≤ 4.99%", the system generates a Flink Pattern. This Pattern defines a sequence of events that monitors the "air_quality_module_remaining" attribute value changing from greater than 4.99% to less than or equal to 4.99%. For state flag-type rules like "Water softener low salt (noSaltFlag changes from false to true)," the conversion is done into a Pattern that detects the topping of specific Boolean state fields. All generated standardized Flink pattern sequences are then loaded into the memory managed by the Flink job.

[0035] During the memory loading phase, the system further invokes Flink's rule pre-compiler to pre-compile these pattern sequences into state transition logic or predicate expressions that can be directly and efficiently matched and computed on streaming data, forming "real-time computeable rule expression" objects that can be directly called by Flink streaming tasks. This pre-compilation process transforms the text-based thresholds and logical conditions in the configuration into binary instructions that can be directly compared numerically or determined at runtime, thus avoiding the overhead of repeatedly parsing strings and constructing logic when processing massive amounts of device data per second.

[0036] This embodiment achieves centralized management and high-performance execution of consumable alarm rules through a process of pulling configurations from a MySQL rules database, converting them into standardized Flink pattern sequences, and performing in-memory pre-compilation. By pre-compiling text configurations into directly executable binary expressions, the runtime computation overhead during rule matching is significantly reduced, avoiding the performance loss of repeatedly parsing and constructing logical conditions for each data stream processing. This ensures the system's high throughput and low latency processing capabilities in scenarios with millions of concurrent device reports. Using standard Flink pattern sequences as an intermediate representation enhances the expressive power of rules and system compatibility, supporting various alarm scenarios ranging from simple threshold comparisons to complex event sequence patterns, laying a solid technical foundation for future rule logic expansion.

[0037] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided. The consumable alarm rules include at least one of the following types: warning rule, alarm rule, and recovery rule; wherein, the warning rule is used to trigger a warning message when the remaining amount of consumable drops to a preset warning threshold, the alarm rule is used to trigger an alarm message when the remaining amount of consumable drops to a preset alarm threshold, and the recovery rule is used to trigger a status recovery message when the consumable status returns to normal from the alarm or warning status.

[0038] Specifically, the early warning rule is triggered when the remaining consumable quantity drops to a preset warning threshold (e.g., the remaining lifespan of a robot vacuum's side brush ≤ 20%), reminding the user in advance. The alarm rule is triggered when the remaining consumable quantity drops to an alarm threshold requiring replacement (e.g., the efficiency of an air conditioner's formaldehyde removal module ≤ 5%), notifying the user to take immediate action. The recovery rule is triggered when the consumable status returns to normal from an alarm or warning state (e.g., after the user replaces a new filter, the relevant attribute values ​​are reset), clearing the previous alarm status and notifying the application to update the interface, ensuring the integrity of status management. Through this refined, pre-compiled, and multi-type rule configuration based on device model, the system lays a solid foundation for subsequent real-time and accurate status judgment.

[0039] By defining three rule types—early warning, alarm, and recovery—the system can fully describe the entire lifecycle of consumables from normal to depletion and then to recovery, providing users with more accurate and detailed status prompts, improving user experience and the effectiveness of alarms.

[0040] S220: Receives and parses consumable status reporting data from devices in real time via message middleware. The consumable status reporting data includes device model and status value.

[0041] The present invention provides a device consumables alarm push method based on real-time status monitoring, which receives and parses consumables status reporting data from devices in real time. Specifically, the method includes: subscribing to consumables status reporting data streams from devices in real time via a message middleware; encapsulating the data streams in a serialized format and transmitting them via a unified Kafka topic; deserializing and decoding the received consumables status reporting data streams and verifying whether they conform to a predefined basic message format, which at least includes a message header and a message body; extracting key information from the verified message body, including device model identifier, consumables attribute identifier, and corresponding status value; and converting the key information into consumables status reporting data in a unified format.

[0042] Specifically, the system subscribes to a unified topic in real time through a dedicated Kafka consumer group. This topic receives raw status data messages reported by various smart devices throughout the house (including but not limited to air conditioners, robot vacuums, water purifiers, and smart door locks) via device-side SDKs or IoT gateways. These reported messages are serialized and encapsulated by the device or edge gateway according to a predefined binary protocol before transmission. The message structure is mandated to include a fixed header and a variable body. The header contains metadata such as protocol version, message type, data timestamp, and message length; the body carries specific device status key-value pairs.

[0043] After the consumer retrieves the raw byte stream, it first calls the corresponding deserializer to decode the byte stream and restore it to a structured memory object. Next, the system performs basic format checks: it checks whether the protocol version in the message header is within the supported range, whether the message length matches the declaration, and whether necessary fields exist and are not empty. If any check fails, the message is recorded as having a format error and discarded, and will not proceed to further processing.

[0044] For messages that pass verification, the system precisely extracts key business fields from the message body: based on predefined field mapping relationships, it parses the "modelId" field to identify the specific device model, the "attributeKey" field to identify the specific consumable attribute, and the latest value corresponding to that attribute. This extracted raw information (which may be of different types such as integers, floating-point numbers, booleans, or strings) is then passed to a data standardization processor. This processor, based on a centralized "device-attribute" metadata configuration table, maps heterogeneous attribute identifiers from devices of different manufacturers or categories to standardized internal attribute codes, and uniformly converts all numerical types to floating-point percentages or preset enumerated values. Finally, the processor outputs a standardized "Consumable Status Reporting Data" object, which fixedly contains the following fields: standardized device model ID, standardized consumable attribute ID, normalized status value, and a precise reporting timestamp inherited from the message header. This standardized object serves as the sole defined input for subsequent status change detection and rule matching modules.

[0045] This embodiment ensures the standardization and integrity of the input data stream through unified topic access and mandatory basic format verification, effectively filtering out dirty data caused by network anomalies, device malfunctions, or protocol inconsistencies, providing a clean and reliable data foundation for subsequent core processing modules. By mapping heterogeneous device models and consumable attribute identifiers to internal unified codes, semantic standardization at the data level is achieved, completely resolving the data fragmentation problem caused by differences in device categories and manufacturers. This allows the subsequent rule engine to process and identify consumable status from any device in a consistent manner, greatly improving the system's compatibility and scalability. Finally, the entire parsing process is efficiently completed within the stream processing framework, realizing a standardized pipeline processing of data from access, reducing repeated access and transformation of raw data, and lowering the overall system processing latency and computational overhead.

[0046] S230: For each received consumable status report, query the previous status value of the device in the memory cache; check whether the current reported status value in the consumable status report data has changed relative to the previous status value.

[0047] Specifically, in a Flink stream processing job, the system maintains a key-value state for each "device-attribute" pair that requires consumable status monitoring. This key-value pair is a composite key, such as "device unique identifier: consumable attribute identifier". When a standardized consumable status report (containing the device ID, attribute ID, and current status value) enters the status detection phase, the system first uses this composite key as an index to query the Flink-managed in-memory state backend. The state backend stores the "previous state value" corresponding to this key, which is initially null or a preset initial value. The query operation is implemented by calling the `ValueState.value()` method, providing a millisecond-level response.

[0048] By leveraging the high-performance, fault-tolerant memory state management mechanism built into the Flink framework to maintain and query the previous state values ​​of device consumables, a fundamental reduction in computational load is achieved. By performing subsequent complex rule matching and message generation processing only on the changed device state data, the unnecessary consumption of system computing resources by the continuous reporting of duplicate and invalid data from massive devices is effectively avoided.

[0049] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided, which detects whether the current reported status value in the reported data has changed relative to the previous status value. Specifically, the method includes: for each received consumable status report, querying the historical status value corresponding to the device and consumable attributes from the cache; comparing the current status value in the consumable status report with the historical status value; if the current status value is different from the historical status value, it is determined that the status value has changed, and the current status value is updated in the cache.

[0050] Specifically, the system maintains a high-performance in-memory cache (e.g., implemented using Redis or Guava Cache) to store the most recent valid status value for each consumable attribute of each device. When the rule engine processes a parsed and standardized consumable status report from Kafka (containing device model, consumable attribute identifier, and current status value), it first combines "device model + consumable attribute identifier" to form a unique cache key, such as "KFR-35GW:filterRemain". The system uses this key to query the historical status value of that consumable attribute for that device from the aforementioned in-memory cache. For example, the retrieved historical value might be "20". The system then strictly compares the current status value in the reported data (e.g., "15") with the retrieved historical status value ("20"). If they differ (15 ≠ 20), the system determines that the status value of the consumable has changed. Once a change is detected, the system not only marks the data as "pending rule triggering" but also immediately updates the corresponding key-value pair in the cache with the current status value "15," ensuring that the cache stores the latest status of that consumable attribute for the device. If the current status value is the same as a historical status value (for example, the remaining percentage is 20% in both reports), it is determined that the status has not changed, and the system will ignore this data, refrain from further rule matching and calculation, and directly process the next data. This mechanism ensures that only data that truly reflects the change in the consumable's status will trigger the subsequent complex rule calculation process.

[0051] By introducing a memory cache to record historical states and perform real-time comparisons, efficient computational filtering is achieved. In scenarios with a large number of devices frequently reporting their states, most reported events are simply repetitive reports of unchanged states (heartbeat packets, periodic synchronization). This mechanism can accurately identify and filter out these redundant "unchanged state" data, avoiding full rule traversal and expression calculations for every reported data, thereby greatly reducing unnecessary computational overhead and CPU resource consumption. This allows the system's processing power to be more focused and efficient on critical data that actually undergoes state changes and requires alarm judgment, providing crucial support for real-time processing of millions of devices. Simultaneously, it directly improves the accuracy of alarm responses, as it ensures that alarm triggering is strictly based on state "changes" rather than "instantaneous values," avoiding duplicate and redundant alarm notifications caused by devices repeatedly reporting the same alarm state value, thus improving the user experience.

[0052] S240: If a change in status value is detected, then based on the consumable alarm rules associated with the device model included in the consumable status reporting data, determine whether the changed status value meets the alarm triggering conditions.

[0053] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided. Based on the consumable alarm rules associated with the device model included in the consumable status reporting data, the method determines whether the changed status value meets the alarm triggering condition. Specifically, the method includes: selecting all consumable alarm rules associated with the device model from pre-loaded alarm rules according to the device model identifier in the consumable status reporting data, generating a target rule subset to be evaluated; for each consumable alarm rule in the target rule subset, extracting its pre-compiled rule expression logic; dynamically binding the changed status value and the associated attribute value extracted from the reporting data as input parameters to the corresponding variables of the rule expression, forming an executable condition judgment instance; traversing the target rule subset according to a preset rule priority order, executing the corresponding condition judgment instance for each rule; and determining that the triggering condition of the consumable alarm rule is met when the evaluation result of the condition judgment instance of any rule is true.

[0054] Specifically, after the consumable status data reported by the device is standardized, its "device model identifier" is used to query the rule index pre-loaded into memory. This index structure uses the device model as the key and associates it with a list of rule IDs configured under that model. The system uses this index to quickly locate and filter all consumable alarm rules that need to be applied to the current data, forming a "target rule subset" to be evaluated. This subset already contains all warning rules, alarm rules, and recovery rules bound to the current model. For each rule in the subset, the system obtains its pre-compiled rule expression logic object in memory. Taking the "formaldehyde removal module remaining quantity" alarm rule for the air conditioner model "AC-202A" as an example, its pre-compiled expression logic is a comparison structure similar to "val<= 4.99".

[0055] The system dynamically binds the "changed status value" parsed from the reported data to the input parameter "val" of the expression. For composite rules involving multiple attributes, the system extracts the values ​​of all related attributes from the same reported data and binds them separately. After binding, a directly executable "conditional judgment instance" is formed. The system traverses subsets according to the priority order pre-configured for each rule (e.g., alarm rules have the highest priority, followed by warning rules, and finally recovery rules). For each rule, its corresponding conditional judgment instance is evaluated. When the alarm rule instance "val <= 4.99" is executed, since 4.5 ≤ 4.99 is true, the evaluation result of this instance is true, and the system determines that the triggering condition of this alarm rule is met, immediately terminating the evaluation of subsequent lower-priority rules to determine the final triggered rule.

[0056] This embodiment establishes an evaluation mechanism based on device model for rapid rule filtering, dynamic expression binding, and priority-based execution. This ensures targeted rule matching, evaluating only rules relevant to the current device model and avoiding unnecessary computational overhead from global rule traversal, thus improving processing efficiency. By binding pre-compiled expression logic with dynamically reported data in real time, it retains the flexibility of rule configuration while achieving near-native code execution performance, guaranteeing the judgment of complex conditions within millisecond latency. The introduction of priority order ensures the determinism and rationality of alarm decisions, accurately selecting the most urgent or relevant alarm type for push when multiple rules may be triggered simultaneously. This effectively avoids notification redundancy and logical conflicts, improving the system's business rationality and user experience.

[0057] S250: If the alarm triggering conditions are met, the template rendering engine is invoked to generate and push alarm messages that match the consumable alarm rules.

[0058] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided, which generates an alarm message matching the consumable alarm rule. Specifically, the method includes: obtaining a predefined message template associated with the triggered consumable alarm rule, wherein the message template contains a notification text corresponding to the consumable type; and generating an alarm notification message containing a consumable details access entry based on the message template, the consumable information corresponding to the triggering rule, and the user information.

[0059] Specifically, when the rule engine determines that a change in the status of a consumable meets the alarm triggering conditions, the system immediately initiates the message generation process. Based on the unique identifier of the triggering rule (e.g., rule ID alarm_water_filter_ABC123), the system retrieves a predefined message template associated with that rule from a pre-configured message template library. This template library is typically stored in a database or configuration center, and the template content is tightly bound to the consumable type, device model, and even the specific alarm rule. For example, a template for the "water purifier PP cotton filter alarm rule" might have the following notification text: "The [consumable name] of your [device alias] is less than [threshold]% remaining. We recommend timely replacement to ensure safe drinking water." The template includes placeholder variables such as {deviceAlias}, {consumableName}, and {threshold}.

[0060] The system will combine the consumable information corresponding to the trigger rule (such as the consumable name "PP cotton filter" extracted from the rule configuration and the trigger threshold "20%)) and user information (such as the user nickname obtained from the device binding relationship and the device custom alias "living room water purifier"), and fill the above variables into the corresponding placeholders in the message template to generate a personalized and complete notification text.

[0061] Furthermore, the message template defines a consumable details access point, which can be a deep link URL or a specific routing instruction. When generating the final message, the system encapsulates this access link along with the notification text into a structured message object. For example, the generated alarm notification message might include: a title "Consumable Expiration Reminder," a body stating "The PP cotton filter cartridge in your living room water purifier has less than 20% remaining. It is recommended to replace it promptly to ensure drinking water health," and a link that, when clicked, directly redirects to the "Consumable Details Page for this Water Purifier" within the app. This details page not only displays the consumable status but also provides a "Buy Now" button, directly linking to the purchase page for that model of filter cartridge on an e-commerce platform.

[0062] By constructing alarm messages using templates and parameterization, personalized and user-friendly alarm content is achieved. Incorporating device aliases, user context, and specific consumable information transforms push notifications from cold code or generic prompts into thoughtful reminders tailored to actual user scenarios, improving readability and user acceptance. Predefined templates and variable population mechanisms ensure consistency and efficiency in message content generation, avoiding errors and performance overhead associated with dynamically concatenating complex strings for each alarm. This also facilitates unified management and optimization of push notification text by operations personnel. The generated alarm messages include direct access to the consumable details page, fundamentally changing the traditional limitation of alarms that only "inform the status." This seamlessly connects the service chain of "status awareness," "details viewing," and even "one-click purchase," providing users with a one-stop closed-loop experience from problem discovery to resolution. This not only greatly improves the convenience and efficiency of consumable replacement for users but also provides a direct and efficient traffic source for subsequent consumable e-commerce conversion, creating significant commercial value.

[0063] According to the present invention, a device consumable alarm push method based on real-time status monitoring is provided, which records key event logs during the alarm triggering process. The key event logs include status change events, rule matching events, and message push events; and writes the key event logs into a preset log storage and analysis system.

[0064] Specifically, the system synchronously records structured critical event logs at key nodes across the entire chain where alarms are triggered. When a change in the status value of a device consumable is detected (i.e., a "status change event"), the system immediately generates a log entry containing at least: the unique identifier of the device that changed, the consumable attribute name, the status values ​​before and after the change, and a precise timestamp. For example, the log entry might be: "device:AC-001,attribute:filterRemain,changed_from:20,changed_to:15, timestamp:2023-10-01T10:00:00.000Z".

[0065] During the rule matching phase (i.e., the "rule matching event"), regardless of whether an alarm is successfully triggered, the system records detailed information about the matching process, including: the device model attempted to be matched, the list of rule IDs traversed, the evaluation result of each rule (satisfied / unsatisfied), and the final triggered rule ID (if any). For example, the log might read: "device_model:KFR-35GW,evaluated_rules:[rule_001, rule_002], triggered_rule:rule_002".

[0066] After a message is generated and attempted to be sent (i.e., a "message push event"), the system records the final status of the push, including: the target user ID, the pushed message ID / template ID, the push channel, the push status (success / failure), and the response or error code returned by the downstream system. For example, the log might be: "user:u_12345, msg_id:alert_xyz, channel:UMS,status:SUCCESS". All these critical event logs are structured according to a pre-defined uniform format and immediately written to a pre-defined log storage and analysis system, either asynchronously or synchronously. This log system is typically built on Elasticsearch (ES) and features high-throughput writing and powerful full-text search and aggregation analysis capabilities. After the logs are written, operations and development personnel can use visualization tools such as Kibana for real-time queries, dashboard construction, and problem tracing.

[0067] By embedding and recording structured logs at key nodes throughout the entire process, transparent monitoring of the system's internal processes is achieved. This allows for the complete traceability of any alarm's trajectory from status change to final push notification, greatly facilitating rapid online problem localization and root cause analysis. Centralized logging into professional log storage and analysis systems like Elasticsearch enables efficient storage, real-time retrieval, and multi-dimensional analysis of massive log volumes. It supports the construction of business monitoring dashboards and performance monitoring metrics, providing data support for stable system operation and performance optimization. Detailed logging enhances system reliability and fault recovery capabilities. In cases of message push failures or other anomalies, manual or automated resending and retries can be quickly performed based on logs, ensuring eventual service consistency. This design improves the overall system maintainability and operational efficiency, reducing the difficulty and cost of daily maintenance and troubleshooting.

[0068] Figure 3 This demonstration showcases the core data flow and module interactions of a whole-house device consumables alarm push system based on real-time status monitoring. The system uses device-reported status as the starting point for data input, with devices continuously reporting consumables status data to the cloud. The consumables alarm push module receives this reported data in real-time through a subscription mechanism. When the consumables alarm push module determines that an alarm needs to be triggered based on the rule engine, it generates an alarm notification and sends the message to the App backend via the notification link. Simultaneously, the real-time status data reported by the devices is persistently stored in the Lindorm database. Upon receiving the alarm notification, the App backend pushes the alarm information to the user's App via a notification channel to refresh the interface or send a push message. When a user actively queries the device consumables status through the App, the App initiates a query request to the App backend. The App backend then queries the Lindorm database to obtain the latest device consumables status data and returns it to the App for display, thus completing a closed loop of user-initiated query.

[0069] Figure 4This document details the internal processing flow and component collaboration of a rule-based device consumable alarm push system. Device status data is reported into a Kafka message queue. The consumable alarm rule calculation module subscribes to this Kafka data stream to consume device status in real time. Simultaneously, this module periodically loads pre-configured consumable expiration and recovery rules from a MySQL database. The module processes each status data entry, with the core logic being the determination of whether a rule has been triggered. The system records trigger logs for monitoring and analysis. If a status change meets the conditions of a rule, it is determined to have triggered the rule, and the trigger event is immediately encapsulated into a message and reported to another specified Kafka Topic. The message delivery module subscribes to this triggering Topic to obtain alarm events. The message delivery module calls a REST service to send alarm information to the messaging platform, integrating personalized text and consumable purchase links, and notifies the App backend to refresh the consumable status to ensure the information displayed on the App is up-to-date.

[0070] The device consumable alarm push device based on real-time status monitoring provided by the present invention is described below. The device consumable alarm push device based on real-time status monitoring described below can be referred to in correspondence with the device consumable alarm push method based on real-time status monitoring described above.

[0071] Figure 5 A schematic diagram of a device consumable alarm push device based on real-time status monitoring provided by the present invention includes the following modules: The rule loading module 510 is used to load pre-configured consumable alarm rules, which are associated with the device model. The data receiving module 520 is used to receive and parse the consumable status reporting data from the device in real time through the message middleware. The consumable status reporting data includes the device model and status value. The status detection module 530 is used to query the previous status value of the device in the memory cache for each received consumable status report data; and to detect whether the current reported status value in the consumable status report data has changed relative to the previous status value. The alarm triggering module 540 is used to determine whether the changed status value meets the alarm triggering conditions based on the consumable alarm rules associated with the device model included in the consumable status reporting data if a change in status value is detected. The alarm module 550 is used to call the template rendering engine to generate and push alarm messages that match the consumable alarm rules if the alarm triggering conditions are met.

[0072] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6As shown, the electronic device may include a processor 610, a communications interface 620, a memory 630, and a communication bus 640. The processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The processor 610 can call logical instructions in the memory 630 to execute a device consumable alarm push method based on real-time status monitoring. This method includes: loading pre-configured consumable alarm rules; receiving and parsing consumable status reporting data from the device in real time; querying the previous status value corresponding to each received consumable status reporting data; detecting whether the currently reported status value in the consumable status reporting data has changed relative to the previous status value; if it has changed, determining whether the changed status value meets the alarm triggering condition based on the consumable alarm rule associated with the device model included in the consumable status reporting data; if it does, calling the template rendering engine to generate and push an alarm message matching the consumable alarm rule.

[0073] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0074] On the other hand, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by the computer, the computer can execute the device consumable alarm push method based on real-time status monitoring provided by the above methods. The method includes: loading pre-configured consumable alarm rules; receiving and parsing consumable status reporting data from the device in real time; querying the previous status value corresponding to the device for each received consumable status reporting data; detecting whether the currently reported status value in the consumable status reporting data has changed relative to the previous status value; if it has changed, determining whether the changed status value meets the alarm triggering condition based on the consumable alarm rule associated with the device model included in the consumable status reporting data; if it meets the condition, calling the template rendering engine to generate and push an alarm message matching the consumable alarm rule.

[0075] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the aforementioned device consumable alarm push methods based on real-time status monitoring. The method includes: loading pre-configured consumable alarm rules; receiving and parsing consumable status reporting data from the device in real time; querying the previous status value corresponding to the device for each received consumable status reporting data; detecting whether the currently reported status value in the consumable status reporting data has changed relative to the previous status value; if it has changed, determining whether the changed status value meets the alarm triggering condition based on the consumable alarm rule associated with the device model included in the consumable status reporting data; if it does, calling a template rendering engine to generate and push an alarm message matching the consumable alarm rule.

[0076] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0077] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including 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 some parts of embodiments.

[0078] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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 of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for pushing equipment consumable alarms based on real-time status monitoring, characterized in that, include: Load pre-configured consumable alarm rules, which are associated with the device model; The consumable status report data from the device is received and parsed in real time through the message middleware. The consumable status report data includes the device model and status value. For each received consumable status report, query the previous status value of the device in the memory cache; Detect whether the current reported status value in the consumable status reporting data has changed relative to the previous status value; If a change in status value is detected, the alarm rule associated with the device model included in the consumable status reporting data is used to determine whether the changed status value meets the alarm triggering condition. If the alarm triggering conditions are met, the template rendering engine is invoked to generate and push an alarm message that matches the consumable alarm rule.

2. The equipment consumables alarm push method based on real-time status monitoring according to claim 1, characterized in that, The pre-configured consumable alarm rules specifically include: The consumable alarm rule configuration information is retrieved from the preset rule database according to various device models. The consumable alarm rule configuration information includes at least one consumable alarm triggering condition and its corresponding alarm rule identifier. The consumable alarm rule configuration information is converted into a Flink pattern sequence, and the Flink pattern sequence is loaded into memory for pre-compilation processing to form a rule expression that can be calculated in real time.

3. The device consumables alarm push method based on real-time status monitoring according to claim 1, characterized in that, The real-time reception and parsing of consumable status reporting data from the device specifically includes: The consumable status reporting data stream from the device is subscribed to in real time through a message middleware; the data stream is encapsulated in a serialized format and transmitted via a unified Kafka topic; The received consumable status reporting data stream is deserialized and decoded, and its conformity with the predefined basic message format is verified. The basic message format includes at least a message header and a message body. Extract key information from the verified message body, including the device model identifier, consumable attribute identifier, and corresponding status value; The key information is converted into consumable status reporting data in a unified format.

4. The equipment consumables alarm push method based on real-time status monitoring according to claim 1, characterized in that, The step of detecting whether the currently reported status value in the consumable status reporting data has changed relative to the previous status value specifically includes: For each received consumable status report, retrieve the historical status value corresponding to the device and consumable attributes from the cache; Compare the current status value in the consumable status reporting data with the historical status value; If the current state value is different from the historical state value, it is determined that the state value has changed, and the current state value is updated in the cache.

5. The equipment consumables alarm push method based on real-time status monitoring according to claim 1, characterized in that, The step of determining whether the changed status value meets the alarm triggering conditions based on the consumable alarm rules associated with the device models included in the consumable status reporting data specifically includes: Based on the device model identifier in the consumable status reporting data, all consumable alarm rules associated with the device model are filtered out from the pre-loaded alarm rules to generate a subset of target rules to be evaluated. For each consumable alarm rule in the target rule subset, extract its pre-compiled rule expression logic; The changed state value and the associated attribute value extracted from the reported data are used as input parameters and dynamically bound to the corresponding variables of the rule expression to form an executable condition judgment instance. The target rule subset is traversed according to the preset rule priority order, and for each rule, its corresponding condition judgment instance is executed. When the evaluation result of any rule's condition judgment instance is true, it is determined that the triggering condition of the consumable alarm rule is met.

6. The device consumables alarm push method based on real-time status monitoring according to claim 1, characterized in that, Generate an alarm message that matches the consumable alarm rule, specifically including: Obtain a predefined message template associated with the triggered consumable alarm rule, wherein the message template contains a notification text corresponding to the consumable type; Based on the message template, the consumable information corresponding to the triggering rule, and the user information, an alarm notification message containing an access point for consumable details is generated.

7. The equipment consumables alarm push method based on real-time status monitoring according to claim 1, characterized in that, The method further includes: Record key event logs during the alarm triggering process, including state change events, rule matching events, and message push events; The key event logs are written to a preset log storage and analysis system.

8. The device consumables alarm push method based on real-time status monitoring according to any one of claims 1 to 7, characterized in that, The consumable alarm rules include at least one of the following types: early warning rules, alarm rules, and recovery rules; Among them, the early warning rule is used to trigger an early warning message when the remaining amount of consumables drops to a preset early warning threshold, the alarm rule is used to trigger an alarm message when the remaining amount of consumables drops to a preset alarm threshold, and the recovery rule is used to trigger a status recovery message when the status of consumables returns to normal from the alarm or early warning state.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the device consumable alarm push method based on real-time status monitoring as described in any one of claims 1 to 8.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the device consumable alarm push method based on real-time status monitoring as described in any one of claims 1 to 8.

Images