A method for proactively alerting IoT devices

Abstract

This invention provides a method for proactively alerting IoT devices. By standardizing uplink event contexts, it uniformly encapsulates uplink data from various devices, eliminating the need to repeatedly develop the entire processing flow when matching different devices. It also standardizes the event data structure and provides a standardized data source.

Description

Technical Field

[0001] This invention relates to the field of IoT technology, and in particular to a method for proactively alerting IoT devices. Background Technology

[0002] In the Internet of Things (IoT), smart devices continuously report their operating status, fault codes, sensor values, enumeration status, and synchronized data from third-party platforms to the cloud. As the number and types of devices increase, the data processing volume becomes enormous. Existing anomaly alert methods are designed for single-type devices, building notification logic for single indicators. When expanding to different types of devices, the processing chain needs to be repeatedly built for each type. Furthermore, the naming semantics of alarms and indicators across devices are inconsistent, making it impossible to comprehensively describe the key elements of an event using a standardized structure.

[0003] In scenarios where devices report data, repeated push notifications for the same type of anomaly on the same device should be blocked to avoid frequently disturbing users. However, events with different fault codes, anomalies, and alarm rules should be notified separately. Existing methods cannot distinguish between multi-dimensional differentiated alarms on the same device, which can easily lead to invalid repeated notifications and critical alarms being incorrectly blocked.

[0004] Meanwhile, equipment anomalies are generally identified through uplink data, but fault recovery relies on multiple handling methods such as downlink control, remote diagnostics, user confirmation, and after-sales work orders. The existing architecture does not provide a standardized conversion model, making it impossible to uniformly map uplink alarm events into handling actions such as message notifications, automatic repair, and work order dispatch. Alarm notifications and fault handling are disconnected, failing to form a complete automated business loop. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method for proactively alerting IoT devices. This method encapsulates uplink data from various devices in a unified manner by standardizing uplink event contexts. This eliminates the need to repeatedly develop the entire processing flow when matching different devices, unifies and standardizes the event data structure, and provides a standardized data source.

[0006] The present invention provides a method for proactively alerting IoT devices, comprising the following steps:

[0007] S1, Preset regulation metadata.

[0008] S2, The device uploads uplink data.

[0009] S3, the cloud platform receives uplink data and performs device identification, protocol adaptation, message parsing, and basic data verification.

[0010] S4. Convert the uplink data into an uplink event context in a unified format.

[0011] S5. Automatically select candidate rules based on the trigger field of the uplink event context.

[0012] S6. Determine if the uplink event context matches the regulation. If yes, proceed to S7; otherwise, do not generate a notification action.

[0013] S7, the event action that generates the uplink event.

[0014] Preferably, the event action includes a notification action, a self-repair action, a work order action, or a remote diagnostic action, and the event action carries a regulation code, action type, abnormal status, template code, action parameters, frequency control policy, and log attribution field.

[0015] Preferably, the following steps are performed after S7:

[0016] S8. For event actions that are notification actions, construct frequency control keys.

[0017] S9. Determine if there is a matching frequency control in the time window. If yes, proceed to S10; otherwise, proceed to S11.

[0018] S10. Intercept the current event action and record the interception result.

[0019] S11. Allow the current event action and write the frequency control flag.

[0020] Preferably, the following steps are performed after S11:

[0021] S12. Extract notification content from the uplink event context and the action parameters of the event action.

[0022] S13. Send the notification content to the user terminal.

[0023] S14. Save the notification log containing the notification content.

[0024] S15. For event actions that are self-repairing actions, enter the self-repair linkage process.

[0025] Preferably, the self-healing linkage process includes the following steps:

[0026] S15.1 Read the uplink event context and determine whether the current fault is in the self-repair whitelist. If yes, proceed to S15.2. If no, generate an event action for notification or work order.

[0027] S15.2 Determine whether the current repair requires user confirmation. If yes, send a message to the user terminal and proceed to S15.3 after user confirmation; otherwise, proceed to S15.3.

[0028] S15.3 Read the device status to confirm whether the fault exists and whether the device is in an executable state. If so, proceed to S15.4.

