Condiciones de cierre y lecturas tardías

Esta página responde a dos preguntas: exactamente cuándo se cierra una alarma y qué ocurre con las lecturas que llegan tarde, por ejemplo después de que un dispositivo estuviera desconectado y envíe su buffer.

Cierre por defecto

Sin una condición clear, una alarma se cierra cuando ninguna condición de severidad es ya verdadera, ampliada por la histéresis, y tras el debounce de cierre. Ejemplo: al abrir con temperature > 80 y histéresis 3, se cierra en 77 o menos.

Condición de cierre explícita

Una condición clear (modo JSON) sustituye esa lógica: la alarma permanece abierta mientras clear sea falso y se cierra en cuanto sea verdadero (tras el debounce de cierre). La histéresis se ignora entonces.

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

La alarma de caída permanece abierta cuando el siguiente evento es normal; solo se cierra cuando el usuario pulsa el botón una vez.

Use una condición de cierre explícita cuando:

• la alarma deba esperar una señal de confirmación (un botón de reinicio, un estado «normal»),
• los valores de apertura y cierre sean claves distintas (abrir con smoke == true, cerrar con alarm_reset == true),
• el cierre necesite varias cosas a la vez (all de puerta cerrada y presión recuperada).

La condición clear tiene la misma forma y los mismos límites que una condición de severidad (16 comparaciones, 4 niveles). Un mensaje que no contenga ninguna clave de la condición de cierre ni ninguna clave de severidad no es una muestra para la regla.

Cierre desde otros lugares

Una alarma de una regla también puede ser cerrada por una persona (Clear), por el bloque Clear alarm de un flujo o por una acción de la tarjeta Rules. Después de que una persona la cierre mientras la condición siga siendo verdadera, la regla espera a que la condición haya sido falsa una vez antes de poder abrir una nueva alarma. Después de que un flujo o una regla la cierre, la regla parte del estado inactivo: la siguiente lectura verdadera (tras el debounce) abre una nueva alarma.

Lecturas tardías

Un dispositivo que estuvo desconectado suele enviar las lecturas que almacenó en su buffer cuando vuelve a conectarse. Hermetry las guarda con sus propias marcas de tiempo (véase Timestamps, late and duplicate readings). Para las alarmas hay dos casos.

Lecturas procesadas tarde

El flujo raíz procesa los mensajes en orden. Un mensaje que esperó más que el tiempo de vida (time-to-live) del host de flujos (por ejemplo, durante una caída del servicio) se marca como tardío. Para las reglas de alarma se trata de un backfill:

• Si es más reciente que la última lectura que evaluó la regla, mueve la regla como de costumbre: las alarmas se abren, cambian de severidad y se cierran.
• Estos pasos se registran en silencio, con la fecha de las lecturas: la lista de alarmas, los contadores de la campana y los paneles en vivo los siguen, pero nadie es avisado, no se envía ningún webhook y no se inicia ningún flujo. Una alarma abierta de este modo lleva la insignia Backfilled; sus pasos en la línea temporal dicen «from late readings».
• Lo que sigue siendo cierto se anuncia una sola vez: si una alarma abierta (o escalada) por lecturas tardías sigue abierta cuando llega la primera lectura en vivo de la regla, se notifica en ese momento, antes de evaluar esa lectura. Si no llega ninguna lectura en vivo, se anuncia 5 minutos después de la última lectura tardía. Si una alarma cuya apertura había sido notificada fue resuelta por lecturas tardías, la resolución se anuncia de la misma manera.
• No se anuncian: una alarma ya resuelta entretanto, una alarma reconocida por alguien entretanto, ni una escalada que volvió a bajar.

Así, una alarma que se abrió y se cerró durante una caída aparece en el historial, y nadie recibe un aviso por hechos pasados.

Lecturas anteriores a la última evaluada

Una lectura cuya marca de tiempo es anterior a la lectura más reciente que la regla ya evaluó (una lectura fuera de orden, o un buffer reenviado que llega después de los datos en vivo) no se evalúa por defecto: una lectura más nueva ya ha decidido el estado.

Para evaluar también estas lecturas, configure "evaluateBackfill": true en la regla (modo JSON):

• Se ejecutan en una repetición separada de la regla, en el orden en que llegan, con su propio debounce.
• Si la repetición abre una alarma, se marca como Backfilled y nunca se notifica. Si la condición ya no es verdadera, la siguiente lectura en vivo la cierra.
• Nunca modifican una alarma que abrieron las lecturas en vivo.

Úselo en dispositivos cuyos buffers llegan a menudo después de los datos en vivo y cuyo historial de alarmas importa (cadenas de frío reguladas, por ejemplo).

Marcas de tiempo

El debounce de duración y el orden de backfill usan las marcas de tiempo de las lecturas. Un dispositivo cuyo reloj es incorrecto produce tiempos de alarma erróneos. Las lecturas con más de 10 minutos de adelanto se descartan antes de llegar a las reglas de alarma. Véase Wrong times and gaps.

Bloques de alarma de flujo y mensajes tardíos

Los bloques de alarma de flujo (Raise alarm, Clear alarm, Acknowledge alarm) no cambian nada para un mensaje tardío: lo pasan sin tocarlo. Solo las reglas de alarma del perfil evalúan las lecturas tardías.