Sending "cooked" JSON data to AllThingsTalk

I am using a Tektelic sensor that send binary data to TTN, and then on to AllThingsTalk. I have a Javascript program (in the “decoder” tab) that parses the raw data and makes it available as a JSON object, and the TTN stuff parses that JSON just fine.

However, when I send that data on to AllThingsTalk, TTN sends the binary data rather than the JSON object. I have played around with the “converter” tab, but it does not seem to have any impact on the data sent to AllThings talk. Am I missing a dialog box somewhere?

Thanks in advance
Bill VerSteeg

Hi Bill,

maybe you will find the answer here
By default ATT does not use JSON as payload format in their applications. I quote from that page:

One of the payload formats Maker understands is CBOR. The message format which AllThingsTalk uses for CBOR is {"<asset name>": <value>} .

On the other hand, here you can find more info about their data formats and here about how to use their LorawanKit.

Let us know if you can sort it out.

I think most, if not all, integrations do not use the output of any Decoder at all. TTN Console might still show it, in which case it might help during debugging. But to make AllThingsTalk use the device’s specific binary encoding, I think one should do the decoding in their platform, which I think they call “Use ABCL to convert custom binary data”. The March 2018 AllThingsTalk ABCL definition for decoding TTN payload might help.

As an aside: I’d not use CBOR. That is just a waste of bandwidth. Like the documentation of the AllThingsTalk Maker integration states:

You typically want to use a binary data format because of the limited payload size which are inherent to LPWAN networks such as LoRaWAN.

But even the binary CBOR just requires too many bytes for just a simple value. Like in this example:

In RDK example, your temperature sensor reads 23 degrees Celsius, and you’d like to see that value in Maker. You can use to convert the payload to CBOR, e.g,

{"temperature": 23} translates to A1 6B 74 65 6D 70 65 72 61 74 75 72 65 17

While the plain text {"temperature": 23} would be 19 bytes, the above CBOR’d version is still 14 bytes for a single integer value!

Even when using {"t": 23}, you’d still get 4 bytes for A1 61 74 17. A fixed position encoding, with an unrealistic temperature accuracy of 2 decimals, would allow for -327.68 thru 327.67 in just 2 bytes.

Adding a decimal in CBOR, {"t": 23.5} yields 6 bytes in A1 61 74 F9 4D E0. But other values might go crazy, like {"t": 23.4} yields the whopping A1 61 74 FB 40 37 66 66 66 66 66 66. Play around with before considering using CBOR.