2.4.1 doesn't connect to Wifi anymore

mhoogenbosch commented 1 year ago

Describe the bug Have two CVE boards, both I tried updating from 2.3.5 to 2.4.1 tonight. Both are offline. They show up with their AP booted up. I can connect to the AP of the board and scan the WIFI, my WIFI to which it has always been connected for at least a year or maybe even more. After the update all settings are maintained and in the config if connected to the app.

I first did a normal reset, then a format of the filesystem. Both didn't work.

To Reproduce Update from 2.3.5, did this on two devices.

Expected behaviour to connect to wifi

Screenshots not applicable

Device information

Firmware version 2.3.5 -> 2.4.1
Hardware revision hw 2
Type/model number Itho : ECO
CC1101 RF module enabled [ yes, no ]
In case of wifi issues, wifi access point make and model: Unifi nano HD downstairs and Unifi Lite upstairs

Debug logging Please provide debug logging from the debug page if possible:

logfile0.current.log

Desktop (please complete the following information):

OS: [e.g. iOS] => ios nad windows device with chrome
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

arjenhiemstra commented 1 year ago

I have a Unifi Lite and two Unifi AC Pro's here with no issues but read on the tweakers forum that for someone the 2.4.1 version tried to connect to the most distant AP and kept trying that. In version 2.4.2-beta1 I explicitly reset the wifi storage on board of the MCU, maybe this helps. Also, which firmware version is running on your AP devices?

mhoogenbosch commented 1 year ago

I honestly dont know how to check to which AP it tries to connect to. I have 5 AP’s around the house, and when I hit ‘scan’ I Always select the one with the most bars. The AP’s are running the latest RC version which is 6.2.39.

I’ll try the beta1 tonight when I’m home again.

Thanks!

Verzonden vanuit Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 voor Windows

Van: Arjen @.> Verzonden: dinsdag 27 september 2022 22:27 Aan: @.> CC: Martijn @.>; @.> Onderwerp: Re: [arjenhiemstra/ithowifi] 2.4.1 doesn't connect to Wifi anymore (Issue #108)

I have a Unifi Lite and two Unifi AC Pro's here with no issues but read on the tweakers forum that for someone the 2.4.1 version tried to connect to the most distant AP and kept trying that. In version 2.4.2-beta1 I explicitly reset the wifi storage on board of the MCU, maybe this helps. Also, which firmware version is running on your AP devices?

— Reply to this email directly, view it on GitHubhttps://github.com/arjenhiemstra/ithowifi/issues/108#issuecomment-1260010681, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIZQWDU7N26S7UYWPALEMADWANKDFANCNFSM6AAAAAAQXCU7IM. You are receiving this because you authored the thread.Message ID: @.***>

mhoogenbosch commented 1 year ago

For some weird reason the downstairs CVE has connected to my Wifi again. The upstairs CVE still doesn't want to connect. Have tried formating the board too. Made it powerless a couple of times, nothing works. I updated to 2.4.2b1. It finds the wifi networks but doesn't connect.

arjenhiemstra commented 1 year ago

I now have experienced also a few connection issues. The biggest changes between the later alpha version and the final were: 1- ESP32 Lib has been updated from 3.50 to 5.1.1 2- Wifi init code has been changed, it appeared some pieces of code were called but never had their intended result.

It seems that for some users these changes solved their wifi issues, for some others it created them.

So two things to do I think to rule out 1 and/or 2, first I will build the latest firmware with the older ESP32 lib. Second I will roll back the wifi changes and build it with the old and new ESP32.

I hope you can help testing the different iterations.

vandenberghev commented 1 year ago

I'm having connectivity issues with Ubiquiti AP's as well, both on 2.3.5 and 2.4.x (Tweakers guy checking in 😊).

The issue mainly appears to be connecting; once it's connected, I find it to be pretty stable. But getting it to connect is a nightmare. I played around a bit this evening, tried switching AP's, changes 2.4GHz channels, disabled band steering, ... Didn't do a thing. Ended up compiling my own firmware(s) with some changes:

