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.
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 cbor.me to convert the payload to CBOR, e.g,
{"temperature": 23}translates toA1 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 http://cbor.me/ before considering using CBOR.