Alarm and Event Lifecycle

Edge-EMS Builder supports individual alarm records and alarm events with recovery workflows. When creating a continuous monitoring rule, use alarm events to track the complete process from an abnormal condition through recovery to manual resolution.

Two alarm methods

Method	Suitable uses	Behavior
Alarm records	Simple notifications and retaining every trigger result	Each action creates an independent record that can be marked as handled
Alarm events	Continuous fault monitoring and tracking of handling	Combines occurrences with the same source and alarm identifier, recording occurrence counts and status changes

Existing scripts remain usable. Existing alarm records are not automatically converted to alarm events.

Event states

Active (ACTIVE) → Recovered (RECOVERED) → Resolved (RESOLVED)

• Repeated abnormal observations merge into the same unresolved event, retaining the first and most recent occurrence times.
• A normal observation moves the event to Recovered; an operator or administrator confirms its resolution.
• An abnormal condition after recovery reactivates the event. An abnormal condition after resolution creates a new event.
• An offline device or invalid data is treated as Unknown, not incorrectly classified as recovery.

Configure observation actions

Alarms use a stable sourceCode + alarmKey identity. Rules should continuously report abnormal, normal, or unknown observations. Running only when an abnormal condition occurs prevents the system from knowing when recovery occurs.

The following example uses the generic point demo_temperature. Replace it with an actual point and configure an appropriate monitoring interval before use:

local value = tonumber(${demo_temperature})
local state = "UNKNOWN"
if value then
  if value > 80 then state = "ACTIVE" else state = "NORMAL" end
end
return {buildAlarmObservationMap("demo_monitor", "demo_temperature_high",
  state, "高温", "1", "温度状态：" .. tostring(value))}

Use this script in an EXPRESSION trigger action. The alarm identifier should not contain the current temperature or a timestamp, which would turn every observation into a new event.

Query and handle events

Filter events by source, type, severity, state, and time range to view occurrence counts, recovery times, and resolution notes. Manual resolution uses the event’s latest version number to prevent concurrent operators from overwriting each other’s changes. When a device or rule is formally decommissioned, an administrator can retire its events with a reason.

For cloud notifications, configure separate reporting using MQTT. For scripts and API usage, see the Lua reference and alarm Skill.