Entwarnungsbedingungen und verspätete Messwerte

Diese Seite behandelt zwei Fragen: Wann genau schließt sich ein Alarm, und was passiert mit Messwerten, die verspätet eintreffen, zum Beispiel nachdem ein Gerät offline war und seinen Puffer sendet.

Standard-Entwarnung

Ohne eine clear-Bedingung schließt sich ein Alarm, wenn keine Schweregradbedingung mehr zutrifft, erweitert um die Hysterese, und nach dem Entprellen der Entwarnung. Beispiel: Auslöser temperature > 80 mit Hysterese 3 schließt sich bei 77 oder darunter.

Explizite Entwarnungsbedingung

Eine clear-Bedingung (JSON-Modus) ersetzt diese Logik: Der Alarm bleibt offen, solange clear falsch ist, und schließt sich, sobald sie wahr ist (nach dem Entprellen der Entwarnung). Die Hysterese wird dann ignoriert.

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

Der Sturzalarm bleibt offen, wenn das nächste Ereignis normal ist; er wird erst geschlossen, wenn die träger Person einmal den Knopf drückt.

Verwenden Sie eine explizite Entwarnungsbedingung, wenn:

der Alarm auf ein bestätigendes Signal warten soll (einen Rückstellknopf, einen Zustand „normal“),
die Werte zum Öffnen und Schließen unterschiedliche Schlüssel sind (öffnen bei smoke == true, schließen bei alarm_reset == true),
die Entwarnung mehrere Dinge gleichzeitig erfordert (all aus Tür geschlossen und Druck wieder normal).

Die clear-Bedingung hat dieselbe Form und dieselben Grenzen wie eine Schweregradbedingung (16 Vergleiche, 4 Stufen). Eine Nachricht, die weder einen Schlüssel der Entwarnungsbedingung noch einen Schlüssel der Schweregrade enthält, ist kein Messwert für die Regel.

Hinweis

Eine Entwarnungsbedingung, die nie wahr wird, hält den Alarm dauerhaft offen. Stellen Sie sicher, dass das Gerät diesen Schlüssel und Wert tatsächlich sendet, oder schließen Sie solche Alarme manuell.

Schließen von anderer Stelle

Ein Alarm einer Regel kann auch von einer Person (Schließen), durch den Block Alarm schließen eines Flows oder durch eine Aktion auf der Regelkarte geschlossen werden. Nachdem eine Person ihn geschlossen hat, während die Bedingung noch wahr ist, wartet die Regel, bis die Bedingung einmal falsch war, bevor sie einen neuen Alarm öffnen kann. Nachdem ein Flow oder eine Regel ihn geschlossen hat, beginnt die Regel im Leerlauf: Der nächste wahre Messwert (nach dem Entprellen) öffnet einen neuen Alarm.

Verspätete Messwerte

Ein Gerät, das offline war, sendet beim Wiederverbinden häufig die Messwerte, die es gepuffert hat. Hermetry speichert sie mit ihren eigenen Zeitstempeln (siehe Zeitstempel, verspätete und doppelte Messwerte). Für Alarme gibt es zwei Fälle.

Spät verarbeitete Messwerte

Der Root-Flow verarbeitet Nachrichten in der Reihenfolge ihres Eingangs. Eine Nachricht, die länger als die Time-to-live des Flow-Hosts gewartet hat (zum Beispiel während eines Ausfalls), wird als verspätet markiert. Für Alarmregeln ist sie ein Nachtrag:

Ist sie neuer als der letzte Messwert, den die Regel ausgewertet hat, bewegt sie die Regel wie üblich: Alarme öffnen sich, ändern den Schweregrad und schließen sich.
Diese Schritte werden still aufgezeichnet und nach den Messwerten datiert: Die Alarmliste, die Glockenzähler und die Live-Boards folgen ihnen, aber niemand wird benachrichtigt, es wird kein Webhook gesendet und kein Flow gestartet. Ein so geöffneter Alarm trägt das Abzeichen Nachgetragen; seine Zeitleistenschritte lauten „aus verspäteten Messwerten“.
Was gültig bleibt, wird einmal gemeldet: Ist ein durch verspätete Messwerte geöffneter (oder eskalierter) Alarm noch offen, wenn der erste Live-Messwert der Regel eintrifft, wird er dann gemeldet, bevor dieser Messwert ausgewertet wird. Kommt kein Live-Messwert, wird er 5 Minuten nach dem letzten verspäteten Messwert gemeldet. Wurde ein Alarm, dessen Öffnung gemeldet worden war, durch verspätete Messwerte aufgelöst, wird die Auflösung auf dieselbe Weise gemeldet.
Nicht gemeldet werden: ein Alarm, der inzwischen bereits aufgelöst wurde, ein Alarm, den jemand inzwischen bestätigt hat, oder eine Eskalation, die wieder zurückgenommen wurde.

Ein Alarm, der während eines Ausfalls geöffnet und geschlossen wurde, erscheint also im Verlauf, und für die Vergangenheit wird niemand alarmiert.

Messwerte älter als der zuletzt ausgewertete

Ein Messwert, dessen Zeitstempel älter ist als der neueste Messwert, den die Regel bereits ausgewertet hat (ein Messwert außer der Reihe oder ein wiedergegebener Puffer, der nach Live-Daten eintrifft), wird standardmäßig nicht ausgewertet: Ein neuerer Messwert hat den Zustand bereits bestimmt.

Damit auch solche Messwerte ausgewertet werden, setzen Sie "evaluateBackfill": true in der Regel (JSON-Modus):

Sie laufen durch eine eigene Wiedergabe der Regel, in der Reihenfolge ihres Eingangs, mit eigenem Entprellen.
Öffnet die Wiedergabe einen Alarm, wird er mit Nachgetragen markiert und nie gemeldet. Ist die Bedingung nicht mehr wahr, schließt ihn der nächste Live-Messwert.
Sie verändern nie einen Alarm, den Live-Messwerte geöffnet haben.

Verwenden Sie dies für Geräte, deren Puffer häufig nach Live-Daten eintreffen und deren Alarmverlauf wichtig ist (zum Beispiel regulierte Kühlketten).

Zeitstempel

Das Entprellen der Dauer und die Reihenfolge der Nachträge nutzen die Zeitstempel der Messwerte. Ein Gerät mit falscher Uhr erzeugt falsche Alarmzeiten. Messwerte, die mehr als 10 Minuten in der Zukunft liegen, werden verworfen, bevor sie die Alarmregeln erreichen. Siehe Falsche Zeiten und Lücken.

Alarmblöcke im Flow und verspätete Nachrichten

Die Alarmblöcke im Flow (Alarm auslösen, Alarm schließen, Alarm bestätigen) verändern bei einer verspäteten Nachricht nichts: Sie leiten sie unverändert weiter. Nur die Alarmregeln des Profils werten verspätete Messwerte aus.