fPort missing in Javascript Codec in encodeDownlink input (v5.14 to v5.15)

Viewed 41

Hello everyone,

We recently updated our ChirpStack server from version 5.14 to 5.15 (using the JavaScript Codec for downlink encoding). Following this update, we encountered an issue where input.fPort is now undefined within the encodeDownlink(input) function.

In version 5.14, we successfully used the fPort to determine the encoding logic, like this:

function encodeDownlink(input) {
  switch(input.fPort) {
    case 3:
      return encodePort3(input);
    case 4:
      return encodePort4(input);
    case 10:
      return encodePort10(input);
    case 20:
      return encodePort20(input);
    default:
      return {
        bytes: [0, 0],
      };
  }
}

Observations in v5.15: After debugging the input object in the new version, we found only two fields:

variables: (Currently empty).

data: Contains the JSON object we want to encode.

The fPort field is completely missing from the input object. We could technically add the port manually inside the JSON payload, but this would require significant changes to our existing integrations and API calls.

Our questions:

Is the fPort still accessible from the encodeDownlink function in v5.15? If so, what is the new path or variable name?

Has the signature of the input object changed recently?

Is there updated documentation available for the JavaScript codec specifically for these versions?

Any guidance on how to retrieve the target fPort within the encoder without modifying the payload would be greatly appreciated.

Thank you for your help!

1 Answers

EDIT: ignore my previous answer, this is about the encode part. Please refer to the Payload Codec API specification:

image.png

Before ChirpStack v4.14.1, ChirpStack was (incorrectly) taking the given fPort, however, it should be returned by the encodeDownlink function based on the provided input. I think this is the difference you are seeing.

I am not sure to understand. This means that since v4.14.1, the variable fPort is not accessible at all inside the encodeDownlink() function ?

That is correct. It shouldn't have been. ChirpStack follows the Payload Codec API as specified by the LoRa Alliance, which specifies that based on the input data, the codec must decide the downlink fPort.

OK understood thanks !