Skip to content
VolatileSys
Get started

Quickstart — from sign-up to live data

You drive VolatileSys two ways: the dashboard (point and click) to set things up, and the ingest API (REST or MQTT) for your devices to push telemetry. This page takes you from a fresh account to a live chart in a few minutes — no hardware required.

Monitoring a website, backend service, or game instead of hardware? Create an Application project and report metrics, events, and errors as JSON — see Application monitoring.

Step 1 · Set up in the dashboard

After signing in, open the console and go to the Fleet tab. There is no separate “enable API” switch — minting an ingest key is what turns the API on. Work top to bottom:

  1. Create a fleet — a named group of devices (e.g. field-sensors).
  2. Add a device to that fleet and give it a name. Note its device id — you'll send data as that device.
  3. Mint an ingest key for the fleet. Copy it immediately — it is shown once and only a hash is stored. This key is your API credential.
  4. Build a payload rule in the visual editor (each field = a name, a bit offset, and a bit length), then click Activate. Without an active rule your bytes arrive but aren't decoded into metrics. See Payload rules.

Step 2 · Send your first frame

Devices post directly to your API host (not through the dashboard site). The endpoint is /v1/ingest; authenticate with the X-Ingest-Key header and send the raw frame hex-encoded in the payload field:

curl -X POST https://<your-api-host>/v1/ingest \
  -H "X-Ingest-Key: vsk_…" \
  -H "Content-Type: application/json" \
  -d '{"device_id": "<device-id>", "payload": "0010740e39"}'

→ 202 Accepted   (queued; decoding happens off the request path)

No firmware yet? The bundled simulator sends realistic frames for you. Its default layout is three fields — heap_free (uint16), batt_mv (uint16), cpu_pct (uint8) — so build a rule with those and you'll see charts move within seconds:

python sim/device_sim.py \
  --url https://<your-api-host>/v1/ingest \
  --key vsk_… \
  --device <device-id>

Step 3 · Watch it decode

Frames buffer on a Redis Stream, decode off the request path, and appear on the device's dashboard within seconds. A 202 means accepted; 401 means the key is wrong or revoked; 404 means the device id isn't in that key's fleet.

Raw frames are retained (per your plan's window), so changing a rule re-decodes history — you never lose data to a decoding mistake. MQTT works on the same key: publish the hex frame to ingest/{fleet_id}/{device_id} (username = fleet id, password = the key). Full details on the Ingest API page.