Set up cloud function when connected

argon
Tags: #<Tag:0x00007fe21ffeeb70>

#1

I may not be wording my queries quite right - please link me if you’ve seen this discussed already elsewhere.

I’ve got an Argon and I want to declare a cloud function - except that it may/may not be able to get online and may be powered off/restarted while out of range. This function isn’t critical and I expect it to be out of range now and then. Its set up right now to do stuff regardless of connectivity. I also don’t have any cloud calls at the moment.

Question(s) is(are) this:
A - if the device powers up and can’t get online, but I’m declaring a function in the setup, will it wait to do anything till it can get a connection (I recall this being a thing with the photon, but its been a while since I’ve needed to think about it)

B - I’m assuming I can tell it to not wait around (no to A essentially), can I have it declare the function later when it gets online? Maybe somewhere in the loop do something like:

if(Particle.connected())
{
   //can you check for a function being declared?  
   //does it matter if tries to set up the function more than once?  
   //if(Particle.function("myFunction"))   
   Particle.function("myFunction",myFunk);
}

Obviously there’d be more that needs to go into some of that logic, but in principal, is this doable (within reason…)?


#2

AFAIK if you have SYSTEM_THREAD(ENABLED); and SYSTEM_MODE(SEMI_AUTOMATIC); you can declare cloud functions and variables before connecting to the cloud and they will work fine.

https://docs.particle.io/reference/device-os/firmware/electron/#optimizing-cellular-data-use-with-cloud-connectivity-on-the-electron


#3

Particle.function() (as well as Particle.variable() and Particle.subscribe()) only tell the device what you want registered with the cloud when it connects (or a short period after it has done so).

So you can register any of these “objects” anytime before the first connect and even when the connection is lost the device will still know what it would need to re-register in case the cloud had forgotten.

That holds true irrespective of SYSTEM_MODE and SYSTEM_THREAD(ENABLED).
However, in order to have your code start running even without WiFi you need to opt for one of the modes @nrobinson2000 has pointed out (AUTOMATIC plus SYSTEM_THREAD(ENABLED) are also valid option - as is MANUAL).


#4

Sweet - I think that mostly answers my question. I knew there was a link somewhere :stuck_out_tongue:

Is there an advantage/disadvantage to using both SYSTEM_THREAD and SYSTEM_MODE? They seem to accomplish similar things.


#5

Not quite.

SYSTEM_THREAD(ENABLED) decouples the application from the system by donating one thread to each of them.
SYSTEM_MODE() won’t change anything about the thread assignment, but controls how the system tasks should act on startup (initiate the connection automatically or user-controlled) and how it will behave while your code is running (e.g. execute Particle.process() between iterations of loop() or not).


#6

Ah, got it. Thanks for the clarification :slight_smile: