# Enter listening mode after failed WiFi connection

**URL:** <https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476>\
**Category:** Firmware\
**Created:** [March 20, 2018, 6:23pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476 "2018-03-20T18:23:35Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![AustinGlaser](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@AustinGlaser](https://community.particle.io/u/AustinGlaser)\
**Post date:** [March 20, 2018, 6:23pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/1 "2018-03-20T18:23:35Z")

</div>

I’m building a device which needs to operate without WiFi at times (for instance, if a user’s WiFi network goes down, or they change their network configuration. The firmware uses `SYSTEM_MODE(SEMI_AUTOMATIC)` and has `SYSTEM_THREAD(ENABLED)`.

I’m handling this situation by timing out the connection to WiFi (using a software timer). This works as expected – if the system is unable to connect after some time, I call `WiFi.off()`, and since I’m using semi-automatic mode the application is able to continue making progress.

However, the user also needs to be able to reconfigure the WiFi credentials for a system in this state. That is, in reaction to an event (button press), I need to put the system in listening mode.

I’m using the following sequence to do this, (which works on a system which either has no credentials, or has a valid active connection):

```auto
WiFi.on();
WiFi.listen(true);

```

But after a connection timeout, the system will only briefly enter listening mode, before continuing its connection attempt. Including a `WiFi.disconnect()` anywhere in that sequence appears to have no effect.

Entering listening mode via the setup button has similar behavior. The system will briefly enter listening mode, then enter a state where it tries to connect intermittently (approximately 40 seconds connecting, followed by 20 seconds not). In this state, `loop()` gets called very intermittently (every 40-60 seconds).

Does anyone with more experience managing a Particle’s connection state have insight into what might be going on here, and a way I can reliably enter listening mode in this state?

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [March 20, 2018, 6:36pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/2 "2018-03-20T18:36:16Z")

</div>

Maybe try tearing down the connection gracefully when your timeout happens instead of just killing it with a cold `WiFi.off()`.

```cpp
  Particle.disconnect();
  delay(100);
  WiFi.disconnect();
  delay(500);
  WiFi.off();

```

Although it should be the default setting on WiFi devices, you could try explicitly setting [`WiFi.setListenTimeout(0)`](https://docs.particle.io/reference/firmware/photon/#setlistentimeout-) before entering LM.

BTW, what system version are you running on your device?

---

<div class="post-metadata">

**Author:** ![AustinGlaser](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@AustinGlaser](https://community.particle.io/u/AustinGlaser)\
**Post date:** [March 20, 2018, 6:45pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/3 "2018-03-20T18:45:57Z")

</div>

I’m using system firmware version 0.6.3.

I’ll give your suggestion a shot, and let you know how it works.

---

<div class="post-metadata">

**Author:** ![AustinGlaser](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@AustinGlaser](https://community.particle.io/u/AustinGlaser)\
**Post date:** [March 20, 2018, 7:13pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/4 "2018-03-20T19:13:55Z")

</div>

The improved disconnect sequence doesn’t appear to make any difference to my system’s behavior.

---

<div class="post-metadata">

**Author:** ![AustinGlaser](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@AustinGlaser](https://community.particle.io/u/AustinGlaser)\
**Post date:** [March 20, 2018, 7:21pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/5 "2018-03-20T19:21:02Z")

</div>

I take that back – it does help with the apparently anomalous behavior when entering listening mode using the setup button. I’m still unable to enter listening mode through an application-level event.

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [March 20, 2018, 7:26pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/6 "2018-03-20T19:26:33Z")

</div>

Can you provide me with a snapshot of your application to test on my device?

---

<div class="post-metadata">

**Author:** ![AustinGlaser](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@AustinGlaser](https://community.particle.io/u/AustinGlaser)\
**Post date:** [March 20, 2018, 7:30pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/7 "2018-03-20T19:30:20Z")

</div>

I can provide you a binary; unfortunately, I can’t share the source code. I’m working on a product design, and the code is proprietary.

I’ll see if I can provide you a MWE based on a subset of our code – that reduction may prove to be valuable in and of itself as well.

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [March 20, 2018, 7:33pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/8 "2018-03-20T19:33:35Z")

</div>

Maybe you should then just go with a PoC for that exact feature and see whether or not this functions as an isolated task.  
If so, you can try scanning your code for potential interference in the other portions of the code which will still run while in listening mode and may well knock your device out of it.  
If it doesn’t work, we can see why this doesn’t work. Whenever I tried to engage LM that way it workes, so I’d suspect your _other_ code to contribute to the erronous behaviour.

---

<div class="post-metadata">

**Author:** ![AustinGlaser](https://avatars.discourse-cdn.com/v4/letter/a/ed655f/32.png) [@AustinGlaser](https://community.particle.io/u/AustinGlaser)\
**Post date:** [March 20, 2018, 7:34pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/9 "2018-03-20T19:34:58Z")

</div>

> [@ScruffR](#):
>
> Whenever I tried to engage LM that way it workes, so I’d suspect your other code to contribute to the erronous behaviour.

That alone is a valuable piece of information. I'll spend some time simplifying this down. Thanks for your help so far!

---

<div class="post-metadata">

**Author:** ![peekay123](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/peekay123/32/810_2.png) [@peekay123](https://community.particle.io/u/peekay123)\
**Post date:** [March 20, 2018, 7:42pm UTC](https://community.particle.io/t/enter-listening-mode-after-failed-wifi-connection/40476/10 "2018-03-20T19:42:14Z")

</div>

Yup, my code includes checks for listening mode so I can skip any wifi or cloud dependent calls.
