Wifi SEMI_AUTOMATIC confusion

I was just about to give up on Particle.

Problem 1:
My design was working great, except when I tested it with no wifi.
It basically hangs. Which is the default mode.
Might be good for some people, but a fatal flaw for my setup.

Problem 2:
There are tons of old threads on the same problem above.
There are so many that they obscured the newer ones.
And the old ones do not have good solutions!!
So I wasted a ton of time going down the wrong path, and
just about gave up.

The magic seems to be this:
SYSTEM_MODE(SEMI_AUTOMATIC)
SYSTEM_THREAD(ENABLED)

I really suggest making that far more obvious for people.

This really seems like something to document in firmware->cloud or firmware->wifi,
not buried in support.

They’re both documented, although admittedly neither of them is very obvious. Take a look at threading as well, might be interesting too.
https://docs.particle.io/reference/firmware/photon/#system-modes
https://docs.particle.io/reference/firmware/photon/#system-thread

Another fun problem with hang on wifi:
time.now() is blocking, when it decides to update via ntp.

I was actually expecting that issue, so the logical fix: Call time.nowNoUpdate() instead.
You would think that would not call updateNTPTime()
But no, delving into the code, it still does.
Easy fix in my local library code.

@rygh, I’m at a loss. There is no Time.nowNoUpdate() function in the firmware, nor is there an updateNTPTime() function. Are you using the built-in Particle system firmware Time class or @bko’s SparkTime library available in the IDE? If so, this is an important detail you left out of your OP.

Using the firmware Time class will not block your code. So please, before you blame the Particle platform, make sure you explore the documentation first! :wink:

3 Likes

HI @rygh

It sounds like you are using my SparkTime NTP library, which is great. It was not clear from your description what the problem you are having is. The library always tries to maintain the correct time with the update interval you have specified so if you call now or nowNoUpdate, it really only changes the order in which the calls are done, that is, update first or update after correcting local time.

First: Big apologies for the confusion. @peekay123
I did not really realize I was using a non standard time library.
Copied from other sample code, and it sounded official, so I never even thought about it.
My mistake.

@bko
Yes, evidently I was using your library. :grinning:
The problem I had was that with the network down, updating time via NTP
will block (technically cause a big timeout, not a permanent hang)
I assumed from part of the name “NoUpdate,” that it would not update.
I should never make assumptions…
I see what you were really doing now. Sorry.

– FYI –
What I am trying to do is this:

  1. Real-time control, to 1 second resolution.
    So no multi-second timeouts, ever. But otherwise pretty easy.
  2. Cool cloud stuff should work when connected.
    Disconnect and reconnect automatically.
  3. Main loop() should work well even when not connected.
    VERY reliably. No stalls. MTBF in years.

So far, not the best of luck.
Yes, a lot of it is due to the keyboard-chair interface.

I am thinking I should look into threads for the real-time code.
Or perhaps timer based.
Any advice on that front would be welcome.

1 Like

@rygh, with threading enabled and MANUAL system mode, you can control when/how the Photon connects to the internet or cloud. You can also implement your own retries, etc. Searching the forum will lead you to lots of ideas and solutions. :wink: