Downlink packet using Rest API: how to set jsonObject correctly

I am having issues sending a downlink packet from the application server to a node. I am using the Rest API page. I have been able to successfully login, generate a token, and delete downlink queues. I am trying to queue some downlink packets to nodes but I cannot get the Curl command to work.

Using the /api page I entered

  "deviceQueueItem": 
 {
    "confirmed": true,
    "data": "eyJ0ZW1wZXJhdHVyZSI6IDIyLjV9",
    "devEUI": "89f87eee857fab51",
    "fCnt": 0,
    "fPort": 1,
    "jsonObject" : "string"
  }

and get the response

{
  "error": "unknown codec type: ",
  "code": 2,
  "message": "unknown codec type: ",
  "details": []
}

I know the jsonObject is not set correctly. However, I cannot find any examples on how to set this. I have gone into the device profiles and tried adding a codec but I have no experience with javascript and Rest. All I want to do is send down a stream of bytes with no encoding (other than base64). My marshaller is set to json as well.

Is there any example that shows how to set the codec for the device profile, and then using the Rest api to queue a downlink packet to a node.

I have also tried installing chirpstack-api but the grpcio fails to install because I am running out of memory on my Raspberry Pi.

Thank you in advance,
Tyler

Do you use these methods to get your results? There’s an example under “DeviceQueueService”. I’m not familiar with this approach; do you use it from website/PHP?

There’s an example in this forum question.

Q: Does the device profile of your device contain a valid CODEC?

Please use </> to specify that your JSON is preformatted (when composing message), so it doesn’t get mangled.

Compare:

Correct:

{
  "confirmed": true,
  "data": "AQI=",
  "devEUI": "47ab41f2002a0046",
  "fPort": 28,
  "jsonObject":"{\"Data\":[1,2,3]}",
  "reference":"qwer"
}

versus

Wrong:

{
“confirmed”: true,
“data”: “AQI=”,
“devEUI”: “47ab41f2002a0046”,
“fPort”: 28,
“jsonObject”:"{“Data”:[1,2,3]}",
“reference”:“qwer”
}

Sorry about the formatting! I have fixed it so it is more readable.

@fmgst I am using those methods to get my results. I am using the example under the “DeviceQueueService” and pressing the “try it out!” button. Once I do get a successful response I will use the Curl command given and convert it into a python script that uses the requests library.

I have looked at that example before, but the issue is I do not know how to translate that definition of the jsonObject into valid CODEC for the device profile. My nodes will be custom and their CODEC are not defined yet. What I am trying to determine is how to set a valid CODEC on the device profile and then how to set the jsonObject correctly.

For context of my application:
My gateway will be off grid that uses satellite to send and receive packets. I will be powering down the gateway at specific intervals to conserve as much power as possible so I want to be able to sync up the nodes so they are transmitting when the gateway is powered up. Satellite data can get expensive so our clients want to be able to transmit a few times a day, but ramp up sampling when “events” occur (which is why we can’t just set a static period).

Is there any example that shows how to set the codec for the device profile, and then using the Rest api to queue a downlink packet to a node.

I can’t help further - you should speak the big man’s name: @brocaar can you help?

our clients want to be able to transmit a few times a day, but ramp up sampling when “events” occur (which is why we can’t just set a static period).

Have you considered programming your sensors to report under and over “threshold” messages, to reduce data usage? Page 16 of this LoRaWAN node design reference recommend this approach. Several of my sensors from radiobridge use this and it works well - see page 8 of this manual for RBS301-TEMP-EXT-US.

@fmgst @brocaar I was able to figure out my issue. I am able to transmit with the following with removing the jsonObject and choosing no CODEC

{
  "deviceQueueItem": {
    "confirmed": true,
    "data": "eyJ0ZW1wZXJhdHVyZSI6IDIyLjV9",
 "devEUI": "536f6c6172613031",
    "fCnt": "0",
    "fPort": "1"
  }
}

The issue was that my device that I was using was not connected at the time and I was receiving the following error response

{
  "error": "enqueue downlink payload error: get next downlink fcnt for deveui error: rpc error: code = NotFound desc = object does not exist",
  "code": 13,
  "message": "enqueue downlink payload error: get next downlink fcnt for deveui error: rpc error: code = NotFound desc = object does not exist",
  "details": []
}

I was interpreting this as the jsonObject was not defined which was not correct. This led me to believe that I needed to use a CODEC and over complicate my issue. The error actually meant that I could not assign the fcnt to the deveui (I know if explicitly says in the error code). From there I determined that I need the device activated (joined) to the network. After joining I tried sending the above without a jsonObject and got the same issue as this post.

After sending an uplink with my node I was able to queue a downlink and get the 200 response code.

I did this 4 times and then checked the response from the get command and got the following response:

 {
  "deviceQueueItems": [
    {
      "devEUI": "536f6c6172613031",
      "confirmed": true,
      "fCnt": 0,
      "fPort": 1,
      "data": "eyJ0ZW1wZXJhdHVyZSI6IDIyLjV9",
      "jsonObject": ""
    },
    {
      "devEUI": "536f6c6172613031",
      "confirmed": true,
      "fCnt": 1,
      "fPort": 1,
      "data": "eyJ0ZW1wZXJhdHVyZSI6IDIyLjV9",
      "jsonObject": ""
    },
    {
      "devEUI": "536f6c6172613031",
      "confirmed": true,
      "fCnt": 2,
      "fPort": 1,
      "data": "eyJ0ZW1wZXJhdHVyZSI6IDIyLjV9",
      "jsonObject": ""
    },
    {
      "devEUI": "536f6c6172613031",
      "confirmed": true,
      "fCnt": 3,
      "fPort": 1,
      "data": "eyJ0ZW1wZXJhdHVyZSI6IDIyLjV9",
      "jsonObject": ""
    }
  ],
  "totalCount": 4
}

@fmgst I appreciate your quick response and trying to help with this issue! I will look into that node design and see what I can use for my own implementation.