3.6.0-RC2 / MQTT not reconnecting when AP/Router is down voor 2-3min on power outage

[fluppie]

Describe the bug MQTT doesn't reconnect after power outage since 3.6.0-RC2

To Reproduce Steps to reproduce the behavior: Cut power to your wifi AP/Router and SmartEVSE's at the same time. Then put power on same time SmartEVSE and Network AP/Router. Your AP/Router will need some time to reboot and the SmartEVSE's but you will see they will not automatically come back online. I tested by reverting to 3.5.1 and then to RC1, worked like expected. Updated to RC2, power cycled the router and EVSE's and they remain offline. HTTP interface is accessible, so I can reboot via the webinterface and then MQTT is connected.

Expected behavior Same as in 3.5.1 and 3.6.0-RC1

[fluppie]

Bit weird that it connected with RC1, because the only major MQTT code changes where from 3.5.1 to 3.6.0. https://github.com/dingo35/SmartEVSE-3.5/commit/83f1c70f41024448900a46f83c5bed3783455cd0

Or it was by accident? That RC1 sometimes connects and sometimes doesn't. On RC2 it never reconnects, for multiple hours (tried it overnight). Modem/Router/WiFi network is back online after +- 3min.

[dingo35]

I cannot reproduce this; if I kill my wifi and let it come back up, mosquitto nicely reports connected/offline, connected/online respectively. Within 10 seconds.

[Imaginous]

Maybe it has something to do with DHCP, since a fix between these 2 versions was the fact that incorrect DNS servers were used. 8.8.8.8 instead of the one supplied via DHCP.

[dingo35]

That would be easy to test, if you put ip address in the MQTT host fields dns is excluded....

[fluppie]

Aha yes, that makes sense. I use a DNS name "xxxxx.dyndns.org" because I monitor installs that are not in my own network.

[dingo35]

So your dhcp server is not (completely) up when wifi connection is established?

That would be a problem.....

[fluppie]

Looks like it, or we can increase the 1000ms delay to 5 or 10s? Or would that be blocking to the loop?

        case WiFiEvent_t::ARDUINO_EVENT_WIFI_STA_CONNECTED:
            _LOG_A("Connected or reconnected to WiFi\n");
            delay(1000);

            // //load dhcp dns ip4 address into mongoose
            // static char dns4url[]="udp://123.123.123.123:53";
            // sprintf(dns4url, "udp://%s:53", WiFi.dnsIP().toString().c_str());
            // mgr.dns4.url = dns4url;

Commenting it out solves my problem.

[dingo35]

Delaying to 5 or 10s wouldnt be good practice, and block the entire thread. What brand/model AP are you using?

[dingo35]

Your AP probably hands out its own ip as dns server (and then is too late to service it). It would probably be solved if you instruct your DHCP server explicitly to hand out 8.8.8.8 directly, so SmartEVSE doesnt have to wait.

[fluppie]

Teltonika, so probably need to add some DNS servers in a txt file

[fluppie]

Didn't manage to get the router config sorted. Commented out the code for now so the 8.8.8.8 is used. So kind of "closed" "solved" but maybe interesting to see if I'm the only one or others with other router HW have this.

[dingo35]

@fluppie can you find out which delay you need? If you need a delay(2000) or delay(3000) this might be acceptable if other users experience the same problem.....

[fluppie]

Nope, sadly doesn't work for me. So back to commenting out the code.

[dingo35]

That is too bad. You might want to try this one, I had to change some timeout params of the mongoose webserver to prevent a reboot on losing the wifi connection, its changed behaviour might influence your dhcp problem:

7aa8aff3.zip

[fluppie]

I'll have a master/slave setup available to test in the coming days. Keep you posted.

[fluppie]

@dingo35 this is even worse, they are not reconnecting to the wifi network anymore. Both after a power cycle (only EVSE's) and one even stopped connecting after the update to this 7aa8aff3 build. So I would not recommend this change.