Payload formatters in v3

TTN V2 to V3 Upgrade Migrating Applications to V3
1

Hello, want to be sure of what I should do to migrate a v2 payload formatter in v3
V2 was basically no specific structure expected:

function Decoder(bytes, port) {
  var decoded = {};
  return decoded;
}

V3 seems to be different:

{
    data: {
      bytes: input.bytes
    },
    warnings: [],
    errors: []
  };

with data structure containing the previous payload.
I want to be sure I can put whatever I want into data and bytes presence is not mandatory.

2

Your post is a bit vague:

  1. It is not a question.
  2. You show the input parameters of the V2 Decoder() function and then what appears to be the return part of the V3 decodeUplink() function, these two are unrelated.

bytes is just an example (provided in the default template) of how to return the input.bytes data undecoded. You can return any elements in ‘data’ as needed.

V2: input parameters: ‘bytes’ and ‘port’
V3: input parameter: ‘input’ (input.bytes and input.fPort)

The default JavaScript decoder function template does not make clear that data.bytes is just an example and also does not mention input.fPort as example.

Please be more clear when asking for help.

3

Short answer is try it, nothing “bad” should happen - although if there is a mushroom cloud over Amsterdam, best close your browser.

I have a template to work on for a client for the decoder, just working on a Data Storage replacement for Swagger right now.

1 Like
4

although if there is a mushroom cloud over Amsterdam, best, clear your history & internet cache, then close your browser.

There FTFY :wink:

5

Cheers - but it occurs to me that if there is a big cloud of smoke over Amsterdam, they probably won’t care.

6

Have a squint at the docs, they seem to cover much of everything: Javascript | The Things Stack for LoRaWAN

Including V2 decoders work in V3

7

Thank you for the details, I did not through my question was unclear at the point to take so much time to explain me how unclear it was … By the way, I’m trying to make a documentation to make the migration clear for all others.
My original question was:
What is the structure format the decodeUplink function is supposed to returned ?
is that :

{
    data: {
    },
    warnings: [],
    errors: []
  };

Or this structure is just and example ?

In the previous version there was no structure (this is why I printed the code, because no structure was a bit complicated to quote).

Thank you for other points I did not asked for but really useful to know.
Paul

1 Like
8

From the documentation:

The function takes an input object and returns and output object:

function decodeUplink(input) {
  return {
    data: {
      bytes: input.bytes
    }
  };
}

The input object has the following structure:

{
  "bytes": [1, 2, 3], // FRMPayload as byte array
  "fPort": 1 // LoRaWAN FPort
}

The output object has the following structure:

{
  "data": { ... }, // JSON object
  "warnings": ["warning 1", "warning 2"], // Optional warnings
  "errors": ["error 1", "error 2"] // Optional errors
}

and the example:

function decodeUplink(input) {
  var data = {};
  var events = {
    1: "setup",
    2: "interval",
    3: "motion",
    4: "button"
  };
  data.event = events[input.fPort];
  data.battery = (input.bytes[0] << 8) + input.bytes[1];
  data.light = (input.bytes[2] << 8) + input.bytes[3];
  data.temperature = (((input.bytes[4] & 0x80 ? input.bytes[4] - 0x100 : input.bytes[4]) << 8) + input.bytes[5]) / 100;
  var warnings = [];
  if (data.temperature < -10) {
    warnings.push("it's cold");
  }
  return {
    data: data,
    warnings: warnings
  };
}

I appreciate this seems a bit passive-aggressive as an answer and I’m sorry if our banter was out of place but we are all learning alongside each other here.

I’d interpret this as “the structure is not just an example, it’s how to do it”

9

Thank you it’s clear and exactly what I was looking for,
I did not found the documentation on my own.
(A link in the ttn-v3 portal could be really nice)

@descartes - passive/agressive what not targeting you.

10

I meant me being passive-aggressive by directly quoting the docs, which, BTW, are linked at the bottom right of the console.

Thanks for all the work on your website, one of my goto resources.

11

You were not, Thank you for the tips on documentation link, I’ve spent 2 hour in front of it and not saw it :wink:

12

I know what you mean, I spent the afternoon putting a starter web interface on the Data Storage - I now speak basic TTI API documentation - took me over an hour to join up all the dots between the API docs, the subtle difference in the URL for data storage and what the web console sends as requests.

As I said, early days but plenty of updates in the last fortnight from TTI, so we are getting there.

13

Please also note the following on the documentation page,
which is about the optional additional elements errors and warnings:

Warning:

If an error is present in errors , the payload is invalid and the message will be dropped. Any warnings in warnings are informative.

1 Like
14

Is there a way to get “received_at” string into the decoder??

Thanks

15

Not directly, all you get passed in is the payload and port.

But you may be able to synthesis this using a JavaScript date function.

received_at will be in the meta data of any outgoing integration or data storage.

16

3 posts were split to a new topic: Payload formatted V3 (from V2)