ESP32 Forum

I have a simple sketch that i want to use for a Client to connect to a server. The server is NOT running.

The moment I call Wifi.Begin(...) on my Client, the ESP32 is creating an AP called ESP_1CBA01

This is a powerful signal (-30dB), and across a huge band (Channels 1 to 7).

What is the AP, why is it created, and how can I stop it!!!!

That is the last configure AP, so when you dont need it as AP you should set wifi mode to station (Sta),, dont have code here but search for it.

Agree007 wrote:That is the last configure AP

Thanks, that is not what it is, but your answer led me to the solution:

For the benefit of anyone else who comes across a similar problem:

The ESP32 stores it's last wifi mode persistently. AND, After a full flash wipe, the default persistent mode is an AP, with a variant of the AP name "ESP_xxxxxx". Which is what happened in my case, I didn't set the mode to AP, i did a full flash wipe. Why that's the default mode after a Full Flash wipe is anyone's guess.

The solution is to put WiFi.mode(WIFI_STA) before WiFi.begin(...) which sets the ESP32 into Station Mode, and also stores that mode persistently. Which is hostile, because if one forgets WiFi.mode(), their code runs as a station because they (or someone) once ran that line of code (sometime in the past). Ie, their code has a bug, but the ESP32 WiFi API masks that bug by doing something it wasn't asked to do. This is evidenced by the numerous online demos showing the use of WiFi.begin to setup as a client, missing the call to WiFi.mode()

This is NOT a good API behaviour. If an API is going to use Persistent data, it should be OBVIOUS that it is going to use persistent data, otherwise it should be declarative. An API should not magically drag up some previous programs state and let it live again, without the program EXPLICITLY asking it to do so.

Something like:
WIFI.restorePersistentState()
WiFi.begin(...)

Its redundant, but worth repeating, any API that does things it's not TOLD explicitly to do is a bad API. One should not have to answer the question "What does WiFi.begin() do?" with "Well, its not possible to know, it all depends on what ran on the ESP32 before..."

It does appear that the semantics are documented ... see:

https://arduino-esp8266.readthedocs.io/ ... html#begin

Notes: * It is possible that calling begin will result in the module being in STA + softAP mode if the module was previously placed into AP mode.

kolban wrote:It does appear that the semantics are documented ... see:

https://arduino-esp8266.readthedocs.io/ ... html#begin

Notes: * It is possible that calling begin will result in the module being in STA + softAP mode if the module was previously placed into AP mode.

Ok, thats documentation for an ESP8266 not an ESP32 which i have the problem with. See: https://github.com/espressif/arduino-es ... Client.ino That particular demo from the ESP32 arduino repository may or may not start a softAP with who knows what configuration, and it doesn't handle it. In fact, reading the code one is under the impression that ONLY a Station is being set up. One may or may not be wrong in that regard, hence my problem. What the code does is not Deterministic.

But in any event, the quote does not tell you that this "previously" includes code that ran before the current session and isn't running now. It could easily just mean, if you have previously IN THIS PROGRAM placed the module in AP mode and that's what one would normally think, without the special knowledge that No, the ESP32 will use it's psychic abilities to determine what you mean, not based on what you are telling it to do NOW, but based on what someone once told it to do. Or does it mean that it is a one-way street? Once in softAP mode, always in softAP mode? thatS kind of what the quote could also imply. There is no documentation on how to reverse or compensate for this state of affairs.

The ESP32 documentation does some handwaving and makes cryptic mention of Wifi NVS:

Wi-Fi NVS Flash

If the Wi-Fi NVS flash is enabled, all Wi-Fi configurations set via the Wi-Fi APIs will be stored into flash, and the Wi-Fi driver will start up with these configurations next time it powers on/reboots. However, the application can choose to disable the Wi-Fi NVS flash if it does not need to store the configurations into persistent memory, or has its own persistent storage, or simply due to debugging reasons, etc.

No discussion however of how this impacts the Arduino Libraries, which should have a known functionality. This behaviour is not good, and certainly not good for a person coming at ESP32s fresh. This sort of behaviour (if it exists AT ALL) should be opt-in, not opt-out (however one does that, because the docs don't tell you).

Documented or not does not change the brokenness of the implementation. Further, it is NOT documented that it will be put into a softAP mode if you erase the flash. Which is what happens. The problem is the way it's implemented the behaviour of WiFi.Begin is not deterministic, it's never possible to know what it will do, because what it will do relies on something else which may or may not have happened in the past. Further, none of the demonstration code published takes this into account, and will spuriously start softAP's sometimes, depending, on whatever.

There is also the issue that this creates excessive battery drain, and pollutes half the Wifi band (Channels 1-7) with AP's which are non functional. If you happen to have set up a ESP32 as a master in the past, and then switch it to a slave, it remembers what you did, and you can end up with Multiple AP's with the same name on air at once which leads to all sorts of problems.

ALSO, it is completely at odds with Arduino which is the source of this API. Arduino does not do this at all. It seems to have no valid purpose, although it clearly was implemented to do this very strange thing. If the code has not asked for an AP to be started, then why is one being started at all? It has no functionality, other than to advertise itself, accept connections and cause problems.