ESP32 does not reconnect to Wifi

[LPG-PG]

What happened?

After an indefinite period of time, the ESP32 module loses the connection to the WiFi. No new DHCP lease is obtained, so neither web, API, MQTT nor ping works.

To Reproduce Bug

It happens ramdomly between 1 and 5 days

Expected Behavior

OpenDTU has to be reboot to fix it temporary

Install Method

Pre-Compiled binary from GitHub releases

What git-hash/version of OpenDTU?

v24.10.15

What firmware variant (PIO Environment) are you using?

generic_esp32

Relevant log/trace output

No response

Anything else?

I checked some parts of the code and I'm not sure, if there is a bug in NetworkSettings.cpp -> NetworkSettingsClass::applyConfig()
line 288ff

WiFi.begin(
            Configuration.get().WiFi.Ssid,
            Configuration.get().WiFi.Password,
            WIFI_ALL_CHANNEL_SCAN);

I mean, that Wifi.begin is called with Channel 1 because the enum WIFI_ALL_CHANNEL_SCAN value is 1.

The declaration of the called function is:

wl_status_t begin(char* ssid, char *passphrase = NULL, int32_t channel = 0, const uint8_t* bssid = NULL, bool connect = true);

So the third paramter is the channel, which is in this case 1.

Please confirm the following

• I believe this issue is a bug that affects all users of OpenDTU, not something specific to my installation.
• I have already searched for relevant existing issues and discussions before opening this report.
• I have updated the title field above with a concise description.
• I have double checked that my inverter does not contain a W in the model name (like HMS-xxxW) as they are not supported.

[Subnum12]

I have same issue.
I did try wifi reconnect while console log was enabled. For whatever reason the console gets disconnected while wifi is disconnect. However, that's the last output even I could not recreate the issue with manual wifi reconnect.

[2094941][E][WiFiClient.cpp:429] write(): fail on fd 48, errno: 113, "Software caused connection abort"
Disconnected from MQTT.
Disconnect reason:TCP_DISCONNECTED
Network lost co˫▒ѥ▒▒5
                     Websocket: [/livedata][5] disconnect

[tbnobody]

I mean, that Wifi.begin is called with Channel 1 because the enum WIFI_ALL_CHANNEL_SCAN value is 1.

You are right. at least the setting of WIFI_ALL_CHANNEL_SCAN is wrong at this place... did you try if it works better if you remove this parameter?

[stefan123t]

@tbnobody I think @LPG-PG is right, we maybe somehow using the wrong signature for the WiFi.begin() method.
We should be using the WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN) separately prior calling the WiFi.begin() method.

https://github.com/espressif/arduino-esp32/blob/352705e6077de4f0575324efa234814e823b9fb8/libraries/WiFi/src/WiFiSTA.cpp#L232-L240

The actual WiFi.begin() method obviously seems to have the signature as @LPG-PG reported:

https://github.com/espressif/arduino-esp32/blob/352705e6077de4f0575324efa234814e823b9fb8/libraries/WiFi/src/WiFiSTA.cpp#L83-L93

The issue seems to be in the „new credentials… “ code path of the NetworkSettings.applyConfig() method:

OpenDTU/src/NetworkSettings.cpp

Lines 279 to 298 in 3dc70ab

	void NetworkSettingsClass::applyConfig()
	{
	setHostname();
	if (!strcmp(Configuration.get().WiFi.Ssid, "")) {
	return;
	}
	MessageOutput.print("Configuring WiFi STA using ");
	if (strcmp(WiFi.SSID().c_str(), Configuration.get().WiFi.Ssid) || strcmp(WiFi.psk().c_str(), Configuration.get().WiFi.Password)) {
	MessageOutput.print("new credentials... ");
	WiFi.begin(
	Configuration.get().WiFi.Ssid,
	Configuration.get().WiFi.Password,
	WIFI_ALL_CHANNEL_SCAN);
	} else {
	MessageOutput.print("existing credentials... ");
	WiFi.begin();
	}
	MessageOutput.println("done");
	setStaticIp();
	}

If this is the case/cause somehow that code path gets active after 2-5 days for some yet unknown reason, but it should eventually show up in the logging.

[LPG-PG]

You are right. at least the setting of WIFI_ALL_CHANNEL_SCAN is wrong at this place... did you try if it works better if you remove this parameter?

I haven't tried it yet.

[pi-amp]

same here for me. Really anoying when you're away from the DTU... Hope it gets fixed !

