Query the fleet. Command the device.

Packet in. Action out.

A device speaks MQTT, Sparkplug B or LwM2M over CoAP/DTLS. DeviceChain decodes it, resolves which device it came from, records the event, updates that device's live state, evaluates it against your rules, and acts on the result. One path, and no glue code between the stages.

A device is a typed object, not a row.

What a device can measure, report and be commanded to do lives in a device profile — a versioned capability aggregate, separate from the device type that references it. Change a profile and you publish a new version; devices are not silently redefined underneath you.

Devices relate to customers, areas, assets and to each other through one typed relationship graph rather than a fixed hierarchy, so the model bends to how your fleet is actually organized.

Device profiles

Versioned metrics, attributes and typed command definitions. Published, not edited in place.

Relationship graph

Typed edges between any entities, with faceted classification instead of one rigid tree.

Dynamic groups

A CEL selector over entity attributes, resolved as an indexed query — membership follows the data.

Customers, areas, assets

Real entities, not examples — areas carry polygon boundaries and nest, assets are assigned to devices as a tracked relationship, and telemetry is anchored to that context when it is written.

Credentials, and replacement

Identity is the stable token; credentials are separate, rotatable material. Swapping failed hardware is one operation that retires every enabled credential with it.

Live state

Last-known-state per device with authoritative presence — asserted by the transport where it can be, inferred from activity where it cannot. No per-device metering.

Test the rule before the fleet does.

Automation is only trustworthy if it behaves in production the way it behaved when you wrote it. Every rule — however it was authored — lowers to one deterministic compiler and one engine, so the same events always produce the same alarms.

That property is what makes the preview meaningful: you can replay real history through a rule and watch what it would have done, before it governs anything.

Author three ways

A typed form on the profile, a visual automation canvas, or by describing the rule in plain language.

Alarms as state

Alarm objects integrate level state over time rather than firing on every matching event.

Eight kinds of rule

Thresholds, rates of change, repetition, duration, absence, aggregates, correlation and connectivity — so "tell me when a device stops reporting" is a rule kind, not a workaround.

Geofences

Draw them in the console or send polygons over the API, holes and all. Containment is callable from any rule, and every fence set is archived so a replay answers with the fences that were live then.

Scoped, not global

Rules are authored on a device profile and can be narrowed to a dynamic group, pinned to a published version of it; membership is stamped at resolution time.

Compiled, not guessed.

Describe what you want in plain language and DeviceChain drafts a candidate rule — then runs it through the exact same compiler as every hand-authored one. If it does not compile, it does not ship. AI proposes; the compiler disposes.

Nothing generated sits in the path that has to stay reproducible, and the feature is opt-in per tenant: the operator registers the model provider and enables external routing tenant by tenant — until then the path is unavailable rather than degraded — or you never turn it on at all.

Dashboards that ship with a version number.

A dashboard is a tenant resource with a draft, a published version and a rollback — not a document someone edited at 2am. Build one against synthetic data before a single device exists, then point the same layout at a live fleet.

Embed them in your own application through the widget runtime, or hand people the standalone viewer with its own login and nothing else attached.

Point your BI tool at it. That is the integration.

Telemetry lands in TimescaleDB and stays queryable as SQL. A governed analytics schema exposes per-relation views with a per-tenant read role, so Metabase, Grafana, Power BI, a notebook or plain psql connect straight to it. No export job, no second store to keep in sync, nothing extra to license.

Tenant isolation is enforced inside the database rather than by the application in front of it — grants plus a tenant predicate keyed on the connecting role — because a BI tool arrives over the Postgres wire and never passes through our API at all.

Read-only by construction

A per-tenant role with select on its own views and nothing else. Opt-in per instance.

Or use the API

GraphQL for applications, SQL for analysts, and the same rows underneath both.

One API, and a door built for agents.

The platform is addressed through per-area GraphQL schemas behind one authenticated surface, with published client SDKs for TypeScript and C# — the latter built to stay usable under AOT, so it works inside Unity as well as on a server.

There is also a read-only Model Context Protocol surface, so an AI agent can inspect devices, state, telemetry, alarms and commands. It carries the caller's own token rather than a service account: an agent can never see more than the person operating it.

GraphQL

Per-area schemas behind one authenticated surface.

SDKs

TypeScript and C#/.NET, plus a Unity package you build from source.

MCP

OAuth 2.1 resource server, read-only in 1.0, scoped to the user's own tenant access.

No Redis. No Zookeeper. No Elasticsearch.

It runs on PostgreSQL and NATS — TimescaleDB for telemetry, and NATS for both messaging and the coordination that usually drags a cache into the diagram. Run it on your own cluster with a Helm chart and a Kubernetes operator, or bring the whole thing up on a laptop. Multi-tenancy is enforced in storage and messaging, not by giving every tenant its own pods.

Device inventory, live device state, two-way command dispatch and hard tenant isolation are defaults rather than premium SKUs — Apache-2.0, no open-core split, no per-device metering.

Monitoring comes up with it: a bootstrap installs Prometheus, Grafana and the alert rules for the platform's own signals, so the first thing you see is whether it is healthy. Disaster recovery and the high-availability behaviour are drilled against a live cluster rather than described — including a restore that has to decrypt real secrets on the other side to count as passing.

The unglamorous half.

The parts nobody puts on a homepage, which are the parts you need in the second month.