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

**URL:** <https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950>\
**Category:** Troubleshooting\
**Created:** [December 23, 2013, 2:17pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950 "2013-12-23T14:17:17Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![kennethlimcp](https://avatars.discourse-cdn.com/v4/letter/k/c0e974/32.png) [@kennethlimcp](https://community.particle.io/u/kennethlimcp)\
**Post date:** [April 1, 2014, 10:00am UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/22 "2014-04-01T10:00:31Z")

</div>

Why don’t you try this?

> **[Non-blocking interrupt driven DHT22 library](https://community.particle.io/t/non-blocking-interrupt-driven-dht22-library/3673)**
>
> I finally got the idDHT22 library for Spark working. It is an interrupt driven, non-blocking version of the DHT22 library. The library can be found on my github :smile:

---

<div class="post-metadata">

**Author:** ![Raldus](https://avatars.discourse-cdn.com/v4/letter/r/9d8465/32.png) [@Raldus](https://community.particle.io/u/Raldus)\
**Post date:** [April 1, 2014, 11:03am UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/23 "2014-04-01T11:03:14Z")

</div>

Thanks, I missed that.

---

<div class="post-metadata">

**Author:** ![seanreynoldscs](https://avatars.discourse-cdn.com/v4/letter/s/13edae/32.png) [@seanreynoldscs](https://community.particle.io/u/seanreynoldscs)\
**Post date:** [December 19, 2014, 5:30pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/24 "2014-12-19T17:30:37Z")

</div>

What is currently best practices with regard to delays in the Loop() function?

Currently I have a loop that has a delay(1); and inside it counts up till it reaches 10 seconds.  
After 10 seconds there is a process that runs which includes a delay(1000).

I’m considering removing the delay(1) in an effort to get faster samples from a microphone.  
Thoughts?

---

<div class="post-metadata">

**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\
**Post date:** [December 19, 2014, 5:35pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/25 "2014-12-19T17:35:09Z")

</div>

Hi @seanreynoldscs,

During long delays (over 1 second), the core will automatically maintain the cloud connection. If you’re in manual mode you can use the Spark.process() calls to opportunistically put the connection maintenance wherever you want. We’ll keep improving this, but you can find more details here: [http://docs.spark.io/firmware/#advanced-system-modes](http://docs.spark.io/firmware/#advanced-system-modes)

Thanks,  
David

---

<div class="post-metadata">

**Author:** ![psb777](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/psb777/32/934_2.png) [@psb777](https://community.particle.io/u/psb777)\
**Post date:** [December 19, 2014, 5:40pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/26 "2014-12-19T17:40:39Z")

</div>

Bump. This needs to be better known and, sigh, documented.

> [@satishgn](#):
>
> the case where "lots and lots of little delays that add up to a big delay" is also handled well in the delay() logic so should not be a problem

---

<div class="post-metadata">

**Author:** ![seanreynoldscs](https://avatars.discourse-cdn.com/v4/letter/s/13edae/32.png) [@seanreynoldscs](https://community.particle.io/u/seanreynoldscs)\
**Post date:** [December 19, 2014, 5:50pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/27 "2014-12-19T17:50:45Z")

</div>

@Dave  
Okay so Spark.process() gets called after every loop iteration in automatic mode.  
Are there any issues with calling it TOO frequently?

If I boot up a spark device and leave loop empty, will everything work?  
It just seemed like things didn’t behave well when i took out delay(1) at the end of my loop() function, but I might have been fooling myself?

---

<div class="post-metadata">

**Author:** ![Dave](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/dave/32/181_2.png) [@Dave](https://community.particle.io/u/Dave)\
**Post date:** [December 19, 2014, 6:03pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/28 "2014-12-19T18:03:17Z")

</div>

Hi @seanreynoldscs,

Hmm, I don’t think there should be any issues with calling it too frequently.

I think having a delay(10000) would be much easier on the connection than 10,000 delay(1)s

Thanks,  
David

---

<div class="post-metadata">

**Author:** ![mtnscott](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mtnscott/32/3217_2.png) [@mtnscott](https://community.particle.io/u/mtnscott)\
**Post date:** [December 19, 2014, 6:13pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/29 "2014-12-19T18:13:36Z")

</div>

@syzygy I’m not aware of any combo / key to get the core to a safe point with WiFi / Cloud to reflash over the IDE. You could build your code in the IDE, download a compiled version and flash locally. You can always put the core into DFU mode using the buttons on the core.

OK - WOW - that was a response to a very old post \> 1yr.

---

<div class="post-metadata">

**Author:** ![mtnscott](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mtnscott/32/3217_2.png) [@mtnscott](https://community.particle.io/u/mtnscott)\
**Post date:** [December 19, 2014, 6:20pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/30 "2014-12-19T18:20:19Z")

</div>

@seanreynoldscs Why don’t you use the millis counter? You can set a variable to the next time you want to sample the microphone.

For example -

```
// global variable
int _next_time_to_sample = millis();

// inside your loop
if (millis() > _next_time_to_sample) {
  // do your sample
  _next_time_to_sample += 1000;
}

```

This way you let the rest of the Spark process what it needs outside of your loop and you won’t have to block inside of your loop.

---

<div class="post-metadata">

**Author:** ![naikrovek](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/naikrovek/32/4162_2.png) [@naikrovek](https://community.particle.io/u/naikrovek)\
**Post date:** [January 26, 2015, 5:06pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/31 "2015-01-26T17:06:06Z")

</div>

so, wait.

should we NOT use long delays, or are long delays ok, now?

both viewpoints seem to be in this thread and neither seem to recognize that the opposite is also recommended.

as a relatively new user to the spark core, I can tell you that i’m very confused about a lot of technical questions I have. The community is virtually useless because, apparently, things have changed so much and there’s a whole bunch of old posts that aren’t taken down or annotated that they contain old information. there are also a lot of old posts that contain perfectly good information, so i can’t base my trust level on the age of the post.

the directions on how to compile for windows, for example, don’t really work. there are steps missing, and there seems to be a lot of guesswork involved in getting around the omissions to a working compile.

same with this. is delay(100000) ok? should I not block in the loop() method while waiting, but only check to see if my action time has come or not? What if there’s blocking work in the loop that takes 30 seconds?

gaaah!

I love these little cores I have laying around, and I can’t wait for the photon, but come on… someone please document something somewhere. please?

---

<div class="post-metadata">

**Author:** ![peekay123](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/peekay123/32/810_2.png) [@peekay123](https://community.particle.io/u/peekay123)\
**Post date:** [January 26, 2015, 5:25pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/32 "2015-01-26T17:25:32Z")

</div>

@naikrovek, using delay() in your code will not block the cloud connection as the firmware will service the cloud connection during long delays. I prefer to use millis() based passive delays that allow the rest of my code to continue and consider this better programming practice. True blocking of the user loop() code for more than 10 seconds will cause the cloud connection to drop when running AUTOMATIC or SEMI\_AUTOMATIC modes are used (MANUAL mode requires the user to manage the cloud connection via Spark.process()).

There are lots of code examples in the Community you can garner from. Your frustration with “outdated” topics and instructions is warranted and I have pointed out to Spark the need for search results by date or other criteria. In the meantime, don’t get so frustrated - ask the Community for help!

---

<div class="post-metadata">

**Author:** ![zach](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/zach/32/20714_2.png) [@zach](https://community.particle.io/u/zach)\
**Post date:** [January 26, 2015, 5:27pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/33 "2015-01-26T17:27:52Z")

</div>

Chill out! We’re happy to answer your questions. Not chill to call the community useless and then ask for help. We’re people, you know.

In general with the Core you want to avoid `delay()`s that are long because blocking code doesn’t allow the connectivity stuff to run in the background. That said, we put in a fix so less people would run into this so that when you run a `delay()` that’s long enough, we’ll run the connectivity code in the background. It’s still not the recommended way - counting `millis()` is better practice - but you can do it. The thing to avoid now is code that is _actually blocking_ (i.e. doesn’t call `delay()` but just takes a long time to process). For instance, if you added `while(1) {}` in your loop, it would kill the module.

hope that helps explain why we sometimes say it’s ok and sometimes say it’s not. The Photon will be multi-threaded, so none of this will be an issue any longer.

---

<div class="post-metadata">

**Author:** ![naikrovek](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/naikrovek/32/4162_2.png) [@naikrovek](https://community.particle.io/u/naikrovek)\
**Post date:** [January 26, 2015, 6:27pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/34 "2015-01-26T18:27:53Z")

</div>

Sorry, I don’t mean the COMMUNITY is useless, I meant the community documentation, and useless isn’t the correct word. I misword things when I am upset or frustrated, and I apologize.

And you may notice that the two replies I got contradict each other, so I’m no better informed than I was before.

I’ll just loop and wait for my time to come around rather than using long delays, I guess. It seems the better of the two approaches.

---

<div class="post-metadata">

**Author:** ![peekay123](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/peekay123/32/810_2.png) [@peekay123](https://community.particle.io/u/peekay123)\
**Post date:** [January 26, 2015, 11:56pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/35 "2015-01-26T23:56:56Z")

</div>

@naikrovek, actually if you read carefully, both replies basically say the same thing! 😄

---

<div class="post-metadata">

**Author:** ![zach](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/zach/32/20714_2.png) [@zach](https://community.particle.io/u/zach)\
**Post date:** [January 27, 2015, 12:12am UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/36 "2015-01-27T00:12:38Z")

</div>

That’s true, our answers said the same thing, although they were worded differently. Basically:

1. It’s ok to use long `delay()`s because in recent versions of the firmware, `delay()` calls a background task that services the Wi-Fi module’s connection to the cloud
2. Passive delays by counting `millis()` is better practice
3. Code that blocks without calling Spark’s background task (like `while(1){}`) will still kill the connection

Does that help clear things up?

---

<div class="post-metadata">

**Author:** ![BulldogLowell](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/bulldoglowell/32/4305_2.png) [@BulldogLowell](https://community.particle.io/u/BulldogLowell)\
**Post date:** [January 27, 2015, 2:10am UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/37 "2015-01-27T02:10:31Z")

</div>

> [@zach](#):
>
> delay() calls a background task that services the Wi-Fi module's connection to the cloud

very clever solution...

I would _ **underscore** _ that the use of blocking code like delay( ) should be avoided, even if the processors (like the cool new Photon) are background processing. There are many ways to avoid it and certainly lots of folks here that can show someone how.

> [@naikrovek](#):
>
> I meant the community documentation, and useless isn't the correct word. I misword things when I am upset or frustrated, and I apologize.

@naikrovek,

Regarding the documentation, I've a friend that is a veterinarian. With all that school and practicum, she knows everything about dogs, yet she could not tell me how to get dog poop out of my carpet... I had to ask around.

Try to post the question "How might I avoid blocking code or delays in this example?" and stand back and see how much help you will get.

---

<div class="post-metadata">

**Author:** ![b3ko](https://avatars.discourse-cdn.com/v4/letter/b/dfb087/32.png) [@b3ko](https://community.particle.io/u/b3ko)\
**Post date:** [May 24, 2016, 1:39pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/38 "2016-05-24T13:39:15Z")

</div>

i know this is a bit of an old topic…but…  
i have a spark core ( i know they are particles now but this has been sitting around for over a year and it is an older spark core, not a particle photon or whatever they are now) and just dusted it off for a project.  
after some updating of my cli i was able to factory reset and get it to connect. i was able to flash code to itsuccessfully and created a few webhooks that are working ( i see the data in the log on the particle dashboard).  
however…every few minutes the core seems to disconnect from the web, reconnect and then runs for a few minutes before repeating, there is a series or flashing white, blue, green, etc, that i didn’t document too closely because i was working on getting the code nailed down before i looked in to this, but i got the impression that the core was rebooting, reconnect after disconnect.

i DO have a rather long delay i put in there, just so i wasn’t slamming my endpoint with calls while i was writing the code and trouble shooting, etc.

i flashed my core using the web ide (last night, 5/23/16) and wondering if this should still be an issue?

any updates would be appreciated.

the delay is only temporary in my code now, but was wanting to know if you think this is what is causing the issue. the timeouts seem to be happening during the delay but may have been right when the delay was ending, not sure. the delay was set to 5 minutes.

i think i set the delay something like this (which reading now is horrible but you get the idea):

int minute = 60;  
int second = 1000;  
int delayTime = minute \* second \* 5;  
delay(delaytime);

thanks,  
jon

---

<div class="post-metadata">

**Author:** ![peekay123](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/peekay123/32/810_2.png) [@peekay123](https://community.particle.io/u/peekay123)\
**Post date:** [May 24, 2016, 3:52pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/39 "2016-05-24T15:52:15Z")

</div>

@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:

```auto
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. 😉

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [May 24, 2016, 8:02pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/40 "2016-05-24T20:02:55Z")

</div>

> [@b3ko](#):
>
> delay(delaytime);

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.  
So the question is what does?  
Could it be that some connection times out during that delay and will cause the issue when touching it again?  
Seeing your code would help there.

---

<div class="post-metadata">

**Author:** ![b3ko](https://avatars.discourse-cdn.com/v4/letter/b/dfb087/32.png) [@b3ko](https://community.particle.io/u/b3ko)\
**Post date:** [May 25, 2016, 1:23pm UTC](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950/41 "2016-05-25T13:23:52Z")

</div>

thanks,  
i haven’t had a chance to look at this again (kids) but should have some time tonight.  
i am going to do some more testing (remove the delay, remove code until i figure out what is causing the drop) and if i can’t figure it out i will post some code.  
i will also post what i find if i figure it out. thanks to both you and @peekay123 for the info.  
-jon

[Previous page](https://community.particle.io/t/known-issue-long-delays-or-blocking-code-kills-the-connection-to-the-cloud/950.md?page=1)