search

tbnobody / OpenDTU

Software for ESP32 to talk to Hoymiles/TSUN/Solenso Inverters
GNU General Public License v2.0
1.78k stars 495 forks source link

WiFi issue still exists #2202

Open SteffenR87 opened 1 month ago

SteffenR87 commented 1 month ago

What happened?

Well I was affected with previous release WiFi disconnect. Two days ago I updated to latest version and today 4pm I had the same kind of disconnect. Reboot and back online.

To Reproduce Bug

I will wait if it happens in 2 days time again

Expected Behavior

Stable WiFi connection

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

Latest

Relevant log/trace output

No response

Anything else?

No response

Please confirm the following

zarzak12 commented 1 month ago

I have the same problem

stefan123t commented 1 month ago

Can you provide your actual version number ?

zarzak12 commented 1 month ago

Can you provide your actual version number ?

V24.8.5

With each daily reboot I lose the Wi-Fi connection, I am forced to disconnect/reconnect it so that it connects

xyCommander commented 1 month ago

Hey. Ich hatte leider keine Zeit die letzten Tage um mich zu registrieren genau das zu melden: der Fehler existiert in der 24.8.5 definitiv immer noch. Ich muss seit der 24.8.1 jedem Tag einmal den Stecker ziehen, da die Weboberfläche nicht mehr antwortet und der HAss via Mqtt keine Daten mehr empfängt. Eine Ursache ist für mich ehrlich gesagt nicht erkennbar. Die Opendtu hat artig um 05:51:36 angefangen Daten zu senden und um 09:16:52 gestoppt. Der Router läuft durchgängig, am Netzwerkaufbau hat sich seit Monaten nichts geändert.

Omega13x commented 1 month ago

Also ich habe keine Probleme. Meine DTU läuft auch mit der 24.8.5 stabil und ist jederzeit erreichbar. Ich habe drei WR eingetragen, von denen zwei über HA dynamisch geregelt werden. Ich habe eine selbstgebastelte DTU mit einem ESP32 S3, einem NRF24 und ein 2,42" Display.

ckbaxter commented 1 month ago

Ich kann das Problem bestätigen, alle paar Tage muss ich meine openDTU neustarten, weil nicht mehr erreichbar. Version 24.8.5

Juergen2453 commented 1 month ago

Wie @Omega13x schon geschrieben hat, habe ich auch keine Probleme mit der V24.8.5. Auch wenn ich den WLAN-Router aus und einschalten Er verbindet sich immer wieder sauber mit dem WLAN. Betriebszeit 7 Tage 00:20:14 Zum Testen würde ich doch einfach mal wenn der Fehler wieder auftritt, openDTU eingeschaltet lassen und den WLAN-Router aus und einschalten ob die DTU sich dann wieder verbindet.

xyCommander commented 1 month ago

Zum Testen würde ich doch einfach mal wenn der Fehler wieder auftritt, openDTU eingeschaltet lassen und den WLAN-Router aus und einschalten ob die DTU sich dann wieder verbindet.

Gute Idee! Ich berichte dann

travor05 commented 1 month ago

Seit dem neuesten Update habe ich auch WiFi Probleme. Mit der vorherigen hatte ich die nie.

Juergen2453 commented 1 month ago

@travor05 Schön wäre es "neuesten Update" welche Version ? "vorherigen hatte ich die nie" welche Version ?

mroenne2022 commented 1 month ago

Bei mir tritt das Problem seit der Version v24.8.5 auch NICHT mehr auf, bei der vorherigen Version v24.8.1 hatte ich es auch mal nach Router Neustart. Hab einen ESP32 (ESP32-D0WD-V3) in Betrieb mit 3 WR (HM Serie), ansonsten nichts besonderes - lese die Daten nur über die WebGUI aus.

jstammi commented 1 month ago

Ad 1: die Änderung in openDTU für die WIFI Verbindung ist, daß jetzt immer ein komplett neuer Verbindungsaufbau erzwungen wird bei openDTU (Re-)Boot und Neu-Verbindung zum AP nach einem Verbindungsverlust. Vorher hat sich openDTU nicht wieder mit dem AP (falls mehere APs: dem selben, idR besten) verbinden können ohne Power-Cycle, d.h. Trennung von der Stromversorgung (der AP nutzt einen neues "Association Packet" für den Verbindungsaufbau, openDTU hat immer an dem einmal für diesen AP festgelegten festgehalten - zu sehen im Serial Log)

