The Photon modules that I’m using connect easily and quickly to my WiFi network at home, but in the office network where I need to deploy them they often have trouble. (My application gives up after a minute and powers down, which I need to do in order to manage battery life.)
I’m suspicious that my troubles may be because, in the office network, we have various access points scattered around the building, all broadcasting the same SSID. I’d expect the Photon to try all channels with a matching SSID, preferably in order of signal strength. If it doesn’t do that, this could explain the problems I’m seeing.
Do we know whether the Photon does the right thing when multiple APs have the same SSID?
I’ve done some spelunking in the source code, but the trail ends at wiced_join_ap_specific(). It seems that is opaque to us. Do we know what it does, exactly?
In the Photon API, WiFi.scan() should be able to tell us what channels to try. But I see no way to tell the device to attempt to connect to a specific channel. Am I missing something?
I ran into others who had the same issue when there are multiple access points sharing an SSID. This seems a serious weakness for the Photon – it’s going to be out-of-the-box unusable in many corporate network environments.
I have a workaround of sorts that restarts the WiFi if it hasn’t established a connection in ten seconds. But it’s a kludge, hurts battery life, and is not as reliable as a proper fix would be.
Can we get Particle to produce a fix for this? Simply prioritizing connection attempts by signal strength ought to do it. Or failing that, an API that would allow me to ask it to connect on a specific channel ought to work, in conjunction with the existing interface that can scan channels. This shouldn’t be hard.
It shouldn't be hard but would only serve a subset of users but imact all as the initial scan would take extra time. I'd think the proposed ability to allow user code to select a BSSID would give the "subset of users" a tool to focus on a specific AP with shared SSID but not impact all "home" users.
Have you added a comment to the issue I linked?
If noone contributes it'll never bubble up as there will always be more prominent issues than a "pesky" old and dusty feature request. Last comment I see was from April 2018 and since then noone seemd to care and hence it can't be that important (could be a possible interpretation).
@will, is there any chance for the above issue to be nudged up in priority? I'd think it may be on a similar priority level as getting WPA2/Enterprise working reliably as both mainly touch on corporate use-cases.
Am 100% with you on this one @David_G and @ScruffR. There are problems in a multi AP environment.
Have been caught out at times during the proverbial demo. Prepare for it in the lab, then place the unit in the demo location 20 m north to have connectivity issues.
Will kick in a comment to your open issue @ScruffR.
