How it works
A reading takes a short, predictable path from the field to your screen — and everything along it is isolated to your organization.
From sensor to dashboard
- A device measures and publishes. Each device carries components and sensors. It connects to the message broker over mutual TLS and publishes readings to a topic scoped to your organization and device —
v1/readings/{orgId}/{deviceId}. - Readings are validated and stored. A dedicated ingestion worker consumes the stream, validates each structured payload against its SensorProfile, and stores the good ones in a TimescaleDB time-series database. Anything that fails validation is set aside in quarantine.
- The API serves reads. The application API reads that stored data — raw, aggregated, or summarized — and the web app turns it into dashboards, alerts, annotations, and exports.
- Configuration flows back down. Commands and desired-state config travel the other way, to a topic the device subscribes to, and the device reports back what it applied.
Devices talk over MQTT
Devices speak MQTT over TLS, with identity proven by a per-device certificate. The organization in the topic path is trusted; anything claiming a different organization in a message body is ignored. That keeps one tenant's devices from ever writing into another's data.
Multi-tenant by default
Everything is scoped to an Organization and isolated at the database level with row-level security. A device, a dashboard, an alert, or an export always belongs to exactly one organization, and queries can only ever see their own. You don't opt into tenancy — it's the floor everything stands on.
Where to go next
- Connect devices — get hardware online
- Model your data — make readings typed and validated
- The MQTT contract — the exact topics and message formats
- Glossary — every concept, defined in one line