Falls diese Änderung bei jemandem zu einer Verschlechterung führt ... kommen wir da IMHO nur mit einem Serial Log weiter (AFAIR sind nur dort die dafür relevanten Log Meldungen zu sehen). Oder einer ausreichend exakten Beschreibung, wie es dazu gekommen ist, so daß das reproduziert werden könnte. "Geht nicht mehr" hilft da meistens leider nicht.

Ad 2: es gibt IMHO mehr mögliche Ursachen für WIFI Probleme als obiges.

Da sind konkurrierende Netze der Nachbarn. Was evtl wieder das Verhalten des APs beeinflussen kann. Ich habe keine Erfahrung damit, ob zB die Fritzbox den Kanal mal wechselt. Und wie openDTU damit dann klarkommt (Erwartung: neuerdings verbindet sie sich wieder, früher nicht). Meine 3 APs nutzen feste Kanäle, da passiert das nicht.

Eine generell eher schlechte WIFI Verbindung.

Ich hatte auch schon ein "schlechtes" Kabel (fast-kabelbruch), wodurch geringste Lageänderung einen bedeutenden Unterschied ausmachte.

"Gefühlt" hat auch die Auslastung der Funkverbindungen eine Rolle gespielt - nicht nur WIFI, auch die zum WR. Habe das aber nie weiter gezielt untersucht, weil nach Kabel-Wechsel und dem eingangs beschriebenen WIFI Patch ich keine Probleme mehr habe. Aber ich könnte mir vorstellen, dass wenn der WR nicht/schlecht erreichbar ist (=>vermutlich erhöhtes Funken wg Wdh => höhere Auslastung des ESP) plus die WIFI Verbindung in seiner Qualität variiert, daß da eine Grenze überschritten wird, dass MQTT plus für jeden Client im Browser per Websocket die Daten nicht mehr in-Time weitergereicht werden können ... kA wie sich das dann auswirken könnte, aber ein "Abhängen" eines/der Clients klingt für mich zumindest plausibel ... ?

PS: falls die WR Funkverbindung wackelig ist und meine Vermutung am Ende plausibel erscheint ... kenne ich mind 3 Ansatzpunkte: der Kondensator zum Funkchip (die Beschreibung dafür ist glaube ich ein wenig versteckt nach dem Umbau der GitHub Seiten), das Netzteil an sich (beides aus persönlicher Erfahrung) und die Funkfrequenz (hier in anderen Issues jetzt mehrmals erwähnt worden)

xyCommander commented 1 month ago

Was ist ein Serial Log und wie kommt man da ran?

Zur Reproduzierbarkeit: es gibt keine Änderungen im Umfeld, keine neuen Wlans, nichts umgebaut oder was weiß ich. Seit Oktober ist alles wie gehabt, jetzt kommt ein Update (bzw. zwei) und ja: es geht halt nicht mehr. Ich bin kein Programmierer oder was weiß ich, tut mir leid.

Andere Frage: Kann man über die Update-Funktion eine ältere Version hochladen als Rollback, ohne das was kaputt geht? Würde meine Anlage gerne vernünftig nutzen können...

mroenne2022 commented 1 month ago

@xyCommander , ja man kann eine ältere Version über die Updatefunktion im Menue installieren, z.B. die Version vom 29.6. 24 ! "Kaputt" gehen sollte nichts, die Einstellungen bleiben erhalten wie bei einem Update auf eine höhere Version. Hier findest du die Versionen : https://github.com/tbnobody/OpenDTU/releases

jstammi commented 1 month ago

@xyCommander Serial Log = die serielle Schnittestelle (=einige PINs) des ESP mit dem Computer verbinden, meistens über einen USB-Serial Adapter

Und die ältere Version wieder draufspielen ist schon mal eine gute Idee. Bin gespannt, ob es danach wieder stabil ist.

Vielleicht noch am AP dazu beobachten, ob es da Kanal Wechsel für das 2,4GHz WLAN gibt

stefan123t commented 1 month ago

@SteffenR87 you wanted to give us feedback on your issue after two days. Anything new, is it fixed with v24.08.05 or do you still have WiFi issues as others have reported as well ?

Please consider posting a Serial Log covering the time (from start) when it is still working until the OpenDTU looses the WiFi connection in order for us to analyze the issue more closely. You should use the Slash Commands [/] Details and [/] Code Block to format the log file, if you do not attach it as a file.

travor05 commented 1 month ago

@Juergen2453 Was ist den die aktuellste? 24.8.5 oder gibt es was neueres? Die vorher war die 24.8.1 dann logischerweise

Juergen2453 commented 1 month ago

@travor05 Die v24.8.5 ist OK Die v24.8.1 hatte einen WLAN Fehler Die v24.6.29 ist OK Du kannst ja auf eine ältere Version Testweise zurück gehen. https://github.com/tbnobody/OpenDTU/releases

SteffenR87 commented 1 month ago

@SteffenR87 you wanted to give us feedback on your issue after two days. Anything new, is it fixed with v24.08.05 or do you still have WiFi issues as others have reported as well ?

Please consider posting a Serial Log covering the time (from start) when it is still working until the OpenDTU looses the WiFi connection in order for us to analyze the issue more closely. You should use the Slash Commands [/] Details and [/] Code Block to format the log file, if you do not attach it as a file.

Hi Stefan, unfortunately still same issue with a disconnect after around 2 days. Using a fusion board. I am using Fritzbox cable 6490 and mesh network Fritz2400 Repeater.

stefan123t commented 1 month ago

@SteffenR87 thanks for the feedback and the confirmation that it may have something to do with either Fritz Mesh Network and or the Fritz Repeater in conjunction with the OpenDTU WiFi connecting to either of the two Access Points in your WLAN. Can you double check the points that @jstammi mentioned, i.e.

  1. can you check to which of the two APs your OpenDTU is connected usually (Router/Repeater) according to Serial logs or Fritz logs.
  2. fix your network device to a dedicated 2.4GHz channel, the ESP32 will not be able to connect to 5GHz.
  3. verify that your NRF/CMT radio modules have the recommended 47/100uF condensator
  4. use a proven and beefy PSU for your setup
  5. check the frequency used by your DTU, e.g. in WLAN range Fritz may free some channels for Airplanes / AIS transponders.
  6. collect serial logs of the event that renders the DTU unreachable. This works on a PC/Laptop using the USB Serial Console.
stefan123t commented 1 month ago

@SteffenR87 do you have MQTT connected and can you check the BSSID value of your WiFi STAtion to which the OpenDTU is connected to ? You may also see that under Info > Network under WiFi Information (Station): BSSID once you are connected to the OpenDTU UI.

@jstammi I came across the following threads:

Optimizing ESP32 Connections with WiFiMulti https://thelinuxcode.com/strongest-wifi-network-wifimulti-esp32/

Establish WiFi connection to AP with strongest radio signal https://esp32.com/viewtopic.php?f=19&t=18979

WIFI_ALL_CHANNEL_SCAN, this parameter doesn't seem to work (IDFGH-6630) #8269 https://github.com/espressif/esp-idf/issues/8269

So basically they recommend to use WiFiMulti instead of WiFi as the reconnect time may be lower and it may even handle multiple APs with the same SSID more graceously. Apart from that the closed issue on the esp-idf has some instructions on how to trace the issue, e.g. under Linux:

ifconfig down
iwconfig mode monitor
ifconfig up
iwconfig channel 7
wireshark

I for once only have a single Fritz!Box and no Repeaters, hence there are no potential problems with duplicate SSIDs but unique BSSIDs nor do afaik I have Fritz!Mesh enabled.

jstammi commented 1 month ago

OK, with mesh there is another topic: If the mesh works on 5ghz, please check your Fritz log for having been forced to stop using the current channel because of flight radar interference*)

Because with/if such, your repeater would become unresponsive some time, opendtu would switch to the other ap with worse signal and only return in restart of opendtu or Fritz

*) AFAIR, better explained in my now integrated pr on the WiFi change

stefan123t @.***> schrieb am Di., 13. Aug. 2024, 23:44:

@SteffenR87 https://github.com/SteffenR87 do you have MQTT connected and can you check the BSSID value of your WiFi STAtion to which the OpenDTU is connected to ? You may also see that under Info > Network under WiFi Information (Station): BSSID once you are connected to the OpenDTU UI.

@jstammi https://github.com/jstammi I came across the following threads:

