跳至主要内容

Alert Rules

Overview​

WEDA's monitoring workflow has two parts that work together:

  • Alert Rule — evaluates incoming values from a data object against trigger and reset conditions
  • Notification Channel — defines how an alert message is delivered, such as by email, Teams, LINE, or webhook

You define alert rules on specific data objects, and each rule references one or more notification channels by channelId. When the trigger condition is met for the configured delay, WEDA sends the alert message through the selected channels. See Notification Channels to configure delivery endpoints first.

An Alert Rule monitors a specific data-object value on a device. WEDA evaluates the rule whenever new telemetry arrives.

Each rule has three evaluation parameters:

ParameterDescription
alertLevelA comparison expression that defines when an alert is triggered, such as >=75
alertResetLevelA comparison expression that defines when the value has returned to its normal range, such as <70
delayThe number of seconds to wait before sending the alert after the trigger condition is first met

When the trigger condition is first met, WEDA starts the delay timer. If a new value meets the reset condition before the timer expires, the pending alert is canceled. Otherwise, WEDA sends the alert when the timer expires.

Deduplication only applies during the delay window. Once the alert has fired, WEDA does not wait for the reset condition before evaluating again — if the anomaly persists, subsequent evaluations can trigger additional alerts. Design your notification handling to tolerate repeated alerts for a sustained condition.

Supported conditions​

Alert conditions support numeric, Boolean, and string values. Include the comparison operator in the condition string.

Data typeTrigger condition exampleReset condition example
Number>=75<70
Boolean==true==false
String=="error"!="error"

Supported comparison operators include >, >=, <, <=, ==, and !=. The condition must be compatible with the data object's dataType. Only a single comparison expression is supported per condition — compound conditions using && or || are not supported.

Operations​

Alert rules are scoped to a specific data object on a device.

OperationAPIDescription
Create Alert RulePOST /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rulesDefine a new rule
List Alert RulesGET /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rulesList rules on a data object
Get Alert RuleGET /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rules/{alertRuleId}Get one rule by ID
Update Alert RulePATCH /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rules/{alertRuleId}Update rule or notification settings
Delete Alert RuleDELETE /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rules/{alertRuleId}Remove an alert rule
Update Rule StatusPUT /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rules/{alertRuleId}/statusEnable or disable a rule without deleting it

Create Alert Rule​

POST /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rules

See Create Alert Rule for the full field reference.

Response 201 Created

Notification message​

The notification object is required. Specify the destination with channelIds and recipients, then use one of the following methods to define the message:

  • Provide templateId and, when required by the template, variables.
  • Provide both subject and content directly.

Do not combine templateId with subject or content in the same request.

Ensure dataObjectName matches the target

The current release does not cross-validate the URL's dataObjectId against the request body's dataObjectName — dataObjectId scoping is not yet enforced server-side. Make sure dataObjectName accurately identifies the data object you intend to target. A future release will enforce ID-based scope validation.

Update Alert Rule​

PATCH /api/v1/devices/{deviceId}/data-objects/{dataObjectId}/alert-rules/{alertRuleId}

See Update Alert Rule for the full field reference.

delay is not preserved if omitted

If a PATCH request does not include delay, it is reset to 0 — not left unchanged. This applies even to a notification-only update (e.g. changing only channelIds or the message content): omitting delay still resets it. Always include the rule's current delay value in every PATCH request unless you intend to change it to 0.

Scenario​

A monitoring engineer sets up a temperature alert on a factory device. The temperature sensor (AI_0) should send an alert if its value reaches 75°C and does not return below 70°C during the 10-second delay:

Constraints​

  • alertLevel and alertResetLevel must be valid expressions compatible with the data object's dataType.
  • alertLevel and alertResetLevel must not be identical. Define distinct trigger and recovery ranges to avoid alert oscillation.
  • channelIds must reference existing notification channels.
  • Disabling a rule stops it from evaluating new telemetry without deleting the rule configuration.
  • Only one Alert Rule can exist per Device + Data Object combination — you cannot create multiple rules with different conditions or notification settings on the same data object.
Last updated on Jul-17, 2026 | Version 1.1.0

On this page ...

Is this helpful?