[0029] S15.4 The cloud platform selects remote repair commands from the command whitelist based on the fault codes and repair strategies;

[0030] S15.5 The cloud platform sends modification commands to the device and records the execution command, execution time, and execution status.

[0031] S15.6 After the command is executed, determine whether the device has been repaired. If yes, proceed to S15.7; otherwise, proceed to S15.8.

[0032] S15.7 The cloud platform records the successful repair and sends a successful repair feedback to the user.

[0033] S15.8 The cloud platform records the reason for failure and generates an event action for the work order action.

[0034] Preferably, to determine whether the device repair is complete, specifically, read the device status again or wait for the device to report the repair result; determine whether the fault code has disappeared, whether the attribute status has been restored, and whether the diagnostic result has passed.

[0035] Preferably, S6 specifically includes the following steps:

[0036] S6.1 Determine whether the uplink event context simultaneously satisfies the applicable scope of the regulatory metadata and the triggering conditions of the regulatory metadata. If yes, proceed to S6.2; otherwise, proceed to S6.3.

[0037] S6.2 Determine the context hit rules for the uplink event.

[0038] S6.3 Determine if the uplink event context does not hit the rules.

[0039] Compared to existing technologies, the beneficial effects of the IoT device proactive alert method described in this invention are mainly reflected in the following aspects: When adding uplink alerts for new devices, the event standardization, candidate rule scheduling, product range matching, frequency control, template rendering, and log attribution links can be reused. For threshold-based, enumeration-based, and fault code-based rules, only adding or adjusting rule metadata, template mapping, and action strategies is required to complete the integration; thus reducing the development cost of adding new alert scenarios.

[0040] The main uplink process only needs to output standard event context; specific alert judgments are handled by the rule scheduling link. Changes in business rules do not directly intrude into the protocol parsing and status entry processes, which helps maintain the stability of device uplink processing.

[0041] By triggering field indexes to select candidate rules, the system only judges rules related to the current report, avoiding scanning all rules for each device report, reducing computational overhead, and improving processing efficiency in high-frequency reporting scenarios.

[0042] The frequency control button consists of a device identifier, rule code, and abnormal status. This ensures that the same device with the same fault code or the same abnormal level is triggered only once within the frequency control window, while different faults and rules can still be notified independently, balancing timeliness and minimal disruption. This reduces repetitive reminders and improves the user experience. Attached Figure Description

[0043] The above and other objects, features, and advantages of the invention will become clearer through a more detailed description of the preferred embodiments illustrated in the accompanying drawings. The same reference numerals denote the same parts throughout the drawings, and the drawings are not intentionally drawn to scale with actual dimensions; the focus is on illustrating the gist of the invention.

[0044] Figure 1 This is a flowchart of the present invention.

[0045] Figure 2 This is a schematic block diagram of an IoT proactive alert system.

[0046] Figure 3 This is a schematic diagram of the link in this invention. Detailed Implementation

[0047] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand the present invention and implement it. However, the embodiments are not intended to limit the present invention. In this embodiment, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the present invention and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting the present invention.

[0048] It should be noted that when one element is considered to be "connected" to another element, it can be directly connected to and integrated with the other element, or there may be an intervening element present. The terms "mounted," "one end," "the other end," and similar expressions used in this invention are for illustrative purposes only.

[0049] like Figure 1-3 As shown, an IoT proactive alert system includes devices, a cloud platform, user terminals, and an operation backend. The cloud platform is equipped with a device uplink access module, an uplink event standardization module, an uplink event regulation configuration center, a regulation scheduling module, a product range matching module, a condition judgment module, an event action generation module, a frequency control module, a notification template module, a notification recording module, a self-repair and handling linkage module, and an action execution recording module.

[0050] The device is an IoT smart terminal device connected to a cloud platform. The device can be a range hood, water heater, stove, water purifier, or HVAC equipment. The device connects to the cloud platform through a self-developed protocol, a third-party platform protocol, or an IoT communication protocol. The device reports fault codes, attribute points, sensor data, enumeration status, and custom alarms to the cloud platform.

[0051] The device uplink access module is deployed on a cloud platform. The device uplink access module is used to receive uplink data from devices from different sources and to perform device identification, protocol adaptation, message parsing, and basic data verification.

