跳至主要内容

Alert Policies

Overview​

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

  • Alert Policy — evaluates incoming values from one or more DataStreams against trigger and reset conditions
  • Notification Channel — defines how an alert message is delivered, such as by email, Teams, LINE, or webhook

An Alert Policy is an independent, Org-level resource — unlike the DataStream it monitors, it isn't owned by any single device. Attach it to one or more DataStreams (at any layer: a raw device stream or an Analyzer's output) via a dedicated attach/detach call. See Notification Channels to configure delivery endpoints first.

An Alert Policy monitors the value of every DataStream attached to it. WEDA evaluates the policy whenever new telemetry arrives on any attached DataStream.

Each policy has these 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
delayDebounce window in seconds. A condition must hold for this long before it takes effect. Optional, defaults to 0 (no debounce)

The delay applies to both directions. A trigger condition must hold for the delay before an alert fires, and the reset condition must hold for the delay before the alert is resolved. With the default 0, both take effect immediately.

Supported conditions​

alertLevel and alertResetLevel are threshold expressions evaluated against the incoming DataStream value. Both are required, and both carry the comparison operator inside the string itself — for example alertLevel: ">=70" with alertResetLevel: "<65".

備註

The API declares these two fields as free-form strings and documents them by example. It does not publish the full grammar — which operators are accepted, and whether anything beyond a single comparison works. Stay with the documented >=70 / <65 form unless RD confirms otherwise.

Operations​

OperationAPIDescription
Create Alert PolicyPOST /api/v1/orgs/{orgId}/alert-policiesDefine a new policy
List Alert PoliciesGET /api/v1/orgs/{orgId}/alert-policiesList policies in the Org (filter by dataStreamId to find policies attached to a specific DataStream)
Get Alert PolicyGET /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}Get one policy by ID
Update Alert PolicyPATCH /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}Update the policy or its notification settings
Delete Alert PolicyDELETE /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}Remove a policy (must be disabled first)
Enable / DisablePOST /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}:{action}Enable or disable a policy without deleting it
List Attached DataStreamsGET /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}/data-streamsDataStreams currently attached
Set Attached DataStreamsPUT /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}/data-streamsReplace the full attachment set
List Alert EventsGET /api/v1/orgs/{orgId}/alert-eventsQuery fired alert history

Create Alert Policy​

POST /api/v1/orgs/{orgId}/alert-policies

See Create Alert Policy for the full field reference. A policy is created disabled — call the enable action once it's ready to evaluate.

Notification message​

The notification object is optional. If provided, 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.

Attach / Detach DataStreams​

PUT /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}/data-streams

This is a full-replacement call, not an incremental add/remove: the DataStreams you include become attached, and any previously attached DataStream left out of the request is detached. Sending an empty array detaches all DataStreams from the policy.

[
  { "deviceId": "cc827f50f406", "dataStreamId": "a1b2c3d4-..." }
]

Enable / Disable​

POST /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}:{action}

action is enable or disable. Disabling a policy stops it from evaluating new telemetry without deleting its configuration or attachment set.

Alert Events​

GET /api/v1/orgs/{orgId}/alert-events

Every fired alert is recorded as an Alert Event you can query independently of the policy that produced it — useful for building a history/audit view. Filter by status, alertPolicyId, deviceId, or a start/end time range.

Each event snapshots the policy's policyName and alertLevel at fire time (not a live join to the current policy), plus the dataStreamId and triggeredValue that caused it, and firedTime/acknowledgedTime/acknowledgedBy/resolvedTime/resolvedBy.

Reading the nullable timestamp fields:

  • acknowledgedTime and acknowledgedBy are null until the event is acknowledged.
  • resolvedTime is null until the event is resolved.
  • resolvedBy being null on a resolved event means it was resolved automatically by the reset condition, not that it is still open. Check resolvedTime or status to tell the difference.
Acknowledging an event is not yet available through the API

An event's status can be Firing, Acknowledged, or Resolved, but WEDA v1.1.1 exposes only the query endpoint above — there is no public API for acknowledging an event. Support for it is planned for a future release. Until then, events reach Resolved automatically when the reset condition holds for the policy's delay.

Scenario​

A monitoring engineer sets up a temperature alert on a factory device. The temperature stream (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 DataStream's dataType, and must not be identical
  • channelIds must reference existing notification channels
  • A policy must be disabled before it can be deleted
  • The PUT .../data-streams call replaces the full attachment set — omitting a currently-attached DataStream detaches it
  • A DataStream can be attached to more than one Alert Policy, and an Alert Policy can attach to more than one DataStream — this is a many-to-many relationship, unlike the one-rule-per-stream limit of the previous release
Last updated on Aug-2, 2026 | Version 1.1.1

On this page ...

Is this helpful?