OpenDTU does not connect to local Wifi anymore #618
Comments
|
Kann ich bestätigen. Habe vorhin auch auf die 97bc964 geupdated. Davor lief alles prima, nach dem Update und einem Spannung aus/Spannung an - selbes Verhalten. Schließlich habe ich die vorherige Version wieder aufgespielt und alles neu eingerichtet. |
|
Ich habe es nun nur durch einen vollständigen Tausch des ESP32 hinbekommen. Läuft soweit mit 97bc964. Ich denke ein erasen und neues flashen des ESP hätte es auch getan. Aber ich hatte noch einen und es war einfacher die HW direkt zu tauschen. Bei dem betroffenen ESP32 habe ich nun ein erasing gemacht und neu geflasht. Denke damit läuft der wieder. Der kommt dann beim Schwiegervater zum Einsatz :) |
|
Hatte ich zwischenzeitlich auch probiert und direkt die 97bc964 geflasht. Ging aber auch nicht stabil. Nach ein paar Neustarts war es wieder nicht erreichbar. |
|
Als ich es gelesen habe hatte ich auch zuerst diesen commit im verdacht. das ist der einzige der was am Wifi krams geändert hat. Aber andererseits hab ich hier 2 ESPs ohne Probleme damit am laufen (und ich flashe das ja auch regelmäßig und bei jeder Änderung) und bei dir läufts jetzt auch... Ich verstehe es ehrlich gesagt noch nicht. |
|
Ja mal beobachten. Ist wirklich eigenartig. Ich hatte aber schon seit ein paar Tagen das Problem, das ich bei WebGUI Zugriff keinen respond mehr bekam und power cyceln musste. Allerdings wurden stets die MQTT topics geschrieben und auch via REST bekam ich meine Werte. Daher ist das immer nur dann aufgefallen wenn ich mal auf die GUI bin. Eventuell hat es bei mir doch auch was mit dem ESP zu tun gehabt. Evtl ist das Issue bei @ntfrnd zufällig das Gleiche aber nicht das Selbe. Mal schauen ob sich noch mehr melden. |
|
Ich hatte heute auch das Problem, dass keine Verbindung mehr zu Stande kam (fixe IP). Konsolenoutput war: Lost connection, trying to connect... oder so ähnlich alle paar Sekunden. Nach ein paar Mal rebooten ging es wieder. |
|
Der commit 07f4473 kommt von mir. Im default Modus macht der esp einen fast scan und verbindet sich mit dem ersten gültigen Access Point. Bei meinem Mesh (Fritz Box) führte es dazu, dass er nach einem Reboot zuerst der Fritz Box hing, statt am Repeater im Gartenhaus. Irgendwann schubst ihn dann die Fritz!Box auf den Repeater, aber das dauert seine Zeit. Dabei war der ESP nicht immer ansprechbar. Mit der Änderung führt der esp erst einen vollen Netzwerk-Scan durch und verbindet sich mit dem stärksten, geeigneten Access-Point. Bei mir läuft das mit 2 ESPs einwandfrei. Man kann das auch wieder rausnehmen, wenn es Probleme macht. Dauert dann eben nur eine Weile, bis man die volle Bandbreite, bzw. eine stabile WiFi Verbindung hat. |
|
Ich bin mir auch nicht sicher ob es was damit zu tun hat. Jedenfalls war nach über einer Stunde der ESP immer noch nicht verbunden. Ich habe eine Unifi Umgebung. Der ESP sieht an seiner Position potentiell 4-5 meiner AP's wobei aber einer klar der Stärkste ist da nur 5 Meter Freifläche gegenüber. Beides ist Außen im Garten positioniert. Natürlich sind da aber auch sämtliche Nachbar AP's sichtbar die da in der Gegend rumfunken. Könnte man den Commit nicht so abändern, dass diese Funktion abschaltbar ist? Dann könnte man prüfen ob in der eigenen Umgebungssituation der Scan evtl ein Problem ist. |
|
@dersch81 kompilierst du selber? Dann brauchst du in WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);
WiFi.setSortMethod(WIFI_CONNECT_AP_BY_SIGNAL); |
|
Jo ich kompiliere selber. Nachdem ich den ESP32 getauscht habe läuft es einwandfrei. Daher bezweifele ich in deinem Commit die Ursache. Aber die Funktion im Webif abschaltbar zu machen könnte evtl anderen helfen. |
Das würde ich so nicht machen. Sonst kann man bald für alles und jeden Separate Settings einführen. Speicher ist limitiert. Wenn das wirklich Probleme macht, dann kommts komplett raus und es dauert bei manchen Leute ggf. etwas länger bis nach einem Restart die WiFi Verbindung da ist. Aber aktuell ist ja noch nichtmal sicher ob es daran liegt. |
|
Ich hatte dasselbe Problem bei mir im "Gästewlan". Bin dann auf das Hauptwlan umgestiegen dort verbindet sich das Device ohne Probleme nach einem Neustart wieder mit dem WLAN. Vielleicht hilft die Information zur Fehlersuche. |
|
Das Problem ist bei mir heute auch aufgetreten (Version 8b158a0). Die DTU lief 2 Monate ohne Probleme. Sie hat heute keinen Zugang mehr zum WLAN. Nachdem ich den Comment von LorenzFi oben gelesen habe, habe ich es mit dem GästeWLAN probiert - und siehe da die Verbindung klappte. Leider klappt es weiterhin nicht mit dem normalen WLAN. Liegt der Fehler gar nicht an der DTU? Macht die Fritzbox aus irgend einem Grund dicht und liefert keine IP-Adresse? |
|
Schade, heute morgen war die DTU wieder offline - es liegt wohl doch nicht wie vermutet am WPA Modus. Erfolg: |
Was weiß bzw. stört einen Teilnehmer im WLAN, ob die SSID einmal oder mehrmals vorhanden ist? Solange SSID und Passwort passen, sollte es doch funktionieren, oder? |
|
Ich muss auch leider berichten, dass die vermeidliche Lösung mit dem WLAN-Netzwechsel keinen Erfolg gebracht hat. Gesten mehrmals neu gestartet ohne Probleme, heute eine Katastrophe. Also auch bei mir noch kein Erfolg in Sicht. |
|
Dann nehmt doch einfach mal 07f4473 raus und versucht es erneut. |
|
Hallo, habe auch Probleme mit einem meiner WLANS. Habe das Gefühl, dass die DTU nicht mit WLAN Passwörtern zurecht kommt, wenn diese nur aus Zahlen bestehen. Also 12345678 geht nicht abcdefgh geht, bei gleichem AP und SSID. Habe keinen Vergleich mit früher, da ich neu bei dem Projekt bin. Habe aber mit ahoyDTU das gleiche Problem gehabt. |
|
ich klink mich mal eben hier ein, weiß nur nicht obs passt: |
|
Schau dir mal unter NTP die Uhrzeit an und synchronisier sie gegebenenfalls von Hand.
...dann ->Einstellungen -> Neustart.
So klappt's bei mir.
klamasi
Am 28. Februar 2023 15:54:55 MEZ schrieb grisu642 ***@***.***>:
…ich klink mich mal eben hier ein, weiß nur nicht obs passt:
Bin Neustarter, also heute 1. mal ESP und 1. mal Odtu, hat direkt funktioniert, nur seit ein paar Neustarts, weil andere Steckdose genutzt etc, findet er meinen WR nicht mehr, online müsste er sein weil über handy z.b. aufrufbar, passt das hier rein? Verbindet sich der WR direkt mit der Antenne des ESP bzw nrf? Weil meine PV aufm Balkon kein Wlan signal abbekommt
-- >
Reply to this email directly or view it on GitHub:
#618 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
|
Danke für den schnellen Hinweis, werd ich später mal ausprobieren. |
|
Today, this happened to my OpenDTU. I rebootet intentional and got no wifi connection to my home network. But I could access OpenDTU as AccessPoint. After several reboots everything was fine again. |
|
Ich klinke mich mal ein, ich habe eine neue ESP32 mit aktueller OpenDTU Version und es kann keine WLAN Client Verbindung hergestellt werden. Der AP bleibt bestehen, er kann sich aber halt nicht in mein WLAN verbinden. In der Konsole 21:50:31.631 > Try reconnecting Irgendwann steht die Verbindung dann auf inaktiv. Umgebung ist ebenfalls Fritzbox, Mesh und ein paar Repeater. Zeit habe ich manuell gesetzt, hat aber keine Änderung gebracht. Eine Idee wäre noch ein "!" im Passwort !? |
|
Hast du den ESP mal komplett Stromlos gemacht? (Nur so als Idee, hat schon das ein oder andere Mal geholfen) |
|
Ja, mehrfach neu gestartet, Strom gezogen. Interessanterweise habe ich gerade via Android einen Hotspot aufgemacht und die Verbindung hat innerhalb von 1-2s funktioniert. Edit: Am Passwort mit ! liegt es nicht. Mit Android Hotspot funktioniert es wunderbar. |
|
Haben $Leute bei denen es die Probleme macht ggf. alle Repeater im Einsatz? Oder haben $Leute Repeater im Einsatz und es geht? |
|
Bei mir treten die Probleme mit normalem FritzBox WLAN ohne Repeater auf. |
|
Es funktionier etwa jede zweite mal: Funktioniert: Funktioniert nicht: |
|
Wenn innerhalb von 15 Sekunden keine Verbindung zustanden kommt wird der Verbindungsversuch abgebrochen und 10 Minuten gewartet. Danach wird wieder für 15 Sekunden versucht eine Verbindung herzustellen. Lines 16 to 17 in 92c9544
Das klingt aber so als würde in dem Moment der AP die Verbindung abweisen. |
|
Ja, abweisen schon. Aber ich denke wegen Problem bei Aushandlung eines "comebacks" (noch nie von gehört, man lernt nie aus). Mechanismus ist hier ein bischen beschrieben: Der dort beschriebene Fix greift hier evtl nicht, weil die "comeback time" unterhalb der dort angegebenen Grenze von 5s liegt. KA was/ob man da was "von außen" machen kann. |
… wlan station mode (tbnobody#618)" This reverts commit c729cf8.
@tbnobody: Bin ich heute drüber "gestolpert": derzeit wird ntp initialisiert, egal ob netzwerk schon verbunden oder nicht. Aber es gibt ja die entsprechenden Events. Und ich hab mal bei mir testweise die Initialisierung dort drangehängt. Tut soweit ich das beurteilen kann (ohne serielles Log). Siehe jstammi@3935599 Wenn das in Deinen Augen passt, dann mach ich da morgen nen PR zu ... ? Und dabei ist mir ein paar Zeilen nach dem NTP-Init die WebApp Initialisierung aufgestoßen: was passiert, wenn zum Zeitpunkt, wenn das durchlaufen wird, noch keine Netzwerkverbindung hergestellt ist? Dann dürfte der Webserver, der in Plus, wird falls ich nichts übersehen habe, ein erfolgreicher Start nicht überprüft. Schlimmer noch, das scheint nicht einmal (direkt) möglich: ich sehe keine entsprechende Methode. Und Und falls der Start fehlgeschlagen ist, wovon man nichts weiß, dann scheitert AFAIS auch jeder weitere Indem wir den ? |
Macht ja nichts. Es wird in dem Moment ja nur ein Server und die Zeitzone gesetzt... Hat nichts mit einem pollen der Zeit zu tun. Das läuft im Hintergrund im IDF als separater Thread.
Der Webserver wird an einen Port gebunden und nicht an die IP. Er lauscht auf allen IP's (auch zukünftigen). |
|
Am Repeater bricht die WLAN-Verbindung nach paar Stunden weg. Auf dem Display wird weiterhin die Werte angezeigt. Da sollte die Verbindung zum Wechselrichter noch stehen, oder? |
Anfängerfehler, sry, korrekt. Mit der NTP "spiele" ich mal ein wenig rum. |
Ja, die WR Verbindung ist noch da. Das Problem ist AFAIS der Verbindungsverlust zum AP, plus beim Wieder-Verbinden, dass da falsche "Association" Pakete untereinander ausgetauscht werden, was den Erfolg verhindert. Wenn man mit Und was ich dazu als Lösungen gesehen haben ist
Plus immer im Ob über Events oder nicht ist AFAIS egal, habe beides in beiden Varianten gesehen. (beides zB hier: https://microcontrollerslab.com/reconnect-esp32-to-wifi-after-lost-connection/) Um das bei Dir zu testen @RaverXX , brauchst Du ein fertiges Binary (welche Variante?) oder kannst Du Dir das aus einem Branch selber erzeugen? |
|
selbsterzeugen müsste ich erst alles installieren. Aktuell setze ich fertiges Binary esp32 ein. Heute ist die Verbindung zum Fritzbox (Router) ebenfalls abgebrochen nach ca. 8 Stunden. |
|
Hier liegt eine Version basierend auf der v23.7.22, bei der ich ein explizites Disconnect vor die Verbindungsaufnahme gepackt habe (generic_esp32 Variante). Und NTP ist da etwas anders aufgesetzt, was aber mit Deinem Problem und dem Test dazu erstmal nichts zu tun hat: |
|
Seit dem ich mit dem Repeater verbunden war, habe ich Probleme WLAN stabil zu bekommen. Entweder bekomme ich gar keine Verbindung oder es bricht nach kurzer Zeit weg. Ich werde wohl erstmal frisch installieren. |
|
Wenn Du kannst wäre in so nem Fall ein Log über die serielle Schnittstelle hilfreich ;-) Btw, was für ein Repeater ist das? Und ist das der, der über WLAN angebunden ist, oder der über LAN? |
|
AVM 6000er über LAN. Cleaninstall ist durch. Ich habe eben mal kurz AhoyDTU getestet. Der bekommt am Repeater gar kein Verbindung. Ich habe jetzt frisch die [v23.8.2] drauf. Werde erstmal bis morgen laufen lassen und schauen, ob es stabil läuft. Erst dann teste ich wieder. Lädst du eine 23.8.2 Version hoch? |
|
Ja, kann ich machen. Landet dann im gleichen Ordner, Link bleibt gleich. Noch was: wenn nur der ESP32 das Problem mit dem Repeater hat, andere Geräte, zB Dein Handy per 2,4GHz kein Problem haben, dann ... hab ich schon öfter davon gelesen, dass manche ESP32 ein Stromproblem haben, dass zu Stabilitäts-Problemen mit dem WLAN führt. Und dass da ein Kondensator hilft. |
|
Mit der frischen Installation ist es den ganzen Tag am Fritzbox stabil gelaufen. Vorhin wieder zum Repeater und nach zwei Stunden ist die Verbindung weg. Seit dem bekommen ich wieder keine Verbindung mehr. Auch nicht am Fritzbox. Verschiedene Netteile habe ich ausprobiert. Kondensator schaue ich mir an. Edit: Nach mehmaligen Stromlos geht es wieder an der Fritzbox. |
|
War das meine Version? Oder die originale 23.8.2? Wenn Du den Fehler das nächste mal hast, dann häng ihn bitte mal per USB an Deinen Rechner und logge die Ausgaben der openDTU seriellen Schnittstelle mit. Möglichst von Anfang an. Mit etwas Glück sehen wir da etwas. |
|
Ich habe aktuell oft Probleme mit der Verbindung. Ich bekomme so etwa jeder 10. Mal Verbindung. Firmware das Original. DIe Verbindung ist nur Stabil, wenn ich am Loggen bin. Log: Switch to WiFi mode ... Ich warte erstmal bis das Elko da ist. |
|
Elko ist da und eingebaut. Ich kann keine Änderung sehen. Problem bleibt gleich. Zumindest eine neue Fehlermeldung: Fetch inverter: XXXXX |
to prevent from invalid association packets exchange tbnobody#618
|
Wieder frisch installiert, verhällt sich wieder halbwegs normal. Sobald ich einmal auf dem Repeater war, geht die Verbindung nur wenn ich am PC Logge. |
|
Ich habe mal das neue AhoyDTU installiert. Funktioniert nun meistens am Repeater. Weiß nicht, ob es am Elko liegt. Bleibt erstmal drauf. |
|
I discovered a fix to make Wifi much more stable for ESP32 Wroom USB-C CH340. I described it here: hoylabs#458 it's really worth trying, it helped me a lot! |
|
Seit dem neu flashen (opendtu-generic_esp32.factory.bin und opendtu-generic_esp32.bin v23.9.18) eines vorher relativ stabilen OpenDTU-ESP32 habe ich nun die oben beschriebenen Probleme. Ich habe mit Chrome geflashed und erased. Mehrfach komplett gebootet, power off, ... . Immer schön das captive popup mit IP 192.168.4.1 am iMac. Mein WLAN eingegeben und unmittelbar danach wird automatisch gebootet. (Finde ich nicht intuitv. Sollte auf ein manuelles Reboot warten.) Log auf seriellem Port: Danach stehts. Habe einen alten ESP32 (ESP32-D0WD-V3 (revision 3)). Ich komme danach auch nur weiter mit Erase und Reflash. Also nochmal von vorne (erase und program, config.json hochladen): Ping auf die IP Adresse 178.188 funktioniert aber das Web Frontend bleibt weiß. Der Source code der leeren Webseite: <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<link rel="icon" href="[/favicon.ico](view-source:http://192.168.178.188/favicon.ico)" />
<link rel="shortcut icon" type="image/png" href="[/favicon.png](view-source:http://192.168.178.188/favicon.png)">
<link rel="apple-touch-icon" href="[/favicon.png](view-source:http://192.168.178.188/favicon.png)">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>OpenDTU</title>
<script type="module" crossorigin src="[/js/app.js](view-source:http://192.168.178.188/js/app.js)"></script>
</head>
<body>
<noscript>
<strong>We're sorry but OpenDTU doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
</noscript>
<div id="app"></div>
</body>
</html>Natürlich ist in meinem Browser JS enabled. Ich habe die config.json vorher zweimal gesichert und kann beide nicht mehr benutzen. Update:Ich konnte inzwischen eine stabile Version 23.8.28 installieren.
Der zerst fehlende Punkte 3 war der eigentliche Grund für die Probleme. |
|
Does this issue still occour? Especially after the changes made in cbbe053 |
Can't exactly say that this fixed it (or something else way before) but after flashing newest firmware (was on config version 71936) it immediately connects to my wifi, sets correct time and is accessible via IP. I will monitor this for a few days and give feedback whether it still works or not. Thank you so far! Update ~36hrs later: So far DTU is reachable everytime I checked. For me it appears this issue is solved. |
|
I am going to close this issue. Please open a new one if this type of issue reoccurs. |
|
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. |
and others
What happened?
During an FW upload the OpenDTU did not respond anymore. Then after a powercycle it just opened up the OpenDTU AP but did not connect to the local anymore.
Then i performed the FW update again but it still does not connect to the Wifi anymore. Then went back to the previous FW but same issue. Did a config restore = fail, then factory default and config restore = fail. Changing the wifi settings and back to the local one = fail.
Nothing helps. The unit is not connecting to the wifi anymore. It don't even try to connect.
I can't see any connect attempts in my Unifi network. There is also no DHCP request in my DHCP Server for that MAC.
But the local OpenDTU AP is working every time. So i'm really out of idea what coud be the reason.
The OpenDTU HW is at the same place since several months and is working great there. Powered up via 5v 2A Adapter. An outdoor AP is in front of it just a few meter away. The wifi coverage is very good.
To Reproduce Bug
no idea
Expected Behavior
Just connect to the fu**ing wifi.
Install Method
Self-Compiled
What git-hash/version of OpenDTU?
97bc964
Relevant log/trace output
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: