CBOR for CoAP payload format

Firmware
1

Great question! We've definitely had some interesting discussions internally about CBOR. It's not really applicable right now, but we may have uses for it in the future. Either way, you can be confident that our whole user experience goal with respect to things like payload format is to do the research, compare our options, make the hard decisions, and do the difficult implementation work so that you don't have to!

You can see all the CoAP code in the Device OS communication folder. Many of our messages don't even use the payload. Here's one example that does:

  • The cloud sends a function call CoAP message to the device, which is confirmable, so the device immediately responds with an ACK.
  • After the function runs in the user thread, a return value is available.
  • The device then sends a function return CoAP message where the payload is simply the 4-byte integer return value, no particular encoding (like CBOR) necessary.

I completely understand that the reason you're asking is for when you as a user publish data. To Particle, that data is an opaque string, where we have no idea the format of the underlying information. You are free to format it however you like, including CBOR, although to keep it a valid string (no null bytes, ASCII, so each char less than 128), you'd need to base64 or base85 encode that CBOR object.

2 Likes
2

Thanks for the detailed response.

Do I understand that the publish operation is using CoAP for transport but requires the payload to be ASCII encoded? If this is the case, it would be helpful (to keep the cell bills down) to provide a binary payload encoding which did not require the overhead of base64 or 85.

Major IoT initiatives, such as Open Connectivity Foundation, have taken the CBOR route. For RESTful IoT interfaces that can not stomach the overhead of HTTP/JSON text, CoAP/CBOR is a useful alternative.

Cheers

1 Like
3

Correct, and a binary payload option is a great suggestion. I'll discuss it with the team.

Keep in mind the downstream UX implications. Your firmware code would probably need to be less pretty and more C-like (e.g., passing buffer length argument), and other parts of the system could get strange — imagine watching the (otherwise all ASCII text) event stream output when binary garbage starts flooding your terminal, causing bells, control characters, and stray carriage returns. However, as long as this wasn't the default behavior, I can imagine experts like yourself benefitting from the functionality.

4

I just posted this issue in the Device OS repo:

5

Is there any one working on binary payload feature?

6

Any update on binary particle.publish support? This is a much needed feature.

7

@longtrail, I doubt there will be support for binary publish data any time soon, if at all. A way around this is to Base64 or Base85 encode your binary data prior to publishing.

1 Like
8

Thanks @peekay123, I’m looking for a lightweight method to transport protobuf encoded data across cellular connections.