How to conditionally bypass connecting a mesh device to the cloud?

I have a simple setup of one Argon and 2 Xenons. The Xenons are running with SYSTEM_THREAD(ENABLED);

I am trying to write code in the loop() section where each Xenon would try connecting to the cloud for 2 minutes. If a cloud connection is not available after that time, I want the Xenons to switch to manual mode. SYSTEM_MODE(MANUAL);

In testing, when the Argon is powered, the 2 Xenons do connect to the cloud (and the mesh). If the Argon is NOT powered, the 2 Xenons do connect to the mesh BUT they keep flashing a fast green. I was expecting the Xenons to breathe white.

Here is the code I am using:

void setup()
{
   startTime = millis();
   bypass = false;
}
void loop()
{
 if ((!Particle.connected()) && (!bypass) && ((millis() - startTime) > 120000))  
  {
    bypass = true;
    SYSTEM_MODE(MANUAL);
  }
}

Why is this not working?

You can't switch SYSTEM_MODE, but you don't need to either.
Once you call Particle.disconnect() the device will not try to reconnect to the cloud unless being told to so or being reset.

Because SYSTEM_MODE() is executed during startup of the device in order to initialise the system accordingly. So calling it after initialisation won't do anything.
BTW, SYSTEM_MODE() is also not ment to be called from within any function and as clearly documented before setup() is executed.
https://docs.particle.io/reference/device-os/firmware/xenon/#system-modes

As mentioned multiple times before: Reading the docs often provides a wealth of insight (or a bit more blunt RTFM :wink: ).

1 Like

Thank you @ScruffR.

I changed the code to:

  if ((!Particle.connected()) && (!bypass) && ((millis() - startTime) > 120000))   
  {
    bypass = true;
    Particle.disconnect();
  }

The 2 Xenons (with the Argon not powered) just keep flashing green ...

Yup, that’s to be expected as the mesh will still be looking for a gateway to hook it up to the internet, but that shouldn’t bother you too much.
AFAIK there are no dedicated RGB LED codes for pure mesh connectivity
https://docs.particle.io/tutorials/device-os/led/xenon/#looking-for-internet

But if you want to stop the looking for internet too - not just Particle cloud - you’d need to disconnect from the mesh via Mesh.disconnect() and then Mesh.connect() again.

Thanks again @ScruffR.

The green flashing does not bother me, I was just concerned it may be consuming processor time …

So to stop it, I should do this?

if ((!Particle.connected()) && (!bypass) && ((millis() - startTime) > 120000))   
  {
    bypass = true;
    Particle.disconnect();

   Mesh.disconnect();
   delay(2000);
   Mesh.connect();
  }

Thanks again.

I am playing with a setup with a Xenon device which is a pure mesh end node [SYSTEM_MODE(MANUAL); and then Mesh.connect(); in setup()] and it breathes green - I assume therefore you are referring to the Argon which is also internet/cloud connected? If the Xenon end node was also internet connected via the gateway it would breathe cyan?

I mean if I power the Argon first then wait for it to connect to the cloud, then power the Xenons after that, both Xenons eventually breathe cyan which is the expected behavior.

Now, If I use the code below but turn the Argon off then restart the Xenons, they flash green forever.

if ((!Particle.connected()) && (!bypass) && ((millis() - startTime) > 120000))   
  {
    bypass = true;
    Particle.disconnect();
  }

If I use the code below, again, the Xenons just keep flashing green like before.

( If the LED flashing green is not indicating processor activity, it does not matter. But is this the case?)

if ((!Particle.connected()) && (!bypass) && ((millis() - startTime) > 120000))   
  {
    bypass = true;
    Particle.disconnect();

   Mesh.disconnect();
   delay(2000);
   Mesh.connect();
  }

Yup, exactly - breathing cyan means connected to the Particle cloud - irrespective of transport.

Where is your code running - on the Xenons? If so then LED flashing green is correct. If you wanted to stop that you would need to switch the Mesh radio off.

The impression I get with all the Device OS versions (but not categorically tested) is that they are all very persistent at trying to connect (or reconnect) once they have been switched on and are that way because the biggest issue has been devices disconnecting and then not reconnecting. I wouldn’t worry about processor usage whilst we have no sleep functions (i.e. the Xenons can’t play sleepy end node device yet) so must be powered 100%.

Thanks @armor. Yes, code is running on Xenons. If it does not affect the processor then it can flash whatever color it wants :-).