Clear conditions and late readings

This page covers two questions: when exactly does an alarm close, and what happens to readings that arrive late, for example after a device was offline and sends its buffer.

Default clear

Without a clear condition, an alarm clears when no severity condition is true any more, widened by the hysteresis, and after the clear debounce. Example: raise temperature > 80 with hysteresis 3 clears at 77 or below.

Explicit clear condition

A clear condition (JSON mode) replaces that logic: the alarm stays open while clear is false and clears once it is true (after the clear debounce). Hysteresis is then ignored.

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

The fall alarm stays open when the next event is normal; it clears only when the wearer presses the button once.

Use an explicit clear condition when:

• the alarm should wait for a confirming signal (a reset button, a “normal” state),
• the opening and closing values are different keys (open on smoke == true, clear on alarm_reset == true),
• the clear needs several things at once (all of door closed and pressure back).

The clear condition has the same shape and limits as a severity condition (16 comparisons, 4 levels). A message that carries none of the clear condition’s keys and none of the severity keys is no sample for the rule.

Clearing from elsewhere

An alarm of a rule can also be closed by a person (Clear), by a flow’s Clear alarm block or by a Rules-card action. After a person clears it while the condition is still true, the rule waits until the condition has been false once before it can open a new alarm. After a flow or rule clears it, the rule starts from idle: the next true reading (after debounce) opens a new alarm.

Late readings

A device that was offline often sends the readings it buffered when it comes back. Hermetry stores them with their own time stamps (see Timestamps, late and duplicate readings). For alarms there are two cases.

Readings processed late

The root flow processes messages in order. A message that waited longer than the flow host’s time-to-live (for example during an outage) is marked late. For alarm rules it is a backfill:

• If it is newer than the last reading the rule evaluated, it moves the rule as usual: alarms open, change severity and clear.
• These steps are recorded quietly, dated by the readings: the alarm list, the bell counts and live boards follow them, but nobody is told, no webhook is sent and no flow is started. An alarm opened this way has the Backfilled badge; its timeline steps say “from late readings”.
• What stays true is announced once: if an alarm opened (or escalated) by late readings is still open when the first live reading of the rule arrives, it is notified then, before that reading is evaluated. If no live reading comes, it is announced 5 minutes after the last late reading. If an alarm whose opening had been told was resolved by late readings, the resolution is announced the same way.
• Not announced: an alarm already resolved meanwhile, an alarm someone acknowledged meanwhile, or an escalation that came back down.

So an alarm that opened and cleared during an outage appears in the history, and nobody is paged for the past.

Readings older than the last evaluated one

A reading whose time stamp is older than the newest reading the rule already evaluated (an out-of-order reading, or a replayed buffer arriving after live data) is not evaluated by default: a newer reading has already decided the state.

To evaluate such readings too, set "evaluateBackfill": true on the rule (JSON mode):

• They run through a separate replay of the rule, in the order they arrive, with their own debounce.
• If the replay opens an alarm, it is marked Backfilled and never notified. If the condition is no longer true, the next live reading clears it.
• They never change an alarm that live readings opened.

Use it for devices whose buffers often arrive after live data and whose alarm history matters (regulated cold chains, for example).

Time stamps

Duration debounce and the backfill order use the readings’ time stamps. A device whose clock is wrong produces wrong alarm times. Readings more than 10 minutes in the future are dropped before they reach the alarm rules. See Wrong times and gaps.

Flow alarm blocks and late messages

The flow alarm blocks (Raise alarm, Clear alarm, Acknowledge alarm) change nothing for a late message: they pass it on untouched. Only the profile’s alarm rules evaluate late readings.