Alarm banner
Dashboard component reference for the Alarm banner, its three presentations, every property, and how alarms are acknowledged from it.
The Alarm banner shows the pending slice of the alarm registry: every alarm that is active or still awaiting an acknowledge, worst priority first, oldest first within a priority. It is the one component that reads the registry directly — it has no address to bind — so its panel only asks how much of the registry to show and how. It is also where the operator answers alarms: on a full-screen dashboard there is no other page to walk to, so the acknowledge buttons live on the banner itself.
Presentations
The Shows property picks one of three shapes. All three are the same reading at three sizes; the severity floor and the row cap below are applied where the registry is read, so a summary never counts an alarm the list beside it was told to leave out.
| Option | What it draws |
|---|---|
| Every pending alarm | One row per alarm with its name, state and how long it has been pending, plus an Ack button per row when acknowledgement is on. |
| One line about all of them | A single sentence, for example 2 active (1 unacked). |
| How many at each severity | One chip per severity that has something pending, worst first, each with its total and, when acknowledgement is on, its unacked count. A severity with nothing pending draws no chip. |
The header always carries the summary line. When the banner shows nothing at all it reads No active alarms; while acknowledged rows are still settling out of a list it reads All acknowledged instead, so the header never reports a quiet plant over visible rows.
Properties
| Property | What it does | Values | Default |
|---|---|---|---|
| Shows | The presentation, as above. | Every pending alarm · One line about all of them · How many at each severity | Every pending alarm |
| Down to | The least severe priority the banner still shows. Priorities run worst-first, so this is a severity floor. It is part of the reading, not the drawing: an alarm below the floor is out of the rows, the summary, the counts and Ack all alike. | Critical only · High and worse · Medium and worse · Every priority | Every priority |
| Rows at most | How many rows the list presentation draws. What is over the cap is counted under the list (3 more alarms are not shown.), never dropped in silence. Only asked of the list presentation. |
1 to 200 | 20 |
| Say what awaits an acknowledge, and offer to answer it | One switch governing both halves of acknowledgement: the marks saying what still awaits an answer (the unacked half of the summary, the unacked count on a chip, the mark on a row) and the buttons that give it (the per-row Ack and the header's Ack all). Off, the banner is purely informational; on a full-screen station that also removes the only way to answer an alarm. What the alarm's own state machine is doing is never hidden by this. | on / off | on |
| Count them by severity too | Adds the per-severity chips beside the summary of the other two presentations. Not offered on the severity presentation, which is already made of them. | on / off | off |
A row count typed outside the 1–200 band is taken at the nearest edge and the panel says so beside the field; text that is not a number leaves the cap in force alone.
Acknowledging
Every acknowledge rides the logic queue and is journaled like any operator acknowledge.
- Ack on a row answers that alarm. A row already answered shows a check mark instead of a spent button.
- Ack all in the header answers everything the banner reads, one alarm at a time
through the same funnel. The severity floor applies — the banner never answers an alarm
it was told not to show — but the row cap does not, because the cap limits the drawing
and the summary already counts what it holds back. The answer line then says how many
were acknowledged; if the run of writes stops partway, it says how far it got
(
2 of 5 acknowledged) rather than leaving the rest pending in silence. - On the list presentation, Ack all appears once more than one alarm awaits an answer (with a single one, the row's own button already is that command). The two summaries draw no rows, so there the header button appears as soon as one alarm is waiting.
After an acknowledge that removes a row from the reading (a latched alarm whose condition has already cleared), the drawn positions hold still for about two seconds — up to six across a burst of presses — so the row under the finger stays the row that was answered. An alarm raised meanwhile is still drawn in whatever room the cap has left; the summary, the counts and the rest of the app run on regardless. A settling row is styled as on its way out rather than keeping an unacked mark it no longer earns.
Permission
Acknowledging takes the Dashboard operation permission of the signed-in local user's role; on a unit's Process screen, the Run procedures permission gates it instead, like every command that screen hosts. Without it, the banner wears the shared lock mark and the buttons' tooltips carry the reason — but only while an answer is actually offered and something awaits one: an informational banner, or one with nothing pending, is a reading, and a reading does not claim the station may not command. The transient result of each press is written on the banner itself, the one surface left when a full-screen dashboard hides the status bar.