After WiFi lost OpenDTU can not reconnect

[PaluZoli]

Hello,
I use OpenDTU since a week. I have installed it to its final place in the basement. I have there a secondary WiFi access point.
2200 to 0600 it switches itself off. It seems that the OpenDTU after looses connection is not able to reconnect when the WiFi is again available. After a reset it preforms fine whole day long. I will leave the WiFi active for the night to prove my theory.
As a reference my Tasmota based devices are able to handle this situation.
Are there any settings which could improve the behavior?
What can I do to debug the behavior so that it could be corrected?

[PaluZoli]

Hi,
Through last night I have left the access point on. There was no problem with OpenDTU. So it has definitely a re-connection issue.
The HW seems to run. The TX pin connected Red led on the dev bord blinks each 30s which is my poll interval. But it is not answering on its IP address.
HW is:

• AZ-Delivery ESP32 NodeMCU Module
• AZ-Delivery RF24L01+ with external antenna
  SW is:
• SDK Version: v4.4.2
• Config Version: 0.1.23
  WiFi:
• Quality: 96 %
• RSI: -52

[PaluZoli]

Hi,
I have updated the SW to the latest stand. With Wifi off through the night on the morning I could not reach the OpenDTU.
Is there a way to debug / log what is happening?
Please respond and help if you have ideas.

[koerri]

My test showed that once the Wifi network "disappears", OpenDTU will switch to AP mode, i.e. it opens up its own Wifi network (OpenDTU-xxxxxxx), just like during basic setup. After a few minutes that AP will be closed and if by then the original Wifi is back on, OpenDTU will reconnect.
I did not test a multi-hour Wifi interruption though.

Issue #404 has an example of some kind of software reset based on Wifi connection state, maybe that could be used in your situation?

[PaluZoli]

Thanks,
At least it seems not to be an unique problem. Any suggestions how to debug it?
Shell I search in code the reconnect counter? With tasmota there is a setting wificonfig which after loosing the wifi either starts the web server or simply waits for wifi reappearing.

Since I have seen many discussion in German, what is the preferred language? I can speak both.

[koerri]

Sorry, I've got no idea about the code, I'm totally new to all this.
Regarding the language I'm just as puzzled as you are. :-)

[PaluZoli]

Hi,
Meanwhile I have checked the source code of OpenDTU. I have found only one instance where the WiFi.reconnect() function is called.
// in NetworkSettings.cpp line 74. //
I have checked the ESP32 WiFi.reconnect() examples. In each example there is a WiFi.disconnect() function call before WiFi.reconnect() call. https://randomnerdtutorials.com/solved-reconnect-esp32-to-wifi/
The way of handling differs from OpenDTU realization where only WiFi.reconnect() is called but without WiFi.disconnect() before.
/ NetworkSettings.cpp line 74.
It could be the reason of my reconnecting issue.
Could someone recompile the code with the above suggested enhancement? Does it makes sense to include it in main release?

[PaluZoli]

Hi,
I have compiled the code with the above discussed change. Now I have no reconnect issues.
I would suggest to include this change in main branch too.

[tbnobody]

Thats interessting, because reconnect calls disconnect internally....

/**
 * will force a disconnect and then start reconnecting to AP
 * @return true when successful
 */
bool WiFiSTAClass::reconnect()
{
    if(WiFi.getMode() & WIFI_MODE_STA) {
        if(esp_wifi_disconnect() == ESP_OK) {
            return esp_wifi_connect() == ESP_OK;
        }
    }
    return false;
}

/**
 * Disconnect from the network.
 * @param wifioff `true` to turn the Wi-Fi radio off.
 * @param eraseap `true` to erase the AP configuration from the NVS memory.
 * @return `true` when successful.
 */
bool WiFiSTAClass::disconnect(bool wifioff, bool eraseap)
{
    wifi_config_t conf;
    wifi_sta_config(&conf);

    if(WiFi.getMode() & WIFI_MODE_STA){
        if(eraseap){
            if(esp_wifi_set_config((wifi_interface_t)ESP_IF_WIFI_STA, &conf)){
                log_e("clear config failed!");
            }
        }
        if(esp_wifi_disconnect()){
            log_e("disconnect failed!");
            return false;
        }
        if(wifioff) {
             return WiFi.enableSTA(false);
        }
        return true;
    }

    return false;
}

[PaluZoli]

Hallo,
Ich muss zugeben, ich habe mich nicht so tief ins code eingegraben. Ich habe die oben genannte Beispiel mit die reconnect vorgang in NetworkSettings.cpp vergleicht.
Tatsache ist aber dass basiert auf letzte Nacht, mit die obere Erweiterung morgen war die OpenDTU problemlos erreichbar.

