SpecsModelExplore
Overview
Actors
External Systems
IoT Platform
Edge
Ingestion
Stream Processing
Device Management
Device Registry
Device RepositoryConnection State TrackerTwin Store
OTA Service
User-Facing Apps
Platform
Device Registry
Internal structure
Components
How it is used
State updates
Desired state
API
SpecsModelExplore
Device Registry
OverviewGuideRegistry APILinks and Communications

Device Registry

The Device Registry answers the question every other service eventually asks: “is this a real, active device, and what is its current state?” It owns the device record, the certificate that proves a device’s identity, and the twin — the desired vs reported state of each device.

Why a single source of truth

Ingestion, OTA and the dashboards all need a consistent answer about a device. Centralising identity and twin state here keeps those answers authoritative and auditable instead of scattered across services.

Internal structure

Could not build diagram for model "example-iot".

Components

Device Repository

Persists device metadata and certificates.

Connection State Tracker

Tracks online / offline state per device.

Twin Store

Desired / reported state per device.

How it is used

Identity check on connect

When a device opens an MQTT session, Ingestion asks the registry to confirm the certificate maps to an active device record.

State updates

The Connection State Tracker flips a device online/offline as sessions open and close; reported twin values are written by ingestion as telemetry arrives.

Desired state

Operators (via the apps) set desired twin values — e.g. a sampling interval — which the edge agent reconciles against on its next sync.

API

The registry exposes a small REST/gRPC surface for fleet lookups and twin updates. The full contract is embedded below on the Overview tab.

Mutations to the twin are idempotent and versioned: a stale If-Match version is rejected so concurrent operators cannot clobber each other.