Optimizing ESP32 Connections with WiFiMulti https://thelinuxcode.com/strongest-wifi-network-wifimulti-esp32/

Establish WiFi connection to AP with strongest radio signal https://esp32.com/viewtopic.php?f=19&t=18979

*WIFI_ALL_CHANNEL_SCAN, this parameter doesn't seem to work (IDFGH-6630)

8269*

espressif/esp-idf#8269 https://github.com/espressif/esp-idf/issues/8269

So basically they recommend to use WiFiMulti instead of WiFi as the reconnect time may be lower and it may even handle multiple APs with the same SSID more graceously. Apart from that the closed issue on the esp-idf has some instructions on how to trace the issue, e.g. under Linux:

ifconfig down iwconfig mode monitor ifconfig up iwconfig channel 7 wireshark

I for once only have a single Fritz!Box and no Repeaters, hence there are no potential problems with duplicate SSIDs but unique BSSIDs nor do afaik I have Fritz!Mesh enabled.

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

stefan123t commented 1 month ago

@jstammi wouldnt it make sense to re-evaluate the reachable APs from time to time ? Afaik most examples i read do that every 30 seconds, though it may be sufficient every 1-5 Minutes as we got other work to do with the DTU. Also I understood that getting a new connection with WiFiMulti goes down to 1/2s from 6-8s using WiFi.

travor05 commented 1 month ago

@Juergen2453 Bin gestern nach meinem Post auch wieder auf die 24.8.1 zurück. Seitdem hängt sich der esp ständig auf. Er zeigt zwar das webinderface kann aber nichts mehr anklicken. Wie eingefroren.

stefan123t commented 1 month ago

@travor05 die v24.08.01 hat einen bekannten Fehler der in v24.08.05 behoben wurde. Bitte entweder die aktuelle Version oder die v24.06.29 verwenden. Das Problem ist ja bekannt und wurde in #2185 hinlänglich beschrieben.

ComGreed commented 1 month ago

My Setup:

Timeline:

Side note: Because of the thunderstorm yesterday I disconnected my inverter from the grid and reconnected it at ~10am but this shouldn't have anything to do with the wifi connection.

jstammi commented 1 month ago

"06:21:23: 5 GHz disabled because of Radar-priority"

THIS is exactly what I was talking about ;-)

And at this time your repeater becomes un-responsive. And I expect the openDTU will switch-over to another one with less signal. And then there will be some degradation I guess, too to limited bandwidth (best guess again).

To get around this: do not use the 5GHz auto channel but fix it to one that is not affected by this radar interference. In the PR that I talked about AFAIR there is a link inside that tells you which channels are not affected.

Am Mi., 14. Aug. 2024 um 13:42 Uhr schrieb JD @.***>:

My Setup:

  • OpenDTU v24.08.05
  • FRITZ!Box 7590 with FRITZ!OS 7.90-115052 BETA
  • FRITZ!Repeater 6000
  • both devices connected in a mesh
  • 2.4 and 5 GHz wifi enabled
  • 2.4 GHz fixed channel, 5 GHz auto channel

Timeline:

  • ~06:19:24: FRITZ!Box firmware update start (timestamp guessed)
  • 06:19:41: OpenDTU connects to repeater (2.4 GHz)
  • 06:20:54: FRITZ!Box firmware update and restart complete
  • 06:21:11: OpenDTU disconnects from repeater (2.4 GHz)
  • 06:21:23: 5 GHz disabled because of Radar-priority
  • 06:22:48: the first device reconnects to the router over wifi
  • no wifi connection attempt logged on the router so far

Side note: Because of the thunderstorm yesterday I disconnected my inverter from the grid and reconnected it at ~10am but this shouldn't have anything to do with the wifi connection.

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

jstammi commented 1 month ago

The time you re-evaluate, the openDTU is then disconnected (I assume so at least). If I am correct on this, doing it every X minutes would be a very bad idea.

This requires some more elaborated heuristic, I guess.

Am Mi., 14. Aug. 2024 um 09:14 Uhr schrieb stefan123t < @.***>:

@jstammi https://github.com/jstammi wouldnt it make sense to re-evaluate the reachable APs from time to time ? Afaik most examples i read do that every 30 seconds, though it may be sufficient every 1-5 Minutes as we got other work to do with the DTU. Also I understood that getting a new connection with WiFiMulti goes down to 1/2s from 6-8s using WiFi.

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

