search

absalom-muc / MHI-AC-Ctrl

Reads and writes data (e.g. power, mode, fan status etc.) from/to a Mitsubishi Heavy Industries (MHI) air conditioner (AC) via SPI controlled by MQTT
MIT License
270 stars 61 forks source link

Wifi reconnect takes too long #125

Closed glsf91 closed 1 year ago

glsf91 commented 1 year ago

I was testing what is happening when my wifi is failing. I know the AC will switch off after 120 seconds. But I saw some strange behavior when blocking and unblocking my Wifi. I (un)block the esp in my AP to test this. I also added some extra debug to show the behavior. The esp was not connected to the airco to make testing easier (removed logging mhi_ac_ctrl_core.loop error). ESP with airco connected has the same behavior.

I observed:

variable WiFiStatus

When I restart the ESP, variable WiFiStatus stays WIFI_CONNECT_ONGOING until first WiFI_SEARCH_FOR_STRONGER_AP_INTERVALL has passed (default 12 minutes) and WiFI_SEARCHStrongestAP = true. This is because it won't call setupWiFi until that moment.

This will influence reconnecting when I block and unblock the Wifi. When I Block my Wifi and for example after 2 sec I unblock my Wifi, it won't reconnect immediately (because of "if(WiFiStatus != WIFI_CONNECT_ONGOING"). It will reconnect after the next WiFiStatus = WIFI_CONNECT_TIMEOUT occurred. At most 10 seconds later. See log: WifiStatus.txt

I don't know if this is intended behavior.

Reconnect Wifi

When the WiFiStatus = WIFI_CONNECT_OK (after the first WiFI_SEARCH_FOR_STRONGER_AP_INTERVALL has passed), I blocked the Wifi. Then I got a lot of MQTTreconnect() messages. When I unblock my Wifi, It takes until WiFI_SEARCH_FOR_STRONGER_AP_INTERVALL (12 min) has passed before setupWiFi() is called again. Then it will reconnect. So this will take at most 12 min. See log: WIFI_CONNECT_OK .txt I changed WiFI_SEARCH_FOR_STRONGER_AP_INTERVALL to 2 minutes for testing. So in the log you will see faster reconnect.

I don't think this was intended behavior. It should reconnect right away when possible.

buennerbernd commented 1 year ago

I also observed this. See https://github.com/absalom-muc/MHI-AC-Ctrl/issues/75#issuecomment-1313725538 With WiFI_SEARCHStrongestAP = false it works much better, no Airco switch off anymore. WI-FI interrupts are no problem. My proposal is to do the WI-FI scanning async as mentioned in the linked comment.

glsf91 commented 1 year ago

With WiFI_SEARCHStrongestAP = false it works much better, no Airco switch off anymore. WI-FI interrupts are no problem. My proposal is to do the WI-FI scanning async as mentioned in the linked comment.

I think you are right. Then you get the first part I described (WiFiStatus stays WIFI_CONNECT_ONGOING). It will reconnect in at most 10 sec.

buennerbernd commented 1 year ago

I have an idea why the reconnect might take that long. Perhaps the ESP identified a stronger access point but the WI-FI mesh has a different opinion. So as a steering measure the selected access point denies the connection. Just guessing.

glsf91 commented 1 year ago

No, it takes that long because setupWifi() is only called in certain situation, as I described.

absalom-muc commented 1 year ago

Please replace row 397 of MHI-AC-Ctrl.ino if (((WiFi.status() != WL_CONNECTED) & (WiFiStatus != WIFI_CONNECT_OK)) || (WiFI_SEARCHStrongestAP & (millis() - previousMillis >= WiFI_SEARCH_FOR_STRONGER_AP_INTERVALL*60*1000))) { by if (((WiFi.status() != WL_CONNECTED) | (WiFiStatus != WIFI_CONNECT_OK)) || (WiFI_SEARCHStrongestAP & (millis() - previousMillis >= WiFI_SEARCH_FOR_STRONGER_AP_INTERVALL*60*1000))) { I believe it addresses both problems.

glsf91 commented 1 year ago

This indeed fixes both problems.

Please also see my last comment on my pull request after it was closed.

absalom-muc commented 1 year ago

fix implemented in v2.6 release