Particle Function max characters

Cloud
1

Hi!

I’m trying to pass JSON data into my particle function and I am routinely blowing past the 63 character limit for String passed into the function.

I can limit this value in my web app, but it would also be nice to have device-end validation. Right I have something more/less like this:

Particle.function("do-something", doSomethingHandler)
...
int doSomethingHandler(String response)
{
  Serial.println(response);
  return 1;
}

When I send too much data, the response that is outputted is that data that was last sent on the device. Even if it was from a separate function. How can I tell that the response is too large so that I can return -1 at the end of the function call?

Thanks in advance!

2

This doesn’t answer your question, but in 0.8.0-rc.4 the function argument size was increased from 63 characters to 622 characters, so you’ll have a lot more room for sending JSON data.

4 Likes
3

I’m pretty sure the cloud won’t send any parameter longer than allowed to the device nor would the Device OS accept (i.e. copy) any longer parameter, so the application will never see a too long response.
If you have a unique terminator character which only can appear at the end of your response, then you can check for its existence - if it’s not there, the response must have been too long (or you failed to send it - also being an error to report as e.g. -1 tho’).

2 Likes
4

@rickkas7: I'm pumped for 0.8.0-rc.4! I'll probably wait for the "stable" release, however. Looking forward to it. In the time being, I can manage the payload size and send a few smaller chunks of data. If we end up sending much larger chunks of code (over 622 chars), then this code will probably be helpful anyway. Is there any function rate limiting that I should be aware of as I pursue this method?

@ScruffR I was able to get a helpful response after all – so thanks for encouraging me to continue down that pay.

I’m pretty sure the cloud won’t send any parameter longer than allowed to the device nor would the Device OS accept (i.e. copy) any longer parameter, so the application will never see a too long response.

The device was never receiving a too long response, but it was sending me data that I had previously seen. Is this a bug? Should I report it?

5

Where would this response data come from?
Particle.function() only returns integers in response to a function call.

Or do you mean you got the same output from Serial.println(response); with only one call of the function?

6

@ScruffR sorry for not being clear. In the example that I gave (below), I am referring to the data passed to the function, response. When the String data was sufficiently short, the data was passed properly. When it was too long, the function would be triggered, and pass whatever data was previously passed to a function. So if I passed a 60 char string first, the handler would receive that data properly. If I then passed a 70 char string, the handler would receive the first 60 char string. I’ve now determined that I can receive an error on the app side of the function call, but on the device side, there is no error, just incorrect data.

Particle.function("do-something", doSomethingHandler)
...
int doSomethingHandler(String response)
{
  Serial.println(response);
  return 1;
}
7

If this is a reproducable problem, then this should probably be filed as an issue report

8

@ScruffR ok. Will do that when I get a chance!

Thanks for the help!

9

How sure are you that this actually went in?
I'm running firmware v0.8.0-rc.8 and latest released iOS SDKs and I'm getting:

Sending: {"tz":600,"dst":false,"off": 0,"sch": 14680071,"pump":3,"clean":6}
Calling func "setConfig" with "{"tz":600,"dst":false,"off": 0,"sch": 14680071,"pump":3,"clean":6}", length: 66
SendState err:  Error Domain=ParticleAPIError Code=1000 "Maximum argument length cannot exceed 63" UserInfo={NSLocalizedDescription=Maximum argument length cannot exceed 63}
10

Now that I think about it, I believe for the same reason that you can’t publish 622 bytes from the API yet, you may not be able to send more than 63 bytes in a function call either. Both changes require both a device firmware change and an API change, and the API side change hasn’t been deployed yet.

11

So I’m not insane which is nice to know. :wink:

Any idea when this is getting rolled out?
I’m not in a hurry for it, just curious.

Thanks for the reply.

12

Is the data you’re trying to pass, a lot longer than 63 bytes, or only a little longer? If only a little longer, you could send the data in a more compact format than JSON, if that’s an option. JSON is useful in that there are libraries for unpacking it, and it is a standard way to pass data, but it is not very space efficient.

13

Hi Ric.

I’ve alread compressed it down to under the 63 bytes hence why I’m not in a hurry.

However I can see that our data may grow in the future and so I’m curious about the ballpark timeframe for this fix, eg 2 weeks, 2 months, 2 years.

14

Is there a plan for when this will be deployed?