Definition
Rule Engine (Rule Engine) triggers alarms, issues Downstream Commands, or calls Webhooks based on device Telemetry, Connection Status and other conditions. It supports thresholds, expressions, and combined conditions to achieve automated operations and maintenance.
Rule Composition
Rules usually include: data sources (device properties, events, connection status, etc.), trigger conditions (threshold judgments, expressions, multi-condition AND/OR combinations), cooldown periods (to prevent repeated triggering), and execution actions (alarms, Webhooks, downstream commands, work order creation, etc.). Rules can be filtered by product, group, or device to define their scope, enabling fine-grained strategies.
Typical Scenarios
Examples: temperature over-limit alarms, device offline alarms after N minutes, batch offline alarms, triggering maintenance work orders when device health drops below threshold, abnormal data triggering Remote Diagnosis. Rules can be integrated with ITSM and Webhook to achieve alarm closure, or directly issue Downstream Commands for automatic control.
Integration with RUL
The Rule Engine can integrate with RUL (Remaining Useful Life) prediction, automatically triggering maintenance plans or work orders when predicted device life falls below a threshold. It supports rule prioritization, enable/disable, and version management, facilitating flexible configuration and auditing by maintenance personnel.
Condition, cooldown, and action are three separate settings
A rule has at least three separate parts: which data is judged, how long a repeat trigger is held back, and what happens after a trigger. The judgment only produces the fact that the condition holds. The cooldown decides whether that fact is emitted again. The action is the alarm, the work order, the API call, or the command. Write all three into one script that cannot be tested in pieces, and changing a threshold also changes who gets notified. A condition that holds but falls inside the cooldown should be recorded as suppressed, not as a condition that did not occur. Otherwise it is later impossible to tell "no breach" from "a breach that was held down."
The condition should use identifiers and units from the thing model, not the raw register address of some firmware version. Change the address and the rule keeps running, but it compares a different quantity. A combined condition must say whether all parts hold at once or any one holds, and how the quantities are aligned in time. Comparing the latest temperature with vibration from an hour ago produces a result with no physical meaning. If an action sends control, it must cite the service name and a parameter template, and it must stay on devices the rule author is allowed to operate. A rule created by an administrator must not let a later editor reach more devices through that rule.
A rule should apply only to a filtered set of devices
The condition for use is that the rule is explicitly bound to a product, a group, or a tag. Unbound should mean the rule applies to no devices, not to all of them. Different products can share an attribute name and still use different units. One shared threshold then false-alarms. After a new device is provisioned, it enters the rule only if it falls inside the filter that was written down. A default of "select all" pulls lab devices into production alarms.
Review side effects of the action together with the filter. Before an automatic restart is sent, confirm that this set of devices may restart unattended, and that another rule will not restart the same unit again inside the cooldown. A rule that opens a work order needs a merge key, for example the same device and the same fault code, so it does not open a new order while one is still open. Before publishing, replay the rule against historical thing model data and see how many units it would hit, then decide whether to enable it. Enable it with no replay and the first live data can fire a large batch of actions.
A cooldown of zero produces an alarm storm
With a cooldown of zero, every sample that crosses the limit triggers once. Temperature reported every five seconds and jittering around the threshold produces hundreds of alarms in an hour, and the same number of outbound calls. The receiver shuts the channel, and a real new fault is then buried as well. The cooldown should cover the normal jitter period, and a recovery condition should be set on its own: back inside the threshold for a sustained period before it counts as recovered. Repeated breaches before recovery do not send a new notice.
Another storm comes from an action that triggers the rule again. For example, a breach writes a shadow value, the write produces a property change, and the change hits the same rule again. Events produced by an action should carry a source mark. By default a rule ignores the echo of what it just wrote, or the depth of the trigger chain is capped. Disabling a rule does not withdraw actions already sent. Commands already in the queue and notices already open have to be handled on their own. Editing a live condition in place makes old and new conditions alternate inside half a window. Clone, replay, then switch, and keep the previous version so it can be returned to immediately.
On the first day after a rule goes live, look separately at the suppression count, the successful-action count, and the failed-action count. An alarm count with neither of the last two does not say whether the condition never held or the action API has been failing. A failed action needs its own alarm. It should not exist only at the end of the rule runtime log. If the order of rules affects the same device, state which rule runs first, and whether a later rule can see the value the earlier one just wrote. If it cannot, treat that as normal before eventual consistency, rather than lowering the later threshold to compensate. Pausing a rule should take effect immediately. Actions already queued but not yet sent are dropped or released according to the pause policy. Write that policy on the rule. Do not settle it in the moment. When several rules cover the same condition, list their actions and confirm they do not undo each other.