Alarms

The alarm editor: identity and address, the condition, the Behavior card with priority, notification, delays, message and acknowledge, the State rail, the state machine, annunciation, and Acknowledge and Ack all.

An alarm watches one Boolean condition and drives an acknowledge state machine, so a condition that mattered can never come and go unseen. Select an alarm under the Alarms root of the Logic column (or create one with New… > New alarm) to open its editor; reading needs View logic, editing Configure logic, acknowledging Operate logic.

The header shows the alarm mark (ringing while the alarm is active), the name, the line "A condition this station watches: while it holds, the alarm announces itself and waits to be acknowledged.", a pill with the current state (Normal; Active, unacked; Active, acked; Cleared, unacked) and a Disabled pill while the alarm is off. The form column holds IDENTITY, CONDITION and BEHAVIOR; the rail holds STATE.

Identity

Condition

The CONDITION card is the script editor with the hint "A single Bool JavaScript expression over the address space, e.g. Connector.Simulated.Pump.Temp.ValueToReal() > Variables.SetpointHigh.ValueToReal(). Conditions cannot reference other alarms." The condition follows every expression rule: one read-only expression, static addresses, the quality gate, the 250 ms limit. It may reference tags, variables of both kinds, Process points, Assets and the diagnostics, never Alarms.*, and it must produce a Boolean ("The condition must evaluate to a Bool, but it produced '…'."). A condition that cannot be evaluated on a sweep (a referenced point Bad, missing or empty) is uncertainty: the state machine holds its last state.

Behavior

A delay that is negative or does not parse keeps the stored value and shows "Delays must be non-negative integers (ms; resolution is the 100 ms sweep)." A delay is sustained observed time: while the condition cannot be evaluated, both delay clocks restart, so a blind window is never credited towards raising or clearing.

Saving a change to the condition, a delay, Requires acknowledge or Enabled resets the machine to Normal (stale state for a different rule would lie); the reset is journaled with the source Configuration and closes the alarm's snackbar card. Changing the name, the description, the priority, the message or the notification, or re-filing the alarm in another folder, preserves the state.

The State rail

STATE shows the current state in words, "Priority: <priority>", Active since (a dash while the condition is not holding) and Last transition (a dash before the first change of state), and the note "Every transition appears on the Events page and in the persistent Alarms history. Alarm state lives in the address space, e.g. Alarms.X.IsActive in an expression or a script." The Alarms root panel lists every alarm with "<state> · <priority> · since <when>" in its Value column and an Ack button per row.

The state machine

A condition that holds true through the on delay raises the alarm from Normal or from Cleared, unacked to Active, unacked (straight to Active, acked when Requires acknowledge is off). A condition that holds false through the off delay clears it: to Normal when already acknowledged, to Cleared, unacked when not. Acknowledging moves Active, unacked to Active, acked and releases the latch back to Normal. The sweep evaluates variables first and alarms second, every 100 ms, on the logic queue. Alarm state lives in memory: after a restart every machine starts at Normal and the first sweep re-derives reality from the live conditions, so a latch or a pending acknowledge does not survive a restart. Every transition, whatever its origin (the sweep, an acknowledge, a reset on save, disable or delete), is journaled and recorded in the durable alarm history of the Events page.

Annunciation

The shell status bar always carries the count and the worst pending severity (the window). Beyond that, the Notification kind decides:

Dismissing a card by hand is not an acknowledge. While the window is hidden to the tray or minimized, a Sticky or Timed activation also raises a system notification with the same text.

Acknowledging

Acknowledging is an operate command and happens wherever the alarm meets you: the Acknowledge verb over an open alarm, Ack all over the Alarms root, the Ack button of each row in the Alarms root panel, the right-click Acknowledge of an alarm row, the Ack of the snackbar card, the Events page, an Alarm banner on a dashboard, and the agent (journaled as MCP). Every acknowledge rides the logic queue, is journaled with its source, and closes the alarm's card.

Wherever it appears, the answer is offered only where there is one to give. An alarm that is Normal or already acknowledged keeps its verb in place, greyed, saying "This alarm is not waiting for a response."; Ack all over a registry with nothing pending says "No alarm is waiting for a response.". And the feed confirms only what moved: pressing an answer that changes nothing reports the same sentence, never "Acknowledged.", because a station log that records an operator act nobody made is worse than a verb briefly out of reach.

What alarms do not do

No hysteresis or deadband beyond what the condition expresses, no shelving, no sound, no acknowledge from a script, no persisted state across restarts, and no evaluation while the alarm is disabled or the runtime stopped. An alarm is not a Process occurrence: those are configured and judged on the Process page.