Strings: Variable types, manipulation, and printing (HOW?!)

There seems to be some discrepancy between methods for manipulating strings on the Spark Core. My current goal is to print a JSON formatted object using an API GET call in order to pass some information out to a server. This seems to be harder than expected:

1 - sprintf() for multiple variables seems to not play nice with the core, resulting in 400 errors or refusing to flash. (link)

Example sprintf statement that fails (with extra casting):

sprintf(output, "{ temperature:%d, humidity:%d, fail:%d }", (int) intTemperature, (int) intHumidity, f);

2 - The String variable type doesn’t print properly. Code:

String test = String(millis(),(unsigned char)DEC);
void setup(){
  Spark.variable("testString", &test, STRING);
void loop(){
  test = "testing"; // commenting this line doesn't seem to affect API results

API Results:

  "cmd": "VarReturn",
  "name": "teststring",
  "TEMPORARY_allTypes": {
    "string": "�$",
    "uint32": null,
    "number": null,
    "double": null,
    "float": null,
    "raw": "�$"
  "result": "�$",
  "coreInfo": {
    "last_app": "",
    "last_heard": "2014-01-06T01:58:45.390Z",
    "connected": true,
    "deviceID": "xxx"

Typical Arduino string manipulation via concat() or += along with casting variables to String(var) does not seem to alter these API results either.

Has anyone else found a way to manipulate chars or String variables?

Turns out that this may be a core bug:

I was trying to find alternate ways of doing your multiple variable sprintf() and figured out the greater than 9 chars issue you linked above… however, here’s my crazy attempt to find another way for the heck of it:

double t = 22.69;
double h = 35.67;
int f = 0;
char temp1[64];
char temp2[64];
char temp3[64];
char output[128];

void setup() {
  Spark.variable("read", &output, STRING);

void loop() {
  t += 0.01;
  h += 0.01;
  (f) ? f=0 : f=1; // toggle f
  // sprintf(output, "{ temperature:%.2f, humidity:%.2f, fail:%i }", t, h, f);
  // a really bad way to do the above line...
  sprintf(temp1, "%.2f, ", t);
  strcpy(temp3,"{ temperature:");
  strcat(temp3, temp1);
  sprintf(temp1, "%.2f, ", h);
  strcat(temp2, temp1);
  strcat(temp3, temp2);
  sprintf(temp1, "%i", f);
  strcat(temp2, temp1);
  strcat(temp3, temp2);
  strcat(temp2, " }");
  strcat(output, temp3);
1 Like

Well, I’m pretty pumped that a cause has been established. I didn’t have any luck with your sample code, fwiw… sadly, the core still throws the timeout error. No matter though - finding a reproducible error is the first step toward a fix!

Thanks for writing all that out though - very useful for string manip noobs such as myself :smile:

No problem… it’s ugly as hell string manipulation in my opinion. And yeah, it won’t work until the character limit is increased. But after that happens your sprintf() with 3 variables should work as well.

1 Like

Very cool. I hope you guys don’t get discouraged with minor bugs like this - the Spark core is definitely one of the biggest highlights of the year for me. I should show you my sticker fridge some time… I’ve backed a handful of uP Kickstarters, Digistump is another of my favorites. But man - I have yet to see anything that even comes close to the ease of wireless integration for this small of a price point. Finally, all of my wireless sensor dreams are a reality!! </fanboy>


150% agree with everything you said!

I’d love to be able to have collections of data returned or even a string of values as opposed to polling individual values but I’m glad you guys figured it out before me. I thought I was going mad. I’m not even 100% sure whether it’s a good idea for a small sensor like this to be sending out 1k objects… But I guess I live in a REST based world where JSON and GETs and POSTS are the norm. To be honest it’s what has excited me about the core… A web based controller/sensor. Genius.

Completely agree about how excited we are with the core… very cool. Keep up the excellent work. Best kickstarter investment I’ve ever made. Not that I’ve made many :smile:

Has this been solved?
I just want to check because I am getting the same “�$” result today.