Variable of string type


I understand that the variable function will expose a custom variable to the cloud.

Spark.variable("myvar", myvar, STRING);

So, in the example above, I can declare a my var string and get the value of it from a regular HTTP call.
What is the max length I can use in myvar?
Can I make it so it returns a complete jsonp string with about 1000 bytes of length??
Or am I barking the wrong tree?
Basically, I have about 200 variables that I’d like to be able to pull from the core on the fly in a single API call.
I can serialize them into a XML or JSON string and store it into a single string variable and expose that variable, can’t I?

Thank you in advance.


The docs don’t mention a max size. I guess you could just create a dummy string of about the same size you’d use, and see if it works. Seems the quickest way to find out if it’ll work. For more detailed info I guess we could ask @Dave, or @kennethlimcp.

I seem to recall that the max string length in a spark variable was on the order of 600 bytes… lemme look it up…

I was just looking it up :smiley:

640 - 2 - 16 = 622 bytes

Hmmm… this sounds like a need for documentation :stuck_out_tongue:

OK… just posted change to docs


Ah, you beat me to it! :slight_smile:


@Dave, is that supposed to create a PR cause I don’t see one. I see the changes but they have not posted yet.

I think since you have privileges to just commit straight into that repo, that it just went in directly. :slight_smile:

The Travis CI system takes a few minutes, but it should build and test your changes, and then deploy them when it’s done. (Edit: looks like the changes are there now :slight_smile: )

Thank you!

@roberto_imai If you can’t get a string long enough to serialize it, the way I have envisioned getting around the 4 variable limit is this:

Create an api-callable function that takes a string and returns a result. The string it takes is the variable name you want to get. Then the function can just do a switch-case or an if-then to return the appropriate variable.

Yes, it’ll require code to either translate your string on the fly into a variable, or else a lot of conditionals with returns manually coded, but I think it’d work. I haven’t tried it yet, but I wanted to offer a possible alternative.

I’d like to get all variables in a single call and not having to do 100 calls to get 100 values back.
I think I’ll just have to serialize in a long train of bytes without the json or XML formating characters and de-serialize on my android app. The only problem is that I have several variables that are bytes and int mixed up and de-serialization will require the length of the variable, which means, I need on byte to indicate size for each variable I’m sending and thus increasing the length of the payload, but I would still be under the 622 bytes.
So, here is how I think I have to do:
Variable 1: 0x40 (byte)
Variable 2: 0x0901 (int)
Variable 3: 0x14A3 (int)
Variable 4: 0xF5 (byte)

The return value of myvar would be: 01400209010214A301F5
The first byte is the length of the variable (01), so the next byte is the value of the variable (40).
The next byte would be the length of the 2nd variable (02), which is an int size, so the next variable value would be 0901
An so on.
Does it make sense? I’m pretty sure this would work, but is there a better solution?
This is what I’d like to ultimately send to the android app. Don’t get caught too much on the length of the payload right now. It does increase overtime as I add more stuff to the code.
XML formatted:


JSON formatted:


Anyone with any other thoughts?


@roberto_imai, if the number of vars, var data sizes and transmit order are fixed, then you don’t need to know the length of each var as it is implied in the order. :smile:

Yeah, but it is not fixed and it will grow overtime…
It used to be fairly short… About a dozen variables about 4 years ago and it just keeps growing as we keep adding more features.
I’m trying to port my product, currently in a ATMega2560 to spark, so we have the ability of remote access without the hassle of port forwarding, which is what everyone using my product right has to go through.
So, one day, I’ll eventually reach the 622 bytes and I’ll have to come up with a different solution for this… :frowning:

@roberto_imai, there will always be a limit to the maximum size of data that can be transmitted at once by the Core, primarily set by the CC3000. You may have to consider a different way of doing things like having the Core publish sections of data and having your Android app subscribe to the events and aggregate the full data. Pieces would be out of “sync” but data would be refreshed at regular intervals. You could also send only the changed data to reduce your payload size.

Another thing is that when your Android app first handshakes with the Core, they could first exchange the data structure. From that point on, the size and order of data is known.

You may want to consider data compression like RLE for example.

1 Like

Like @peekay123 said, I would define my own packed format and make the first byte be the version number of the packed format. That way you can write a smart parser on the other end that just knows what to do when it sees the results from any particular core.

1 Like