Delay 1-2 seconds between the first WiFi.disconnect and WiFi.begin(), as inspired by this issue (the DEAUTH happens for me as well). No change.
Default firmware tries to connect for 30 seconds, changed this to 60 seconds. No change.
Added a subsequent WiFi.disconnect(), delay and WiFi.begin() if the first begin() results in a status that is not WL_DISCONNECTED. Inspired by this issue. You can find my commit here. This seems to greatly improve chances of connection.

2337 I: System boot, last reset reason: SDIO_RESET
2602 I: HW rev: 2, FW ver.: 2.5.3
66610 I: Setup: wifi not connected - WL_DISCONNECTED
66805 I: Setup: Wifi connect STA failed
68355 I: wifi AP mode started
68488 I: Setup: AP mode active
68650 I: Setup: Virtual remotes, start ID: 32,D1,BC - No.: 1
68877 I: Setup: remotes configfile loaded
69271 I: I2C init: QueryDevicetype - fw:27 hw:29
69649 I: I2C init: QueryStatusFormat - items:25
70043 I: I2C init: QueryStatus
72091 I: MQTT: connection failed, System config: 1
72477 I: Webserver: started
72628 I: mDNS: started
72780 I: Hostname: nrg-itho-d1bc
72947 I: Setup: done
391982 I: Firmware update: nrgitho-hw2-v2.5.4.bin
415517 I: Reboot requested
2290 I: System boot, last reset reason: SDIO_RESET
2508 I: HW rev: 2, FW ver.: 2.5.4
6947 I: Disconnected, reconnecting in 1s
10551 I: WiFi: connection successful
10673 I: WiFi info:
10798 I: Mode:STA
10963 I: Status:WL_CONNECTED
11137 I: IP:192.168.2.10
11320 I: Setup: Virtual remotes, start ID: 32,D1,BC - No.: 1
11582 I: Setup: remotes configfile loaded
14797 I: MQTT: connection failed, System config: 1
15039 I: Webserver: started
15454 I: mDNS: started
15675 I: I2C init: QueryDevicetype - fw:27 hw:29
15826 I: Hostname: nrg-itho-d1bc
15981 I: Setup: done
16147 I: I2C init: QueryStatusFormat - items:25
16516 I: I2C init: QueryStatus
18048 I: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
2297 I: System boot, last reset reason: POWERON_RESET
2530 I: HW rev: 2, FW ver.: 2.5.4
2493 I: System boot, last reset reason: POWERON_RESET
2715 I: HW rev: 2, FW ver.: 2.5.4
9970 I: Disconnected, reconnecting in 1s
13394 I: WiFi: connection successful
13563 I: WiFi info:
13745 I: Mode:STA
13943 I: Status:WL_CONNECTED
14150 I: IP:192.168.2.10
14363 I: Setup: Virtual remotes, start ID: 32,D1,BC - No.: 1
14677 I: Setup: remotes configfile loaded
15245 I: I2C init: QueryDevicetype - fw:27 hw:29
15547 I: I2C init: QueryStatusFormat - items:25
15880 I: I2C init: QueryStatus
18064 I: MQTT: connection failed, System config: 1
18267 I: Webserver: started
18468 I: mDNS: started
18671 I: Hostname: nrg-itho-d1bc
18890 I: Setup: done
22324 I: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
952982 I: Reboot requested
2250 I: System boot, last reset reason: SDIO_RESET
2433 I: HW rev: 2, FW ver.: 2.5.4
51147 I: Setup: wifi not connected - WL_DISCONNECTED
51351 I: Setup: Wifi connect STA failed
52986 I: wifi AP mode started
53207 I: Setup: AP mode active
53439 I: Setup: Virtual remotes, start ID: 32,D1,BC - No.: 1
53807 I: Setup: remotes configfile loaded
54149 I: I2C init: QueryDevicetype - fw:27 hw:29
54496 I: I2C init: QueryStatusFormat - items:25
54862 I: I2C init: QueryStatus
56975 I: MQTT: connection failed, System config: 1
57191 I: Webserver: started
57413 I: mDNS: started
57639 I: Hostname: nrg-itho-d1bc
57874 I: Setup: done
953189 I: Reboot requested
2241 I: System boot, last reset reason: SDIO_RESET
2487 I: HW rev: 2, FW ver.: 2.5.4
7918 I: WiFi: connection successful
8076 I: WiFi info:
8259 I: Mode:STA
8459 I: Status:WL_CONNECTED
8668 I: IP:192.168.2.10
8882 I: Setup: Virtual remotes, start ID: 32,D1,BC - No.: 1
9228 I: Setup: remotes configfile loaded
12377 I: MQTT: connection failed, System config: 1
12544 I: Webserver: started
12716 I: mDNS: started
12894 I: Hostname: nrg-itho-d1bc
13093 I: Setup: done
15266 I: I2C init: QueryDevicetype - fw:27 hw:29
15651 I: I2C init: QueryStatusFormat - items:25
16065 I: I2C init: QueryStatus
16417 I: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
60062 I: Attempt to reconnect WiFi
65311 I: Disconnected, reconnecting in 1s
68816 I: Disconnected, reconnecting in 1s
72345 I: Disconnected, reconnecting in 1s
75876 I: Disconnected, reconnecting in 1s
79329 I: Reconnect WiFi successful
82595 I: HA DISCOVERY: Start publishing MQTT Home Assistant Discovery...
2099788 I: Warning: Task MQTT timed out!
2448 I: System boot, last reset reason: SDIO_RESET
2593 I: HW rev: 2, FW ver.: 2.5.4
8097 I: Disconnected, reconnecting in 1s
11638 I: Disconnected, reconnecting in 1s
15169 I: Disconnected, reconnecting in 1s
18610 I: WiFi: connection successful
18805 I: WiFi info:
18994 I: Mode:STA
19183 I: Status:WL_CONNECTED
19567 I: IP:192.168.2.10
19783 I: Setup: Virtual remotes, start ID: 32,D1,BC - No.: 1
19965 I: Setup: remotes configfile loaded
20326 I: I2C init: QueryDevicetype - fw:27 hw:29
20676 I: I2C init: QueryStatusFormat - items:25
21049 I: I2C init: QueryStatus
23148 I: MQTT: connection failed, System config: 1

