IoT & devices

The fleet problem

A connected-device fleet has the same structural shape as a CMS: schemas (device profiles), records (instances of devices in the field), and actions (commands you fire at them). Jaina handles all three.

Schemas you'll define

• DeviceProfile — model, firmware version, capabilities (array), expected telemetry fields (json).
• Device — serial, profile (reference to DeviceProfile), last seen, location (json).
• Telemetry — device (reference), timestamp, metrics (json), errors (array).
• Command — device (reference), action, payload (json), issued_at, ack_at.

Actions = device commands

Jaina lets you define actions on schemas. For an IoT fleet, an action on Device might be reboot, update_firmware, or set_config. Firing the action from the GUI, API, or MCP triggers your webhook handler, which translates the action into MQTT, HTTPS, or whatever protocol your devices speak.

// In your fleet operator backend
app.post('/jaina/webhook', verify, async (req, res) => {
  const event = req.body;
  if (event.type === 'action.device.reboot') {
    const { device_id } = event.data;
    await mqttClient.publish(`devices/${device_id}/cmd`, JSON.stringify({ op: 'reboot' }));
  }
  res.sendStatus(200);
});

Telemetry ingestion

For telemetry, the inbound path is the REST API. Devices (or a gateway aggregating them) POST records into the telemetry schema. Jaina's pagination and filter API handles "show me the last 24 hours of errors for device X."

Why this shape

Fleets and CMSes look different but share a single underlying primitive: a typed record with a schema that everyone agrees on. Jaina gives you that primitive plus the three doors. Your protocol code lives where it should — in your device firmware and your gateway — and Jaina handles the operator-facing layer.