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?
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 - #7 by eivholt might help.
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 cbor.me to convert the payload to CBOR, e.g,
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 http://cbor.me/ before considering using CBOR.