Not a 100% success rate, but I was also updating AP firmware & Unifi controllers in between so that may have caused the failure to connect, I'm not sure. I didn't check the AP debug logs, I might end up doing that one of the next days.

TL;DR: the connect-disconnect-connect trick from the issue linked above seems to help.

BTW I'm also willing to test some beta firmwares to help resolve this issue 👍

TD-er commented 1 year ago

On some access points which are either running WiFi mesh, or at least capable of doing so, it might also help to force the ESP to connect in 802.11b or 802.11g mode only.

(by the way, Tweakers user too, with the same alias :) )

mhoogenbosch commented 1 year ago

Yes I really want to help get this sorted! No problem. I was already looking for a new beta, but I guess you are busy with it.

I reverted the AP back to the latest official FW (6.2.35) because of some stability with Shelly’s. That seems to work better now, but the ITHO wifi board upstairs still doesn’t want to connect.

ps. Tweakers.net users here too, but not very active ;-)

arjenhiemstra commented 1 year ago

I've added the changes of @vandenberghev to the beta2 release. I've had a better experience connecting to wifi compared to the 2.4.1 release.

mhoogenbosch commented 1 year ago

I've added the changes of @vandenberghev to the beta2 release. I've had a better experience connecting to wifi compared to the 2.4.1 release.

Maybe I'm doing something wrong, but it keeps saying beta1 firmware is installed. Could you validate the links i'm using is correct? : https://github.com/arjenhiemstra/ithowifi/raw/master/compiled_firmware_files/hardware_rev_2/nrgitho-hw2-v2.4.2-beta2.bin

arjenhiemstra commented 1 year ago

Yes, I downloaded via that link and flashed my devices with it. Correctly says it's on beta2. I noticed with funky wifi it seems that flashing sometimes also fails. A possible solution would be to start in AP mode or fail save mode and go to http://192.168.4.1/update and flash the firmware.

mhoogenbosch commented 1 year ago

