Conditions de fermeture et mesures en retard

Cette page répond à deux questions : à quel moment exactement une alarme se ferme, et que devient une mesure qui arrive en retard, par exemple après qu’un appareil a été hors ligne et envoie son tampon.

Fermeture par défaut

Sans condition clear, une alarme se ferme lorsqu’aucune condition de gravité n’est plus vraie, élargie par l’hystérésis, et après le temporisateur de fermeture (debounce). Exemple : déclencher temperature > 80 avec une hystérésis de 3 ferme l’alarme à 77 ou en dessous.

Condition de fermeture explicite

Une condition clear (mode JSON) remplace cette logique : l’alarme reste ouverte tant que clear est faux et se ferme dès qu’elle devient vraie (après le temporisateur de fermeture). L’hystérésis est alors ignorée.

{
  "type": "fall_detected",
  "title": "{{device.name}}: fall detected",
  "severities": [ { "severity": "CRITICAL", "condition": { "key": "event", "op": "==", "value": "fall" } } ],
  "clear": { "key": "event", "op": "==", "value": "press_once" }
}

L’alarme de chute reste ouverte lorsque l’événement suivant est normal ; elle ne se ferme que lorsque la personne porteuse appuie une fois sur le bouton.

Utilisez une condition de fermeture explicite lorsque :

• l’alarme doit attendre un signal de confirmation (un bouton de réarmement, un état « normal »),
• les valeurs d’ouverture et de fermeture sont des clés différentes (ouverture sur smoke == true, fermeture sur alarm_reset == true),
• la fermeture nécessite plusieurs éléments à la fois (all de porte fermée et pression rétablie).

La condition clear a la même forme et les mêmes limites qu’une condition de gravité (16 comparaisons, 4 niveaux). Un message qui ne contient aucune des clés de la condition de fermeture ni aucune des clés de gravité n’est pas un échantillon pour la règle.

Fermeture depuis un autre endroit

Une alarme d’une règle peut aussi être fermée par une personne (Fermer), par le bloc Fermer l’alarme d’un flux ou par une action de la carte Règles. Après qu’une personne l’a fermée alors que la condition est toujours vraie, la règle attend que la condition ait été fausse une fois avant de pouvoir ouvrir une nouvelle alarme. Après la fermeture par un flux ou une règle, la règle repart de l’état inactif : la prochaine mesure vraie (après le temporisateur) ouvre une nouvelle alarme.

Mesures en retard

Un appareil qui était hors ligne envoie souvent les mesures qu’il a mises en mémoire tampon à son retour. Hermetry les enregistre avec leurs propres horodatages (voir Horodatages, mesures en retard et en double). Pour les alarmes, il existe deux cas.

Mesures traitées en retard

Le flux racine traite les messages dans l’ordre. Un message qui a attendu plus longtemps que la durée de vie (time-to-live) de l’hôte de flux (par exemple pendant une panne) est marqué comme en retard. Pour les règles d’alarme, il s’agit d’un rattrapage :

• S’il est plus récent que la dernière mesure évaluée par la règle, il fait évoluer la règle comme d’habitude : les alarmes s’ouvrent, changent de gravité et se ferment.
• Ces étapes sont enregistrées discrètement, datées d’après les mesures : la liste des alarmes, les compteurs de la cloche et les tableaux de bord en direct les suivent, mais personne n’est averti, aucun webhook n’est envoyé et aucun flux n’est lancé. Une alarme ouverte de cette façon porte le badge Rattrapée ; ses étapes de chronologie indiquent « à partir de mesures en retard ».
• Ce qui reste vrai est annoncé une seule fois : si une alarme ouverte (ou escaladée) par des mesures en retard est encore ouverte lorsque la première mesure en direct de la règle arrive, elle est notifiée à ce moment-là, avant l’évaluation de cette mesure. Si aucune mesure en direct n’arrive, elle est annoncée 5 minutes après la dernière mesure en retard. Si une alarme dont l’ouverture avait été signalée a été résolue par des mesures en retard, la résolution est annoncée de la même manière.
• Non annoncé : une alarme déjà résolue entre-temps, une alarme acquittée entre-temps, ou une escalade qui est redescendue.

Ainsi, une alarme ouverte et fermée pendant une panne figure dans l’historique, et personne n’est sollicité pour le passé.

Mesures plus anciennes que la dernière mesure évaluée

Une mesure dont l’horodatage est plus ancien que la mesure la plus récente déjà évaluée par la règle (une mesure arrivée dans le désordre, ou un tampon rejoué arrivant après les données en direct) n’est pas évaluée par défaut : une mesure plus récente a déjà déterminé l’état.

Pour évaluer aussi ces mesures, définissez "evaluateBackfill": true sur la règle (mode JSON) :

• Elles passent par un rejeu distinct de la règle, dans l’ordre d’arrivée, avec leur propre temporisateur.
• Si le rejeu ouvre une alarme, elle est marquée Rattrapée et n’est jamais notifiée. Si la condition n’est plus vraie, la prochaine mesure en direct la ferme.
• Elles ne modifient jamais une alarme ouverte par des mesures en direct.

Utilisez-le pour les appareils dont les tampons arrivent souvent après les données en direct et dont l’historique des alarmes compte (chaînes du froid réglementées, par exemple).

Horodatages

Le temporisateur de durée et l’ordre de rattrapage utilisent les horodatages des mesures. Un appareil dont l’horloge est fausse produit des heures d’alarme fausses. Les mesures situées à plus de 10 minutes dans le futur sont supprimées avant d’atteindre les règles d’alarme. Voir Heures incorrectes et trous.

Blocs d’alarme de flux et messages en retard

Les blocs d’alarme de flux (Déclencher l’alarme, Fermer l’alarme, Acquitter l’alarme) ne modifient rien pour un message en retard : ils le transmettent sans le toucher. Seules les règles d’alarme du profil évaluent les mesures en retard.