Product Firmware Cloud Update Timing

Cloud
1

Question: With a Particle Product’s firmware management, can we speed up firmware update messages from the Cloud which seem to take a consistent 9 seconds of Cloud connection before arriving?

Background: I’m playing around the firmware upgrade functionality by creating a product in Particle’s console. My device, to minimize power, only wakes occasionally from sleep and keeps the WiFi powered even less often and only for short blips of time. I’m finding that it never gets the updated firmware.

I wrote another application to test how long it takes before a firmware message from the Cloud arrives. After 4 trials, I found it always gets a message for a new firmware update after being Cloud-connected for 9 seconds. My application loop is below (NOTE: Because I’m using SYSTEM_MODE(MANUAL), I’m controlling processing and wifi/cloud).

Ideas: Alternatively, I can manage updates through my own system but if Particle is going to offer this feature, I might as well use it. To get around this, I can keep my device awake for a minimum of 10 seconds and then check the firmware_update_pending event or System.updatesPending(), both of which do not occur (trigger or return true) unless the Cloud sends the message 9 seconds in.

Testing App:

void loop() {
    Serial.print("...loop\n");
    Serial.flush();
    digitalWrite(D6,LOW);
    
    // manual setup of this
    WiFi.on();
    if ( WiFi.ready() == false ) {
        Serial.print("WiFi not ready so turning on\n");
        WiFi.connect();
        while(WiFi.ready() == false ) {
            Serial.print("... waiting for WiFi\n");
            Particle.process();
            delay(1000);
        }
    }
    if ( ! Particle.connected() ) {
        Serial.print("Particle not connected to Cloud\n");
        Particle.connect();
        while( Particle.connected() == false ) {
            Serial.print("... waiting for Cloud\n");
            Particle.process();
            delay(1000);
        }
    }

        
    Serial.print("...process\n");
    Particle.process();

    Serial.printlnf("...delay %d sec",ds);
    delay(ds*1000);
    ds+=1;

    Serial.print("...process one last time\n");
    Particle.process();

    Serial.print("...sleep\n");
    System.sleep(1);
}
2

You would not need to stay awake that long each time. Once you have your product deployed it wouldn’t matter to your customers if they got a pending update a day sooner or later, but you could only stay awake longer once a day.

I’d think the background for the delayed event is due to the fact that your device takes some time to wake and reconnect. Then there is a reserved time frame (I think that’s 5sec) for your code to potentially register Particle.variables, Particle.functions and Particle.subscribes before the “enumeration” with the cloud happens, and only after that the cloud knows of your device being online and will check and send the pending update notification.
The device already knows it’s connected and hence starts breathing immediately, but all the cloud-fairies need some time to understand the new situation :wink:

You can slightly speed up your own code this way

    if ( !Particle.connected() ) {
        WiFi.on();
        Serial.print("Particle not connected to Cloud\n");
        Particle.connect();  // WiFi.connect() and waiting for it is done implicitly with minimal delay
        Serial.print("... waiting for Cloud\n");
        waitUntil(Particle.connected); // waitFor() would allow to set a timeout
        Serial.print("connected\n");
    }
3

I guess I was hoping for a call I could make to immediately check if all Cloud connections have been made. Otherwise, I’m just guessing at ensuring that it stays awake for 12 seconds or so. Also, it’s 9 seconds each time after Particle.connected(). Not a huge drain, but I’m trying my best to keep these things alive as long as possible.

Is there someplace that details exactly what the flowchart is for the Cloud connection? That would be interesting to look at. I took a look at the code quickly and realized it wasn’t going to be simple to put this together since it is mostly callback based on the backend… i.e. hard to trace a simple program flow.

Thanks for the help. I’ll either keep it alive or send a bit from my servers, telling the device if it should check for a firmware update.