Yes, I downloaded via that link and flashed my devices with it. Correctly says it's on beta2. I noticed with funky wifi it seems that flashing sometimes also fails. A possible solution would be to start in AP mode or fail save mode and go to http://192.168.4.1/update and flash the firmware.

the beta2 installed fine after using the /update url. It unfortunately still doesn't want to connect. It keeps coming back to the AP mode. It finds 27 SSIDs

logfile0.current.log

mhoogenbosch commented 1 year ago

I just downgraded to 2.3.5 and it connects immediately. This just to validate ;-)

And update to 2.4.2b2 fails to connect again.

arjenhiemstra commented 1 year ago

Ok thats a pity but thanks for the feedback!

This version is feature wise a version 2.4.2 build but with the old wifi init code and older core libs. Could you try this one to set a baseline? If this works I will generate different build pulling in the other changes one by one until it fails.

nrgitho-dev-v2.4.2-wifitest1.bin.zip

sanderkob commented 1 year ago

The test version updated without problems, immidiately connected to STA, so no problems.

mhoogenbosch commented 1 year ago

The test version updated without problems, immidiately connected to STA, so no problems.

and you were having issues, or did the 2.4.1 FW connect too?

arjenhiemstra commented 1 year ago

The test version updated without problems, immidiately connected to STA, so no problems.

An nog log entry with "WiFi: status != WL_DISCONNECTED, reinit setup"?

arjenhiemstra commented 1 year ago

Ok, then this build. It is with the latest arduino core (5.2.0 in this case) but with mostly the old wifi init code. Mostly because 1 statement of that code is for sure causing issues in combination with 5.2.0 so I removed that one but otherwise it is the same. https://github.com/arjenhiemstra/ithowifi/blob/2bb1eff0a85a129f7567842291573f4a5a6ac1c5/software/NRG_itho_wifi/src/task_syscontrol.cpp#L475-L505 (minus line 490) plus https://github.com/arjenhiemstra/ithowifi/blob/2bb1eff0a85a129f7567842291573f4a5a6ac1c5/software/NRG_itho_wifi/src/task_syscontrol.cpp#L563-L608 in case of DHCP on. (minus 582-597)

nrgitho-dev-v2.4.2-wifitest2.bin.zip

arjenhiemstra commented 1 year ago

If that last one works, the puzzle would become a whole lot smaller....

TD-er commented 1 year ago

For ESP32 I do this when explicitly disconnecting:

  WiFi.disconnect();
  WiFi.removeEvent(wm_event_id);
  {
    const IPAddress ip;
    const IPAddress gw;
    const IPAddress subnet;
    const IPAddress dns;
    WiFi.config(ip, gw, subnet, dns);
  }

sanderkob commented 1 year ago

nrgitho-dev-v2.4.2-wifitest2.bin also connects immediately, no issues in debug log

sanderkob commented 1 year ago

The test version updated without problems, immidiately connected to STA, so no problems.

and you were having issues, or did the 2.4.1 FW connect too?

As of 2.4.2 fw I had problems with the wifi connection: the add-on started on AP mode and was difficult to get into STA.

mhoogenbosch commented 1 year ago

Ok, then this build. It is with the latest arduino core (5.2.0 in this case) but with mostly the old wifi init code. Mostly because 1 statement of that code is for sure causing issues in combination with 5.2.0 so I removed that one but otherwise it is the same.

https://github.com/arjenhiemstra/ithowifi/blob/2bb1eff0a85a129f7567842291573f4a5a6ac1c5/software/NRG_itho_wifi/src/task_syscontrol.cpp#L475-L505

(minus line 490) plus https://github.com/arjenhiemstra/ithowifi/blob/2bb1eff0a85a129f7567842291573f4a5a6ac1c5/software/NRG_itho_wifi/src/task_syscontrol.cpp#L563-L608

in case of DHCP on. (minus 582-597) nrgitho-dev-v2.4.2-wifitest2.bin.zip

does the wifitest2 have a 'new' build name with the update page? If I update with this build it still says beta2.

// scratch that it now shows wifitest2, but still doesn't connect.

