Using WiFi.off()

Firmware
1

Hi Everyone, Just a quick question, is there anyway that in my coding i can call WiFi.off() while my photon is on listening mode and then later if i want to leave an WiFi.off() be able to go back to previous mode which in this case it was in the listening mode?

The reason for this is because I want a user to be able to put his photon offline even if it is in the listening mode and maybe for some reason his photon cannot connect to his router.
I have attached few lines of coding. So far a photon can go from listening mode to offline easily but doesn’t leave the offline mode unless i restart the photon.

if (mbut == UI_SELECT) {
    if(WiFi.listening()) {
       WiFi.off();
    }
    else{
      WiFi.on();
    }
}

Thanks!

2

By default Listening Mode suspends execution of your code, hence your code cannot end Listening Mode which means you need to reset the device (or use any of the repspective serial commands to make Listening Mode end itself).
In order to keep executing your application code while in Listening Mode you need to use ´SYSTEM_THREAD(ENABLED)`.

However, can you elaborate a bit more why you want WiFi.off() in Listening Mode? That somewhat defeats the purpose of Listening Mode.

When the Photon is put into Listening Mode it will disconnect from the previous WiFi router anyway since it will expose its own SoftAP (which it couldn’t with WiFi.off()).

3

Lately I have been receiving complaints from some of my clients having issues with connecting the photon to their router but somehow in my studio all these photons that my clients are complaining about they do connect just fine.

Now this is why and my teammates agreed that it’d be better if we have an option for a user in UI to switch off the wifi so that the Photon can breath a constant white instead of flashing blue since that can somehow irritate the user.

FYI before we ship off the photons to clients, we completely reset WiFi credentials meaning the client always receive it in listening mode

4

In that case, I’d suggest an entirely different approach (thinking outside the box).

If you want your device to not be in LM you may want to opt for SYSTEM_MODE(SEMI_AUTOMATIC)

I’m also not conviced that this …

… should be addressed by “faking” signals like …

Breathing white has a distinct meaning which is entirely different from Listening Mode.

I’d think an uninstructed user won’t be able to make sense of either signal but good communication can help users understand any signal.
Assumptions what users may or may not understand are typically only rarely helpful, but properly “educating” them should be the preferred way.

Having said that, we’d need more background on the actual, intended behaviour of your devices in these situations and what your UI would do in such cases to provide better advice.

Also, have you considered taking over RGB control to disable or reappropriate the RGB LED instead of “messing” with the underlying logic to indirectly achieve something you could get cheaper otherwise?

5

Okay thanks for advise I will opt for SYSTEM_MODE(SEMI_AUTOMATIC) surely it will help me,

Anyway eventually I would like to fix this problem once and for all, so like i said before that other devices cannot connect to other clients router but it does successfully connect to my studio.

When the device is at my client’s house and using the app to connect, the app will go through all the process of connecting and the device will also attempt to connect but lose connection afterwards and go back to flashing blue even after the app report that the device is successfully connected.

So it seems like these devices they don’t make it to the cloud.
I would really appreciate your insight based on that.

6

You will need some info from your users about their WiFi environment.
e.g. WEP needs some special care with providing the key, 5GHz networks are not supported, captive portals are neither, are they using a proxy, …

Without a complete understanding of the context any “counter action” will be no more than a shot in the dark.

7

I’m trying to build Photon code which defers connecting.

I’ve tried this code on a Photon with System version 1.5.2, and it works fine (blue LED flashes,
breathing white).

  • However, the same code fails (continually flashes navy blue) on 2.0.0-rc.2.

Has something changed?

#include "Particle.h"

SYSTEM_THREAD(ENABLED)
SYSTEM_MODE(MANUAL)

int led_blue = D7;

void setup() {
  pinMode(led_blue, OUTPUT);
}

const int FAST_FLASH_MS = 500;
unsigned long ledLastFlashMs = 0;
boolean ledStateOn = false;

boolean fastFlash() {
       unsigned long now = millis();
	if ((now - ledLastFlashMs) >= FAST_FLASH_MS) {
            digitalWrite(led_blue, (ledStateOn?LOW:HIGH));  
            ledLastFlashMs = now;
            ledStateOn = ! ledStateOn;
            return true;
    }
    return false;
}

Running VSCode on macOS Catalina, 10.15.7
VS Code: 
Version: 1.49.3
Commit: 2af051012b66169dde0c4dfae3f5ef48f787ff69
Date: 2020-10-02T17:54:06.165Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 19.6.0
8

There is no loop() function in the code you have shared?

Likely there has been change in behaviour - you can use SYSTEM_MODE(SEMI_AUTOMATIC) rather than MANUAL.

9

I believe the most likely cause is that you have an unmet system dependency. If you only flashed Device OS 2.0.0-rc.2, and not the bootloader, the missing bootloader is causing the problem.

The reason is that if you have an unmet system dependency the device cannot fully boot. So it goes into safe mode to retrieve the missing part OTA. That will result in blinking green, blinking cyan, then breathing magenta normally. However if a Wi-Fi device has no credentials, it will go into blinking dark blue (listening mode) to await credentials so it can get the missing part OTA.

It doesn’t matter if user code uses SYSTEM_MODE(MANUAL) because the user code never runs, because the system is not in a stable state yet.

You can check for missing dependencies in listening mode and USB connected using

particle serial inspect
1 Like