No wifi reconnection after connection loss - Heishamon Large (ESP32) #621
Comments
|
I can confirm this behavior, i noticed after updating rebooting my AP heishamon will go to failsafe hotspot mode, and will not reconnect, just rebooted heishamon and it connect's back. |
|
No there is something else weird going on with ESP32 wifi. I haven't figured it out yet. Will keep searching when I have some more spare time |
|
I have found the problem. It is a logical error in the function check_wifi(). The ESP32 also loses the IP address at the same time as the connection. This means that result of line 173 is always false: On the ESP32 you get the correct information WL_CONNECTION_LOST as wifistatus if the connection is lost. I suggest the following change: void check_wifi() { } else if ((wifistatus != WL_CONNECTED) || (!WiFi.localIP())) { |
|
No that is not it. That if statement is specially written for the ESP8266 which can be in this state. I know that for the ESP32 it will never go in that statement. |
|
I hope to have it fixed in IgorYbema@2eee519 and will release in v3.9 |
I have the same issue of @oxyde42 ...can we try the beta release of 3.9 ? because in raining conditions I need to reconnect the board every day |
|
Yes you can test it. If you login to github and go to this page, you will see a 'artificat' which is a ZIP file containing test firmware for v3.9. The ESP8266 file is for the small heishamon and the ESP32 is for the large heishamon |
|
an "this page" is with page ? any link ? |
|
Sorry, forgot the link: https://github.com/IgorYbema/HeishaMon/actions/runs/12772225974 |
|
For me this went somehow terrible wrong. Web interface become unresponsive, also didn't get any values from pump Previous worked version for me was |
|
if it gives something here is partial log from access point
and ping
|
|
and by block access to AP it will not go to hot spot mode anymore. |
For me works fine and it connects automatically to my AP |
|
For my old ESP8266 based also fine. |
|
@geduxas this version does try to connect to any accesspoint with the corrent SSID on each channel and tries to look for the strongest one. Maybe it now connects to a faulty (but stronger) accessspoint at your home? That is the only thing what I can think of right now. |
|
Or it is crashing. Check the stats mqtt log line for the uptime |
|
no, i have disabled all of them, and seams its crashing, here is output from console: |
|
Damn, then this one isn't ready for release yet. Can you tell me you setup? What could be different with your config. What are your settings? |
|
no rules, no dallas, no s0 large board using relays, mqtt with password, wifi with possible multiple AP.. full mqtt retransmit lowest possible (5s ?) everything worked in this build: https://github.com/IgorYbema/HeishaMon/actions/runs/12716712132 |
|
Ah ok then it isn't hard to find the cause. Can you try working upwards from the builds from where it did work? Only focus on the v3.9b succes builds. So https://github.com/IgorYbema/HeishaMon/actions?query=branch%3A3.9b+is%3Asuccess |
|
It could be the websocket change (the latest one on the list) causing this. If you have retransmit each 5s this causes a lot of websocket traffic. If this is the cause, I'll need to redesign this. -- edit: no this can't be it as it isn't causing more websocket traffic -- |
|
Ah wait, I see where it goes wrong. At TOP92. That is the heatpump model which now got changed. I'll focus on looking why this goes wrong for you |
|
@geduxas please try the build from this run when it finishes. I believe I found the issue. |
|
yes, in release where removed heatpump model it started to crash https://github.com/IgorYbema/HeishaMon/actions/runs/12736286709 ill try latest |
|
ok, latest working without crash. interesting why it effect only me ? |
|
The function ran out of boundary (buffer overflow) and that causes problems at random. Not sure how this exactly works but it really depends on how the controller maps the memory. Good we found it. |
|
I have made some test's on my WiFi, and it's works!. After disabling access to one of my AP, heishamon switches to another, disabling on all AP's it will switch to hotspot mode. And bringing back access to AP it will reconnect to AP. So this issue may be closed I think |
interesting fact that with crashing firmware if I wait for a while, about after 10-20 minutes it will boot, and will work after all.. but after I reset it or reboot it will go to crash cycle... |
|
Now I have waited until the release of the finished version 3.9. Unfortunately, the implemented change does not bring any improvement on the ESP32. Although the Heishamon now connects to the strongest SSID (my repeater), the connection loss still happens again - without reconnecting. Out of desperation, I took the esphome_panasonic_heatpump project as a model and started my own ESPHome Heishamon. Connected to the proxy port of the big Heishamon, it maintains the wifi connection to my home assistant, despite the fact that I use a hideous “ESP32-C3 Super Mini” for it. |
|
Strange why you're setup is working different. I had same problem as yours, but with 3.9 it's now works as expected, if one of my AP will go down, heishamon jumps to another, if all AP's down it will open hotspot, and after bringing AP back it will recover and connect's to my wifi.. |
Yes, after pressing the boot button everything is O.K. again. The Heishamon otherwise continued to run without errors. I could see this on my ESPHome adapter connected to the proxy port. |
|
So why it's disconnect from wifi? What wifi AP do you use? Us it possible to reproduce? Also if you can manually trigger problem, could you share log from usb interface? |
|
No, unfortunately I cannot reproduce this. I have a FRITZ!Box 7580 with FRITZ!OS: 07.30 as an access point and also a FRITZ!Repeater 2400, which is within a decent range. I have a Wifi signal of 74% to the repeater (Heishamon display). My Fritz! repeater says: 2.4 GHz, 137 Mbit/s down, 70 Mbit/s up, Wi-Fi 4, 40 MHz, WPA3, 1 x 1. If the connection is lost, I can no longer access the log. It doesn't happen so often that I could record the log via USB-C with the laptop. |
|
Is it possible that your AP somehow change's it's channels, and it could lead to this behavior? |
Is it possible that your AP is somehow changing its channels and this could be causing this behavior? No, the channel is fixed. Now I have tried to provoke this loss of connection. I have kicked out the heishamon on the repeater and forbidden renewed access. It switched to the worse access point without any errors. Now it stays there. I am attaching the log. |
|
If it can't reconnect within 30 secs it starts the access point but it will still keep trying to reconnect. If it reconnects it shuts down the access point again. |
No, I can rule that out. It only seems to happen after a cold boot. When I restarted the Heishamon via reset, the wifi connection seems to be stable. But now a question about roaming: If it now works wonderfully to select the best AP, can't it also be done cyclically to switch to the best one? I can select this in ESPHome, and the µC also consumes much less power there. |
Sometimes my Heishamon loses the wifi connection, but there is no reconnection.
Has this been forgotten for the ESP32?
void check_wifi() {
int wifistatus = WiFi.status();
if ((wifistatus != WL_CONNECTED) && (WiFi.localIP())) {
// special case where it seems that we are not connect but we do have working IP (causing the -1% wifi signal), do a reset.
#ifdef ESP8266
log_message(_F("Weird case, WiFi seems disconnected but is not. Resetting WiFi!"));
setupWifi(&heishamonSettings);
#else // here for ESP32
log_message(_F("WiFi just got disconnected, still have IP addres."));
#endif
...
Or can a reconnection be triggered with a rule?
The text was updated successfully, but these errors were encountered: