OpenDTU does not connect to local Wifi anymore

[dersch81]

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

[ntfrnd]

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.

[dersch81]

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 :)

[ntfrnd]

Hatte ich zwischenzeitlich auch probiert und direkt die 97bc964 geflasht. Ging aber auch nicht stabil. Nach ein paar Neustarts war es wieder nicht erreichbar.

[dersch81]

Eine Vermutung meinerseits ist dieser change hier: https://github.com/tbnobody/OpenDTU/commit/07f4473a4efcb0e8bbef71971ff35d367e17341a

Allerdings läuft auf einem neuen ESP32 die 97bc964 inkl dieses changes bisher einwandfrei.

[tbnobody]

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.

[dersch81]

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.

[b-a-9-0]

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.

[helgeerbe]

Der commit https://github.com/tbnobody/OpenDTU/commit/07f4473a4efcb0e8bbef71971ff35d367e17341a 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.

[dersch81]

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.

[helgeerbe]

@dersch81 kompilierst du selber? Dann brauchst du in src/NetworkSettings.cpp nur die beiden Zeilen (124-125) rauszunehmen.

            WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);
            WiFi.setSortMethod(WIFI_CONNECT_AP_BY_SIGNAL);

[dersch81]

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.

[tbnobody]

Könnte man den Commit nicht so abändern, dass diese Funktion abschaltbar ist? 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.

[LorenzFi]

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.

[klamasi]

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? _2 Stunden später___ Jetzt habe ich den WPA Modus der FritzBox von WPA2 + WPA3 auf den gleichen Modus wie beim Gastzugang, also auf WPA (CCMP) gesetzt und siehe da die DT verbindet sich!

[klamasi]

Schade, heute morgen war die DTU wieder offline - es liegt wohl doch nicht wie vermutet am WPA Modus. Ich habe dann ein Update auf Version 97bc964 eingespielt - erfolglos!

Erfolg: Es hatten alle WLAN Accesspoints (hinter einer FritzBox 7490) die gleiche SSID. Seit ich dem Repeater in der Nähe der DTU eine individuelle SSID gegeben und die DTU damit verbunden habe, steht die Verbindung der DTU jetzt schon seit 10 Stunden.

[ntfrnd]

Erfolg: Es hatten alle WLAN Accesspoints (hinter einer FritzBox 7490) die gleiche SSID. Seit ich dem Repeater in der Nähe der DTU eine individuelle SSID gegeben und die DTU damit verbunden habe, steht die Verbindung der DTU jetzt schon seit 10 Stunden.

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? Außerdem empfiehlt AVM in einem Mesh-System hinter einer FritzBox immer dieselbe SSID zu nutzen. Von daher ist es bei mir auch so und ich hatte ja auch so meine Probleme mit der Version https://github.com/tbnobody/OpenDTU/commit/97bc964b6c761401cbd72120e1db564a78cdb91b aber an meinem WLAN-Aufbau oder dem Gastnetz habe ich nicht rumgespielt, das bleibt so wie es ist.

[LorenzFi]

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.

[tbnobody]

Dann nehmt doch einfach mal https://github.com/tbnobody/OpenDTU/commit/07f4473a4efcb0e8bbef71971ff35d367e17341a raus und versucht es erneut.

[dare83]

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.

[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

[klamasi]

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:

https://github.com/tbnobody/OpenDTU/issues/618#issuecomment-1448325525

You are receiving this because you commented.

Message ID: @.***>

[grisu642]

Danke für den schnellen Hinweis, werd ich später mal ausprobieren.

[helgeerbe]

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.

10:11:45.726 > Starting OpenDTU

10:11:45.726 > Initialize FS... done

10:11:45.728 > Reading configuration... done

10:11:45.837 > Reading PinMapping... [   144][E][vfs_api.cpp:105] open(): /littlefs/pin_mapping.json does not exist, no permits for creation

10:11:45.847 > using default config done

10:11:45.849 > Initialize Network... done

10:11:45.978 > Setting Hostname... Configuring WiFi STA using new credentials... done

10:11:45.990 > Initialize NTP... done

10:11:45.992 > Initialize SunPosition... done

10:11:45.995 > Initialize MqTT... done

10:11:45.997 > Initialize WebApi... done

10:11:46.902 > Initialize Display... done

10:11:46.904 > Check for default DTU serial... done

10:11:46.907 > Initialize Hoymiles interface... Connection error!!

10:11:46.912 >   Setting radio PA level... 

10:11:46.916 >   Setting DTU serial... 

10:11:46.918 >   Setting poll interval... 

10:11:46.921 >   Adding inverter: 114181019607 - Solar done

10:11:46.925 >   Adding inverter: 112182857016 - Luna done

10:11:46.929 > done

10:11:46.929 > Initialize ve.direct interface... 

10:11:46.931 > ve.direct rx = 22, tx = 21

10:11:46.934 > done

10:11:46.934 > Switch to WiFi mode

10:11:46.937 > Setting Hostname... done

10:11:46.955 > Configuring WiFi STA using existing credentials... E (2946) wifi:sta is connecting, return error

10:11:46.967 > [  1271][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007

10:11:46.973 > done

10:11:46.973 > Configuring WiFi STA DHCP IP... done

10:11:48.106 > WiFi connected

10:11:50.695 > MODULE: VE.Frame

10:11:50.697 > ERROR: [CHECKSUM] Invalid frame

10:11:50.701 > Fetch inverter: 114181019607

10:11:50.721 > Request SystemConfigPara

10:11:55.702 > MODULE: VE.Frame

10:11:55.705 > ERROR: [CHECKSUM] Invalid frame

10:11:55.707 > MODULE: VE.Frame

10:11:55.709 > ERROR: [CHECKSUM] Invalid frame

10:11:55.734 > Fetch inverter: 112182857016

10:11:55.755 > Request SystemConfigPara

10:12:00.766 > Fetch inverter: 114181019607

10:12:00.788 > Request SystemConfigPara

10:12:00.915 > MODULE: VE.Frame

10:12:00.917 > ERROR: [CHECKSUM] Invalid frame

10:12:01.994 > Disable search for AP... WiFi disconnected

10:12:02.000 > Try reconnecting

10:12:02.002 > Network lost connection

10:12:02.004 > done

After several reboots everything was fine again.

10:16:45.769 > Starting OpenDTU

10:16:45.770 > Initialize FS... done

10:16:45.772 > Reading configuration... done

10:16:45.879 > Reading PinMapping... [   144][E][vfs_api.cpp:105] open(): /littlefs/pin_mapping.json does not exist, no permits for creation

10:16:45.891 > using default config done

10:16:45.893 > Initialize Network... done

10:16:46.023 > Setting Hostname... Configuring WiFi STA using new credentials... done

10:16:46.035 > Initialize NTP... done

10:16:46.037 > Initialize SunPosition... done

10:16:46.040 > Initialize MqTT... done

10:16:46.043 > Initialize WebApi... done

10:16:46.054 > Initialize Display... done

10:16:46.057 > Check for default DTU serial... done

10:16:46.060 > Initialize Hoymiles interface... Connection error!!

10:16:46.066 >   Setting radio PA level... 

10:16:46.069 >   Setting DTU serial... 

10:16:46.072 >   Setting poll interval... 

10:16:46.075 >   Adding inverter: 114181019607 - Solar done

10:16:46.079 >   Adding inverter: 112182857016 - Luna done

10:16:46.083 > done

10:16:46.083 > Initialize ve.direct interface... 

10:16:46.086 > ve.direct rx = 22, tx = 21

10:16:46.089 > done

10:16:46.090 > Switch to WiFi mode

10:16:46.099 > WiFi connected

10:16:46.102 > Setting Hostname... done

10:16:46.123 > Configuring WiFi STA using existing credentials... done

10:16:46.139 > Configuring WiFi STA DHCP IP... done

10:16:49.214 > WiFi got ip: 192.168.178.78

10:16:49.218 > Network connected

[cthiele-mogic]

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 21:50:31.639 > Network lost connection 21:50:32.656 > WiFi disconnected 21:50:32.656 > Try reconnecting 21:50:32.662 > Network lost connection 21:50:33.688 > WiFi disconnected 21:50:33.688 > 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 !?

[tbnobody]

Hast du den ESP mal komplett Stromlos gemacht? (Nur so als Idee, hat schon das ein oder andere Mal geholfen)

[cthiele-mogic]

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. Edit: Fritzbox mit Gastzugang SSID geht ebenfalls nicht

[tbnobody]

Haben $Leute bei denen es die Probleme macht ggf. alle Repeater im Einsatz? Oder haben $Leute Repeater im Einsatz und es geht?

[b-a-9-0]

Bei mir treten die Probleme mit normalem FritzBox WLAN ohne Repeater auf.

[grisu642]

Ich hab n Repeater im Einsatz und funktioniert, bin mir aktuell nicht sicher ob mit fritzbox oder fritzrepeater verbunden. Müsste aber eig der repeater aufgrund entfernung sein --Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.Am 06.03.23, 22:06 schrieb tbnobody @.***>:

Haben $Leute bei denen es die Probleme macht ggf. alle Repeater im Einsatz? Oder haben $Leute Repeater im Einsatz und es geht? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[dersch81]

Ich habe keine Repeater im Einsatz. Aber seit dem Tausch des ESP32 auch keine Probleme mehr gehabt.

grisu642 @.***> schrieb am Mo., 6. März 2023, 22:09:

Ich hab n Repeater im Einsatz und funktioniert, bin mir aktuell nicht sicher ob mit fritzbox oder fritzrepeater verbunden. Müsste aber eig der repeater aufgrund entfernung sein --Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.Am 06.03.23, 22:06 schrieb tbnobody @.***>:

Haben $Leute bei denen es die Probleme macht ggf. alle Repeater im Einsatz? Oder haben $Leute Repeater im Einsatz und es geht? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/tbnobody/OpenDTU/issues/618#issuecomment-1457005345, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADI6ECYCTMYYO2BN7XA35S3W2ZG65ANCNFSM6AAAAAAVET4PXQ . You are receiving this because you were mentioned.Message ID: @.***>

[cthiele-mogic]

Scheinbar sind das gängige Probleme beim ESP32 mit Fritzbox und Wifi - Mesh

https://randomnerdtutorials.com/esp-mesh-esp32-esp8266-painlessmesh/ https://forum.arduino.cc/t/esp32-probleme-mit-wifi-begin-bei-mehreren-hotspots-mit-gleicher-ssid/1087240/2

[ntfrnd]

Ich hab ne Fritzbox 7490 mit FritzRepeater 2400 im Einsatz (als Mesh) und mit oben genannter Version meine Probleme, mit den Versionen vorher lief in der gleichen Umgebung alles problemlos. Es war auch ein neuer ESP32. Und ich habe es auch an Stellen getestet (z.B. Hobbyraum) wo definitiv nur ein WLAN vorhanden ist, da dürfte der ESP32 nichts von der Mesh-Umgebung mitkriegen.

[cthiele-mogic]

Ich konnte das Problem umgehen, meine OpenDTU liegt jetzt neben der Fritzbox (Mesh Master) und kann sich problemlos einloggen - offenbar hat er ein Problem wenn der Repeater ein stärkeres Signal sendet.

[ntfrnd]

Mir ist in dem Zusammenhang FritzBox - Mesh aufgefallen, dass seit geraumer Zeit sehr oft zwischen Repeater und Fritzbox gewechselt wird. Mein Notebook steht am Schreibtisch, Repeater ist ca. 6m entfernt und liefert volles Signal. Notebook ist damit verbunden. Plötzlich bricht das WLAN-Signal kurz ab und danach sehe ich nur einen Balken. Wenn ich dann nachsehen, ist das Notebook plötzlich mit der FritzBox verbunden, die aber ein Stockwerk tiefer steht und deshalb auch der Empfang deutlich schlechter ist. Deshalb ja auch der Repeater (meiner arbeitet aber als Access-Point, ist also per LAN angebunden).

Im FritzBox-Systemlog (WLAN) sieht man deutlich, das auf einmal der Repeater ein abmelden und wieder anmelden an der FritzBox initiiert. Der Grund hierfür ist offenbar

Also immer wenn der Repeater auf seinem Kanal einen anderen Router/Repeater aus der Nachbarschaft entdeckt (auch wenn das Signal noch so schwach ist, denn am Notebook sehe ich das WLAN nicht), fängt er an, meldet alles ab, bei der Fritzbox wieder an und nach ein paar Minuten werden alle Geräte wieder zum Repeater umgemeldet.

Ist für mich irgendwie völlig unnötig, da es keinerlei Beeinträchtigung für mich gibt. Nur das Umgemelde nervt enorm. Vielleicht hat das auch was mit dem Problem hier zu tun?

Jedenfalls kam das Verhalten erst vor kurzem mit irgendwelchen Fritz-Updateas dazu, denn diese Kombination läuft schon seit mehreren Jahren problemlos.

Ich habe nun ein paar Haken in der Fritzbox anders gesetzt und teste mal wie sich das hier verhält.

[andi-he]

Derzeitiger andauernder Kanalwechsel der Fritz!Box mit Ab- und Anmeldung macht Opendtu nicht mit. 2,4 G fest auf Kanal 1 und alles klappt wieder. Habe Heltec_wifi_lora_32_V3 im Einsatz.

[CptWonderful]

Ich möchte mich hier auch mal 'einklinken': Habe einen Synology Router und draussen einen Outdoor EAP von TP-Link. Die openDTU Box wurde im Büro mit meinem IoT Netzwerk (2,4 & 5GHz) verbunden (Zur Ersteinrichtung + Test), muss aufgrund der schlechten Verbindung zum WR aber in Garage wo der Outdoor AP steht. Hier verbindet sich openDTU nicht mehr mit dem gleichen Netzwerk (Gleiche SSID, gleiches PW, nur der Outdoor AP). Hole ich die Box wieder ein -> Funktioniert es. Behelfsweise habe ich auf dem Outdoor AP ein dediziertes Netzwerk im gleichen VLAN erstellt -> Funktioniert.

Nutzt openDTU ESSID zur Verbindungherstellung (Kann ich mir eigentlich nicht vorstellen)?`

[klamasi]

Schade, heute morgen war die DTU wieder offline - es liegt wohl doch nicht wie vermutet am WPA Modus. Ich habe dann ein Update auf Version 97bc964 eingespielt - erfolglos!

Erfolg: Es hatten alle WLAN Accesspoints (hinter einer FritzBox 7490) die gleiche SSID. Seit ich dem Repeater in der Nähe der DTU eine individuelle SSID gegeben und die damit verbunden habe, steht die Verbindung der DTU jetzt schon seit 10 Stunden

Die DTU läuft jetzt an der FB mit individueller SSID auch nach 3 Wochen immer noch fehlerfrei.

...aber ich habe auch andere (alte) Geräte die seit kurzem das gleiche Problem haben: z.B. 1 Nexus TAB 2013. Das Nexus wechselt ständig den AccessPoint und gibt irgenwann die Verbindungsversuche auf. Da muss sich ohne mein Zutun etwas am Fritz Mesh (Version 7.29) geändert haben. Wenn ich die Repeater im Mesh eingebunden lasse und nur den Haken in der folgenden Option entferne funktionieren die Geräte problemlos wie seit Jahren. Ich denke das Problem liegt bei AVM!!!!

Einstellungen aus dem Mesh automatisch übernehmen

Dieser FRITZ!Repeater ist Bestandteil des WLAN Mesh und übernimmt automatisch Einstellungen der FRITZ!Box.

Dazu gehören:

Alle relevanten WLAN-Einstellungen, darunter Name des Funknetzes, Gastzugang, Funkkanal
Einstellungen für Auto-Updates, Push Service und AVM-Dienste
Der im Bereich Heimnetz des Mesh Masters für dieses Gerät vergebene Geräte-Name

[ ] Einstellungsübernahme aktiv

[klaus-weindel]

Die Fritzboxen und Mesh spielen sicher auch eine Rolle, die verwendete Software aber auch. Nachdem ich nach einem Update keine Verbindung mehr bekam bin ich auf Ahoy DTU umgestiegen und hier funktioniert die gleiche Hardware tadellos. Auch meine zahlreichen Tasmota Geräte funktionieren ohne Probleme.

[Xenon-s]

gleiches Problem, mehrfach neu geflasht und auch andere Versionen ausprobiert, er bekommt keine Verbindung zum WLAN. Schade, bleibe ich halt bei AhoyDTU, da funktioniert es auf Anhieb

[indie89]

Ich habe aktuell auch ein vermutlich Wifi-bezogenes Problem. Ich versuche es mal mit dem festen Kanal für Wifi und falls das nicht klappt, eröffne ich ein eigenes Issue. Kurzbeschreibung meines aktuellen Problems: Ich nutze den openDTU Adapter von ioBroker und kommuniziere per Web API mit der openDTU. Nach 1/2-x Tagen fängt der Adapter an, fast sekündlich neue Websocket-Connections zur openDTU aufzumachen. Gleichzeitig verändern sich die WR-Gerätenamen in openDTU (hab 2 connected) in komische (Sonder-)Zeichen. Und dann stürzt der Adapter im ioBroker ab (wegen mehrfachen Neustarts). Was Ursache und was Wirkung ist, weiß ich nicht, ich hab aber schon einiges probiert. Evtl. verliert die openDTU die Verbindung zum Wifi und der Adapter versucht dann immer wieder zu connecten...oder es ist doch etwas anderes (wie gesagt, ich eröffne ein eigenes Issue, falls das mit den festen Kanälen nicht hilft).

[TheOtherDoctor]

Seit heute hier dasselbe Problem. Frisch eingerichtetes OpenDTU lief seit einigen Tagen problemlos, dann musste ich heute mal mein WLAN runterfahren und seit das danach (unverändert) wieder hochkam, will OpenDTU nicht mehr connecten. Keine Verbindungsversuche sichtbar, stattdessen wird der 192.168.4.1 wieder aktiviert. Dort in den Einstellungen steht mein WLAN noch drin, aber OpenDTU verbindet sich einfach nicht. In den WLAN-Einstellungen steht Status "nicht aktiv", obwohl meine WLAN Infos hinterlegt sind, genau wie im Initial Post hier. Sieht mir also so aus, als ob das Problem seit mehr als 2 Monaten unverändert existiert. :-(

Hier ist eine aus dem bin package installierte v23.4.25 am Start - Netzwerk ist langweilig: Fritzbox als äusseres Gateway und ein lokaler AP, der dahin durchroutet, für zig Clients seit jeher bestens funktionierend. Kein Mesh oder so. Sehr frustrierend, sehe keinen Ansatzpunkt mehr.

[TheOtherDoctor]

gleiches Problem, mehrfach neu geflasht und auch andere Versionen ausprobiert, er bekommt keine Verbindung zum WLAN. Schade, bleibe ich halt bei AhoyDTU, da funktioniert es auf Anhieb

Könntest du verraten, bis zu welcher Version du zurückgegangen bist? Dann würde ich von da ab weiter zurückgehen... Ich mag nicht gleich auf AhoyDTU wechseln, hatte mich grad erst auf OpenDTU eingerichtet.

edit: Mit 23.4.28 probiert, damit ging's dann wieder; hatte ja erst die Ursache in der persistent abgelegten config befürchtet, aber ging sogar ohne explizites Wiping des EPROMS. Mal sehen wie lange hält.

[klamasi]

Hast du dir mal die Zeit auf der DTU angeschaut? Ist die aktuell? Erst wenn ich die manuell (per direkt Access) setze verbindert die DTU sich danach mit dem WLAN. Warum das so ist weiß ich nicht. Ich habe das Anfang Jahr schon mal beschrieben.

[Troubadix]

Hallo,

ich bin neu im Solarbereich und bin dabei auf dieses tolle Projekt gestoßen.

Leider habe uach ich mit der aktuellen Version 23.5.3 das Problem, das sich der ESP32 nicht mit meinem Heimnetz verbinden möchte. Ich habe dann mal testweise den ESP komplett gelöscht und die 23.4.28 aufgespielt, mit dieser Version verbindet sich der ESP sofort mit meinem Netz (Unifi U6-Enterprise). Wenn ich dann übers Webinterface ein Update auf die 23.5.3 mache, ist der ESP wieder draußen aus dem WLAN.

Gibt es denn besondere Einstellungen, die fürs Unifi-WLAN empfohlen werden für erhöhte Kompatibilität)

[tbnobody]

Das ist auch interessant... weil eigentlich hat sich zwischen 23.4.28 und 23.5.3 absolut garnichts am code geändert. Nur ein klein wenig Doku und die Webapp die aber nur am Client ausgeführt wird.

https://github.com/tbnobody/OpenDTU/compare/v23.4.28...v23.5.3

[stefankubis]

Habe (hatte) in meinem Setup auch Probleme.

Ich habe mehrere Ubiquity Access Points im Einsatz - mit dem Ergebniss, das die Verbindung zu den ESPs sehr Instabil läuft.

Testweise habe ich mal eine SSID so konfiguriert, das nur einer der Access-Points sie ausstrahlt und OpenDTU darauf konfiguriert - seitdem läuft das stabil. Dies ist jedoch eher ein Workaround als eine Lösung.

[isostar1101]

Hallo Zusammen, Du hast die Möglichkeit die OPENDTU an einen AP zubinden das hat bei mir sehr gut funktioniert! Den Punkt Lock to Access Point findest Du unter Client Devices. Das hilft leider nur bei Ubiquity Access Points!

[Troubadix]

Ich muss hier nochmal nachhaken. ..

Die 23.4.28 tuts nach erneutem Flashen auch nicht mehr. Übrigens auch bei der aktuellen 23.5.9 das gleiche Problem.

Wo bekomme ich denn ältere Versionen her? Unter "Releases" sind nur 10 Stück zu finden, die älteste von Anfang April. Den Beiträgen hier zu folgern scheint das Problem ab Februar zu starten. Ich würde daher gerne mal die "last known good" Version testen - wo kann ich diese downloaden?

PS: Ich habe nur einen AP, das "pinnen" an einen bestimmten ist also nicht zutreffend für mich.

Danke!

[SpiGAndromeda]

OpenDTU hat sich bei mir einmal kurz mit der Fritzbox verbunden. Sie hat auch eine IP Adresse bekommen. Aber seitdem geht gar nichts mehr. Mesh komplett deaktiviert und Router stromlos genommen. Verschiedene Kanäle und Passwörter probiert.

Eigentlich wollte ich von AhoyDTU umsteigen wegen besserer MQTT Funktionalität. Aber OpenDTU ist so leider (für mich) nicht nutzbar.

[tbnobody]

Es bräuchte mal jemanden der das Problem hat und den Code selbst compiliert. Sonst wird das mit testen recht mühsam...