stefan123t commented 1 month ago

@ComGreed thanks for your review and the write up of your affected setup. This helps us to identify that it has indeed something to do with the Fritz!Box and at least one Fritz!Repeater in Fritz!Mesh mode. Actually the combination of roaming 802.11k and management 802.11v is described as "Mesh Steering" on their website:

What is Mesh Wi-Fi steering and how does it work? https://en.avm.de/service/knowledge-base/dok/FRITZ-Box-7590/3515_What-is-Mesh-Wi-Fi-steering-and-how-does-it-work/

AVM erklärt WLAN Mesh Steering https://avm.de/ratgeber/avm-erklaert-wlan-mesh-steering/

@jstammi I just found another thread which talks about 802.11k, 802.11r and 802.11v Support in ESP-IDF and points to the following issue about 802.11r support and WiFi roaming, which seems to be a pre-requisite.

ESP32 Fritz!Box-Mesh = same SSID for router & repeater force connecting to a certain MAC-Adress? https://forum.arduino.cc/t/esp32-fritz-box-mesh-same-ssid-for-router-repeater-force-connecting-to-a-certain-mac-adress/1160028/2

**Does ESP32 support seamless Wi-Fi roaming (IEEE 802.11v, r, k) in the STA mode? (IDFGH-1392)

3671**

https://github.com/espressif/esp-idf/issues/3671

Effectively the discussion is about the two roaming example's in the EPS-IDF: https://github.com/espressif/esp-idf/tree/master/examples/wifi/roaming

Actually both 802.11k and 802.11r are necessary for seamless Basic Service Set (BSS) transitions aka roaming:

Here is a more detailled write up of the communication flows from Cisco:

802.11r BSS Fast Transition Deployment Guide https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/80211r-ft/b-80211r-dg.html

ComGreed commented 1 month ago

THIS is exactly what I was talking about ;-)

And at this time your repeater becomes un-responsive. And I expect the openDTU will switch-over to another one with less signal. And then there will be some degradation I guess, too to limited bandwidth (best guess again).

That would have been way too easy. 😉 It didn't change anything. I doubt my DTU even supports 5GHz.

What I did this time:

- rebooted by DTU so it connects with my router again
- switched to manual channel outside of radar range
- rebooted by router
- DTU switched to mesh repeater
- router reboot finished
- DTU disconnects from repeater
- DTU doesn't connect to router

After that I did:

- rebooted by DTU so it connects with my router again
- disabled 5 GHz wifi
- rebooted by router
- DTU switched to mesh repeater
- router reboot finished
- DTU disconnects from repeater
- DTU doesn't connect to router

Aaaand after that I did:

- rebooted by DTU so it connects with my router again
- flashed firmware [v24.6.29](https://github.com/tbnobody/OpenDTU/releases/tag/v24.6.29)
- rebooted by router
- DTU switched to mesh repeater
- router reboot finished
- DTU stays connected to repeater
- I reboot the repeater
- DTU switches to router wifi
- repeater finished reboot
- DTU stays connected to router

I think I'll stick to v24.6.29 for now.

jstammi commented 1 month ago

It is not your opendtu using the 5ghz. It is your mesh using it. And temporarily shutting it down. Leading to a temporarily not working mesh. The repeater and all devices attached then have no access to the LAN devices attached to the Fritz router. Nor the Internet (irrelevant here).

Which is the AP opendtu has best signal level with, the Fritz router or the repeater?

With the old firmware opendtu will not re-connect again with an ap having lost the connection to. This works again only after opendtu power cycle. Reboot ist Not sufficient.

But with now having set the router 5ghz channel to one not interfering with radar, this should not happen again that often. But not because of the older firmware, but because of new 5ghz channel setting.

JD @.***> schrieb am Mi., 14. Aug. 2024, 19:51:

THIS is exactly what I was talking about ;-)

And at this time your repeater becomes un-responsive. And I expect the openDTU will switch-over to another one with less signal. And then there will be some degradation I guess, too to limited bandwidth (best guess again).

That would have been way too easy. 😉 It didn't change anything. I doubt my DTU even supports 5GHz.

What I did this time:

  • rebooted by DTU so it connects with my router again
  • switched to manual channel outside of radar range
  • rebooted by router
  • DTU switched to mesh repeater
  • router reboot finished
  • DTU disconnects from repeater
  • DTU doesn't connect to router

