Wifi connection loop: possible improvement.

[treepleks]

I have a poor wifi connection (RSSI around -80) and the network connection is unstable. By default, I understand the net loop restarts OpenEVSE in AP mode every 2 reconnect retries, for 5 minutes.

In my case, this ended up in a situation where the station remained in AP mode most of the time. Because I use the divert mode, this was creating issues with no update of the solar output while in AP mode. I often had to go to the garage and use my phone to reconnect the box to my network. A constant pain.

I modified the net loop and recompiled the firmware: after 2 retries, I instead reset wifi and let the box retry STA mode. I understand the AP mode can still be reached by pressing the touch button for a sufficiently long period of time.

This has been a game changer. Since then, the whole system has been working flawlessly. I do not need to go to the garage anymore. Night and day really. I imagine I'm not the only person in this situation. I could use a wifi repeater, but this uses money and power, and maybe a source of failure. Instead, a small code change does the job.

I can imagine that the OpenEVSE team wants to stick to this AP approach to facilitate the usage of the box when it is used as a mobile charger. But clearly, this destroys the reliability of the system for all people with weak wifi (which may be more numerous than mobile users in practice).

My suggestion would be to do the "try AP after 2 STA connect retries" only once at boot time, and then shift to a pure STA loop (with a long press or reboot still allowing to shift to AP mode). In mobile usage, when you use the box, you necessarily reboot (plug the box) when you want to use it, so you'll have the AP mode accessible. If you miss the AP mode time window, you can always unplug the box and retry or long press. For static users (most users I assume), this would lead to much more stable network connections.

Here are my naive changes (for a pure static user). If needed I could try to spend more time to code the proposal above and submit a PR, but it could take more time from me than from OpenEVSE experts.

if (isClientOnly && !WiFi.isConnected())
   {
     // If we have failed to connect turn on the AP
-    if(client_disconnects > WIFI_CLIENT_DISCONNECTS_BEFORE_AP) {
-      startAP();
-      client_retry = true;
-      client_retry_time = millis() + WIFI_CLIENT_RETRY_TIMEOUT;
+    if (client_disconnects > WIFI_CLIENT_DISCONNECTS_BEFORE_AP)
+    {
+      net_wifi_restart();
     }
   }
 
-  // Remain in AP mode for 5 Minutes before resetting
-  if(isApOnly && 0 == apClients && client_retry && millis() > client_retry_time) {
-    DEBUG.println("client re-try, resetting");
-    net_wifi_restart();
-  }

[glynhudson]

Thanks for the feedback, I agree it would be good to make the unit try harder to maintain a connection before reverting to WiFi AP. We'll consider the options for doing this.

[octera]

I think it was a typo for closing this one instead of the 424.
Should we reopen this issue?

[jeremypoulter]

Yes you are correct, thanks for the heads up

[KipK]

Yep sorry for the typo 😁

[pbix]

There is another scenario that relates to this bug. In my case if there is a power outage my network and charger both go offline. But as it seems to take much longer for my router to come back up than my charger I find that the charger is liable to get stuck in AP mode after every power outage.

I agree that the charger should try harder to remain in STA mode. And the power up sequence especially should be a time that more patience is employed in trying to connect to a Wifi AP that might still be initializing.

One more comment is that according to the Wifi ICON on the charger home page (when in AP mode) my Wifi signal appears to be weak but according to my phone in my hand right next to it the signal is 5 bars. So I wonder also why the ESP cannot obtain a good signal. I wonder if there is a source of radio interference in the charger that is really hobbling this Wifi. This something else that should be investigated.

[ruimarinho]

I have exactly the same problem as you @pbix - it's not a recurrent situation but when it happens it always causes trouble. I own several Shelly devices which I believe are on ESP32 and they offer the ability to keep AP mode always available plus connecting to two other independent WiFi networks. Bluetooth can also be used for provisioning. Perhaps some of that logic can be replicated?