Strange behaviour in ESP8266 AccessPoint was password related

In my previous article, I made a skeleton program for a tutorial about the various ways of WiFi connection of an ESP8266, I ran into an odd problem that turned ourt to be related to the password.
the code aimed to include both STA and AP connection and I set up the credentials like this.

#define WIFI_SSID "YOURSSID"
#define WIFI_PASS "YOURPASSWORD"

// Set AP credentials
#define AP_SSID "YOUR_DESIRED_AP_NAME"
#define AP_PASS "YOUR_DESIRED_AP_PW"

After uploading the acces point ofcourse identified itself as ‘YOUR_DESIRED_AP’ and I quickly set to correct my mistake of not filling out my credentials and I changed it to:

// Set AP credentials
#define AP_SSID "Pond"
#define AP_PASS "1234"

After uploading again, I was surprised to see that instead of the expected AP SSID ‘Pond’, I now saw ESP-859C2F, with the numbers being the last 3 bytes of my ESP’s MAC-number. Chosing that accespoint made me connect to the ESP without asking for a password.
what the heck was going on? I knew the code was allright as on myinitial upload I had seen the SSID of the AP when it was still called “YOUR_DESIRED_AP_NAME”.
To make a long story short: I found out the problem was with the password: apparently there is a problem with a password that is too short, or contains numbers.
1234–> no proper AP_SSID visible
abcd–>works well
abcd1234 –>no proper AP SSID visible
abcd123–> works well.
So initially I thought that perhaps the amount of letters needed to be bigger than the amount of numbers in th epassword.
but ‘1234567’ worked fine….till I tried ‘123456’ which did not work, and then ‘1234567’ did not work either anymore and i had to go to ‘12345678’ to make it work.
Note: I uploaded the sketches with the “Tools-erase all flash content set”.
So I am still not entirely sure the exact problem, but I do know that numbers in the password apparently can cause problems with the AP

Advertisement

2 thoughts on “Strange behaviour in ESP8266 AccessPoint was password related”

  1. Short answer, make sure to set
    WiFi.persistent(false);
    and
    WiFi.setSleepMode(WIFI_NONE_SLEEP); // even on battery / sleep devices
    This is right in my setup() source code since late 2015.
    // WiFi Setup, note:
    /* it has come to my attention, that the WiFi stack writes to Flash excessively,
    * involving: WiFi.mode(WIFI_STA); WiFi.begin(id, pass);
    * It may do so during reconnects as well
    *
    * It is now important to include WiFi.persistent(false);
    * If its a brand new unit, I guess the settings, can be saved.
    * Word is the Expressif SDK is doing this.
    * The WiFi stack is a binary blob, due to radio device certification requirements.
    * The FLASH issue was first uncovered in:
    * https://github.com/esp8266/Arduino/issues/1054, and fixed by ‘igrr’,
    * on or about Nov 20 2015.
    * It is when the new WiFi.persistent(); was added, and the docs updated
    * https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/generic-class.html
    */
    Back then, this issue came up when I was first working with esp8266. Weeks spent fixing WiFi.
    I found that they would NOT get back on WiFi on their own if I reset the main router. I faced the prospect of running around resetting all these devices by hand.
    Now they have been running some 5+ years, some have been up for many months at a time.
    I found your article during my upgrade to Node-RED / InfluxDB, these past weeks.
    I have had better luck with WiFiMulti, it was more stable at the time (2015), and covers me if I take one to the cottage.
    With a new unit run WiFi.persistent(true),
    do your tests, then set to ‘false’ thereafter, and re-flash.
    If fact, you can delete the ssid, password lines after running ‘true’ once, re-flash, and it will still get on your network, using what it has stored in the WiFi binary blob internal flash.
    Lots of code examples are still running around out there without the WiFi.persistent() command , and people are killing that WiFi flash, making things unstable or worse bricking them.
    My network password is the MAX length allowed, so never had issue with password too short.
    I found hostname settings are ignored. Default is ESP-xxxxxx. (x= last parts of MAC).
    I gave up on hostname, and let Python deal with it.
    Python passes tested valid data to MQTT.
    I have ESP-xxxxxxxx host names in a dictionary row for each device, along with other settings, such as battery voltage calibration. Python issues WARN , or ERROR if problems come up, like low battery. Logging is normally set to INFO logging level to a file. You have a timestamp when you lost a device and other debug info. I’m finding I’m blind in Node-RED when things go wrong.
    code:
    //TOP
    static const char ssid[] = “your_network”;
    static const char password[] = “your_passwd”;
    static const char ssidB[] = “your_B_network”;
    static const char passwordB[] = “your_B_passwd”;
    MDNSResponder mdns; // WiFi: multi WiFi, can’t remember what this does
    ESP8266WiFiMulti WiFiMulti; // WiFi: multi WiFi
    ESP8266WebServer server(80);
    WebSocketsServer webSocket = WebSocketsServer(81); // my data that python gets
    // in setup() ,
    WiFi.persistent(false); // save your WiFi radio flash. If not included here, default is ‘true’
    // this default ‘true’ behavior is hard coded in the Espressif WiFi binary blob, discovered in 2015
    Serial.println(F(” setup: set WiFi modes: WIFI_STA, WIFI_NONE_SLEEP”)); WiFi.mode(WIFI_STA); //
    WiFi.setSleepMode(WIFI_NONE_SLEEP); // AC powered devices dropped off net without this
    Serial.println(F(” setup: set WiFi AP(s)”));
    WiFiMulti.addAP(ssid, password); // add local netowork credentials, start (wait on) WiFi
    WiFiMulti.addAP(ssidB, passwordB); // add optional additional netowrks
    Serial.println(F(” setup: wait on WiFi connect ( half second per dot) “));
    // wait
    while (WiFiMulti.run() != WL_CONNECTED) {
    delay(1000);
    Serial.print(F(“. “));
    }
    Serial.println(F(” setup: done waiting for WiFi”));
    Best of luck.

    1. Thanks for your input Dave. I think i discusses the WiFi.persistent in my article about deepsleep. I may want to start using it too in none deepsleep applications. I do use the wifimulti on occasion, but since i also like static IP’s that’s a bit hard to combine.
      Have given up on hostname pretty much too.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: