Downlink via mqtt using the object field fails


i can succesfully send downlink messages to a device (e.g. an adeunis field tester) using the data field:

let data = {
    "confirmed": true,
    "fPort": 25,
    "data": "aGFsbG8="

however, when using the object field, I receive an error:

let data = {
    "confirmed": true,
    "fPort": 25,
    "object": {

the codec in the device profile ignores the object:

function Encode(fPort, obj) {
  	return [225, 230, 255, 0];

the loraserver reports in its logfiles:

level=error msg=“handle data-down payload error: no or invalid codec configured for application” application_id=7 dev_eui=[mydeviceid]

the application reports in the app-server the following:

  • error:“no or invalid codec configured for application”
  • type:“CODEC”

both messages are send to [...]/application/7/device/[mydeviceid]/tx

I do not receive an error on the mqtt topic application/+/device/+/error

Do you have any idea what might be going wrong here? Is the forum the right place to ask this question or shall I better refer to github?


1 Like

The first message work fine beacause you send your data in base64 “data”: “aGFsbG8=”.
you should use function that’s encode everytime your data on base64 and after send it by mqtt.


according to the (documentation, I should be able to send downlink messages through mqtt either as base64 encoded data or - and that is what is not working for me - by providing an object, which will then be encoded in the application server to base64…

However, that’s where I receive the above mentioned errors

1 Like

I believe that this is a bug that I ran into that I’ve been meaning to report it :roll_eyes:

I saw a similar issue on version 3.0.0. It seems that the codec was moved to the device profile yet lora-app-server was still looking for it on the application. It completely ignored the codec in the device profile in my experience. I’m using 3.0.1 now but I haven’t tested if it works appropriately now or not.

One of my applications didn’t have the codec field under application configuration and the other did. When applications are created via the api it adds the codec field back to the application on the web gui.

What I did was use the api to update the application. Go to the api and use the PUT and update your codec there.

It’s labeled

You can leave string there in the codec fields and it’ll add the codec screen back to the application. Once I did that my application decoded properly.

Don’t forget to fill in name and description with the correct information. If you don’t it’ll just say string and overwrite your current application name and description.


I submitted a bug for this:


I am using LoRaServer 3.0.1 and recently faced the same problem as OP: When utilizing custom Javascript codec functions defined in “Device profile”, the server was unable to encode the payload when the “object” field was provided instead of the “data”, resulting with “no or invalid codec…” The Decode function, on the other hand, worked well.

I have tried to work this around as suggested by @bryansmith. The codec dropdown list is now present when creating new application in LoRaServer. When I provide a valid code, functions are doing their job and there are no error messages.