Listening mode persisting past SoftAP setup

Has anyone else had any issues where after setting up the photon via the softap the device is still broadcasting it’s SSID? I’m running my app in SEMI_AUTOMATIC mode with SYSTEM_THREAD(enabled) and calling the Particle.listen manually if there are no credentials present. Then I use the SoftAP to send credentials. The device successfully gets connected to wifi and then to Particle (breathing cyan). I’m sending and receiving events etc and monitoring it all via serial, but… the computer that I used to setup the device is still connected to it’s Photon_XXXX network. That and I can see and connect to it via other devices (i.e. my phone). Once I restart the device by either unplugging it or hitting the reset button it no longer broadcasts an SSID. Again, my app checks credentials at startup before entering listening mode.

I can strip out a lot of code and see what’s causing it more specifically, but didn’t know if A) this was already a thing or B) there was something I can do that can turn off the ssid broadcast / manually disable listening mode after it connects.

1 Like

Ping @mdma

@mdma

So here is my basic sketch that will allow the Photon got into listening mode, get credentials, connect to wifi + particle, but never stop broadcasting a wifi SSID… and I can even continue to talk to it with the SoftAP once it’s up and running. As soon as I restart the device after setting it up (aka it now has wifi credentials) with SoftAP it never enters listening mode, but I’d prefer not to have to restart it each time it’s setup.

Note, I have a separate thread that pushes to a display via Serial1 that I need to not be interrupted by going in and out of wifi modes…still, maybe I’m doing double duty on the threading? Even so, why doesn’t it exit listening mode? Oh and it’s 0.4.9 system firmware.

SYSTEM_MODE(SEMI_AUTOMATIC);

SYSTEM_THREAD(ENABLED);

const int GLOBAL_DELAY = 20;
bool particleConnectedFlag = false; // Set once we begin connection to particle
Thread* displayThread; // Independent display thread

void setup()
{
    displayThread = new Thread("displayThread", displayThreadLoop);

    // Connect to particle if you have credentials from SoftAP
    if (WiFi.hasCredentials())
    {
      particleConnectedFlag = true;
      Particle.connect();
    } else {
      WiFi.listen();
    }

}

void loop()
{
  // Connect to particle once connected to wifi
  if (WiFi.ready() && !particleConnectedFlag) {
    particleConnectedFlag = true;
    Particle.connect();
  }

  delay(GLOBAL_DELAY);
}

void displayThreadLoop()
{
  while(true)
  {
    /*Serial.println("thread");*/
    delay(GLOBAL_DELAY);
  }
}

I don’t want to sound like a pest…but I’m really struggling with this problem. My current solution get keep things moving is to restart the device once I have credentials. I’ll have to do some fancy footwork and retain my display state, but it’s an option. I’d just love to know if I’m doing this incorrectly.

My P1’s and P0’s are doing the same when I try to provision the Wifi credentials. Everything seems to be sent just fine and the device is able to connect to Wifi however the SoftAP is still present. I am using a custom iOS app based on the Particle setup library to configure the Wifi credentials but the SoftAP seems not to be torn down after the setup process is complete. Pressing the Reset button after the setup process shuts down the SoftAP as expected.

I am not totally sure but I think I only noticed this issue once my devices were upgraded to 0.4.9. I will do more testing on some other P1’s and P0’s I have here.

Hi @lige
Just to get you an update. I never ended up getting this resolved (even in 0.4.9). Instead I just listen for wifi credentials to be set and then reset the device via firmware. It’s not an ideal solution because my application has a display that the user can see during this…but it’s the only way to shut down the SoftAP after receiving the credentials.

Sorry for the difficulties you’re having with this. I’ve reproduced the problem and found a fix that will be in firmware 0.6.0.

In the meantime, you can avoid this issue by adding WiFi.on() at the start of the setup() function.

1 Like

That’s great news @mdma

Thanks for the fix!