Is a Spark.publish string limited to 622 bytes?

Hello All,

I am searching this forum quite a while but have not found the answer:

is a string I publish thru


limited to the same maximum length of 622 bytes as a string

Spark.variable("DUMP_VAR", publishString, STRING);


@MarkusL, actually it is limited to 63byte
Look in the docs here

Thanks - that is even worse :frowning:
How would I publish for example 1500 bytes of data? Would i have to cut it up into 3 chunks of 500 bytes each and use

Spark.variable("DUMP_VAR", publishString, STRING);

What is the best practice here?

Where do you want to send this data to?

If you will be needing the data in or round about the same subnet as your Core is, try TCPClient/TCPServer or UDP, but beware of some little issues (discussed all over the forum ;-))

Otherwise you may well go the Spark.variable() route and if you have a lot of time (aprox. 30sec) you could even send 63byte junks via Spark.publish() but only one junk per second :worried:

What kind of data do you want to transfer?

I want to send the data to a mobile app drawing a graph. The data is recorded sensor data (1 per minute) that will be stored in the core for 24 hours -> 60*24 = 1440 bytes
The app should work in any network, not only the local.

That’s some data :wink:

Sure the Spark.variable would then be a possible way - maybe even three variables for an eight hour block each.
But I wouldn’t necessarily dismiss the TCP/UDP route either. If you’ve got the possibility to reach your Core globally (e.g. DynDNS) you could have your Core run a TCPServer or even a Webduinio
Or you could push the data to another server (via TCPClient) from where you’ll pull it into your phone.
There are some threads about that do deal with similar demands to yours - have a search :wink:

Some results with search for graph

and lots of others

1 Like

I just realized that the data I have to send is not an ASCII string, if it contains zeros then it will truncate the string and not send all the rest in that array. So either I have to sacrifice the zero or choose another way. This feels kludgy.
Using the TCP/UDP server seems like a giant overkill thats eating up lots of resurces.

If you are not building a project that will need the given resources for its own functionality there is nothing wrong in using these resources instead of having them lay around unused :wink:
It might seem overkill, but it’s not that gigantic really.

But if your use case calls for it, got for it instead of making up workarounds (e.g. zero substitution go shoehorn binary data into a string variable).