Cellular.on() / Cellular.off() and Cloud Functions

Firmware
1

Following from a previous topic I’ve posted, I’m planning to use Cellular.on() / Cellular.off() to conserve battery power in my Electron application. I’m also planning to take advantage of Particle.function() capabilities to remotely invoke functions on the Electrion. I’d also like to keep my options open for OTA firmware updates.

So my question is, when my sketch uses Cellular.off() and Cellular.on(), and System.sleep functionality, how are cloud interactions / pattern affected by this kind of power conserving behavior? Here are some specifics I’m wondering about:

  1. Do I need to remain connected for some period of time after calling Cellular.on() and receiving Cellular.ready() confirmation before calling Cellular.off() in order to guarantee pending Particle.function() events are received and executed?

  2. Does the Electron need to be connected at the instant that the POST /v1/devices/{DEVICE_ID}/{FUNCTION} API call happens, or is the function invocation queued in the Particle Cloud and delivered on the next device connection to the Cloud?

  3. When are Cloud-pushed firmware updates delivered to the devices, and do the power saving tactics I’ve described interfere with those mechanisms? If they do interfere generally, what boundaries do I need to observe in order to avoid that kind of interference?

2 Likes
2
  1. Cellular.on() & Cellular.ready() are not enough to receive Particle.function() calls (you need Particle.connect()/Particle.connected()) and these calls are never pending, but only issued once and have to be serviced within a few seconds, otherwise the call will timeout.
  2. see answer to 1.
  3. Yes, they are effected since user OTA flash orders are not queued, only Product OTA updates via the Particle Console are “queued” by default, but you could set up your own OTA updating server that could subscribe to an online-event of your device.
1 Like
3

@ScruffR thanks! As far as OTA, I should have been clearer in that I am thinking of a Product case, not an individual device case here.

So, first, in that case what is required to receive a Product firmware push? Do I have to write firmware that intervenes / supports / participates in OTA in that case? I'm envisioning a sequence like:

Cellular.on() -> Cellular.connected() -> do internet related stuff -> Particle.connect() -> Particle.connected() -> Product OTA needed (Yes or No) ? (Yes) Stay Connected and eventually reset automatically because Product OTA finishes : (No) Cellular.off() -> Sleep

Second, with delivering Particle.function() messages to a particular device (within a given Product umbrella), and with the battery conserving strategy above, what is a recommended strategy if Particle.function() isn't "reliable" under intermittent Cloud connection? I suppose I could just keep trying with sufficient frequency to "catch" the device while it's briefly (with remain connected duration built into firmware) Particle.connected() and before Cellular.off(), until I get a successful response from the Particle Cloud API call. Since Particle.functions() are free according to the pricing page, that seems like a viable, if inelegant, approach. Is there a better (or recommended) approach available that I'm not thinking of (or haven't noticed)?

4

As far as the OTA goes, that flow should work.

For the Particle.function calls, you could try to subscribe to the device came online event and then push the call button.

1 Like
5

Cool, but two things;

  1. How can my firmware know if “Product OTA needed” is true or not after Particle.connected()? And…
  2. Where can I read more about this “device came online event” and how to subscribe to it, e.g. from a NodeJS application running on a server somewhere?
1 Like
6

There are some system events for that like System.updatesPending()

https://docs.particle.io/reference/firmware/photon/#system-events-reference
https://docs.particle.io/reference/firmware/photon/#ota-updates

1 Like
7

@ScruffR thanks that’s excellent!

8

And if you look at this URL, you’ll see when any of your devices comes online

https://api.particle.io/v1/devices/events/?access_token=<yourAccessToken>

or one particular device

https://api.particle.io/v1/devices/<yourDeviceID>/events/?access_token=<yourAccessToken>

9

There’s the ParticleJS library, for Node.js, that offers an easy wrapper for the API, including subscriptions :smile: Do take a look!

1 Like