[SebStaeubert]

Das Problem scheint mit der aktuellen Firmware nicht behoben zu sein.
Erst nach einem Neustart kommt wieder eine Verbindung zustande.

[mhin76]

Ja. Ist bei mir leider genau auch so. Bei mir läuft 24.9.30. mein WLAN schaltet sich in der Nacht aus. Am Morgen muss ich den OpenDTU jeweils neu starten.

[SebStaeubert]

Update: Bei mir ist die Verbindung nun stabil und wird auch nach einer Unterbrechung wieder hergestellt!

Ich hab die neuste Version 24.10.6 installiert.

Ich habe aber auch die WLan-Verbindung verbessert, d.h. der bisherige Repeater hat eine neue Position. Das lief eine Woche gut. Aus anderen Gründen hab ich ihn heute zudem durch ein Outdoor Repeater ersetzt. Auch damit scheint es keine Probleme zu geben.

[mhin76]

I updated to latest version but still it does not reconnect anymore after wifi gets available again. Very strange. no idea why. We did switch router, but it is the same brand at the same location and I think even uses the same band. I am a bit puzzled. will try to reproduce it during the day by switching wifi off and on again. will post any findings here.

[mhin76]

Update: I downgraded to version v24.6.29 and do not have any issues anymore with WiFi connecting back after the WiFi night outage!! Will, when I have time, slowly upgrade to find out after which firmware the issue occurs!

[Hannes58]

I now can confirm that this issue does not happen with 24.6.29 where 24.11.7 did not reconnect.

[Harryauso]

Ist bei mir leider genau auch so. Bei mir läuft 24.11.7 bei einer Internet neu Anmeldung in der Nacht keine Verbindung mehr. Am Morgen muss ich den OpenDTU jeweils durch Sterkernetzteil ziehen neu starten, dann ist alles wieder in Ordnung.

[Hannes58]

Ich habe vermutlich genau das gleiche Problem. Meine DTU fährt v24.11.7 und auch hier muss ich seit ein paar Tagen morgens die Stromversorgung kurz trennen um wieder connecten zu können.

Router ist Speedport, es gibt zwei Repeater im WLan.

Habe jetzt mal die 24.6.29 geladen und vergleiche das Verhalten.

Update: Mit Version 24.6.29 tritt das Verhalten nach downgrade nicht mehr auf.

[mhin76]

genau wie bei mir. version 24.6.29 läuft stabil

[mroenne2022]

Bei mir läuft die aktuelle Version vom 7.11.24 , reconnect nach WLAN Abschaltung klappt problemlos. Als Router läuft bei mir ein Speedport Smart4 ohne jegliche Repeater.
Ein Bekannter von mir hat allerdings auch Probleme, er nutzt eine FritzBox und mehrere Repeater.

[Harryauso]

Ja, habe auch eine FritzBox.

[mroenne2022]

Ich habe den Verdacht das es damit was zu tun hat 🤷‍♂️

[mhin76]

interessant, danke für deinen Erfahrungsbericht. bei mir läuft version 24.6.29 stabil. OpenDTU verbindet sich jeden Morgen, wenn WLAN wieder eingeschaltet wird. Bei neueren Firmware klappt das leider nicht mehr. Daher glaube ich nicht, dass es was mit dem AccessPoint zu tun hat, zumindenst nicht bei mir :(

[Saharel001]

Ich habe TP-Link Access-Points und habe das selbe Problem. Nur die Open-DTU kommt nicht mit einem Neustart der AP's klar. Alle andern Gerät (Auch ESP32, kommen damit klar)

[maroviher]

Ich habe die Version v25.2.3 (SDK v4.4.7-dirty) und kann das Problem bestätigen. Die Verbindung geht nachts verloren und es hilft dann nur power off/on damit ich opendtu wieder erreichen kann

[Gelegenheitsbastler]

Ich schließe mich dem an. FritzBox mit mehreren AP im Mesh. Immer mal wieder kommt es (Grund nicht zu finden) zu sporadischen Wlan-Verbindungsverlusten von OpenDTU. Ein Reconnect findet nicht erfolgreich statt. Es hilft nur ein Reset. Das ist sehr ärgerlich, da ich nicht täglich danach schaue und so die Ertragsstatistik total ungenau wird.

Hat das mal jemand an die Entwickler weiter gegeben?

[Gelegenheitsbastler]

I've created a hardware solution for the problem. Anyone interested is welcome to test it and report back.

Ich habe eine Hardware Lösung für das Problem erstellt. Wer Interesse hat darf gerne mit testen und dann berichten.

#2624

[holle75]

selbes Problem hier mit aktuellster 25.5.10.

Besonders unschön daran ist, dass bei einer Insellösung, bei Notabschaltung (warum auch immer ... und dann alle deine Router/AP´s erstmal offline sind) und Recover du sowieso am Rennen bist und genau zu der Zeit keinerlei Infos über dein AC-Coupling hast.
Wenn dann noch das openDTU-"Kästchen" weit weit weg steht, kann das deutlich stören.

Auch bei mir hilft nur mindestens 30 Sekunden Stromversorgung (die dann wieder da ist) zu trennen.

Strom weg, somit alle Komponenten (MikroInverter, Inselnetz, Wlan, openDTU) aus
Strom wieder da, alles fährt hoch, openDTU verbindet sich nicht.

An welcher Stelle es genau zickt, konnte ich noch nicht herausfinden. Was mich wundert: openDTU wird bei diesem Ablauf neu gestartet. Also genau das was normalerweise das Problem löst.

[schneeer]

Hi,

ich wolltte hier in OpenDTU wegen Überheblichkeit und Ignoranz der Admins eigentlich nie mehr aktiv sein, ich mach mal eine Ausnahme.

Direkt helfen kann ich dir auch nicht, aber vieleicht hilft mein Gedanke über die Entwickler allen Betroffenen.

Ähnliche Probleme hatte ich in eigenen Projekten teilweise auch, insbesondere, wenn der ESP32 doch ein bischen beschäftigt ist.
Teilweise kein Neuverbinden nach Neustart des ESP32, nach der Zwangstrennung des Routers oder beim Neustart des Routers.
Manchmal ist der ESP32 der Meinung, die Verbinung steht noch bzw. wieder, dann aber mit IP 0.0.0.0 (keine IP per DHCP bekommen, obwohl der Router immer die selbe IP vergibt).

Was mir aber richtig gut geholfen hat (wenn sich die Verbindung nicht mehr aufbaut oder die IP 0.0.0.0 ist) ist, darauf hin zu überwachen und den WLAN Chip mal komplett für 2 Sekunden ausknipsen ( WiFi.mode(WIFI_OFF); ) und danach wieder anknipsen ( WiFi.mode(WIFI_STA); und WiFi.begin(ssid, password); ) . Das klappt schnell und super.

Ich habe mir nicht die Mühe gemacht den Programmcode von OpenDTU dahingehend zu analisieren. Kann sein, das sowas da schon drinne ist.

[holle75]

Danke dir.

[schneeer]

Nicht der Rede wert.
Wenn es mal implementiert ist und das WLAN-Neuverbinden tatsächlich auch bei der OpenDTU verbessert, könnte nochmals Dank angebracht sein.
Vorerst erstmal abwarten, ob sich hier überhaupt was dahingehend tut.
Es ist zwar erst ein Tag vergangen; geäusert hat sich bisher dazu noch kein Entwickler. Es ist aber auch Urlaubszeit und Job und Familie haben sie sicher auch noch.

[holle75]

Eben (Nacht) wieder 30 Minuten auf dem Speicher verbracht und versucht eine Verbindung herzustellen. Mein Mobile hat sich nach Sekunden mit dem fast danebenstehenden AP verbunden. openDTU konnte ich auch nach den 30 Minuten noch nicht überreden. Hab mehrmals stromlos probiert. Vielleicht haben die Minuten nicht gereicht.

Vielleicht hängt es auch mit dem momentan ausgeschalteten Mikro zusammen?

Es wäre doch sehr schön, wenn da mal "jemand beigehen" könnte, wie der Norddeutsche sagen würde.

EDIT: ist übrigens keine fritze sondern ein TP-Link mit openWRT.
Edit2: nach ca einer Stunde plötzlich wieder online. Schon seltsam ....

[schneeer]

Mit dem offlinen WR hängt das nicht zusammen, d.h. sollte nicht, die OpenDTU bekommt nur keine Daten.

Ich kenne das auch von eigenen Projekten; der ESP32 oder hier die OpenDTU ist einfach unmotiviert.
Man ist ja auch noch von Expressif abhängig bzw. muss als Entwickler reagieren, wenn die an ihren Zeugs etwas verschlimmbessern.
Wer will kann sich hier mal umschauen: https://github.com/espressif/arduino-esp32 Andere haben noch ganz andere Probleme.
Meinen Lösungsansatz für das schlechte WLAN-Neuverbinden hatte ich ja schon geschrieben.