Payload formatter not added to integration JSON

Application Development
1

I have a node that is sending a simple value of 90.

I have a decoder that is the most basic possible:

function decodeUplink(input) {
  return {
    data: {
      bytes: input.bytes,
      f_port: input.fPort
    },
    warnings: [],
    errors: []
  };
}

When I test it in the payload formatter tool, the output is as follows:

{
  "f_port": 1,
  "frm_payload": "JgsVMw==",
  "decoded_payload": {
    "bytes": [
      38,
      11,
      21,
      51
    ],
    "f_port": 1
  },
  "rx_metadata": [
    {
      "gateway_ids": {
        "gateway_id": "test"
      },
      "rssi": 42,
      "channel_rssi": 42,
      "snr": 4.2
    }
  ],
  "settings": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 7
      }
    }
  }
}

However in the uplink message on both MQTT and via Webhooks, the uplink_message field has neither the f_port nor the decoded_payload fields as documented at Data Formats | The Things Stack for LoRaWAN

{
  "end_device_ids": {
    "device_id": "<DEVICE_ID>",
    "application_ids": {
      "application_id": "<MY APPLICATION>"
    },
    "dev_eui": "<DEV_EUI>",
    "join_eui": "<JOIN_EUI>",
    "dev_addr": "<DEV_ADDR>"
  },
  "correlation_ids": [
    "as:up:01GH4SXZXHT5JMQ2DKKM4G8VEV",
    "gs:conn:01GH4NPAEM49XY2TE912SVF2WY",
    "gs:up:host:01GH4NPAEWH6TBZYQTFT8E0DNS",
    "gs:uplink:01GH4SXZQ3AKNN1YXXM9TZVVZ6",
    "ns:uplink:01GH4SXZQ41K8H2185J0RMWXT9",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01GH4SXZQ48QS27WFGWEPNA632",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01GH4SXZXGZA1P06GYMZGDDS1G"
  ],
  "received_at": "2022-11-05T21:07:47.760681222Z",
  "uplink_message": {
    "session_key_id": "<SESSION_KEY>==",
    "f_cnt": 7,
    "rx_metadata": [
      {
        "gateway_ids": {
          "gateway_id": "<GWID>",
          "eui": "<GWEUI>"
        },
        "time": "2022-11-05T21:07:47.526207923Z",
        "timestamp": 149241811,
        "rssi": -70,
        "channel_rssi": -70,
        "snr": 9,
        "uplink_token": "<TOKEN>",
        "received_at": "2022-11-05T21:07:47.528937388Z"
      }
    ],
    "settings": {
      "data_rate": {
        "lora": {
          "bandwidth": 125000,
          "spreading_factor": 7,
          "coding_rate": "4/5"
        }
      },
      "frequency": "868100000",
      "timestamp": 149241811,
      "time": "2022-11-05T21:07:47.526207923Z"
    },
    "received_at": "2022-11-05T21:07:47.556263882Z",
    "confirmed": true,
    "consumed_airtime": "0.041216s",
    "version_ids": {
      "brand_id": "heltec",
      "model_id": "wifi-lora-32-class-a-abp",
      "hardware_version": "_unknown_hw_version_",
      "firmware_version": "1.0",
      "band_id": "EU_863_870"
    },
    "network_ids": {
      "net_id": "000013",
      "tenant_id": "ttn",
      "cluster_id": "eu1",
      "cluster_address": "eu1.cloud.thethings.network"
    }
  }
}

Any idea why this might be?

2

It only works with values of 42 or 69 (dude).

I’ll power up my WOPR in the morning and give that decoder a test - the JS interpreter has shown a few edge case foibles so it may respond strangely to there not being any actual code.

3

:joy:

Cheers!

It’s just a bit odd that the field isn’t there at all - I’d at least expect it to be an empty dict, but it’s just completely absent!

4

Google Protocol Buffers has a “feature” of not including things that are null or empty or zero - but you are sending 90, so there should be at least one byte …

1 Like
5

Are you certain your node is sending 90 in the payload?

As if I test it

{
  "f_port": 1,
  "frm_payload": "Wg==",
  "decoded_payload": {
    "bytes": [
      90
    ],
    "f_port": 1
  },
  "rx_metadata": [
    {
      "gateway_ids": {
        "gateway_id": "test"
      },
      "rssi": 42,
      "channel_rssi": 42,
      "snr": 4.2
    }
  ],
  "settings": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 7
      }
    }
  }
}

image
image1121Ă—430 14.5 KB

1 Like
6

@proffalken What are you seeing in the application console live data for the node?

1 Like
7

Using handy Adafruit Feather M0 with RFM95 + LMIC 4.4.1.

From the console:

    "received_at": "2022-11-06T14:18:03.368783834Z",
    "uplink_message": {
      "session_key_id": "AYRNTiYioZVSJufW7dLRnQ==",
      "f_port": 1,
      "frm_payload": "Wg==",
      "decoded_payload": {
        "bytes": [
          90
        ],
        "f_port": 1
      },

From my webhook PHP to Tab - which also saves the JSON for debugging:

  "received_at": "2022-11-06T14:18:03.368783834Z",
  "uplink_message": {
    "session_key_id": "AYRNTiYioZVSJufW7dLRnQ==",
    "f_port": 1,
    "frm_payload": "Wg==",
    "decoded_payload": {
      "bytes": [
        90
      ],
      "f_port": 1
    },

So not sure what’s going on - maybe a stray character in the JS is doing something - I copied and pasted your PF above.

[Std note about use of confirmed uplinks inserted here]

8

I have been an absolute idiot…

There was a “payload” coming through on the message, but the payload itself was null so there was nothing to forward on.

I’ve updated my function in my C++ code to actually load the data from the sensor into the payload, and surprise surprise it’s all working.

Sorry to have wasted all your time - is “make sure your payload is actually being sent” the LoRaWAN equivalent of missing a semi-colon off a line? :joy: :cry:

9

No worries, happens to the best of us, only takes a minute or so with the test rigs I have, I’m just really lucky thus far with not going public with my own foobars.

2 Likes
10

Great you have found the issue, :+1: I thought it were something small. Happy coding.

2 Likes
11

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.