Well - all I can say is there is some 'magic' that happens outside of the main loop. I have spent some time diving into the core firmware to try and understand what's going on but probably not enough time to try and fix it. (I think I would need to debug the Spark using JTAG - I have the equipment, just not taken the time to setup and get working)
In my experience trying to bring up the network connection from a dead off to working can not happen within one pass of the user loop. That is why I created a state machine to perform the task. (Also blocking and waiting for DHCP negotiation and calling Spark.process()
seems like poor application design.)
I have found cases where WiFi.ready()
will return true while you don't have a connection you can use, so I added !WiFi.connecting()
I could have dug in a bit more to understand it better and maybe discovered it's not needed, but I moved on to address other problems.
I posted a networking test app here - It will let you manually bring up and down things such as WiFi, Cloud and test DNS. It's also a great start as a template to try out your own stuff.
Let me see if I can address another comment you made -
Funny thing about Spark.connect()
it likes to manage all of the network operations, for example if you fun SYSTEM_MODE(MANUAL)
and manually bring up the WiFi in your setup (which can be done) and then manually try and start the cloud connection with Spark.connect()
It blocks and hangs the core. However if you don't bring up the WiFi and just call Spark.connect()
in setup everything is happy. And - yes, Spark.connect()
blocks until the Cloud connection is up. I've also found is not entirely accurate, you can call Spark.connect()
and then immediately try and use a Cloud function such as Spark.syncTime()
however it not always successful. So Spark.connect()
much like WiFi.ready()
are not always 100% accurate representations of the state of the service. The services will be available sometime after, just not immediately 100% of the time.