Cycle de vie des alarmes et événements

Edge-EMS Builder prend en charge les enregistrements d’alarme individuels et les événements d’alarme avec processus de retour à la normale. Pour une nouvelle règle de surveillance continue, un événement permet de suivre apparition de l’anomalie, rétablissement et résolution manuelle.

Deux modes d’alarme

Mode	Usage	Comportement
Enregistrement d’alarme	Notification simple et conservation de chaque déclenchement	Chaque action génère un enregistrement indépendant, qui peut être marqué comme traité
Événement d’alarme	Surveillance continue des défauts et suivi du traitement	Fusion par source et identifiant d’alarme, avec nombre d’occurrences et changements d’état

Les anciens scripts restent utilisables. Les enregistrements existants ne sont pas convertis automatiquement en événements.

États d’un événement

Anomalie active (ACTIVE) → Rétabli (RECOVERED) → Résolu (RESOLVED)

• Les anomalies répétées sont fusionnées dans le même événement non résolu, avec les dates de première et dernière occurrence.
• Une observation normale fait passer l’événement à « Rétabli » ; un opérateur ou administrateur confirme sa résolution.
• Une nouvelle anomalie après rétablissement réactive le même événement ; après résolution, elle crée un nouvel événement.
• Un équipement hors ligne ou une donnée invalide constitue un état « inconnu », jamais un rétablissement.

Configurer les actions d’observation

Une alarme est identifiée par un sourceCode + alarmKey stable. La règle doit signaler continuellement un état anormal, normal ou inconnu, et pas seulement s’exécuter en cas d’anomalie ; sinon, le système ne peut pas connaître le rétablissement.

L’exemple utilise le point générique demo_temperature. Remplacez-le par un point réel et configurez une période de surveillance adaptée :

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))}

Ce script s’utilise dans une action de déclenchement EXPRESSION. L’identifiant d’alarme ne doit pas contenir la température courante ni un horodatage, afin d’éviter un nouvel événement à chaque observation.

Consultation et traitement

Filtrez les événements par source, type, niveau, état et plage temporelle, puis consultez occurrences, heure de rétablissement et explication de résolution. La résolution manuelle utilise la dernière version de l’événement pour éviter d’écraser les actions d’autres utilisateurs. Lors de la mise hors service définitive d’un équipement ou d’une règle, un administrateur peut retirer l’événement en précisant la raison.

Pour une notification cloud, configurez séparément une remontée via MQTT. Consultez la référence Lua et le Skill d’alarmes pour les scripts et API.