Shell 1.11.0: alerts — a module flashes every dashboard listening on one of six channels
A module that sees something a tech must act on now (a timer overrun, a meter past its limit, timecode gone) raises an alert on a channel, 1–6, and every dashboard listening to that channel flashes: the menu bar — brought out for the duration if it was hidden — and a frame round the screen alternate between the level's two colours, with the alert's text bold across the bar. Low fades slowly, medium faster, critical snaps with no fade and floods the board behind the tiles too, in a muted cut that shows faintly through the tile panels without costing their content any contrast. Server: the hub. One alert per channel (a new one replaces the last), timed out server-side (1–600 s, 15 by default, 0 = held until cleared), broadcast over the shell stream as `alert` / `alert-clear`; GET /api/alerts for a dashboard that opens or reconnects mid-alert; POST /api/alerts and DELETE /api/alerts/<n>, open like a layout save. Modules raise from their server entry with shell.alert() / shell.clearAlert() or from a tile with moduleApi.alert() / moduleApi.clearAlert(); a module's alerts end when it stops. Colours live as alerts.colors in the data directory's proddash.json. Dashboard: the Layouts menu gains a folded Alerts row with six numbered toggles; the channel list saves with the layout, local and named (the server keeps it in a saved layout). Admin: a folded Alerts section with two colour pickers per level, a swatch running each level's cadence, and a Test row. Docs: docs/ALERTS.md (the feature), a "Raising alerts" section in the module guide, README. Tools: tools/alert.js raises/clears/lists from the command line; tools/alerts.test.js drives it all end to end. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5.1
parent
a3500f98b1
commit
5ca0a672fa
@@ -437,6 +437,8 @@ export default function create({ root, moduleApi }) {
|
||||
| `fetch(path, opts)` | `fetch` scoped to your server routes: `fetch('/state')` hits `/api/modules/<id>/state`. |
|
||||
| `sse(path, handlers)` | An `EventSource` scoped the same way, **with auto-reconnect** (see below). Returns a handle with `close()`. |
|
||||
| `setStatus(state, msg)` | Drives the tile's status dot: `'ok'`, `'connecting'` or `'error'`, plus a hover message. Call it honestly — during a live service the dot is how an operator spots a dead feed. |
|
||||
| `alert(opts)` | Flash every dashboard listening to an alert channel — `{ channel, level, text, duration }`, see **Raising alerts**. Returns a promise. A module with a server entry raises from there (`shell.alert`) instead. |
|
||||
| `clearAlert(channel)` | End the alert on a channel early. Returns a promise. |
|
||||
| `header.addButton(…)` | Put a small button in the tile's own title bar (see below). |
|
||||
| `header.addMenu(…)` | Put a dropdown menu button there (see below). |
|
||||
|
||||
@@ -600,6 +602,9 @@ module.exports = {
|
||||
- `shell.port` is the port ProdDash is serving on — what you need to read
|
||||
another module's routes over loopback (`http://127.0.0.1:${shell.port}/api/
|
||||
modules/<id>/…`). Never guess it.
|
||||
- `shell.alert(opts)` flashes every dashboard listening to an alert channel
|
||||
and `shell.clearAlert(channel)` ends one early — see **Raising alerts**.
|
||||
Alerts your module raised end when it stops.
|
||||
- Handlers get plain Node `(req, res)`. On a prefix route, `req.wildcard` is
|
||||
the matched remainder (leading `/` included) and `req.search` is the query
|
||||
string (with `?`, or `''`) — so a proxy rebuilds the upstream path as
|
||||
@@ -704,6 +709,72 @@ per-client `res.write` in try/catch (drop the client on failure). The
|
||||
`propresenter-now-next` module is the reference implementation of this
|
||||
pattern.
|
||||
|
||||
## Raising alerts
|
||||
|
||||
An alert is for the thing a tech must act on *now*, whichever tile they
|
||||
happen to be looking at — a timer that has overrun, a meter past its limit,
|
||||
timecode that has gone quiet mid-service. Every dashboard that listens to
|
||||
the alert's channel flashes: its menu bar (brought out for the duration,
|
||||
even if it was hidden) and a frame round the whole screen alternate between
|
||||
the level's two colours, with your text bold across the middle of the bar.
|
||||
The shell owns all of that — the colours (Admin → Alerts), the cadence,
|
||||
which screens listen (each dashboard's Layouts menu → Alerts) — so a module
|
||||
only has to say what happened. [docs/ALERTS.md](ALERTS.md) has the
|
||||
operator's side.
|
||||
|
||||
Raise one from your server entry, where the condition is usually noticed:
|
||||
|
||||
```js
|
||||
init({ config, log, shell }) {
|
||||
// …when timecode drops:
|
||||
shell.alert({ channel: config.alertChannel, level: 'critical', text: 'LTC lost', duration: 0 });
|
||||
// …and when it is back:
|
||||
shell.clearAlert(config.alertChannel);
|
||||
}
|
||||
```
|
||||
|
||||
or from a tile, through the shell's server:
|
||||
|
||||
```js
|
||||
await moduleApi.alert({ channel: 2, level: 'medium', text: 'Service over by 5:00', duration: 20 });
|
||||
```
|
||||
|
||||
| Field | Meaning |
|
||||
| --- | --- |
|
||||
| `channel` | `1`–`6`. Which dashboards flash: each listens to the channels its operator chose in the Layouts menu. A channel carries no meaning of its own — the booth decides that "1 is the stage, 2 is video" — so **make yours an admin setting** (`configSchema`, `type: "number"`, `min: 1`, `max: 6`) rather than hard-coding one. |
|
||||
| `level` | `low` — a slow fade between the two colours, for something to know about; `medium` — a quicker pulse, for something to deal with soon; `critical` — no fade, the colours snap, and the board behind the tiles floods with a muted cut of them too, for something to deal with now. |
|
||||
| `text` | What happened, in a few words — 80 characters at most (more is cut, whitespace is collapsed). It is shown as given, so write it the way it should read on a wall: `SPL 102 dB — over limit`, not `spl_over_limit`. |
|
||||
| `duration` | Seconds, 1 to 600; `15` when omitted. `0` holds the alert until you clear it — for a condition you will *notice ending* (timecode lost, a feed down) and clear; a one-off event takes a duration. |
|
||||
|
||||
Both return the alert as raised (`{ id, channel, level, text, source,
|
||||
startedAt, duration, endsAt, remainingMs }`) and throw — reject, on the
|
||||
client — with a one-line reason when the input is refused. That is a bug
|
||||
in your module, not something to show the operator.
|
||||
|
||||
What to know:
|
||||
|
||||
- **One alert per channel.** A new alert on a channel replaces whatever was
|
||||
on it, whoever raised it; `clearAlert(channel)` ends whatever is on it.
|
||||
Two modules on one channel talk over each other — one more reason the
|
||||
channel is admin config.
|
||||
- **Your alerts end when you stop.** A disable, an uninstall or a config
|
||||
save that re-inits you clears every alert your module raised, held ones
|
||||
included. If the condition is still true, raise it again from `init()`.
|
||||
- **Raise on the transition, not the state.** `if (over && !wasOver)
|
||||
shell.alert(…)` — an alert re-raised on every poll restarts its timer and
|
||||
flashes for ever. Clear it, or let it expire, when the condition ends.
|
||||
- **Make alerting a setting**, and the threshold too: a `switch` in
|
||||
`configSchema`, off by default unless alerting is the module's reason to
|
||||
exist. A screen that flashes for nothing teaches a room to ignore it.
|
||||
- **It is not a status.** The tile's dot (`setStatus`) says how *you* are;
|
||||
an alert says what the *room* must do. An unreachable upstream turns the
|
||||
dot red; it raises an alert only if that is something a tech has to act on
|
||||
during the service, and the operator switched that on.
|
||||
- Alerts reach the server over `POST /api/alerts` — what `moduleApi.alert`
|
||||
calls, with your module id as `source` — which anything on the network may
|
||||
use too; `node tools/alert.js -c 1 -l critical "LTC lost"` raises one from
|
||||
the command line while you build (`--clear`, `--list`).
|
||||
|
||||
## Working with other modules
|
||||
|
||||
Modules don't import each other. When one needs what another knows, it reads
|
||||
@@ -961,6 +1032,10 @@ client-side failures (a tile that fails to start says so in the tile).
|
||||
- `GET /api/modules/<id>/...` — your routes, `curl`-able. For SSE:
|
||||
`curl -N http://localhost:24500/api/modules/<id>/stream`.
|
||||
- `GET /api/admin/state` — enabled flags, health, mount errors.
|
||||
- `GET /api/alerts` — what is flashing, and the colours. `node tools/alert.js
|
||||
-c 1 -l critical "LTC lost"` raises one without a module (`--clear`,
|
||||
`--list`); a dashboard shows it once channel 1 is chosen in its Layouts
|
||||
menu → Alerts.
|
||||
|
||||
**Mock upstreams** (so you can develop without the real gear):
|
||||
|
||||
|
||||
Reference in New Issue
Block a user