Particle.process() quirks

[robc]

@sampath1

So is particle.process() being called during delays even in manual mode (which I am in)…

Yes. While in manual mode, you are responsible for placing Particle.process() in your code. So far, you have had no trouble with your code. A one second blocking delay is not affecting your connection, yet.
The delay(1000) statement happens to call Particle.process() for you but, as you add new routines, may not call it often enough. A connection could break if not attended by Particle.process() often enough.

I had read about this a long time ago. Hope the following helps. Here is what I found today in the forum:

@ScruffR

While the suggestion to write non-blocking code is good practice in any case, I’d say this delay() should not cause the disconnect, since in default “single” threaded mode delay() calls Particle.process() every 1000ms of accumulated waiting time.

Known issue: long delays or blocking code kills the connection to the Cloud

@b3ko, if you post your actual code it would help. If you want to delay without killing the cloud connection, you need to implement a non-blocking delay, something like this: unsigned long myDelay = millis() + (60*5*1000); while (millis() < myDelay) { Particle.process(); delay(10); } This will appear like a blocking delay (where other code is not running and loop() is not looping). However, it will be calling Particle.process() which will keep the cloud connection active.