After that I did:

  • rebooted by DTU so it connects with my router again
  • disabled 5 GHz wifi
  • rebooted by router
  • DTU switched to mesh repeater
  • router reboot finished
  • DTU disconnects from repeater
  • DTU doesn't connect to router

Aaaand after that I did:

  • rebooted by DTU so it connects with my router again
  • flashed firmware v24.6.29 https://github.com/tbnobody/OpenDTU/releases/tag/v24.6.29
  • rebooted by router
  • DTU switched to mesh repeater
  • router reboot finished
  • DTU stays connected to repeater
  • I reboot the repeater
  • DTU switches to router wifi
  • repeater finished reboot
  • DTU stays connected to router

I think I'll stick to v24.6.29 for now.

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

broth-itk commented 1 month ago

v24.8.5 works now fine with my hardware. Last update fixed the disconnect issues.

This does not mean other issues exist. They might be infrastructure related and need proper investigation.

stefan123t commented 1 month ago

@SteffenR87 being the OP of the issue made this statement:

Hi Stefan, unfortunately still same issue with a disconnect after around 2 days. Using a fusion board. I am using Fritzbox cable 6490 and mesh network Fritz2400 Repeater.

So this is most likely related to OpenDTU not supporting WLAN roaming 802.1k/r or Mesh Steering 802.11v using the ESP-IDF examples as noted above.

@tbnobody is there anyone from the development team able to look into this rather involved setup using at least a Fritz!Box and an Fritz!Repeater to diagnose / trace the handover of WLAN clients like OpenDTU being steered from Router to Access Points and/or back again.

cortmen commented 1 month ago

Same Problem. v24.8.5 , 3 meter from AP, 3-4 offline 24 hour.

Downgrade to older Version.

SDK-Version | v4.4.7-dirty 0.1.28 v24.8.5 generic_esp32 Chip-Modell ESP32-D0WD-V3 Chip-Revision 3 Chip-Kerne 2 CPU-Frequenz 240 MHz CPU-Temperatur 71,1 °C Flash-Speichergröße 4.194.304 Byte (4 MB)

Omega13x commented 1 month ago

Bei der Temperatur würde ich auch aussteigen. Mein ESP32 kommt gerade mal auf 42°C. Aber über 70°C ist schon sportlich.

mroenne2022 commented 1 month ago

@Omega13x : 2 meiner DTUs haben ständig und nach kurzer Zeit auch über 70 Grad, eine knapp über 40. Das ist schon seit Einführung der Temp. Anzeige so.Und das ist egal ob im Gehäuse , hab extra eine mal rausgeholt. Diese (Bild) ist dauerhaft in Betrieb und läuft damit prima. Ich geb dem keine große Bedeutung mehr, anfangs war mir das auch nicht geheuer. Und ich seh er hat das gleiche Model wie meine ESP32-D0WD-V3 Screenshot_20240817_202231_Chrome

broth-itk commented 1 month ago

The temperature reading seems odd to me. Mine shows 68.3°C and when touching the metal case I can barely feel any heat.

It looks like the internal sensor has a significant offset which differs from chip to chip. So not useful for absolute readings.

cortmen commented 1 month ago

I once pointed a small fan at the ESP32 not packed in the housing, 1 hour running time, 67.2° C ... Temperature values are probably only bad for this chip.

home-cloud commented 1 month ago

Ja, das Problem besteht immer noch. Aber es hat nicht zwingend etwas mit einer Fritzbox zu tun. Ich betreibe Unifi Accesspoints und da passiert es auch, wenn die DTU roamt...

jonastr commented 4 weeks ago

I have not yet upgraded to 24.8.x, but I can confirm that I also have random disconnects with 24.6.29.

My setup:

Funnily enough, while it reconnects without problems every morning, it sometimes gets disconnected during the day, e.g., for an hour or more. It sometimes reconnects, sometimes it doesn't (or I am not waiting long enough?). It doesn't happen every day though, maybe more like 1-2 times per week.

I did have Mesh steering enabled until now. I will disable it now and see how the situation changes/improves. I will update you once I have some more data.

schneeer commented 3 weeks ago

Hi, is a bug, use the latest firmware and everything is fine. I also have a Fritz!Mesh running and had similar problems before.