[karamo]

Ich habe vor 2 Wochen von der 24.5.6 auf 24.11.7 upgedatet.
Die Folge waren permanente Abbrüche der WiFi-Verbindung.
Bin wieder zurück auf die bei mir funktionierende 24.5.6

I updated from 24.5.6 to 24.11.7 2 weeks ago.
The result was permanent lost of the WiFi connection.
I'm back to 24.5.6, which works for me.

[ms1958]

Guten Tag,
jetzt ist ja die Version 25.1.14 draussen. ist das Problem damit behoben ?
Ich bin solange auf die v24.6.29 zurück gegangen, und hatte bis dato keine verbindungsabbrüche mehr.

[Subnum12]

habe mit v25.1.14 seit Mittowch keine Abbrüche mehr. -> issue can be closed.

[andreas-bulling]

I have upgraded to 25.1.14 yesterday and today OpenDTU doesn't connect to Wifi anymore. No changes otherwise, in particular I haven't moved the device or anyting.

[Subnum12]

actually after almost a week running without any issue I got same error yesterday evening again.

[andreas-bulling]

I think they must have changed something on the wifi stack - or maybe wireless transmission power? The OpenDTU device is located in the basement. No wifi connection problems whatsoever since more than a year now.

With the new firmware it didn't connect. I now brought it upstairs, closer to an AP and it connects without problems.

Back in the basement it also connects now for some reason.

[ms1958]

Guten Morgen,
bin ich nach einem Test von 2 Wochen mit [v25.1.14] wieder zurück zur [v24.6.29]
Auch mit [v25.1.14] habe ich schon mehfach verbindungsverlust gehabt.
Dann muss ich jedesmal in die Garage die DTU Booten.
Nachts Bootet mein Router neu, dabei ist DHCP mal für 4min weg.
ich habe in der DTU schon eine feste IP vergeben, aber das nutzt nix.
Mit der [v24.6.29] habe ich jedenfalls diese Probleme nicht, Die verbindung bleibt über Monate bestehen.
Gruss, Manfred

Good morning,
after a 2 week test with [v25.1.14] I've gone back to [v24.6.29]
I've also had several connection losses with [v25.1.14].
I then have to go into the garage to boot the DTU.
At night my router reboots and DHCP is gone for 4 minutes.
I've already assigned a fixed IP in the DTU, but that's no use.
I don't have these problems with [v24.6.29], the connection stays up for months.
Best wishes, Manfred

[Heiko-L]

My last working version is also v24.6.29.
In all versions after that the whole device freezes (LEDs turn off too) if WiFi is lost.
Last output before freeze:

WiFi disconnected
Try reconnecting
[7163522][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 113, "Software caused connection abort"
Disconnected from MQTT.
Disconnect reason:TCP_DISCONNECTED
Network lost connection

SDK-Version v4.4.7-dirty
Konfigurationsversion 0.1.28
Firmwareversion / git Hash v24.6.29
PIO Umgebung generic_esp32
Chip-Modell ESP32-D0WD-V3
Chip-Revision 3
Chip-Kerne 2
CPU-Frequenz 240 MHz
CPU-Temperatur 26,1 °C
Flash-Speichergröße 4.194.304 Byte (4 MB)

[LPG-PG]

I changed the ESP32 Module and flashed the v25.2.3.
Since then i have a continuous and stable WiFi connection over 8 days. Additionally the RSSI value is 30dBm better (old -85dBm, now -55dBm).

I think a big part of my problem was probably caused by the ESP module itself.

[Heiko-L]

Have you turned off your WLAN AP(s) to check what happens when OpenDTU gets disconnected?
I only have ESP32-D0WD-V3s, so I can't check if other hardware revisions cause this problem.

[kopierschnitte]

Same observation here. Like @Heiko-L said, the ESP32 stalls if Wifi is lost. Happened last time when my Ubiquiti gear performed an update and switched off the APs for about 30sec.

Maybe a watchdog or simple reboot if there's no connection for a period of time would do the trick?

[LPG-PG]

Have you turned off your WLAN AP(s) to check what happens when OpenDTU gets disconnected? I only have ESP32-D0WD-V3s, so I can't check if other hardware revisions cause this problem.

I did some tests today. After turning the AP off and on again, the ESP module reconnected to the WiFi. I also tried using a Mash WiFi to turn off individual APs and all APs at the same time. The tests were repeated several times with the same result. I use Mikrotik devices.