Enter listening mode after failed WiFi connection

Firmware
1

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):

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?

2

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

  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) before entering LM.

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

3

I’m using system firmware version 0.6.3.

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

1 Like
4

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

5

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.

6

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

7

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.

8

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.

9

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

10

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

2 Likes