2

I am stumped. I have a few Wemos D1 Mini boards that were working on the local WiFi yesterday, yet today none of them will connect. More puzzling is that I can flash Tasmota on them and they all connect to the WiFi, but none with this code that was working yesterday. Any tips would be appreciated. 

void setup_wifi() {
  delay(10);
  // We start by connecting to a WiFi network
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(wifi_ssid);

  //Connect to WiFi network so we can reach the MQTT broker and publish messages to topics.
  WiFi.mode(WIFI_STA);
  WiFi.begin(wifi_ssid, wifi_password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("");
  Serial.print(F("WiFi connected, "));
  Serial.print(F("IP address: "));
  Serial.println(WiFi.localIP());
}
VE7JRO
  • 2,515
  • 19
  • 27
  • 29
user3573562
  • 183
  • 1
  • 11

3 Answers3

1

Fixed. My router is ancient and does not support WPA. As of ESP8266WiFi library Version 2.5.0, WPA is is the preferred mode. The solution is to get a better router, or add WiFi.enableInsecureWEP(); before calling WiFi.begin().

WiFi.enableInsecureWEP();
WiFi.begin(wifi_ssid, wifi_password);
user3573562
  • 183
  • 1
  • 11
0

Solved. (sort of). This is a working workaround.

I have determined that if I use ESP8266WiFi library Version 2.5.0 or later, all I get from WiFi.status() is WL_NO_SSID_AVAIL.

By reverting to ESP8266WiFi library Version 2.4.2, I can get a connection with the same sketch.

(Juraj's comments pushed me in the direction of trying older library versions.)

user3573562
  • 183
  • 1
  • 11
0

Assuming that it's not something silly and accidental like the password or ssid being changed in your code, there are two things you may be running in to:

  1. The WiFi.begin() function is technically not needed more than once. Values written with it are stored in a separate part of flash memory that is not overwritten by any sketch uploads. Since it's stored persistently, it may start connecting before your connection code is called. This causes a race condition that triggers a bug in the library that is, to my knowledge, still present, and can break the WiFi subsystem. If this has happened, the reason that the other firmware might work is if it fixes the error or somehow uses a different method. You can work around this by waiting a few seconds and then trying to connect if it's not currently connected. Try this fix: https://github.com/kentaylor/EraseEsp8266Flash to see if that's the problem. Alternatively, you can try some of the options in the first link of my next item to see if those work for this purpose.

  2. Remember how I said that the functions persist data in flash? That has a limited write count, and no, that partition has no wear-leveling. After so many writes (and, since begin() is called in setup, it does so every time the device starts or wakes!) it will fail to hold the correct values. The endurance can be quite poor on some cheaper flash devices (and cheaper boards). But, if you want to keep using begin() to set up the WiFi (rather than set it once the normal way and then make sure begin() isn't called again by your code), delete the stored parameters (Does the ESP8266 somehow remember wifi access data?) and then turn off persistence (esp8266 advertising AP even when flashed with custom firmware). I also suggest running the following code fragment to turn off persistence and then stop turning it off (since THAT change persists too!):

    if (WiFi.getPersistent()) { WiFi.persistent(false); }

This latter case is known to break Arduino projects, but NOT nodeMCU Lua ones. If the Tazmota firmware uses a different method, it could also ignore this issue but your code might experience it. To test this, try running the code on a different board (can be the same type, just so long as it's not the same one).