Core concepts

The platform models everything you monitor with a handful of objects that nest inside one another. Understand how they relate and the rest of the docs falls into place.

The object model

A measurement always traces back through the same chain: an organization owns devices, a device has components, a component exposes sensors, and a sensor produces readings.

Device

A Device is the unit you provision and manage — a gateway, a sensor node, or a virtual stand-in. It has a name, a status, optional location and tags, and belongs to exactly one organization. A device is the thing that comes online and reports; on its own it doesn't say what it measures — that's what its components describe.

Component

A Component is an addressable sub-unit of a device. One physical device often contains several: a gateway might carry a sensor-node component, a reference-instrument component, and a weather component. Each component is bound to a SensorProfile, which is what gives its data meaning — the fields it reports, their units, and their valid ranges.

This split matters: the device is the hardware you own, the component is a capability on it, and the profile is the contract for what that capability measures. Swap a component's profile version and you've evolved its schema without touching the device.

Sensor

A Sensor is a single typed data channel — temperature, current on phase one, a door's open/closed state. Each sensor has a value type that fixes how its data is stored and validated:

• DOUBLE — floating-point measurements
• BIGINT — integer counts
• BOOLEAN — on/off states
• TEXT — short string states

Sensors are created automatically as a device reports them, under the component they belong to.

Reading

A Reading is one timestamped value from one sensor. Readings are the raw material everything else is built on — they're stored in a time-series database, charted, alerted on, annotated, and exported. A reading is never stored loose: it's validated against its sensor's profile first, so what lands is always well-formed.

Putting it together

Take a small weather station as an example:

• The station is a device.
• It carries one component — an outdoor-weather module — described by a weather sensor profile.
• That component exposes several sensors: temperature, humidity, pressure.
• Every few minutes, each sensor produces a reading.
• Group several stations into a Site for a location, or a tag-based DeviceGroup, and they all live inside your Organization.

The same four-object chain models a distillery cask, a conveyor's drive motor, or a cold-chain truck — only the profiles change. That's what keeps the platform general-purpose: the objects are universal, and the use case lives in the pack that defines the profiles.

Beyond the chain

A few more objects organize and describe the core ones:

• Site and DeviceGroup group devices — by location, or by tag.
• DeviceProfile describes a whole device type: which components it carries and what's configurable.
• SensorProfile describes what a component measures.

Every object is defined in one line in the Glossary.