Sensors API

A sensor is the logical input on a device — one device may carry many. A channel is the sensor + its rules. In the API we collapse the two, because in practice you always edit them together. See Concepts for the data model rationale.

List sensors on a device

GET /v1/devices/dev_b1d2/sensors

{
  "data": [
    {
      "id":          "snr_a1b2",
      "channel_id":  "chn_a1b2",
      "device_id":   "dev_b1d2",
      "kind":        "temperature",
      "label":       "front",
      "unit":        "°C",
      "ok_min":      -2,
      "ok_max":       8,
      "grace_min":   15,
      "rule_enabled": true,
      "last_value":   4.2,
      "last_ts":     "2026-05-17T08:22:00Z",
      "state":       "ok"
    },
    ...
  ]
}

state is one of ok, grace, alarm, silent, no_data.

Update a channel's thresholds

PATCH /v1/sensors/snr_a1b2
{
  "ok_min": -1,
  "ok_max": 6,
  "grace_min": 30
}

Changes are audit-logged. The previous threshold is preserved in the audit trail and shown on the channel page.

Add a custom rule

For complex cases (windows, multiple bounds), use the alerts endpoint, not this one. This endpoint is for the single-rule simple case (one operating range, optional grace, optional windows).

Silence a channel

POST /v1/sensors/snr_a1b2/silence
{
  "from": "2026-05-17T22:00:00Z",
  "to":   "2026-05-18T02:00:00Z",
  "reason": "scheduled defrost"
}

Silence windows do not suppress measurements or audit-log events; they suppress notifications only. The alarm still appears in the dashboard and the PDF report; the operator does not get woken up.

Recompute state

POST /v1/sensors/snr_a1b2/recompute

Replays the rule engine over the last 24 h of measurements and emits any missed events. Idempotent. Use after editing a rule retroactively (rare); the audit trail records the recompute and the new events.

Errors