Telemetry and history
Current readings and retained history make device behavior inspectable over time.
About DeviceOps
One console for devices that do different jobs.
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.
One device manifest, a UI built from its capabilities.
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.
Architecture
A deliberate path from device to operator
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.
Device / simulator
mqtt.deviceops.net
Fly Mosquitto
FastAPI
PostgreSQL
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.
Device capability model
The device describes what it can do
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.
Security and ownership
User, device, and transport boundaries
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.
Operational behavior
Evidence across the device lifecycle
Online and offline lifecycle
Presence and last-seen evidence show whether each device is available.
Commands and acknowledgements
Commands remain pending until the device commits a success or failure acknowledgement.
Events and alerts
Persistent activity records sit alongside threshold and offline alert lifecycles.
Try software first or connect hardware
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.
Hosted as a complete system
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.
DeviceOps console
Connect your device to the hosted system.
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.