Documentation on device `DescribeReturn` COAP


I’m sending a Describe message over COAP with data that looks like this:
41 01 72 2c 01 b1 64

The response coming back is this:

{ p: 6,
   [ { s: 16384, l: 'm', vc: 30, vv: 30, f: 'b', n: '0', v: 7, d: [] },
     { s: 262144, l: 'm', vc: 30, vv: 30, f: 's', n: '1', v: 102, d: [] },
     { s: 262144,
       l: 'm',
       vc: 30,
       vv: 30,
       f: 's',
       n: '2',
       v: 102,
       d: [ { f: 's', n: '1', v: 102, _: '' } ] },
     { s: 131072,
       l: 'm',
       vc: 30,
       vv: 30,
       u: '2BA4E71E840F596B812003882AAE7CA6496F1590CA4A049310AF76EAF11C943A',
       f: 'u',
       n: '1',
       v: 2,
       d: [ { f: 's', n: '2', v: 1, _: '' } ] },
     { s: 131072, l: 'f', vc: 30, vv: 0, d: [] } ] }

The main thing I’d like to do is get the function names.
This format is also different from the old format where I was getting the function names so I don’t know how to do it.

There used to be a v property in the json that could get me the names.

Ok, I dug through the firmware source and figured out that in the later firmware versions the data from Describe gets sent in two events… Seems a bit weird to me but ok.

Anyone know the reason why this is? It seems like all that data could just be sent at once with the right flags set.

The first post as you shared contains information about the device itself. System and user firmware version which can be retrieved without a wifi connection.

I assume you are talking about Particle.function() which is only available when the Particle device connects to the :cloud: and then made available in the describe message


So in older firmwares when you made a COAP request with Describe it would return the functions and system info in a single message.

Now it sends two messages like this -

I think this pattern is not very intuitive and it really doesn’t make sense to me why there are two messages. If the send_description call was passed DESCRIBE_SYSTEM & DESCRIBE_APPLICATION it would return all the data in a single message.


Hi @Brewskey

I think at some of these types of questions could be better answered by looking at the GitHub issues that have been closed. Maybe looking there could save some time in the future. I found this one quickly by looking for issues with the word “describe” in the title.

In this case, this change seems to have been made to support Electron over UDP and there is some discussion of the trade-offs in the issue:

1 Like

Thanks @bko.

It’s true that they changed the protocol.cpp to follow that pattern but not the spark_protocol.cpp. As the code stands right now it will just ignore any flags I pass.

Maybe you can share your use case and how this behavior is causing issues?

1 Like

Sorry, this is solved but it was very weird behavior. Even in that github issue they talked about 1 request 1 response.

Since the system and application data may be too large for the COAP packet, I would prefer to be able to pass flags and make two requests. You could keep the default implementation as you have now but also allow the spark protocol to work with the flags if they are passed in.