Particle.publish() blocking after cloud connected

TL;DR Don't call WiFi.on() in your loop


I'm having an issue project, but only when all of my code is included. I can't seem to put together an minimal example that does the same thing.

When connecting to wifi/cloud, my loop will block for about 5 seconds after Particle.connected() returns true and cloud_status_connected gets returned from the cloud_status callback. If I don't try to call Particle.publish(), there isn't a 5 second block. This seems suspiciously similar to me calling more than 20 asynchronous system api calls and having the application thread block me for 5 seconds, but I just don't think I am. Is it possible that I'll still be blocked for 5 seconds if I call a synchronous system call, and the number of asynchronous calls also happens to be more than 20 deep?

I see a lot of the following printed to my log,
[system.nm] TRACE: Request to power on interface 4
It first gets called when I call Particle.connect(), then again when the network status handler returns network_status_on, but then goes off the rails when network_status_connecting is returned. If I remove my debug prints per loop, it still gets called every 10-20 ms. If I take a peek at NetworkManager::powerInterface() it mentions that there is a workaround to a race condition present. That may have something to do with it. And I think that every time NetworkManager::powerInterface is called from network_on(), it puts it on the async task queue (I think).

Sometimes when a network isn't available it will actually lock up after [ncp.rltk.client] INFO: disconnected and get reset by the watchdog, but that might be unrelated.

So my question is, what am I doing wrong to cause the network manager to be so upset with me? I changed my code to only call Particle.connect() a single time if it's unconnected and hasn't yet tried to connect. I'm sure there's more to it but it looks like the async queue is getting filled up.

Just kidding like 2 seconds after I wrote this up I noticed that I had a WiFi.on() call one line above where I call Particle.connect() a single time... So yeah obviously I'd fill up that async queue. Interestingly, repeated calls to Particle.connect() must have some sort of check inside them because they aren't mean to the Network Manager... WiFi.on() not so much. Though embarrassing, I'm posting this anyway because maybe it will help someone in the future.


Glad you figured it out! On current versions of Device OS you no longer have to call WiFi.on() or Cellular.on() in SEMI_AUTOMATIC mode. This wasn't the case in some 1.x and earlier versions of Device OS.

That's exactly it, I'm porting our current Photon program that is on Device OS 1.4.4 in manual mode.

@rickkas7 What about OS 2.3.1 - does that count as earlier version?