Offline, quiet and alarm rows

The physical worldMQTTDashboardline-alarmmachine-offlinemachine-quietMACHINE_QUIET_MSMACHINE_OFFLINE_DEBOUNCE_MS

A stopping alarm, a dropped machine and a silent one each become a row for the line operator, resolved when the machine recovers.

The situation

A machine raises an emergency stop, loses its network, or stays connected but stops reporting. Each needs a person, and each should clear itself when the machine is back, with a record of how long it took.

The recipe

Name the operator role on the line, and tune the timers in the environment:

{ "siteId": "site-1", "lineId": "line-1",
  "roles": { "operator": "line-operator" },
  "machines": [{ "machineId": "cut-01", "process": "cut" }] }

MACHINE_OFFLINE_DEBOUNCE_MS=15000
MACHINE_QUIET_MS=90000

Row	Raised when	Resolved when
`line-alarm`	A critical or emergency alarm is raised	The machine clears it, with who cleared it. A person who resolves it first sends `ack-alarm`
`machine-offline`	Presence goes offline past the debounce	The machine is heard again
`machine-quiet`	A connected machine sends nothing for `MACHINE_QUIET_MS`	It is heard again (`0` turns this off)

An alarm body may name its catalog edition, catalog: { domain, key, version }, so the row reads the code’s meaning as of that edition.

The guarantee

A replica taking the line reads back its open alarm, offline and quiet rows, then the machines’ retained state, so a clear or a return that happened while no gateway was listening still resolves its row. An alarm id reused with a new raise time counts as a new alarm. See Machines.

The physical world