logfile1.current.log

mhoogenbosch commented 1 year ago

quick question; If I scan wifi, it shows all AP's separately. My SSID is called 'Apparaten-2G', It shows 5 of them all with a couple of bars. When selecting a AP does it actually connect to that specific AP or does it try to connect to the 'best' AP with a SSID. I could try and kill a couple of AP's to see if roaming is the issue, would that be helpful?

vandenberghev commented 1 year ago

quick question; If I scan wifi, it shows all AP's separately. My SSID is called 'Apparaten-2G', It shows 5 of them all with a couple of bars. When selecting a AP does it actually connect to that specific AP or does it try to connect to the 'best' AP with a SSID. I could try and kill a couple of AP's to see if roaming is the issue, would that be helpful?

The WiFi connection is started with only an SSID and password, there is no BSSID given. Whatever happens after that, is black box magic 😋 (well, to me at least).

vandenberghev commented 1 year ago

@ Everyone testing: make sure you perform your test multiple times to see if the behavior is consistent. One random test might be successful, but the result needs to be reproducible all the time and not based on happenstance.

vandenberghev commented 1 year ago

On some access points which are either running WiFi mesh, or at least capable of doing so, it might also help to force the ESP to connect in 802.11b or 802.11g mode only.

@TD-er Do you mean a setting on the ESP itself, or in Unifi?

[EDIT] Never mind, just found it in the ESP docs :)

[/EDIT]

Connecting in b mode could be an interesting approach, there's hardly any throughput and the connection should be more reliable. Not sure if it changes anything while setting up the connection?

arjenhiemstra commented 1 year ago

@vandenberghev have you also tested nrgitho-dev-v2.4.2-wifitest1.bin.zip?

sanderkob commented 1 year ago

@ Everyone testing: make sure you perform your test multiple times to see if the behavior is consistent. One random test might be successful, but the result needs to be reproducible all the time and not based on happenstance.

Repeated nrgitho-dev-v2.4.2-wifitest2 successfully.

vandenberghev commented 1 year ago

@vandenberghev have you also tested nrgitho-dev-v2.4.2-wifitest1.bin.zip?

Not yet, I'll try either tonight or tomorrow.

arjenhiemstra commented 1 year ago

Interesting stuff here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html

scan_method	For WIFI_FAST_SCAN scan, the scan ends when the first matched AP is found. For WIFI_ALL_CHANNEL_SCAN, the scan finds all matched APs on all channels. The default scan is WIFI_FAST_SCAN.

sort_method

This field is only for WIFI_ALL_CHANNEL_SCAN.If the sort_method is WIFI_CONNECT_AP_BY_SIGNAL, all matched APs are sorted by signal, and the AP with the best signal will be connected firstly. For example, the station wants to connect an AP whose SSID is “apxx”. If the scan finds two APs whose SSID equals to “apxx”, and the first AP’s signal is -90 dBm while the second AP’s signal is -30 dBm, the station connects the second AP firstly, and it would not connect the first one unless it fails to connect the second one.[...]

Not sure which methods are use by the arduino-esp32 core, would be good to look into this

TD-er commented 1 year ago

WIFI_FAST_SCAN differs depending on how specific you are with the connection parameters. Per channel it will scan for at least the set minimum nr. of msec. But the actual scan time per channel depends on whether any AP may have replied in that time.

This does matter when the "best" AP is quite busy while scanning and thus may take slightly longer to reply. Have to check, but I think the default minimum is 70 msec per channel. You may want to set this minimum to 100 msec (or actually 103 msec as the default beacon interval is almost always 102.4 msec) so you have a significant higher chance the desired AP is seen.

If you set the explicit MAC address and channel while connecting, the connection will be made a lot faster. However, you still may want to add some delays right after changing the WiFi.mode as things will otherwise timeout. Thus by adding some delays, you may actually speedup things :)

arjenhiemstra commented 1 year ago

Looking at the arduino-esp32 repo here: https://github.com/espressif/arduino-esp32/blob/5f6d093d4a8a371c78acd6e1a0e7a95b7346cbec/libraries/WiFi/src/WiFiSTA.h#L69-L70

