Skip to content
NereusDocs

Device Profiles

Sensors don’t speak metrics — they speak bytes. An Arad flow meter and a Dragino level sensor send completely different payloads, yet a Nereus dashboard binds to flow_rate_lpm and level_m without knowing or caring which vendor produced them. A device profile is the piece that bridges the two: it teaches Nereus how one vendor model’s decoded payload maps onto the canonical metric catalogue.

What a profile holds

Section titled “What a profile holds”

A profile is one row per vendor model. It carries:

  • Vendor and model — the identity shown in the enrolment picker (e.g. Arad · Gladiator).
  • A metric map — the decoder rules. Each entry names a field in the vendor’s decoded payload and says which canonical metric it becomes, with an optional scale factor for unit conversion.

A metric-map entry reads like this:

Payload field (vendor) Canonical metric Scale Result
volume_l water_volume_m3 0.001 litres → m³
pressure_kpa pressure_kpa — passed through as-is

The scale is applied once, at ingest, so everything downstream — storage, charts, rules — sees the value already in the catalogue’s unit. This is the normalization seam: device heterogeneity is absorbed the moment a payload lands, and nothing past that point has to know the sensor’s origin.

How enrolment binds a sensor to a profile

Section titled “How enrolment binds a sensor to a profile”

When you enrol a sensor, you supply its DevEUI and choose a profile from the picker. From that point on, every uplink from that DevEUI is decoded through the chosen profile’s metric map. Enrolment is keyed by DevEUI and idempotent — enrolling the same DevEUI again updates the existing sensor (adopting the right profile and metadata) rather than creating a duplicate, so a sensor that ingest auto-provisioned can be adopted cleanly.

Picking the right profile matters: it’s the difference between a payload decoding into structured readings and decoding into nothing (or the wrong units). The picker only offers profiles that already exist in your organisation’s registry.

Profiles are registry-managed, not a UI screen

Section titled “Profiles are registry-managed, not a UI screen”

There is deliberately no “create a device profile” button in the app. Profiles are managed as part of the device registry / configuration — decoders and their metric maps are engineering artefacts that need to match a vendor’s payload spec exactly, so they’re provisioned centrally rather than hand-typed in a form. The enrolment picker selects from existing profiles; it doesn’t author new ones.

So if you’re enrolling a sensor model that isn’t in the picker, the fix isn’t a settings toggle — the profile for that model needs to be added to the registry first. Reach out to whoever administers your Nereus deployment to have it provisioned.

Section titled “Related”