Skip to content
Docs

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 HydroScope 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 HydroScope 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.

Sensors that need a type

Section titled “Sensors that need a type”

Not every sensor arrives with its profile already chosen. A device auto-provisioned by ingest — one that starts sending uplinks before anyone enrolled it by hand — has no profile picked for it, so HydroScope works out its type from the data itself. There are three outcomes, and a sensor’s badge on the Sensors screen tells you which applies:

  • Typed — a profile is confidently bound (you picked it at enrolment, or a match was confirmed). Uplinks decode normally; no badge.
  • Auto-typed — HydroScope matched the sensor’s payload fingerprint to exactly one registry profile and adopted it automatically. The sensor is already decoding, but the match is unconfirmed — a quick check locks it in. Carries an Auto-typed badge.
  • Needs a type — no confident match, so HydroScope declines to guess. The raw uplinks are kept, but nothing decodes into readings until it’s typed. Carries a Needs type badge.

The fingerprint match is deliberately strict: a profile only qualifies when every field its metric map expects is present in the payload as a number, and HydroScope adopts one only when exactly one profile qualifies. If several fit (an ambiguous payload) or none do, the sensor stays untyped rather than decode into the wrong units — a wrong codec is worse than a missing one.

Resolving an untyped or auto-typed sensor

Section titled “Resolving an untyped or auto-typed sensor”

You resolve the type from the Sensors screen — see Set or confirm a sensor’s type. Set a type on an untyped sensor by picking its model; confirm an auto-typed one, or override it with a different model. Either way HydroScope rebuilds that sensor’s history under the chosen profile: every raw uplink it has already sent is re-decoded, so past readings appear as if the right codec had been in place all along. (Confirming an auto-type it’s already using changes nothing to decode, so there’s no rebuild.)

If no model in the picker matches your hardware, its profile hasn’t been added to the registry yet — which is the same registry constraint the next section describes.

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 HydroScope deployment to have it provisioned.

Section titled “Related”