jonastr commented 3 weeks ago

@schneeer

Hi, is a bug, use the latest firmware and everything is fine. I also have a Fritz!Mesh running and had similar problems before.

Hey, then I possibly misunderstood the description. Can you please confirm - I was under the impression that this bug was introduced only after 24.6.x and hopefully fixed with the most recent 24.8.5?

Thanks, Jonas

schneeer commented 3 weeks ago

Hi,

My mesh configuration: 1x Fritz!Box 7590 (7.90-115249 BETA) 1x Fritz!Repeater 2400 1x Fritz!Repeater 1750E

The stupid thing is that you look for the problem within yourself and the network and don't make any notes about it, especially if it works again after a bit of trying.

AVM occasionally releases new betas. For the last six months, with every update I've had the problem that some WLAN devices don't reconnect, and the DTU in particular was always affected. I can only speculate to what extent AVM updates were to blame.

This eventually improved for the rest of my WLAN participants, but in the last few weeks I've particularly noticed it at the DTU. Since I also updated the DTU at the same time when it was available, I cannot specify the affected firmware versions exactly.

I would say that with or after openDTU v24.6.29 it was particularly bad, connection problems pretty much every day.

With v24.8.5 everything worked again, and there were no problems with the last FritzOS update a few days ago.

(Thanks to Google Translate (DE/EN))

jonastr commented 3 weeks ago

@schneeer thanks for elaborating!

Yes, many moving pieces here. I also noticed that AVM has released non-beta 7.58 for its Repeater 1200 AX, which I am using. The release notes state

Es konnte zu einem dauerhaften Abbruch der Netzwerkverbindung kommen, wenn Geräte mit einem spezifischen Chipsatz genutzt werden

... which would fit the symptoms we are seeing: disconnects. However, as the release notes stay so vague, I can only guess whether that might help.

I've now also updated to 24.8.5 and reactivated mesh steering in the Fritzbox. Time will tell. If it's worse, I can still go back. ;)

schneeer commented 3 weeks ago

Hello,

Totally great. ;)

Something else: Updates don't always bring benefits... I once had to completely rebuild my mesh.

CommanderROR9 commented 2 weeks ago

I just started using OpenDTU with a "Fusion" board kit. It is running the very latest Firmware 24.8.5 and keeps losing Wifi and never reconnecting. I have managed to provoke the disconnect by manually switching the WiFi Channel on my FritzBox. It appears that once the OpenDTU is disconnected it never even attempts to reconnect. I have turned off auto channel for now on the Router, but hope there will be a fix for OpenDTU soon.

schneeer commented 2 weeks ago

Hi. @tbnobody wrote somewhere here that the DTU doesn't reconnect immediately, but that it can take up to 10 minutes.

Do you have a 2nd ESP board to test? The Fusion board could also be defective.

For me, openDTU with v24.8.5 has been running without any problems for several days.

CommanderROR9 commented 2 weeks ago

Hi. @tbnobody wrote somewhere here that the DTU doesn't reconnect immediately, but that it can take up to 10 minutes.

Do you have a 2nd ESP board to test? The Fusion board could also be defective.

For me, openDTU with v24.8.5 has been running without any problems for several days.

The Open DTU board never reconnects. Not even after 12 hours. But since I told my FritzBox to stay on a fixed channel it hasn't disconnected.. it's only been 3 hours so far now, but that's something at least. I have other ESP boards lying around...I can set one up with basic Wifi and so on and see how that works...I doubt my board is defective though, this seems like a Software issue.

jonastr commented 2 weeks ago

quoting from @schneeer

I would say that with or after openDTU v24.6.29 it was particularly bad, connection problems pretty much every day.

With v24.8.5 everything worked again, and there were no problems with the last FritzOS update a few days ago.

Not for me, unfortunately. I did update to most recent OpenDTU version and it appears that as soon as I activate mesh steering, the OpenDTU is starting to have connection issues again, being offline for hours. It oftentimes recovers by itself, but it's really annoying as it means losing data and not being able to run automation based on that data.

So, at least for my setup, I can say that there is no noticeable difference between 24.6.29 and 24.8.5.

What data could be useful to help further diagnostics?

DietmarSi commented 2 weeks ago

Hi,

I have the same issue with WiFi issue, reconnecting does not work.

Screenshot: OpenDTU_v24 8 5