Default scan_method = WIFI_FAST_SCAN and default sort_method = WIFI_CONNECT_AP_BY_SIGNAL

So if I read the ESP IDF docs correctly WIFI_CONNECT_AP_BY_SIGNAL sort method is default but isn't having any effect because WIFI_FAST_SCAN is active

vandenberghev commented 1 year ago

Just FYI: this might be completely unrelated, but I just saw a post in the Tweakers Ubiquiti thread that mentions recent AP switching/sticky client issues... (see here)

Is everyone here using Ubiquiti AP's?

TD-er commented 1 year ago

So if I read the ESP IDF docs correctly WIFI_CONNECT_AP_BY_SIGNAL sort method is default but isn't having any effect because WIFI_FAST_SCAN is active

Nope. You can still have multiple matching APs found when scanning in fast scan mode. Depends on how specific you are when calling WiFi.begin And when in doubt, you can also scan yourself and pick the best AP from the found list.

mhoogenbosch commented 1 year ago

Just FYI: this might be completely unrelated, but I just saw a post in the Tweakers Ubiquiti thread that mentions recent AP switching/sticky client issues... (see here)

Is everyone here using Ubiquiti AP's?

Yes, I am and so is @arjenhiemstra himself I believe. I downgraded to the latest official release because of some wireless issues I was having with some Shelly's (not all). The current version I'm running is 6.2.35 where the latest RC version is 6.2.39. I however do not have any issues with FW 2.3.5 connecting to my SSID based on the same FW versions of my Unifi AP's.

arjenhiemstra commented 1 year ago

Nope. You can still have multiple matching APs found when scanning in fast scan mode. Depends on how specific you are when calling WiFi.begin And when in doubt, you can also scan yourself and pick the best AP from the found list.

Ok, so by default WIFI_CONNECT_AP_BY_SIGNAL is active and working while connecting? Or is it that (with the standard non specific config in WiFi.begin) any AP, which carries the SSID name that the ESP32 is configured to connect to, that reacts fast enough or the fastest gets connected? Or will a lower signal level AP only get connected when other higher signal level AP's do not react in time?

arjenhiemstra commented 1 year ago

Is see the documentation in the WiFiSTA.cpp code is quite descriptive:

on setScanMethod() /**

Set the way that AP is chosen.
First SSID match[WIFI_FAST_SCAN] or Sorted[WIFI_ALL_CHANNEL_SCAN] (RSSI or Security)
Must be called before WiFi.begin()
@param scanMethod wifi_scan_method_t */ and WIFI_FAST_SCAN = default

So I believe that with the code that currently is active for the add-on, the WIFI_FAST_SCAN option is active and the add-on will connect based on first SSID match and not on RSSI sort. So if we have multiple AP's with the same SSID and "the scan ends when the first matched AP is found", if that AP match is only based on SSID name and that AP first matched is far away and difficult to connect to, connection could well enough fail. That could explain the behaviour we are observing isn't it?

TD-er commented 1 year ago

If you have multple APs with the same SSID, you may also be facing the issue where an AP may disconnect you if it thinks you should connect to another one. This typically happens when you have WiFi mesh capable access points.

One way to overcome this is to force connecting using the 802.11g protocol instead of the 802.11n

About the fast scan... There is a difference between performing a scan and then connecting or only calling WiFi.begin() with a specific ssid set. Or at least there was... Have to check the code to see if it clears the last scan results when connecting. If you're only calling WiFi.begin() with a specific ssid set, it will connect to the one which replies the fastest. But... if you increase the minimal scan time and your separate APs with the same SSID run on the same channel, there will still be something to sort.

arjenhiemstra commented 1 year ago

So I see that one could call WiFi.begin() with just the SSID/PWD combo (which is what I'm using) or also with an BSSID specified. The BSSID info is currently not used (so it doesn't matter which AP you select after a wifi scan on the web interface if multiple AP have the same name).

I've added:

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

To the wifi init code

The observed behaviour is completely different. Now it seems (at least here) that the add-on connects to the strongest AP every time. If I switch floors here at my house the add-on immediately connects to the correct (=closest) AP every time.