[0052] The uplink event standardization module is used to convert uplink data in different protocol formats into a unified uplink event context, thus masking differences between protocols and platforms. The uplink event context includes device identifier, home identifier, platform type, product identifier (product ID, product key, or third-party product identifier), device category, reporting fields, field values, fault codes, alarm content, event time, and original message digest.

[0053] Preferably, the uplink data is converted into a unified uplink event context, including parsing the original protocol message; identifying the device identity and platform source; mapping different protocol fields to unified fields (e.g., mapping third-party fields to standard fields); performing field type conversion (e.g., conversion between enumerated values, numerical values, and time formats); supplementing device information (e.g., supplementing product identifiers, device categories, and household identifiers); generating a unified uplink event context; and retaining the original message digest.

[0054] The uplink event regulation configuration center is used to store and manage rule metadata. Rule metadata includes multiple regulations. Each regulation includes rule code, rule name, rule type, trigger field, applicable platform, product identifier (product ID, product key, or third-party product identifier), device category, trigger condition, frequency control time window, notification template code, action policy, start / stop status, and priority.

[0055] The trigger fields include the device fault code (errorCode), the range hood VOC concentration (voc), the device custom alarm (customAlert), the filter life (filterLife), the water quality status (waterQuality), the temperature (temperature), the offline status (offlineState), and the standard fields mapped from the third-party platform.

[0056] The regulation scheduling module is used to select candidate rules based on the trigger fields of the uplink event context and schedule the candidate rules. Preferably, the regulation scheduling module establishes a trigger field index. Candidate rules refer to a set of potentially matching regulations related to the reporting fields of the current uplink event context; if the uplink event context includes the VOC concentration of the range hood, then the range hood VOC concentration regulation is selected; if the uplink event context includes equipment fault codes, then the equipment fault regulation is selected; in a preferred embodiment, candidate rules include fault rules, anomaly rules, custom alarm regulations, consumable lifespan regulations, water quality anomaly regulations, offline reminder regulations, temperature anomaly regulations, third-party event rules, and range hood VOC concentration regulations.

[0057] The product scope matching module is used to determine whether a rule is applicable to the current device based on the rule code, platform, product ID, product key, third-party product identifier, and device category. After scheduling relevant candidate regulations, candidate rules are matched sequentially through precise configuration, secondary precise configuration, category configuration, and global default configuration. Precise configuration matches candidate rules based on platform type, product ID, and product key. Secondary precise configuration matches candidate rules based on platform type, product ID, or product key. Category configuration matches candidate rules based on the set categories. The global default configuration matches general candidate regulations.

[0058] The condition judgment module is used to determine whether a rule has been hit based on the uplink event context and rule triggering conditions. Triggering conditions may include fault code presence, attribute threshold, enumerated status, status duration, consecutive count, combined conditions, cross-field conditions, or external diagnostic results.

[0059] The event action generation module is used to generate one or more event actions after a rule is matched. Event actions include notification actions, self-repair actions, work order actions, remote diagnostic actions, operational event actions, or third-party synchronization actions. Each event action carries a rule code, action type, action parameters, frequency control strategy, template code, and execution priority.

[0060] The frequency control module is used to construct frequency control keys based on device identifiers, rule codes, and abnormal states, and to intercept repeated event actions within the corresponding frequency control time window. Abnormal states can be fault codes, attribute levels, alarm subtypes, or status identifiers specified by rules. The frequency control module can record hit, release, interception, and expiration statuses.

[0061] The notification template module is used to load channel template configurations based on template codes in notification actions and render notification content according to field mapping rules. Specifically, the notification template module loads mini-program, app, or in-site message templates based on template codes in actions and extracts notification fields from the uplink event context and action parameters according to field mapping rules. Preferably, alarm time, current pollution level, and device name are extracted.

[0062] The notification logging module is used to persist notification logs. The notification logs can record notification category, notification subtype, alarm type, alarm subtype, rule code, device information, family information, notification content, template code, sending channel, frequency control result, sending result, and creation time.

