Devices & Media

A device is the thing that reports; equipment is the thing being reported on. CAN loggers (CANedge), vision cameras (Argos, Ring), and anything else that can POST to the device contract are devices, and what they send lands on the machine or site they are linked to.

List devices — GET /api/v1/devices

curl "https://trydozer.com/api/v1/devices?status=transmitting" \
  -H "Authorization: Bearer $DASH_API_KEY" \
  -H "Project-ID: pr_northpit"

Which devices have stopped reporting?

data_query {
  "collection": "devices",
  "where": {
    "status": "transmitting"
  }
}

{
  "object": "list",
  "data": [
    {
      "object": "device",
      "id": "obj_123",
      "device_id": "canedge-ht14",
      "name": "CANedge2 — HT-14",
      "status": "transmitting",
      "status_color": "status color",
      "status_reported_at": "2026-07-25T12:00:00.000Z",
      "state": "state",
      "observation": "observation",
      "timeline_changes": "timeline changes",
      "metrics": {},
      "created_at": "2026-07-25T12:00:00.000Z",
      "updated_at": "2026-07-25T12:00:00.000Z"
    }
  ],
  "has_more": false,
  "next_cursor": null
}

Every field is in the devices reference; the files and images a device produces — raw MF4, camera frames, clips — are artifacts. Media is referenced through context.media on the object it describes, so there is no separate attachments collection to join.

Three status fields, three owners

Crossing these is the recurring bug, so they are named separately and written by different paths:

Freshness is a field, not a feeling: last_live_data_at (equipment) and last_seen_at (device) are what make a silent logger visible instead of healthy.

What to know before you call it

Both resources are read-only over REST: a device is minted through the provisioning path, which returns a one-time key, and artifacts arrive by ingest. POST /api/v1/devices/provision-info returns the bucket and HMAC reference a CANedge config.json needs; a camera worker POSTs frames to /api/v1/devices/stream with its device key and an Idempotency-Key. Config download, offline resolution and worker runs hang off /api/v1/devices/{id}/…. A device key is scoped to its own device and run — it is not a workspace token, and it reveals nothing about another project's devices.

From your own agent, mint keys and push media through the device tools — devices_new, devices_api_key_roll, devices_settings_update, devices_upload_media, devices_worker_register, devices_worker_run (MCP Tools). Never hand-roll a key or a media URL.

telemetry-onboarding is the way in and the way back: link serials that are already shipping data, order and configure new hardware, or compare hardware options — the same skill, months apart. telemetry-events reads the threshold alerts that come back and decides what needs a human, and setup seeds simulated cameras so the pipeline runs before hardware arrives (Simulate your cameras).

A CAN device write normalizes J1939 traffic into equipment fields (engine hours, fuel rate, utilization, DTC counts), preserves the reported timestamp, and carries provenance in context so any number traces back to the run that produced it. Threshold alerts carry a stable rule_id — match on that, not rule_name, which can change — plus a severity and the signal_name that crossed. An alert whose machine_id is null is logged and its downstream actions skipped rather than guessed onto a machine; pairing belongs to telemetry-onboarding.

Next: Vision AI for what a camera frame becomes · Daily Ops and Mechanic AI for the work an alert turns into · task and run logs for a worker run's own output.