Nach WLAN-Router Neustart keine Verbindung mit der DTU

[Juergen2453]

What happened?

Sobald mein WLAN-Router neu gestartet wird Verbindet sich die DTU nicht mit dem WLAN. Kein ping oder sonst etwas.
Das Problem ist erst seit der Version vom v24.8.1, vorher gab es die Probleme nicht.
Getestet mit einem ESP32 und mit ESP32-S3 (OpenDTU Fusion 2.x).
Auf beiden Boards ist der Fehler wiederholbar (ob original Firmware oder selbstgebaut).
An meiner WLAN-Konfiguration hat sich seit Jahren nichts geändert.

To Reproduce Bug

keine Verbindung

Expected Behavior

Verbindung mit WLAN

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

v24.8.1

Relevant log/trace output

No response

Anything else?

No response

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.

[mroenne2022]

@Juergen2453 : bei mir gestern genau so passiert , gleiche Version, gleiches Verhalten. DTU einmal stromlos schalten hat geholfen.

[tm-107]

Gleiches Problem hier, ebenfalls reproduzierbar.
VG

[tbnobody]

an der stelle wurde absolut nichts geändert. es gab nicht mal ne neue core version.
daher... konsolen ausgabe.

[tbnobody]

hm was sich schon geändert hat ist #2117 was aber eigentlich alles besser machen sollte.
tritt das nur 1x nach nem udpate auf und nach einem power cycle nicht mehr oder reproduzierbar immer? (console output)

[SteffenR87]

I have installed the usb image on latest fusion board yesterday afternoon. It worked perfectly. Today I have no opendtu connected to my WiFi. Maybe there was a nightly disconnect. I will check this evening and reboot the board.

[Juergen2453]

Gerade vom Ausflug wiedergekommen, WLAN-Router aus und eingeschaltet und dann keine Verbindung mehr zur DTU.
liegt es vielleicht ah [Fix: explicitly disconnect prior connecting to wifi].

[tbnobody]

Bei mir lief es mit dem fix 2 Wochen ohne Probleme durch. Müsste also jemand die eine Zeile entfernen, bauen und testen. Ich kann es nicht machen, weil wie gesagt, keine Probleme.

[Juergen2453]

Meinst du die Zeile 30 und 82 ?
Und ich bin ja nicht der einzige der das Problem hat.

Das 2 Wochen durchlaufen ist auch nicht das Problem, WLAN-Router aus und einschalten dann haben wir das Problem

[SteffenR87]

Ich kann es leider aktuell nicht testen, da nicht daheim. Aber meine Fritzbox 6490 Cable sagt:

Das Gerät war zuletzt am 03.08.2024, 14:42 aktiv.

Also irgendwie scheint es sich erfolgreich zu verbinden und ist dann wieder weg.

Firmware-Update hatte ich gestern ca 18 Uhr gemacht und die Werte via MQTT kamen bis heute 4:56 Uhr zu Homeassistant rein.

[tbnobody]

Meinst du die Zeile 30 und 82 ?

Ja

[tm-107]

Kann ich hier auch beliebig oft reproduzieren. Sobald ich den WLAN-Router neu starte, baut OpenDTU keine Verbindung mehr auf.
Das System an sich läuft weiter, erkennbar am Display. Es wird aber dann halt keine IP mehr angezeigt.
Zum selbst Bauen fehlt mir leider die Erfahrung und die Software-Umgebung 🤷🏼‍♂️

[Kroki0815]

Bei mir das Selbe:
Nachdem ich meine Fritz!Box upgedatet habe ist die DTU nicht mehr erreichbar. Ich dachte erst, dass es das Update der Box ist und habe daraufhin die DTU in mein Smarthome-Wlan migriert. Aber hier zeigte sich das gleich Verhalten. OpenDTU nicht erreichbar ! Nun habe ich die DTU auf die vorige Version downgegraded und alles ist wieder OK !

Gruß Thorsten

[Tomashaglund1]

Same problem here updated from 24.6.29 to 24.8.1 and DTU was lost unable to ping.
Restored 24.6.29 and all working again

[SteffenR87]

Ich biete mich gern an, eine generic_esp32s3_usb zu testen. Wenn du mir eine baust. Ich bin nicht daheim. Aber einmal stecke ziehen von der dtu und wieder rein hat erstmal geholfen und aktuell ist diese wieder im Netzwerk erreichbar. Wahrscheinlich steigt die dann wieder nach X Stunden aus

[Juergen2453]

Was ich auf die schnelle festgestellt habe,
wenn ich die beiden Zeilen die Zeile 30 und 82 entferne verbindet sich die DTU mit dem WLAN-Router.
Wenn die beiden Zeilen drin sind, keine Verbindung zum WLAN-Router aber intern läuft die DTU weiter,
man sieht die Kommunikation mit dem WR, der AP wird auch aktiv.

Die 24.6.29 läuft Problemlos. Leider habe ich heute nicht mehr Zeit um weiter zu Testen.

[tbnobody]

@jstammi do you have a opinion about this issue?

[MichaelPankow]

Der Commit von #2117 hat offensichtlich nichts damit zu tun: Nachdem ich die beiden Disconnects herausgenommen habe, geht der Reconnect nach WiFi Aus/An in der Fritzbox trotzdem nicht. Nur ein Restart der Dtu hilft.

[jblond4711]

Bei mir gibt es das Problem auch. Heute Vormittag war OpenDTU noch mit dem Router verbunden und als ich eben mit dem Pad auf das WebIF zugreifen wollte tat sich nichts.
Auf dem Display lief es außer das die IP Adresse nicht mehr angezeigt wurde. Mir blieb nichts anderes übrig als die OpenDTU kurz vom Strom zu trennen nach dem Neustart war die WLan Verbindung wieder da.
Da es leider noch keine Offizielle Möglichkeit gibt die Daten auf SD Karte zu speichern bin ich auch erstmal wieder auf die v24.6.29 gegangen.

@ tbnobody
kannst du dir mal bitte die SD Karten Implementation aus den Pull requests #2125 anschauen und in die offizielle Version übernehmen!

[Fokker-1]

Ich habe seit Update auf die v24.8.1 (Version: opendtu-generic_esp32s3_usb.bin) vor 2 Tagen das gleiche Problem, allein heute war die Fusion DTU 3x nicht mehr erreichbat (Handy, PC), musst sie jedesmal wieder aus- und einschalten.

Wäre super, wenn die v24.6.9 temporär wieder verfügbar wäre - danke.

Gruß
Werner

[mroenne2022]

@Fokker-1 :
Die ganzen vorherigen Versionen findet man eigentlich hier:
https://github.com/tbnobody/OpenDTU/releases
Allerdings nicht v24.6.9 , aber 6.10 und 6.29

[Fokker-1]

@ meoenne2022

Hi,

