Specification · section 8
Notifications
Servers push notifications (JSON-RPC requests without id) for anything a supervising agent needs to react to:
| Method | Params | When |
|---|---|---|
notifications/signals/update |
{name, value, ts} |
a subscribed or driver-chosen signal changes |
notifications/settings/changed |
{name, value, by} |
any client writes a setting |
notifications/jobs/started |
{job} |
job leaves the queue |
notifications/jobs/progress |
{job, ...extra} |
driver reports progress (extra keys are device-specific) |
notifications/jobs/finished |
{job} |
job reaches done / failed / cancelled |
notifications/jobs/paused, jobs/resumed, jobs/cancelling |
{job, by} |
pause, resume or cancel requested |
notifications/safety/estop |
{by, reason, stopped, stop_error} |
e-stop engaged by a client or the watchdog |
notifications/safety/fault |
{reason} |
the device latched a fault with an unknown outcome |
notifications/operator/instruction |
{text, job?} |
an operator-run instrument asks a person to act |
notifications/safety/reset |
{by} |
device returned to idle |
notifications/methods/saved, methods/retired |
{method: card, by} |
a method was saved (new version or new method) or retired |
A supervising host consumes these without asking: the reference bridge subscribes to every device it opens
(in-process, over the HTTP /events stream, or over stdio), keeps the recent ones per device for
mhp_data op='updates', appends them to the events.jsonl of any run that has used the device, and writes
the notable ones (job finished with its result, safety, operator, methods) to the lab's run log. An agent
reads what came in and decides the next run; nothing in this path polls the instrument.