Please test with attached file if this is also the case for you.

nrgitho-dev-v2.4.2-wifitest3.bin.zip

arjenhiemstra commented 1 year ago

For the ones reading along, the shared firmware files in this issue are only for the CVE hw rev2 version of the add-on.

sanderkob commented 1 year ago

So I see that one could call WiFi.begin() with just the SSID/PWD combo (which is what I'm using) or also with an BSSID specified. The BSSID info is currently not used (so it doesn't matter which AP you select after a wifi scan on the web interface if multiple AP have the same name).

I've added:
WiFi.setSortMethod(WIFI_CONNECT_AP_BY_SIGNAL);
WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);
To the wifi init code

The observed behaviour is completely different. Now it seems (at least here) that the add-on connects to the strongest AP every time. If I switch floors here at my house the add-on immediately connects to the correct (=closest) AP every time.

Please test with attached file if this is also the case for you.

nrgitho-dev-v2.4.2-wifitest3.bin.zip

Updated twice, first time connected after a few seconds (scanning?), second time immediately.

mhoogenbosch commented 1 year ago

So I see that one could call WiFi.begin() with just the SSID/PWD combo (which is what I'm using) or also with an BSSID specified. The BSSID info is currently not used (so it doesn't matter which AP you select after a wifi scan on the web interface if multiple AP have the same name).

I've added:
WiFi.setSortMethod(WIFI_CONNECT_AP_BY_SIGNAL);
WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);
To the wifi init code

The observed behaviour is completely different. Now it seems (at least here) that the add-on connects to the strongest AP every time. If I switch floors here at my house the add-on immediately connects to the correct (=closest) AP every time.

Please test with attached file if this is also the case for you.

nrgitho-dev-v2.4.2-wifitest3.bin.zip

updated the firmware and direct replies from my ping. So connected.

vandenberghev commented 1 year ago

Can confirm, 5/5 successful connections on boot with 2.4.2-wifitest3 👍 (whereas previously maybe 1/20 succeeded)

arjenhiemstra commented 1 year ago

So it might be that we are getting somewhere.....

vandenberghev commented 1 year ago

Pretty much :) Although I don't understand yet why other/most people did not experience the issue on v2.3.5 then?

arjenhiemstra commented 1 year ago

A few reasons could be (not checked though)

between esp32-arduino core 3.5.0 and 5.1.1 default settings changed? Just had a look and this commit: https://github.com/espressif/arduino-esp32/commit/5f6d093d4a8a371c78acd6e1a0e7a95b7346cbec it added the possibility to use setSortMethod and setScanMethod. So that is definitively something that was not there in core 3.5.0.
In the wifi init code of fw version 2.3.5 were items (ie. switch off storage of wifi settings) that were not working
Firmware update of ubiquity could also have an effect (at least, I was not experiencing issues with a much oder FW version)

TD-er commented 1 year ago

3. Firmware update of ubiquity could also have an effect (at least, I was not experiencing issues with a much oder FW version)

That's one statement which can be stated with the "could also have" replaced by "does have". I've also had some users contacting me about unreachable ESP nodes, which also played "hard to get" with other firmwares after updating their Ubiquity stuff.

arjenhiemstra commented 1 year ago

They make great devices (at least compared to the apple APs I had before, wifi experience in general is much better) but on multiple accounts I felt forced to downgrade a firmware because strange issues.... apparently they are no better than me :P

TD-er commented 1 year ago

Well at least you can downgrade firmware without messing up settings. Try that on other brands...

mhoogenbosch commented 1 year ago

I really love my unifi devices, but they are making a lot of mistakes lately. Constantly I'm missing my sonos devices in my overviews and with the latest couple of builds some of my shelly devices won't connect. Very irritating.

Back on topic; @arjenhiemstra wifitest3 works great. I updated and downgraded a couple of times and overtime it connect without a problem. I assume you renamed wifitest3 to beta3. What's the next step. Are you going to close this issue or should I?

arjenhiemstra / ithowifi

2.4.1 doesn't connect to Wifi anymore #108