Telemetry and history
Current readings and retained history make device behavior inspectable over time.
DeviceOps is an IoT fleet management and observability platform. It gives operators a consistent way to monitor and control heterogeneous devices while allowing each device to expose its own metrics and controls.
This Air Sensor example advertises its own telemetry and supported commands. DeviceOps renders the relevant values, numeric charts, and controls from that manifest without a device-specific frontend. The live view also records the device's successful diagnostics acknowledgement.

Device traffic is ingested, authenticated, committed, and then delivered to the browser through the application backend. Compatible devices implement the DeviceOps v1 protocol and advertise their own metrics and commands. In production the path is device or simulator → mqtt.deviceops.net → Fly-hosted Mosquitto → FastAPI → PostgreSQL → REST/WebSocket → Next.js console.
REST + authenticated WebSocketFastAPIThe browser never connects to MQTT directly. It loads snapshots and history through REST, then receives newly committed events over an authenticated WebSocket.
Each compatible device advertises the metrics and commands it supports. The console renders those capabilities instead of hard-coding a single device type, so a sensor, portable monitor, or future implementation can share the same operational workflow without pretending to be identical. Device firmware still owns sensor drivers, wiring, sampling, units, and the decision about which compatible capabilities to advertise.
User authentication protects the console, and device ownership keeps fleet data scoped to its operator. Registration issues a one-time device secret that cannot be recovered later. That one secret supplies key material for separate broker authentication and signed, versioned DeviceOps envelopes. Production MQTT uses verified TLS. Credentials and internal secrets are never shown on this page.
Current readings and retained history make device behavior inspectable over time.
Presence and last-seen evidence show whether each device is available.
Commands remain pending until the device commits a success or failure acknowledgement.
Persistent activity records sit alongside threshold and offline alert lifecycles.
The Python simulator is one software implementation and provides selectable device profiles without physical hardware. The ESP32-S3 + BME280 build is the verified reference hardware implementation. Other capable devices can integrate by implementing the documented DeviceOps v1 protocol; compatibility is not automatic.
The production stack uses Vercel for the Next.js frontend, Fly.io for the FastAPI backend, Supabase PostgreSQL for persistence, and a DeviceOps-managed Mosquitto broker on Fly.io at mqtt.deviceops.net:443 with verified TLS.
Create an account, register a device, and connect the Python simulator, ESP32 reference firmware, or a compatible custom implementation. The repository's Docker stack remains available separately for local development.