encodeDownlink() capability limitations?

TTN Network and Services The Things Stack v3
1

During testing I have noticed limitations or perhaps I am not referencing the data correctly.

I am attempting to send configuration changes to a device. The data begins as key value pairs in JSON format. The encodeDownlink() function transforms the JSON data and adds a “frm_payload” item to the message. The device I am working with needs to receive key value pairs to know which setting to change. In testing, the function appears to be able to only encode the value of the key value pair.

As an example, if is send the function {“CycleTime”: 1800} and use input.data.CycleTime to access the data the function encodes only 1800 into the “frm_payload” item. The 1800 alone is meaningless to the device.

{
  "f_port": 1,
  "frm_payload": "CA==",
  "decoded_payload": {
    "CycleTime": 1800
 }
}

In addition, I have tried to send {“CycleTime”: “\”CycleTime\”: 1800”}, {“CycleTime”: “{\”CycleTime\”: 1800”}}, and other variations. Whenever the value contains anything other than an integer or float the function encodes zero. It adds the information to the “decoded_payload” section properly, but “frm_payload” contains zero.

{
  "f_port": 1,
  "frm_payload": "AA==",
  "decoded_payload": {
    "CycleTime": {
      "CycleTime": 1800
    }
}
}
2

There is a strong consensus that sending any form of text based payloads isn’t a good thing - forum search will flesh this out, but basically it’s highly inefficient.

So the encoder isn’t setup to do anything like converting JSON in to, er, JSON.

You either need to construct the whole byte array as your device needs it or you use a far preferable set of binary data structures. Whilst it’s not great, CayenneLPP allows you to tag data, that may be a starting point.

3

  1. Please use </> formatting next time you post code or json for readability.

  2. Most devices I know do not require json to be sent to the device but key value pairs in form of a byte for the key and depending on the key one or more bytes values. Do your devices really require json in the downlinks?

4

  1. Thanks for the formatting assistance.

  2. The device does not require JSON. It accepts bytes. But the bytes must be a key and a value. The value alone has no meaning to the device. The reason for starting with key value pairs is for human readability of configuration items in the device twin. We hope to store and make changes to the desired section of the device twin.

"properties": {
        "desired": {
            "decodedPayload": {
                "CycleTime": 1100
            }
            }
            }

There are many items configurable by download, so the device needs to know which setting or settings to change. This is the premiss of the topic. I wanted to know if there is a way to include more data in the “frm_payload” field.

5

You can put anything you like in to the payload any way you like as you have to return a byte array.

Not being a standard, this could be anything, a before and after example would be beyond exceptionally useful.

I wonder if you looked at the CayenneLPP format?

6

Is "CycleTime" the important part of the message?

Then make “CycleTime”= 1 and sent that as a byte. Then on the other side you know 1 = “CycleTime”

Build a dictionary were words or phrases are represented by numbers.

7

Yes there is, however you will need to provide code to encode the key and values yourself, there is no way TTN can know which key has which byte value and how many bytes the value need to be encoded as. So you’ll need to write JavaScript to translate the json to an byte array yourself. (Or do it in an other language at your side before posting the value to TTN)