vielen Dank!
Irgendwie hatte ich noch nicht registriert, dass man dazu erst "assets" klicken muss :-(

Habe mir jetzt die 6.29 geladen und bin gespannt, ob das Problem da auch auftritt.

Gruß
Werner

[mroenne2022]

@Fokker-1 : Nein die 6.29 hatte das Problem glaube ich nicht.

[Fokker-1]

@Fokker-1 : Nein die 6.29 hatte das Problem glaube ich nicht.

DANKE!

[hemagi]

Ich bin von dem Problem auch betroffen, Nachts geht die Verbindung verloren, ich bekomme aber nach stromlos machen häufig keine neue Verbindung.

Kann ich einen Downgrade machen und einfach ein älteres Release wie etwa die v24.6.29 drüberinstallieren, oder muss ich dann neu konfigurieren?

[Fokker-1]

Ich bin von dem Problem auch betroffen, Nachts geht die Verbindung verloren, ich bekomme aber nach stromlos machen häufig keine neue Verbindung.

Kann ich einen Downgrade machen und einfach ein älteres Release wie etwa die v24.6.29 drüberinstallieren, oder muss ich dann neu konfigurieren?

Ich habe die ältere FW v24.6.29 einfach neu drüber installieren, alles ok.

[tbnobody]

Wenn niemand die Ausgabe der Seriellen Konsole mitliest und hier zur verfügung stellt wird es recht schwer da weiter zu kommen... und wenn 50 Leute schreiben das sie das gleiche Problem haben ändert das ebenfalls nichts.
Es ist wichtig zu wissen ob eine Exception Auftritt oder das WiFi aus anderen Gründen nicht Neu-Verbinden kann.

[Juergen2453]

Ich habe jetzt 4-5 mal alles wiederhole immer das selbe Ergebnis.
mit Zeile 30,82 Probleme, die Zeilen entfernt alles ok.
Ich hoffe es hilft etwas, das einzigste was ich sehe ist nur die Reihenfolge der Netzwerk-Befehle.

mit Zeile 30 , 82 danach kommt keine Zeile mehr mit WiFI oder Network oder Dis...

06:46:20.842 > WiFi disconnected
06:46:20.842 > Try reconnecting
06:46:20.845 > [117016][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 113, "Software caused connection abort"
06:46:20.862 > Disconnected from MQTT.
06:46:20.863 > Disconnect reason:TCP_DISCONNECTED
06:46:20.870 > Network lost connection
06:46:20.875 > Fetch inverter: 114171419120
06:46:20.879 > TX RealTimeRunData Channel: 75 --> 15 71 41 91 20 80 11 11 60 80 0B 00 66 B0 59 1B 00 00 00 00 00 00 00 00 1E 12 67
06:46:20.924 > Interrupt received
06:46:20.925 > RX Channel: 23 --> 95 71 41 91 20 71 41 91 20 01 00 01 01 35 00 18 00 4A 01 36 00 18 00 4B 00 0F 98 | -80 dBm
06:46:20.985 > Interrupt received
06:46:20.986 > RX Channel: 23 --> 95 71 41 91 20 71 41 91 20 02 36 A7 00 0F 0D 32 00 02 00 02 08 E0 13 86 00 8E C5 | -80 dBm
06:46:21.007 > Interrupt received
06:46:21.009 > RX Channel: 23 --> 95 71 41 91 20 71 41 91 20 83 00 00 00 06 03 E8 00 C0 00 03 04 44 78 | -80 dBm
06:46:21.418 > RX Period End
06:46:21.419 > Success
.

---

ohne/entfernt Zeile 30 , 82

07:07:17.882 > WiFi disconnected
07:07:17.882 > Try reconnecting
07:07:17.884 > Network lost connection
07:07:17.885 > [256324][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 113, "Software caused connection abort"
07:07:17.898 > Disconnected from MQTT.
07:07:17.898 > Disconnect reason:TCP_DISCONNECTED
07:07:17.900 > Fetch inverter: 114171419120
07:07:17.904 > TX RealTimeRunData Channel: 3 --> 15 71 41 91 20 80 11 11 60 80 0B 00 66 B0 5E 04 00 00 00 00 00 00 00 00 F4 2F A8
07:07:18.046 > Interrupt received
07:07:18.047 > RX Channel: 40 --> 95 71 41 91 20 71 41 91 20 83 00 00 00 0D 03 E8 00 C5 00 05 A8 FF 67 | -80 dBm
07:07:18.443 > RX Period End
07:07:18.444 > Middle missing
07:07:18.444 > Request retransmit: 1
07:07:18.445 > TX RequestFrame Channel: 23 --> 15 71 41 91 20 80 11 11 60 81 F5
07:07:18.492 > Interrupt received
07:07:18.493 > RX Channel: 61 --> 95 71 41 91 20 71 41 91 20 01 00 01 01 3B 00 30 00 96 01 3C 00 30 00 96 00 0F 9D | -80 dBm
07:07:18.575 > RX Period End
07:07:18.576 > Middle missing
07:07:18.576 > Request retransmit: 2
07:07:18.577 > TX RequestFrame Channel: 40 --> 15 71 41 91 20 80 11 11 60 82 F6
07:07:18.706 > RX Period End
07:07:18.706 > Middle missing
07:07:18.706 > Request retransmit: 2
07:07:18.708 > TX RequestFrame Channel: 61 --> 15 71 41 91 20 80 11 11 60 82 F6
07:07:18.838 > RX Period End
07:07:18.838 > Middle missing
07:07:18.838 > Request retransmit: 2
07:07:18.840 > TX RequestFrame Channel: 75 --> 15 71 41 91 20 80 11 11 60 82 F6
07:07:18.874 > Interrupt received
07:07:18.875 > RX Channel: 23 --> 95 71 41 91 20 71 41 91 20 02 36 AA 00 0F 0D 36 00 05 00 06 08 E6 13 89 01 1E 57 | -80 dBm
07:07:18.969 > RX Period End
07:07:18.969 > Success
07:07:20.296 > WiFi disconnected
07:07:20.296 > Try reconnecting
07:07:20.298 > Network lost connection
07:07:22.712 > WiFi disconnected
07:07:22.713 > Try reconnecting
07:07:22.714 > Network lost connection
07:07:22.901 > Fetch inverter: 112190575841
.
. einige Zeit später wieder Verbindung mit WLAN-Router
.
07:08:03.769 > WiFi disconnected
07:08:03.769 > Try reconnecting
07:08:03.770 > Network lost connection
07:08:03.951 > RX Period End
07:08:03.951 > Success
07:08:06.224 > WiFi connected
07:08:07.231 > WiFi got ip: 192.168.10.162
07:08:07.231 > Network connected
07:08:07.231 > Connecting to MQTT...
07:08:07.244 > Connected to MQTT.
07:08:07.911 > Fetch inverter: 114171419120
.

[hemagi]

Bei mir sieht es gerade anders aus:

E (292) esp_core_dump_flash: No core dump partition found!
403 - HMS-2000 hinten done
Adding inverter: 116495104094 - HMS-2000 vorne done
done
Switch to WiFi mode
Setting Hostname... done
Configuring WiFi STA using new credentials... done
Configuring WiFi STA DHCP IP... done
Fetch inverter: 116480900403
WiFi connected
Fetch inverter: 116495104094
Fetch inverter: 116480900403
Fetch inverter: 116495104094
Fetch inverter: 116480900403
Fetch inverter: 116495104094
Fetch inverter: 116480900403
Fetch inverter: 116495104094
Fetch inverter: 116480900403
Fetch inverter: 116495104094
Fetch inverter: 116480900403
Fetch inverter: 116495104094
Fetch inverter: 116480900403
Fetch inverter: 116495104094
Fetch inverter: 116480900403
Disable search for AP... WiFi disconnected
Try reconnecting
Network lost connection
done

Es kommt auch nicht wieder. Die weiße LED blinkt, die blaue leuchtet nicht.

[hemagi]

Deaktiviert habe ich nichts, wenn das die Implikation war.
Bin nun auf die vorherige Version zurück, ohne Konfigurationsänderung. Die Verbindung wurde sofort aufgebaut.

Wenn ich irgendwie helfen kann, installiere ich wieder die aktuelle Version

[Kroki0815]

So, ich denke ich habe das Problem lokalisiert!
Der reconnect funktioniert nicht mehr, wenn der Admin-AP deaktiviert wird !
Die Zeile 82 ist an der Stelle, meiner Meinung nach, falsch. Hier wird mit der Funktion WIFI.disconnect(true, true) das Wlan-Radio abgeschaltet und die Session-Info's gelöscht. Das diese aber im case ARDUINO_EVENT_WIFI_STA_DISCONNECTED passiert, ergibt das hier irgendwie hier keinen Sinn, da ja bereits disconnected ist !
Im case NetworkSettingsClass::init (Zeile 30 ) wiederum ist das ok, da hier ja die Session komplett neu aufgebaut wird.
Ich denke, wenn der Admin-AP deaktiviert wird, wird der case ARDUINO_EVENT_WIFI_STA_DISCONNECTED ausgeführt und damit Wifi deaktiviert !

Vielleicht liege ich ja komplett daneben, aber das habe ich heute morgen durch viel Compilieren und Debugging rausgefunden.

Gruß Thorsten

[jblond4711]

@hemagi, du warst nicht gemeint sondern @tbnobody, in Bezug auf das wieder verbinden der OpenDTU mit dem Router. Es können ja Zeitvorgaben abgearbeitet werden, nur nutzt das ja nichts wenn das Wifi der OpenDTU deaktiviert bzw. aus welchen Gründen auch immer inaktiv ist.
Die v24.6.29 läuft hier jetzt auch wieder so wie es soll ohne Auffälligkeiten.

[Fokker-1]

Ja, bei mir läuft auch alles wieder seit gestern problemlos nach Rückgang auf die V.4.6.29.
Fusion DTU mit HM-800 und HMS-1000.

[jblond4711]

@Kroki0815, zumindest bei mir kann das so nicht stimmen. Ich weiß jetzt nicht ob der Admin-AP nach einem OTA Update aktiviert wird aber falls ja hätte das Wifi nach spätestens 3 Minuten deaktiviert sein müssen. Nach dem Update lief es hier aber mindestens 24h bzw. etwas länger ganz normal. Am 2.8 ganz früh hatte ich das Update durchgeführt und die letzte Verbindung war am 3.8 um ca. 9.45 Uhr. Als ich dann nachmittags nochmal geguckt habe war das Wifi deaktiviert.

[Kroki0815]

@jblond4711, ich hab ja nicht gesagt, das Wifi direkt deaktiviert wird, wenn der der Admin-AP ausgeschaltet wird. Das war nur eine Vermutung. Auf alle Fälle wird der weitere Prozess für ein Reconnect nach Wlan-Ausfall nicht wieder getriggert.
'Disable search for AP...' kommt nicht mehr und ein Neustart des WLAN-Scans nach #define WIFI_RECONNECT_REDO_TIMEOUT 600 passiert dann auch nicht mehr. Nimmst du nur die Zeile 82 raus ist alles wieder wie vorher.
Solange der Admin-AP aktiv ist funktionierts noch.
Ich hab das mit kürzeren Zeiten ausprobiert und in allen möglichem Konstellationen. Immer wenn 82 drinnen ist, auch mit parameter false, false, also Wifi-Radio nicht ausschalten und Session-Data nicht löschen, immer das selbe Fehlerbild.

[Juergen2453]

@Kroki0815 @tbnobody ich bin gerade wiedergekommen und habe deine dein Beitrag Kroki0815 gelesen.
Natürlich sofort ausprobiert Zeile 82 weg und kein Problem mehr.
Das ganze habe ich 3 mal gemacht WLAN-Router aus und wieder an.
Die DTU hat sich immer wieder sauber mit dem WLAN verbunden.
Für mich ist der Fehler behoben da ich ja selber bauen kann.

Schön wäre es wenn noch andere User es bestätigen könnten.

[Kroki0815]

@tbnobody , ich hab noch mal ein bisschen weitergeforscht.
NetworkSettings.cpp Zeile 82:
Anscheinend ist ein reconnect() nach einem disconnect() nicht möglich.

// funktioniert nicht
WiFi.disconnect(true, true);
WiFi.reconnect();

//funktioniert
WiFi.disconnect(true, false);
WiFi.begin();

//funktioniert ebenfalls
WiFi.disconnect(true, true);
WiFi.begin(
Configuration.get().WiFi.Ssid,
Configuration.get().WiFi.Password,
WIFI_ALL_CHANNEL_SCAN);

[jblond4711]

@Juergen2453 das Problem kommt doch aber nicht vom Router. Es nutzt nichts den Router neu zu starten. Das Problem ist das die OpenDTU „sein“ Wifi zu einem bestimmten Zeitpunkt deaktiviert.

[Kroki0815]

@jblond4711 , Das ist so nicht ganz richtig. Anscheinend wird die DISCONNECTED-Routine nicht aufgerufen solange der Admin-AP aktiv ist. Ist auch logisch, da sich beide das Interface teilen. Sobald der Admin-AP deaktiviert ist und es ein WiFi-Disconnect ausgelöst wird, wird durch die DISCONNECTED-Routine das disconnect(true,true) ausgelöst, womit das WiFi-Interface deaktiviert wird und die AP-Info's gelöscht werden.
Nach diesen disconnect ist ein reconnect nicht mehr möglich sondern es muss eine neue Session mit begin() gestartet werden. Der Auslöser für den WiFi-Ausfall kann also doch der Router sein, der neu startet.

[mroenne2022]

@jblond4711 und @Kroki0815
Ich bin da auch nicht ganz sicher ob es nicht doch an bestimmten Routern liegt, meine DTU mit v24.8.1 an einem Speedport Smart 4 läuft jetzt schon mehr als 3 Tage problemlos durch, ich hatte lediglich EINMAL das Problem bemerkt weil ich meinen Router aus anderen Gründen booten musste und anschließend die DTU nicht erreichbar war. Einmal DTU stromlos und alles lief wieder - und seit dem alles OK !

[Kroki0815]

@mroenne2022 Schalte einfach mal WLAN am Router für 1 Minute aus und schau ob sich die OpenDTU wieder verbindet. Ich denke nicht.

Hab das hier mit zwei DTU's sauber nachgestellt. Der Admin-AP muss aber schon deaktiviert sein.

[mroenne2022]

@Kroki0815
Richtig, dann würde es hier auch nicht funktionieren mit dem erneuten verbinden, das ist klar . Aber wenn ich das hier in einigen Kommentaren richtig gelesen hab entsteht das Problem auch einfach "so" ohne das WLAN am Router abgeschaltet wird oder der Router neu gestartet wird - oder ich hab das tlw. falsch verstanden. Und oftmals sind FritzBoxen erwähnt.

[Kroki0815]

@mroenne2022 Die OpenDTU braucht nur aus irgendeinen Grund ihre WiFi-Verbinding zu verlieren.

[Juergen2453]

@jblond4711
Ich habe nicht gesagt das es am WLAN-Router liegt.
Bei mir ist der Fehler wenn die WLAN-Verbindung getrennt wird z.B. durch aus und einschalten des WLAN-Router oder Neustart des WLAN-Router, dann verbindet sich die DTU nicht mehr mit dem WLAN-Router.
Wie @Kroki0815 geschrieben hat "Die OpenDTU braucht nur aus irgendeinen Grund ihre WiFi-Verbinding zu verlieren."
Ist der WLAN-Router immer an gibt es kein Problem.

[mroenne2022]

@Kroki0815 , ja das stimmt natürlich. OK - das kommt bei mir so gut wie NIE vor weil Router in der Nähe und immer eine saubere Verbdg. da ist. OK , deshalb hatte ich das nur beim Reboot des Speedports.
Verbindung verlieren oder WLAN abschalten ist dasselbe sozusagen.

[tm-107]

Ich bin da auch nicht ganz sicher ob es nicht doch an bestimmten Routern liegt, [...]

Nur um sicher zu gehen, habe ich das Ganze jetzt an einer Fritzbox 7490, einem Buffalo WHR-G54S mit dd-wrt und an einer Telekom Digitalisierungsbox Premium (bintec elmeg) getestet. Alles nicht mehr ganz frische Hardware, aber mit der jeweils aktuellsten Firmware versehen. Und der Fehler tritt bei allen Routern gleichermaßen auf ...
Habe jetzt auch wieder die v24.6.29 drauf und zumindest am dd-wrt-Router (Buffalo WHR-G54S) kann ich das WLAN beliebig ausschalten und den Router neu starten, ohne dass OpenDTU dabei die Verbindung dauerhaft verliert.

[stefan123t]

@Kroki0815 danke für die ausgiebigen Nachforschungen zum DISCONNECTED event!

Das sollte mE auch relevant sein wenn wir irgendwann zB um die HMS-xxxW WiFi Series Modelle mit built-in DTUBI ansprechen wollen.

Man kann ja neben dem AP und STA bzw. dem ETH Network Interface auch noch eines zum AP einer DTUBI aufbauen.
Wenn diese Verbindung oder eine andere Netzwerkverbindung das DISCONNECTED Event auslöst, müssten wir auch prüfen ob und welches WiFi.disconnect die richtige Methode ist bzw ob wir die Verbindung auch kappem und neu aufbauen wollen.

[Juergen2453]

@tm-107 Ja genau welcher Router ist egal. WLAN unterbrochen und schon hat man das Problem.

[jstammi]

@jstammi do you have a opinion about this issue?

I just saw that long thread, missed it the weekend.

And yes, this is exactly what I was talking about. And for me (with having this patched since several months already), this made this problem disappear.

But please note, that there is still room for improvement: with having a mesh of multiple APs, the openDTU will switch to the next AP on losing connection to the best one. And openDTU will never again switch to the better one again, until doing a power cycle (with this patch: in browser is sufficient - without the power supply must be disconnected).
I could imaging of some rule to auto-power-cycle the openDTU in case of having noticed a degraded wlan signal after change of AP

[Juergen2453]

Ich mach mal CLOSE , der Fehler wurde gefunden und beseitigt.

[stefan123t]

@jstammi I would rather vote for a periodic check for the best available WLAN SSID instead of doing a complete power cycle.
Is there a rule of thumb for the frequency of such changes eg in WLAN Mesh solutions ?

[Fokker-1]

Danke an alle für die Aktionen zur Fehler-Erkennung und -Behebung!
Ich habe die neue FW vorhin geladen.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.