[0063] The self-repair and handling linkage module is used to determine whether to trigger remote self-repair, generate a work order, or initiate remote diagnosis after the rule is hit, based on the device capability, fault type, firmware version, user authorization, command whitelist, security policy, retry policy, and status verification rules.

[0064] The action execution record module is used to record the execution status of self-repair actions, work order actions, and remote diagnostic actions, including action type, rule code, device identifier, fault code, pre-execution status, execution command, execution result, post-execution status, failure reason, and fallback measures.

[0065] The user terminal and the operations backend include the user terminal and the operations backend. The user terminal is used to receive notifications, view alarm details, confirm self-repair, and view repair results. The operations backend is used to maintain rule start / stop, product application scope, frequency control time window, template binding, self-repair strategy, fault whitelist, and rule statistics.

[0066] A method for proactively alerting IoT devices includes the following steps:

[0067] S1, Preset regulation metadata.

[0068] S2. The device uploads uplink data. Uplink data includes fault codes, attribute points, sensor values, enumerated status, custom alarms, or data synchronized from third-party platforms.

[0069] S3, the device uplink access module of the cloud platform receives uplink data and performs device identification, protocol adaptation, message parsing and basic data verification.

[0070] S4. Convert the uplink data into a unified format uplink event context. The uplink event context includes device identifier, home identifier, platform type, product identifier (product ID, product key, or third-party product identifier), device category, reported fields, field values, fault codes, alarm content, event time, and original message summary.

[0071] S5. The regulation scheduling module automatically selects candidate rules based on the trigger field of the uplink event context. When selecting candidate regulations, only those related to the trigger field are selected. If the uplink event context contains the VOC concentration of the flue gas machine, only candidate rules related to the VOC concentration of the flue gas machine are scheduled; if the uplink event context contains the equipment fault code, only equipment fault candidate rules are scheduled.

[0072] Preferably, after scheduling relevant candidate regulations, candidate rules are matched sequentially through precise configuration, sub-precise configuration, category configuration, and global default configuration; the precise configuration matches candidate rules by platform type, product ID, and product key; the sub-precise configuration matches candidate rules by platform type, product ID, or product key; the category configuration matches candidate rules by the set categories; and the global default configuration matches general candidate regulations.

[0073] S6. The condition judgment module determines whether the uplink event context matches the regulation. If yes, proceed to S7; otherwise, no reminder action is generated.

[0074] S7. Generate an uplink event action. The event action includes a notification action, a self-repair action, a work order action, or a remote diagnostic action. The event action carries a regulation code, action type, abnormal status, template code, action parameters, frequency control policy, and log attribution field.

[0075] S8. For event actions that are not notification actions, construct frequency control keys. Preferably, frequency control keys are constructed using device identifiers, regulatory codes, and abnormal states. The following are examples: When a device malfunctions, use "device identifier, corresponding candidate rule, and device fault code"; when a VOC warning is issued, use "device identifier, corresponding candidate rule, and VOC concentration of the smoke machine".

[0076] S9. Determine if there is a matching frequency control in the time window. If yes, proceed to S10; otherwise, proceed to S11.

[0077] S10. Intercept the current event action and record the interception result.

[0078] S11. Allow the current event action and write the frequency control flag.

[0079] S12. Extract notification content from the uplink event context and the action parameters of the event action. Preferably, the notification template module loads a mini-program, app, or in-site message template according to the template code in the action, and extracts notification fields from the uplink event context and action parameters according to the field mapping rules. Preferably, the following are extracted: alarm time, current pollution level, and device name.

[0080] S13. Send the notification content to the user terminal.

[0081] S14. Save the notification log containing the notification content. This log also records the notification category, notification subtype, alarm type, alarm subtype, rule code, template code, device information, family information, frequency control result, and sending result. The user terminal displays device alarm details based on the notification content.

[0082] S15. For event actions that are self-repairing actions, enter the self-repair linkage process.

[0083] The self-healing linkage process includes the following steps:

[0084] S15.1 Read the uplink event context and determine whether the current fault is in the self-repair whitelist. If yes, proceed to S15.2. If no, generate an event action for notification or work order.

