WiFi issue still exists #2202
Comments
|
I have the same problem |
|
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 |
|
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. |
|
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. |
|
Ich kann das Problem bestätigen, alle paar Tage muss ich meine openDTU neustarten, weil nicht mehr erreichbar. |
|
Wie @Omega13x schon geschrieben hat, habe ich auch keine Probleme mit der V24.8.5. |
Gute Idee! Ich berichte dann |
|
Seit dem neuesten Update habe ich auch WiFi Probleme. Mit der vorherigen hatte ich die nie. |
|
@travor05 |
|
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. |
|
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. 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) |
|
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... |
|
@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. |
|
@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 |
|
@SteffenR87 you wanted to give us feedback on your issue after two days. 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. |
|
@Juergen2453 |
|
@travor05 |
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. |
|
@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.
|
|
@SteffenR87 do you have MQTT connected and can you check the BSSID value of your WiFi STAtion to which the OpenDTU is connected to ? @jstammi I came across the following threads: Optimizing ESP32 Connections with WiFiMulti Establish WiFi connection to AP with strongest radio signal WIFI_ALL_CHANNEL_SCAN, this parameter doesn't seem to work (IDFGH-6630) #8269 So basically they recommend to use ifconfig down
iwconfig mode monitor
ifconfig up
iwconfig channel 7
wiresharkI 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. |
|
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 <espressif/esp-idf#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
<#2202 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWNMAS7U7XEFZHTH4YJOF3ZRJ42TAVCNFSM6AAAAABMKAGLU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBXGE4TCMJWG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@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. |
|
@Juergen2453 |
|
My Setup:
Timeline:
Side note: |
|
"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
<#2202 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWNMAV7GOYSVZJUPAGCAXTZRM7CFAVCNFSM6AAAAABMKAGLU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBYGUZDCMZSGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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
<#2202 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWNMAWARFJO7XE4YTRE4XLZRL7TZAVCNFSM6AAAAABMKAGLU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBYGAYTONJRHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@ComGreed thanks for your review and the write up of your affected setup. What is Mesh Wi-Fi steering and how does it work? AVM erklärt 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? Does ESP32 support seamless Wi-Fi roaming (IEEE 802.11v, r, k) in the STA mode? (IDFGH-1392) 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 |
I am no expert in this either -- WDYT about the following pragmatic 1st step: Check connectivity regularly, attempt to reconnect if connection is lost? I am suggesting/asking this because I have another Wifi device with a USB Wifi dongle that does not support mesh steering either (I think none of the k/r/v standards). But it still reconnects when the AP terminates the connection -- according to AVM docs, this is what the Fritz mesh implementation does to force legacy devices to look for a better AP connection. It's not really mesh steering because these legacy devices still only pick the AP based on their local signal strength, not based on mesh load. Anyway, this machine is running Ubuntu Linux. Aka, there appear to be different strategies from basic "just reconnect to AP with best signal" to fully following the standards of service set transition (mesh steering). |
|
I think only the implementation of 802.11 k/r/v will help in the constellation with AVM Mesh. Otherwise a fixed channel (channel 1 is stable for me) or do not include the devices in the mesh. It would be nice if someone could tell me if there are plans to implement k/r/v in OpenDTU? |
Could you elaborate, why do you think that is the case? Like how is an average legacy Wifi dongle different (see my example above) - or why would a simple reconnect strategy not help at all? I don't say it would be the best solution, but couldn't it at least help alleviate the problem until proper k/r/v is implemented? |
k/r/v has to be implemented in the Arduino core. This is nothing which can be done in user space. Checking whether the connection is established is indeed already done. Its not done per interval its done event based. The IDF/Arduino core sends a disconnect event. Then the connection will be re-established. In this case you should also see an console output. It this does not happen, it's a bug in the Arduino Core. |
|
I know almost nothing about ESP32 Hardware or Software development...and I probably won't have much time to experiment with mine over the next two weeks. My guess as to what is causing this issue though is, that the ESP32 doesn't realise it has been disconnected due to the nature of the disconnect. If the Network were to drop out, this would likely trigger the reconnect. However, of it's only a "Channel change" by the Fritz Box, this might not trip the right wires. The ESP will perhaps still see the WiFi.and not realise it can no longer send or receive anything. IMHO this could easily be rectified by a "heartbeat" which would essentially ping the DNS Host at regular intervals and trigger a disconnect/reconnect if the Ping times out. |
DNS is not mandatory for a working DTU. Means, it can be empty. |
|
That's interesting. I wasn't aware the network connection could work with DNS. |
|
@tbnobody I see. Despite DNS, the DTU could nonetheless ping any IP address, right? Say, some host in the internal network like the router or MQTT server's address, possibly as an optional configuration. |
|
That would be an easy test IMHO..add an optional "ping heartbeat" setting. In my case I would just ping the Router 192.168.178.1 since that should always be Online |
@tbnobody did you look into the ESP-IDF example code for 802.11k/r/v mesh steering? https://github.com/espressif/esp-idf/tree/master/examples/wifi/roaming Maybe it is not yet implemented in the Arduino core which OpenDTU builds rely on. But on another thought maybe the events and processes of switching the STA from one of these BSSIDs to another BSSID allow us to determine which event may be missing / needs to be changed to make it work in Arduino/OpenDTU too ? Here they explicitly distinguish the disconnect reason WIFI_REASON_ROAMING: } else if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_DISCONNECTED) {
wifi_event_sta_disconnected_t *disconn = event_data;
ESP_LOGI(TAG, "station got disconnected reason=%d", disconn->reason);
if (disconn->reason == WIFI_REASON_ROAMING) {
ESP_LOGI(TAG, "station roaming, do nothing");
} else {
esp_wifi_connect();
} |
|
Currently I don't care about the disconnect reason. If a disconnect is received I just try to reconnect: OpenDTU/src/NetworkSettings.cpp Lines 78 to 86 in 0cc55f3 But that leads again to my request of a console output in case of a reconnect... Do you see a |
|
@tbnobody I would be happy to try to provide some logs. Unfortunately, I am not sure I have the means to retrieve the serial log. Did a bit of googling, returned various results, all with some gaps in the instructions, I feel. The best resource I could find is this one: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/establish-serial-connection.html. But it's still pretty vague, not sure what to do exactly for the board that I have. Do you have any better resources/howtos at hand? |
|
|
Hi, For most, WLAN shouldn't cause any problems, unless there are only a handful of openDTUs. My DTU has been running completely error-free for almost 23 days since the update to v24.8.5. Connection characteristics: Wi-Fi 4, 20 MHz, WPA3, 1 x 1 FRITZ!Box 7590, FRITZ!OS: 7.90-115394 BETA Band and mesh steering are active 2.4 GHz currently on channel 1 At the moment the DTU (OpenOTU-BW) was directly connected to FRITZ!Box. (As can be seen in the picture.) I'm watching this. |
|
@schneeer please consider providing us with a detailled serial log as requested:
Follow the link to the documentation to setup for USB / serial logging: @tbnobody would it be possible to add the disconnect reason to the logging somehow ? I searched in arduino-esp32 and found the following issue for WiFi Roaming: it enables the following four options in the PR: espressif/esp32-arduino-lib-builder#160 CONFIG_ESP_WIFI_11KV_SUPPORT=y
CONFIG_ESP_WIFI_SCAN_CACHE=y
CONFIG_ESP_WIFI_MBO_SUPPORT=y
CONFIG_ESP_WIFI_11R_SUPPORT=y |
|
Yes, I can do that, but as I said, to date the DTU has run without any errors for 23 days without (Wifi) interruption. I have no problems. I can relatively easily deactivate every WLAN AP in the mesh to which the DTU is currently connected. The 1st Test
PuTTY log 2024.09.02 20:11:07TX RealTimeRunData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF F2 00 00 00 00 00 00 00 00 DA B8 DB RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF F2 00 00 00 00 00 00 00 00 DA B8 DB RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF F2 00 00 00 00 00 00 00 00 DA B8 DB RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF F2 00 00 00 00 00 00 00 00 DA B8 DB RX Period End All missing Nothing received, resend count exeeded TX AlarmData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF F2 00 00 00 00 00 00 00 00 00 A3 00 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF F2 00 00 00 00 00 00 00 00 00 A3 00 **_WiFi disconnected_** **_Try reconnecting_** **_Websocket: [/livedata][1] disconnect_** RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF F2 00 00 00 00 00 00 00 00 00 A3 00 **_Network lost connection_** RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF F2 00 00 00 00 00 00 00 00 00 A3 00 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF F2 00 00 00 00 00 00 00 00 00 A3 00 RX Period End All missing Nothing received, resend count exeeded TX SystemConfigPara Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF F2 00 00 00 00 00 00 00 00 14 B7 14 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF F2 00 00 00 00 00 00 00 00 14 B7 14 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF F2 00 00 00 00 00 00 00 00 14 B7 14 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF F2 00 00 00 00 00 00 00 00 14 B7 14 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF F2 00 00 00 00 00 00 00 00 14 B7 14 RX Period End All missing Nothing received, resend count exeeded Fetch inverter: 116174406658 Request SystemConfigPara TX RealTimeRunData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF FA 00 00 00 00 00 00 00 00 1A DF 74 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF FA 00 00 00 00 00 00 00 00 1A DF 74 **_WiFi connected_** RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF FA 00 00 00 00 00 00 00 00 1A DF 74 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF FA 00 00 00 00 00 00 00 00 1A DF 74 **_WiFi got ip: 192.168.2.15_** **_Network connected_** RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D5 FF FA 00 00 00 00 00 00 00 00 1A DF 74 RX Period End All missing Nothing received, resend count exeeded TX AlarmData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF FA 00 00 00 00 00 00 00 00 C0 C4 AF RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF FA 00 00 00 00 00 00 00 00 C0 C4 AF RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF FA 00 00 00 00 00 00 00 00 C0 C4 AF RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF FA 00 00 00 00 00 00 00 00 C0 C4 AF RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D5 FF FA 00 00 00 00 00 00 00 00 C0 C4 AF RX Period End All missing Nothing received, resend count exeeded TX SystemConfigPara Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF FA 00 00 00 00 00 00 00 00 D4 D0 BB RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF FA 00 00 00 00 00 00 00 00 D4 D0 BB RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF FA 00 00 00 00 00 00 00 00 D4 D0 BB RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF FA 00 00 00 00 00 00 00 00 D4 D0 BB RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D5 FF FA 00 00 00 00 00 00 00 00 D4 D0 BB RX Period End All missing Nothing received, resend count exeeded Fetch inverter: 116174406658 Request SystemConfigPara TX RealTimeRunData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 02 00 00 00 00 00 00 00 00 69 86 5A RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 02 00 00 00 00 00 00 00 00 69 86 5A RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 02 00 00 00 00 00 00 00 00 69 86 5A RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 02 00 00 00 00 00 00 00 00 69 86 5A RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 02 00 00 00 00 00 00 00 00 69 86 5A RX Period End All missing Nothing received, resend count exeeded TX AlarmData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 02 00 00 00 00 00 00 00 00 B3 9D 81 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 02 00 00 00 00 00 00 00 00 B3 9D 81 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 02 00 00 00 00 00 00 00 00 B3 9D 81 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 02 00 00 00 00 00 00 00 00 B3 9D 81 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 02 00 00 00 00 00 00 00 00 B3 9D 81 RX Period End All missing Nothing received, resend count exeeded TX SystemConfigPara Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 02 00 00 00 00 00 00 00 00 A7 89 95 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 02 00 00 00 00 00 00 00 00 A7 89 95 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 02 00 00 00 00 00 00 00 00 A7 89 95 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 02 00 00 00 00 00 00 00 00 A7 89 95 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 02 00 00 00 00 00 00 00 00 A7 89 95 RX Period End All missing Nothing received, resend count exeeded Fetch inverter: 116174406658 Request SystemConfigPara TX RealTimeRunData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 0A 00 00 00 00 00 00 00 00 A9 E1 F5 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 0A 00 00 00 00 00 00 00 00 A9 E1 F5 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 0A 00 00 00 00 00 00 00 00 A9 E1 F5 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 0A 00 00 00 00 00 00 00 00 A9 E1 F5 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 0A 00 00 00 00 00 00 00 00 A9 E1 F5 RX Period End All missing Nothing received, resend count exeeded TX AlarmData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 0A 00 00 00 00 00 00 00 00 73 FA 2E RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 0A 00 00 00 00 00 00 00 00 73 FA 2E RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 0A 00 00 00 00 00 00 00 00 73 FA 2E RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 0A 00 00 00 00 00 00 00 00 73 FA 2E RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 0A 00 00 00 00 00 00 00 00 73 FA 2E RX Period End All missing Nothing received, resend count exeeded TX SystemConfigPara Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 0A 00 00 00 00 00 00 00 00 67 EE 3A RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 0A 00 00 00 00 00 00 00 00 67 EE 3A RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 0A 00 00 00 00 00 00 00 00 67 EE 3A RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 0A 00 00 00 00 00 00 00 00 67 EE 3A RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 0A 00 00 00 00 00 00 00 00 67 EE 3A RX Period End All missing Nothing received, resend count exeeded Fetch inverter: 116174406658 Request SystemConfigPara TX RealTimeRunData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 12 00 00 00 00 00 00 00 00 A9 4B 47 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 12 00 00 00 00 00 00 00 00 A9 4B 47 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 12 00 00 00 00 00 00 00 00 A9 4B 47 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 12 00 00 00 00 00 00 00 00 A9 4B 47 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 12 00 00 00 00 00 00 00 00 A9 4B 47 RX Period End All missing Nothing received, resend count exeeded TX AlarmData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 12 00 00 00 00 00 00 00 00 73 50 9C RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 12 00 00 00 00 00 00 00 00 73 50 9C RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 12 00 00 00 00 00 00 00 00 73 50 9C RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 12 00 00 00 00 00 00 00 00 73 50 9C RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 12 00 00 00 00 00 00 00 00 73 50 9C RX Period End All missing Nothing received, resend count exeeded TX SystemConfigPara Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 12 00 00 00 00 00 00 00 00 67 44 88 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 12 00 00 00 00 00 00 00 00 67 44 88 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 12 00 00 00 00 00 00 00 00 67 44 88 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 12 00 00 00 00 00 00 00 00 67 44 88 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 12 00 00 00 00 00 00 00 00 67 44 88 RX Period End All missing Nothing received, resend count exeeded Fetch inverter: 116174406658 Request SystemConfigPara TX RealTimeRunData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 1A 00 00 00 00 00 00 00 00 69 2C E8 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 1A 00 00 00 00 00 00 00 00 69 2C E8 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 1A 00 00 00 00 00 00 00 00 69 2C E8 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 1A 00 00 00 00 00 00 00 00 69 2C E8 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 1A 00 00 00 00 00 00 00 00 69 2C E8 RX Period End All missing Nothing received, resend count exeeded TX AlarmData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 1A 00 00 00 00 00 00 00 00 B3 37 33 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 1A 00 00 00 00 00 00 00 00 B3 37 33 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 1A 00 00 00 00 00 00 00 00 B3 37 33 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 1A 00 00 00 00 00 00 00 00 B3 37 33 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 1A 00 00 00 00 00 00 00 00 B3 37 33 RX Period End All missing Nothing received, resend count exeeded TX SystemConfigPara Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 1A 00 00 00 00 00 00 00 00 A7 23 27 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 1A 00 00 00 00 00 00 00 00 A7 23 27 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 1A 00 00 00 00 00 00 00 00 A7 23 27 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 1A 00 00 00 00 00 00 00 00 A7 23 27 RX Period End All missing Nothing received, resend whole request TX SystemConfigPara Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 05 00 66 D6 00 1A 00 00 00 00 00 00 00 00 A7 23 27 RX Period End All missing Nothing received, resend count exeeded Fetch inverter: 116174406658 Request SystemConfigPara TX RealTimeRunData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 22 00 00 00 00 00 00 00 00 A8 1F 22 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 22 00 00 00 00 00 00 00 00 A8 1F 22 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 61 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 22 00 00 00 00 00 00 00 00 A8 1F 22 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 75 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 22 00 00 00 00 00 00 00 00 A8 1F 22 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData Channel: 3 --> 15 74 40 66 58 80 14 20 27 80 0B 00 66 D6 00 22 00 00 00 00 00 00 00 00 A8 1F 22 **_Websocket: [/livedata][2] connect_** RX Period End All missing Nothing received, resend count exeeded TX AlarmData Channel: 23 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 22 00 00 00 00 00 00 00 00 72 04 F9 RX Period End All missing Nothing received, resend whole request TX AlarmData Channel: 40 --> 15 74 40 66 58 80 14 20 27 80 11 00 66 D6 00 22 00 00 00 00 00 00 00 00 72 04 F9 RX Period End All missing Nothing received, resend whole request The 2nd test
The 3rd test
Edit: Why the log is now destroyed, I have no idea. |
Yes, same applies to me. I also cannot reproduce this issue. 11K is enabled on the relevant SSID, 11V is disabled (as I don't have any devices which support it). |
Sure, just apply this code changes or wait for the next release: diff --git a/include/NetworkSettings.h b/include/NetworkSettings.h
index 40ddc914..433867e9 100644
--- a/include/NetworkSettings.h
+++ b/include/NetworkSettings.h
@@ -62,7 +62,7 @@ private:
void setStaticIp();
void handleMDNS();
void setupMode();
- void NetworkEvent(const WiFiEvent_t event);
+ void NetworkEvent(const WiFiEvent_t event, WiFiEventInfo_t info);
Task _loopTask;
@@ -85,4 +85,4 @@ private:
bool _lastMdnsEnabled = false;
};
-extern NetworkSettingsClass NetworkSettings;
\ No newline at end of file
+extern NetworkSettingsClass NetworkSettings;
diff --git a/src/NetworkSettings.cpp b/src/NetworkSettings.cpp
index 55ea428e..31313feb 100644
--- a/src/NetworkSettings.cpp
+++ b/src/NetworkSettings.cpp
@@ -23,20 +23,21 @@ NetworkSettingsClass::NetworkSettingsClass()
void NetworkSettingsClass::init(Scheduler& scheduler)
{
using std::placeholders::_1;
+ using std::placeholders::_2;
WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);
WiFi.setSortMethod(WIFI_CONNECT_AP_BY_SIGNAL);
WiFi.disconnect(true, true);
- WiFi.onEvent(std::bind(&NetworkSettingsClass::NetworkEvent, this, _1));
+ WiFi.onEvent(std::bind(&NetworkSettingsClass::NetworkEvent, this, _1, _2));
setupMode();
scheduler.addTask(_loopTask);
_loopTask.enable();
}
-void NetworkSettingsClass::NetworkEvent(const WiFiEvent_t event)
+void NetworkSettingsClass::NetworkEvent(const WiFiEvent_t event, WiFiEventInfo_t info)
{
switch (event) {
case ARDUINO_EVENT_ETH_START:
@@ -76,7 +77,8 @@ void NetworkSettingsClass::NetworkEvent(const WiFiEvent_t event)
}
break;
case ARDUINO_EVENT_WIFI_STA_DISCONNECTED:
- MessageOutput.println("WiFi disconnected");
+ // Reason codes can be found here: https://github.com/espressif/esp-idf/blob/5454d37d496a8c58542eb450467471404c606501/components/esp_wifi/include/esp_wifi_types_generic.h#L79-L141
+ MessageOutput.printf("WiFi disconnected: %d\r\n", info.wifi_sta_disconnected.reason);
if (_networkMode == network_mode::WiFi) {
MessageOutput.println("Try reconnecting");
WiFi.disconnect(true, false);
|
|
I was interested to know whether the latest updates have led to increased DTU activity and thus increased power consumption. I couldn't find anything unusual. When restarting, my DTU with display and NRF24 requires around 180 mA, and after a few seconds it only needs just under 100 mA. This is pretty much the same for several firmware versions. So I can rule that out. |
|
I still can't provide any meaningful insight, but turning off "auto channel" on my FritzBox 7690 seems to have completely eliminated the issue. Edit: I installed an Update for my Router this afternoon. At first the OpenDTU was still alive after the Update, but had connected to a different AP within the mesh. When I checked again later, the DTU had completely lost connection to the Network and never reconnected. |
|
I once bought an ESP32-S3 because it works better with WiFi. Yes, it's true. The S3 can handle AVM Mesh much better. I'm now going to switch to the S3 completely. |
|
Wwe would need some more logs from any of the Mesh users posting about a problem here: @SteffenR87 @jonastr @DietmarSi @ComGreed @CommanderROR9 @home-cloud @cortmen and whoever else still has the problem of loosing the connection with the DTU / inverter please 🙏 send us a log so we can analyse the issue in more detail. Currently we only have anecdotal evidence that you are all plagued by this issue and it may have something to do with Mesh Roaming / Steering. Follow the link to the documentation to setup for USB / serial logging: PS: @Andre0be we have found out that neither our OpenDTU nor the default Arduino WiFi libraries do support 802.11r/k/v yet. That is the ESP-IDF has some example code but regardless of whether you are using the ESP32S3 or any other Espressif chip, neither will make use of these developments yet. You may be right that ESP32S3 could be a bit better at WiFi in general eg compared with the slightly older ESP32 Wroom models but not with the above three standards on mesh roaming and steering. |
Hi @stefan123t, fully understood. While I am willing to contribute, I didn't have the time yet to set everything up. It's no one's fault, but given that I need to get another machine ready to monitor the logs doesn't make it easier; I don't have one at hand. It may take some more days, perhaps weeks until I find the time. :) In the meantime, I can report that my problems seem to have vanished for now after physically relocating the DTU very close to the main Fritzbox. This was only possible because I relocated the inverter before. In any case, I had no interruptions since multiple days after that, despite mesh steering being activated. I am pretty sure I can reproduce it in the old physical DTU location, though. So again, when I find the time, I will capture the logs. |
|
So.... unfortunately I still can't provide any logs, but after having a stable connection for about a week I decided to turn the "Auto Channel" feature back on in my FritzBox and...after just an hour or so the OpenDTU lost connection again and never rejoined the Network. |
|
@CommanderROR9 bitte die Logs dazu sonst können wir das Problem nicht analysieren. Danke! Follow the link to the documentation to setup for USB / serial logging: |
Next week I should have a little more time and will attempt to provide the logs. |
|
I am also curious about the logs!
|
|
Hi there, i have change my opendtu to esp32-s3 and a new location. |
Das bringt bei mir nichts. Erst mit Neustart der OpenDTU kommt wieder eine Verbindung zustande (ich habe 1+ Stunde vergeblich gewartet und gehofft, dass die Verbindung automatisch wieder hergestellt wird). |
and others
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
The text was updated successfully, but these errors were encountered: