LoRaWAN Device Profiles and Payload Decoders

Three things in one place

What a Device Profile Contains

A profile is the definition of a device model, and it holds three separate things that are easy to confuse.

One function, run on every uplink

Writing the Decoder

The decoder is a single JavaScript function written to the standard LoRaWAN codec shape, the same one manufacturers publish alongside their hardware. If your vendor supplies a decoder, it will usually run here with no changes at all.

function decodeUplink(input) {
  // input.bytes    -> number[] of payload bytes
  // input.fPort    -> the LoRaWAN port the device used
  // input.recvTime -> a Date object, when the message arrived

  return {
    data: {
      temperature: input.bytes[0] - 40,
      battery_percent: input.bytes[1],
    },
    warnings: [],  // optional, surfaced in the device's Events tab
    errors: [],    // optional, marks the uplink as decode-failed
  };
}

Before a single device depends on it, test it against a real payload:

• 1
  Paste a hex payload and the port into the test panel.
• 2
  Run it.
• 3
  Read the decoded object and any warnings or errors it produced.

Four types, three behaviors

Fields: What Your Devices Produce

A field is a named value with a type. The type decides what can be stored and how it is validated; a second setting decides how the value behaves over time, which is what lets a chart roll it up correctly without you thinking about it.

How the value accumulates

For Number fields you also declare how the value accumulates, which decides what a chart does with it.

From a distance reading to a fill level

A Worked Example: Tank Depth to Percent Full

An ultrasonic sensor in the lid of a tank does not report how full the tank is. It reports how far away the liquid is. Turning one into the other needs a number the device does not know and cannot send: how far the sensor sits above the bottom.

Not every value arrives every time

Values That Do Not Arrive on Every Uplink

Plenty of devices report a state only when it changes. A valve sends open, then says nothing for a week. Handled naively, a dashboard looking at the last hour shows no data, and an operator concludes the device is dead.

Per device, not per profile

Correcting a Sensor That Reads High

Real sensors drift. That is a property of the individual unit, not of the model — which is why correction sits on the device rather than on the profile.

The other direction

Sending Commands Back to the Device

A decoder turns bytes from the device into fields. A downlink goes the other way: a command sent to the device. Define it once on the profile as a named template and it is available on every device using that profile.

What a command template holds

Five parts, defined once on the profile.

Start from something tested

The Manufacturer Profile Library

Most devices need no JavaScript at all. The library covers common sensors from major manufacturers, and starting from an entry gives you a working profile without writing a line of code.

The honest version

Writing Decoders Yourself Against Starting From the Library

Plenty of teams already decode payloads somewhere — in a Lambda, a middleware layer, or a script somebody wrote and left. Here is the same work, done both ways.