[0085] S15.2 Determine whether the current repair requires user confirmation. If yes, send a message to the user terminal and proceed to S15.3 after user confirmation; otherwise, proceed to S15.3.

[0086] S15.3 Read the device status to confirm whether the fault exists and whether the device is in an executable state. If so, proceed to S15.4.

[0087] S15.4 The cloud platform selects remote repair commands from the command whitelist based on the fault codes and repair strategies;

[0088] S15.5 The cloud platform sends modification commands to the device and records the execution command, execution time, and execution status.

[0089] S15.6 After the command is executed, determine whether the device repair is complete. If yes, proceed to S15.7; otherwise, proceed to S15.8. Specifically, determining whether the device repair is complete involves rereading the device status or waiting for the device to report the repair result; determining whether the fault code has disappeared, whether the attribute status has been restored, and whether the diagnostic result has passed.

[0090] S15.7 The cloud platform records the successful repair and sends a successful repair feedback to the user.

[0091] S15.8 The cloud platform records the reason for failure and generates an event action for the work order action.

[0092] The above method, S6, specifically includes the following steps:

[0093] S6.1 Determine whether the uplink event context simultaneously satisfies the applicable scope of the regulatory metadata and the triggering conditions of the regulatory metadata. If yes, proceed to S6.2; otherwise, proceed to S6.3.

[0094] S6.2 Determine the context hit rules for the uplink event.

[0095] S6.3 Determine if the uplink event context does not hit the rules.

[0096] The above methods allow for the reuse of event standardization, candidate rule scheduling, product scope matching, frequency control, template rendering, and log attribution chains when adding new device uplink alerts. For threshold-based, enumeration-based, and fault code-based rules, integration can be completed simply by adding or adjusting rule metadata, template mapping, and action strategies; thus reducing the development cost of adding new alert scenarios.

[0097] The main uplink process only needs to output standard event context; specific alert judgments are handled by the rule scheduling link. Changes in business rules do not directly intrude into the protocol parsing and status entry processes, which helps maintain the stability of device uplink processing.

[0098] By triggering field indexes to select candidate rules, the system only judges rules related to the current report, avoiding scanning all rules for each device report, reducing computational overhead, and improving processing efficiency in high-frequency reporting scenarios.

[0099] The frequency control button consists of a device identifier, a rule code, and an abnormal status. This ensures that the same device with the same fault code or the same abnormal level is triggered only once within the frequency control window, while different faults and different rules can still be notified independently, balancing timeliness and minimal disruption. This reduces repetitive reminders and improves the user experience.

[0100] The following examples illustrate this:

[0101] Example 1.

[0102] Active device fault code alerts. When a device reports a fault code, the device's uplink access module parses the fault code and generates a unified device fault event. The rule scheduling module selects the corresponding candidate rule based on the trigger field of the device fault code. The product scope matching module matches the global device fault rules, and the condition judgment module determines whether the fault code is in an abnormal state. If abnormal, a device fault notification action is generated, and a frequency control key is constructed using "device identifier, corresponding candidate rule, and fault code". After frequency control is granted, the notification template module generates a device fault alert, and the notification record module saves the rule code and fault classification field.

[0103] Example 2.

[0104] Abnormal VOC Concentration Warning for Range Hoods. When a range hood reports its VOC concentration, the rule scheduling module selects the corresponding candidate rule based on the trigger field of the VOC concentration. The product range matching module determines whether the current platform, product ID, product key, or third-party product identifier has enabled VOC concentration rules for the range hood. If the current product has enabled rules, and the VOC enumeration value is 2 or 3, the condition judgment module determines that the rule has been matched. The system generates an abnormal VOC concentration notification action for the range hood, using a dedicated VOC concentration template to display the alarm time, current pollution level, and warning type, and records the rule code of the corresponding candidate rule in the notification log.

[0105] Example 3.

[0106] Device Fault and User Confirmation for Self-Repair. When a device reports a recoverable fault code, the system matches the device fault rules and sends a fault alert to the user. The self-repair and handling linkage module queries the fault whitelist to determine whether user confirmation is required for the current repair. If it is confirmed that the fault supports online repair but requires user confirmation, a message is sent to the user's terminal. After the user clicks "Attempt Repair" on the alarm details page, the system checks the device's online status, firmware version, and command whitelist. If the conditions are met, a remote repair command is issued. After repair, the system reads the device status. If the fault code disappears, the system records a successful repair and notifies the user; if the fault persists, a service order is generated.

