Continuing the discussion from Spark.variable() STRINGS larger than 9 chars issue [SOLVED]:
What discussion?
The original post in the refered thread is ancient and the actual problem was in the test code
char output[20];
void setup() {
Spark.variable("read", &output, STRING); // <--- that's just wrong!
}
So what’s your personal problem you want discussed?
I am using a very simple firmware just to demo GET, POST and subscribe to private events. I have experienced all the symptoms described in the previous closed thread marked as SOLVED. Is there some other factor at play here?
// name the pin
int led = D7;
// declare variables
int battery = 100;
char printStr[20];
// This routine runs only once upon reset
void setup()
{
//Register the Spark function here
Spark.function("led", ledControl);
Spark.variable("getbat", &battery, INT);
// Configure the pin to be output
pinMode(led, OUTPUT);
// Switch on on board LED for 1 second
digitalWrite(led, HIGH);
delay(1000);
// Initialize LED to be OFF
digitalWrite(led, LOW);
}
// This routine loops forever counts down from 100 to 0 in steps of 10 and when at <10% publishes an event
void loop()
{
if (battery >= 10) {battery-=10;} else {battery = 100;}
if (battery <= 10) {
sprintf(printStr, "%i", battery);
Spark.publish("Battery Critical", printStr, 60, PRIVATE);
}
delay (1000);
}
// This function gets called whenever there is a matching API request
// the command string format is <state>
// for example: on or off
//
int ledControl(String command)
{
if (command=="on") {
digitalWrite(led,HIGH);
return 1;
}
else if (command=="off") {
digitalWrite(led,LOW);
return 0;
}
else {
return -1;
}
}
i don’t see any subscribe function declared
@kennethlimcp I am just creating events here Spark.publish and not subscribing - the listening to an event stream is happening in a web app. My comment about other symptoms refers to the led blinking cyan occasionally and difficulties with flashing the device (Core).
That's what you stated.
Have you tried using firmware V0.4.5 for the core and doing a CC3000 patch?
Could you just elaborate which symptoms this are for you?
For example in the other thread there are problems you won’t see anymore since firmware has changed and your code looks different.
And it’s asking a bit much for us to read through a whole ancient thread and guessing what your actual problems are.
I see, you’ve added the info while I was typing
I am building with 0.4.5
When I do a Curl URL call, for example:
curl https://api.particle.io/v1/devices//getbat\?access_token\=
I get:
{
“error”: “Timed out.”
}
Since you're spending most time in delay()
this might contribute to some of your issues.
Try this instead (to rule out the above)
uint32_t msLast;
void loop()
{
if (millis() - msLast > 1000)
{
if (battery >= 10) {battery-=10;} else {battery = 100;}
if (battery <= 10) {
sprintf(printStr, "%i", battery);
Spark.publish("BatteryCritical", printStr, 60, PRIVATE);
}
msLast = millis();
}
}
See if this improves anything.
What are those backslashes in your curl command?
BTW: I think it's just personal preference, but I'd avoid blanks in event names
Thanks - I will try this.
It’s all good here now. So the lesson is delay() and Spark functions should not be mixed in the same firmware.
The more general lesson should be to avoid delay()
(and any other blocking code) wherever possible to keep the whole program but especially the cloud most responsive.
With FreeRTOS (in future releases) the impact of blocking user/application code on the cloud servicing will be reduced, but it’s still good style to be non-blocking