[0107] Example 4.

[0108] Automatic repair and fallback for low-risk faults. For low-risk, rollbackable, verifiable faults that have been authorized by the user, the system can perform self-repair actions after a rule is matched. Before execution, the system reads the device status to confirm that the fault still exists; after execution, it reads the status again and verifies the repair result. If two consecutive executions fail or the device status is abnormal, the system stops retrying, records the reason for the failure, and creates a work order or remote diagnostic task to avoid repeated repairs or misoperations.

[0109] In this specification, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0110] In the description of this specification, the references to terms such as "preferred embodiment," "another embodiment," "other embodiment," or "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0111] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for proactively alerting IoT devices, characterized in that: Includes the following steps: S1, Preset regulation metadata; S2, Device uploads uplink data; S3, the cloud platform receives uplink data and performs device identification, protocol adaptation, message parsing and basic data verification; S4. Convert the uplink data into an uplink event context in a unified format; S5. Automatically select candidate rules based on the trigger field of the uplink event context; S6. Determine if the uplink event context matches the regulation. If yes, proceed to S7; otherwise, do not generate a notification action. S7, the event action that generates the uplink event.

2. The method for proactively reminding IoT devices according to claim 1, characterized in that: The event actions include notification actions, self-repair actions, work order actions, or remote diagnostic actions. The event actions carry regulation codes, action types, abnormal states, template codes, action parameters, frequency control policies, and log attribution fields.

3. The method for proactively reminding IoT devices according to claim 1, characterized in that: After S7, proceed with the following steps: S8. For event actions that are notification actions, construct frequency control keys; S9. Determine if there is a duplicate frequency control in the time window. If so, proceed to S10. If not, proceed to S11; S10. Intercept the current event action and record the interception result; S11. Allow the current event action and write the frequency control flag.

4. The method for proactively reminding IoT devices according to claim 1, characterized in that: After S11, proceed with the following steps: S12. Extract the notification content from the uplink event context and the action parameters of the event action; S13. Send the notification content to the user terminal; S14. Save the notification log containing the notification content; S15. For event actions that are self-repairing actions, enter the self-repair linkage process.

5. The method for proactively reminding IoT devices according to claim 4, characterized in that: The self-healing linkage process includes the following steps: S15.1 Read the uplink event context and determine whether the current fault is in the self-repair whitelist. If yes, proceed to S15.

2. If no, generate an event action for notification or work order. S15.2 Determine whether the current repair requires user confirmation. If yes, send a message to the user terminal and proceed to S15.3 after user confirmation; otherwise, proceed to S15.

3. S15.3 Read the device status to confirm whether the fault exists and whether the device is in an executable state. If so, proceed to S15.

4. S15.4 The cloud platform selects remote repair commands from the command whitelist based on the fault codes and repair strategies; S15.5 The cloud platform sends modification commands to the device and records the executed commands, execution time, and execution status; S15.6 After the command is executed, determine whether the device has been repaired. If yes, proceed to S15.7; otherwise, proceed to S15.

8. S15.7 The cloud platform records the successful repair and sends a successful repair feedback to the user; S15.8 The cloud platform records the reason for failure and generates an event action for the work order action.

6. The method for proactively reminding IoT devices according to claim 4, characterized in that: To determine whether the device repair is complete, specifically, read the device status again or wait for the device to report the repair results; check whether the fault codes have disappeared, whether the attribute status has been restored, and whether the diagnostic results have passed.

7. The method for proactively reminding IoT devices according to claim 1, characterized in that: S6 specifically includes the following steps: S6.1 Determine whether the uplink event context simultaneously satisfies the applicable scope of the regulatory metadata and the triggering conditions of the regulatory metadata. If yes, proceed to S6.2; otherwise, proceed to S6.

3. S6.2 Determine if the uplink event context hits the rules; S6.3 Determine if the uplink event context does not hit the rules.

Images