Use ESP8266WifiMulti instead of ESP8266Wifi?

[Zebble]

Have you look for this feature in other issues and in the wiki? Yes

Is your feature request related to a problem? Please describe. WiFi networks with multiple AP's broadcasting the same SSID can cause connectivity issues.

Describe the solution you'd like Connect to the AP with the highest RSSI.

Describe alternatives you've considered None.

Before I look at making the modifications myself, does anyone not recommend using ESP8266WiFiMulti instead of ESP8266WiFi?

I have a network with 6 AP's broadcasting the same SSID on various channels. Tasmota seems to boot up and pick the first AP it sees (ie. the first beacon wins) which is not often the one with the highest RSSI so connection can often be slow or will be unreliable. I've also had it where the signal was too weak and would disconnect and stay disconnected until rebooted.

Would be better if the device did a network scan first, then picked the AP with the highest RSSI for the requested SSID. That's what ESP8266WiFiMulti does out of the box. It can also use additional SSID's if the first one isn't available.

As an interim step, I may just add some intelligent SSID-scanning code to the existing code so the changes aren't as drastic.

Thoughts?

[Jason2866]

Hmm, i have 5 Accesspoints and the problem you describe never occured for me (the Accesspoints are sending all the same SSID on different channels).

[pascalsaul]

https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/station-examples.html

In this case it will cycle through the networks just like AP1 and AP2 does now so what's the real difference?

If you've the same SSID on various channels it won't help. Maybe the code does help to cycle through AP1, AP2 and N...

[Zebble]

@Jason2866 : I saw your previous posts, which is why I thought I was crazy in what I was seeing. It does seem like at least the 2.3.0 library grabs a connection to the first SSID beacon it sees which is not necessarily the strongest signal. I can get it to connect to another AP if I reboot a few times, but it's all luck and not predictable. If I simply kick the device off on the AP side, it immediately reconnects to the same AP. It won't try a stronger AP.

@pascalsaul: The difference is that esp8266wifimulti tries to connect to the AP with the strongest RSSI for a given SSID. esp8266wifi seems to only connect to the first AP that provides a beacon for a given RSSI, which is not necessarily the strongest AP.

I think the quickest fix would be to do an WiFi.scannetworks() call, filter out all SSID's except for the one we want, sort by RSSI and then add that BSSI/MAC to the WiFi.begin() call. No change required to any other code, but would be nice to leverage esp8266wifimulti at some point, and let it take care of the whole AP1/SSID1 versus AP2/SSID2 versus AP3/SSID3 stuff...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mkh595]

Hmm, i have 5 Accesspoints and the problem you describe never occured for me (the Accesspoints are sending all the same SSID on different channels).

I have same problem as Zebble, multiple AP with same SSID.

Device keeps connection to AP with signal 18% even scan shows stronger AP with 58%

[ebcjaa]

I have same problem, multiple AP with same SSID...

[mkfink]

I'm seeing the same thing. I have ~90 devices running tasmota 6.1.1, version 2.4.1 library, with 3 APs that are all on the same SSID (it's a hackerspace with enterprise grade hardware, not trying to run this on consumer grade stuff). I rebooted the APs one at a time a week ago, and each time I reboot an AP all the devices jump over to another AP, which means when I reboot the third AP nothing connects to it because everything is connected to the other two APs. I end up seeing 60 devices on one AP, 30 devices on another, and 0 on the third. In quite a few cases, devices are connected to the weakest AP. And a week later, this is still the case, no devices have changed APs unless the device rebooted.

The thing that makes this a big issue for me is that sometimes RSSI for a device will get really bad when it's not connected to the ideal AP, causing it to lose connection with the mqtt broker, so it ends up going offline and online a bunch of times, sometimes only spending seconds or less online, making it basically unusable. And it never tries to use the secondary SSID either. I can reboot until it connects to another AP as a workaround, but with so many devices, and me not being on site most of the time, it doesn't help much.

So it would be very helpful if devices were able to roam between APs when they see one with better RSSI.

[Jason2866]

@mkfink Dont use arduino core 2.4.1 upgrade your firmware to core 2.4.2 Arduino core 2.4.0 and 2.4.1 has wifi issues! All Arduino core 2.4.x versionsl has sleep issues. So you cant use sleep! If you want stable wifi and want to use sleep you have to use 2.3.0 All precompiled versions von Theo uses 2.3.0

[Kedryn]

I too have multiple APs, same SSID, and have tasmotized devices connecting to wrong APs.

[nosaj66au]

Hi Guys, Yep same problem 3 AP's 70 devices. Just would like the devices to pick the strongest AP. Each time I have a power outage a half the devices attach to the wrong access point the I need to reset each device in order to hopefully connect to the correct strongest AP. Thanks Jason

[Geitde]

Same here. Had around 40 new Wifi Devices in addition to the 50++ already installed over the weekend. After three days only one of my devices was reachable. All others dropped dead and only performed offline actions.

I don´t think it is a general signal quality problem. I configured only one existing wifi and one only for mainenance purpose, which is not even available since the AP is located in my toolbox.

My guess is that the network traffic itself is kicking devices over time. Usually it takes a few days to kill all wall mounted sonoffs from being accessable via network, but with all the additional and for sure active hardware last weekend it was only a matter of hours.

Today I created a separate network just for the 22 tasmota devices and two echo dot using the guest network to avoid further problems.

Diconnecting permanently is one of the most annoying issues with tasmota.

[nosaj66au]

Same here. Had around 40 new Wifi Devices in addition to the 50++ already installed over the weekend. After three days only one of my devices was reachable. All others dropped dead and only performed offline actions.

I don´t think it is a general signal quality problem. I configured only one existing wifi and one only for mainenance purpose, which is not even available since the AP is located in my toolbox.

My guess is that the network traffic itself is kicking devices over time. Usually it takes a few days to kill all wall mounted sonoffs from being accessable via network, but with all the additional and for sure active hardware last weekend it was only a matter of hours.

Today I created a separate network just for the 22 tasmota devices and two echo dot using the guest network to avoid further problems.

Diconnecting permanently is one of the most annoying issues with tasmota.

Hi Geitde, Sounds like your problem is very different to the issue in the thread. When you say "dropped dead" do you mean no comms of any type? I use TasmoAdmin (https://github.com/arendst/Sonoff-Tasmota/wiki/TasmoAdmin) to check all my devices its a great tool for look over thing like Wifi signal strength.

Your problem could be the MQTT no reconnect issues raised in earlier firmware which is now fixed.

Jason

[Geitde]

@nosaj66au

There is no use for any external tool.

The devices stay offline and there is no way to revive them, beside cutting main power at the fuse box, which is not only anoying, but also stress for other devices using mains power.

Web interface is dead, alexa handling is dead and even a simple ping fails.

[Kedryn]

i'm wondering what you are controlling, at home, with 70 sonoffs...

[Zebble]

FYI, Espurna uses their own "JustWifi" library. It seems to be a bit more clever than ESP8266WifiMulti and appears to be simpler to implement. I'm going to run Espurna on a couple of consistently problematic devices to see if it works any better. It at least seems to be smarter at connecting to the AP with the strongest signal...

[Geitde]

I moved all my 20 tasmota devices plus two alexas into their own sub network with their own AP.

It is running for about a week now and no device got disconnected.

It seems that the overall network traffic of the network is breaking Tasmotas connectivity. By overall network traffic I mean network data inside the network not ment for the tasmotas themself. Since I silenced traffic caused by laptops and other (20++) devices due moving IoT stuff to an entirely new network it seems all problems are gone.

The only issue I experienced is that NTP somehow fails when used in some 192.168.189.xx network and the clock always starts at 1970. I still need to investigate that, but I just changed AP network settings and static to DHCP. Internet is available from that network as I can use my ipad via the IoT AP and of course use alexa, whom requires an internet connection to operate.

I know this may be not related to this topic, but on the other side it may. Who knows if it is related to swapping networks or just the noise on the network causing the devices to misbehave. The issues are somewhat related.

[tim-devel]

+1 for more intelligent selection of hotspots. I have had to set different ssid's for my hotspots and programme each sonoff manually to select the best hotspot as I was suffering all the symptoms listed above

[arendst]

Enable feature wifi network scan with SetOption56 1

To force AP selection you will need to disable wifi scan first (SetOption56 0)

[Zebble]

Thanks Arendst, that's great! I'll compile and give this a test over the next day or two...

[Zebble]

FYI, I did some testing with Espurna as a comparison, and here's how things worked:

• Booted up the Espurna device and it connected to the strongest AP (let's call it AP1).
• Removed AP1 from the network and the Espurna device connect to the next-strongest AP within seconds (AP2).
• Turned AP1 back on, and the Espurna device stayed connected to AP2. I did not leave it long enough to see if it did an automatic rescan at regular intervals for stronger APs to see if it would automatically connect to AP1. I may test this.
• Rebooted Espurna device and it connected to AP1.

I'll try the same test with this new Tasmota option and see how it goes.

[arendst]

Bullet three is expected as both Espurna and Tasmota will only scan for a stronger AP when the connection to the active AP is lost.

[mtfurlan]

It looks like it can't scan for networks while it's connected, is that still true?

https://github.com/esp8266/Arduino/issues/1140 https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/src/ESP8266WiFiScan.cpp#L81

[arendst]

Did you try?

As the Web GUI always had wifi scan available which runs just fine when a connection is present I don't see any reason why this shouldn't work.

On the other hand, this feature does not scan the networks when there is a connection; it only scans when connection is lost and it want to re-connect.

[arendst]

The overhead of switching from AP to AP just don't make sense. You're not supposed to walk around with your Tasmota device.

[jjlawren]

If a multi-AP environment has maintenance on the APs at different times, devices could become stuck on a poor signal.

[mtfurlan]

I have not, I'll look into it tomorrow. The issue @mkfink and I have is that when we reboot our AP's, we reboot one at a time and devices end up on the wrong AP. We could just reboot all the devices after the AP's are upgraded or whatever needed a reboot as it's not a thing that happens terribly often.

[Zebble]

Interesting... Wonder if it would be possible to have it check RSSI periodically and if it dropped below a programmed level it would try a scan? I know we can do this at the AP level (Mikrotik CAPsMAN supports an ACL based on RSSI) but best practice seems to dictate that the device be able to make that decision rather than the AP.

[ascillato]

@Zebble

That behaviour is the same as the cellular network has for mobile cellphones. So, are you moving your sonoff devices as a mobile phone around your home? How are you using them? I'm curious. Please give us an example.

[Jason2866]

@ascillato Could it be done via a rule? RSSI <20 -> do AP search ?

[ascillato]

It is not supported that.

But, why you would want that? What is the use case of that?

[Jason2866]

I see no use case, just asked if possible ;-)

[jjlawren]

@ascillato, see https://github.com/arendst/Sonoff-Tasmota/issues/3173#issuecomment-439999278 and https://github.com/arendst/Sonoff-Tasmota/issues/3173#issuecomment-439999330 above where @mtfurlan and I gave real-life use cases of temporarily unavailable access points.

[davidelang]

another issue is if the AP and/or the device is moving (or things are moving around it that could block the signal)

It's also a good idea to check every once in a while (infrequently, every few hours for example) to see if there is a new AP up on the same SSID that has a better signal. That way when you add an AP, you don't have to manually bounce devices, they will just start using the better one.

David Lang

[Zebble]

@davidelang , exactly.

A use case here is when our AP's do an automatic scan for better overall channels. We can program this to happen at regular intervals to optimize the network. They don't all go down or come back up at once, so the Tasmota device may hang onto a weaker AP after the process is completed. That's fine as long as the RSSI is decent. Having a configurable RSSI threshold would make this even better.

[arendst]

Enable feature re-scan every 44 minutes with a rssi threshold of 10 with command SetOption57 1.

For now the values are fixed to get some feeling about it's functionality. Might be changed to user SetOps in the future.

[digiblur]

I'll give this a spin as well as I have to access points here and noticed the same thing at times when I upgrade firmware on one AP, ESP8266 devices won't come back over to their good signal AP. Since I only had two I ended up putting another specific SSID that was only each AP, like a AP.Front and AP.Back SSID, then make the closest devices use that SSID. Of course that kinda kills the reliability of one AP is down so I put in the SSID that was across both APs as AP2, once I did an upgrade I'd just push a MQTT message across the "sonoffs" group to make them go back to AP1.

[ascillato2]

Closing issue as the feature has been added. Thanks everyone for sharing their ideas. Very appreciated.

[ascillato2]

@davidelang nice to see you around again ;)

[hamwong]

great to see this enhancement, I've been waiting for this for 2 years. Thank you @arendst

I got a question, does SetOption57 1 means re-scan every 44 minutes only when rssi value below 10? or either 44 minutes , or below rssi 10 will do a scan? but actually I think 10 is way too low, on sonoff devices, when rssi around 5x-6.x will have slow response, I suspect packet drop as well, in console, sometimes command will be missed in Console

[arendst]

No the 10 (dB) means the better rssi difference compared to the current rssi value. So if the current rssi = -55 (dB) and after a scan there is a network with -44 (dB) it will select this network.

[hamwong]

Wow, Thank you, amazing feature!

[Zebble]

Tried the same tests with Tasmota and SetOption56 ON and SetOption57 ON that I did with Espurna. Seems very resilient! Was not able to knock the Tasmota device off the network. I have 1 fairly consistent problem device I'm going to test as well...

[Zebble]

Seemed to work for a while, now I'm getting devices that oscillate between connected/disconnected quite often. I don't have one on the bench to see what's going on on the console, so I'll have to take a closer look when I do.

[Zebble]

Gave up on Tasmota and moved to Espurna. All devices were very reliable with Espurna, but I really missed the functionality in Tasmota (rules mostly) so tried again with the latest 6.5.0 release. With the move back to the 2.3.0 wifi library (Espurna also uses 2.3.0), I thought I'd give Tasmota another shot. I have a Sonoff iFan02 installed in a bedroom that I use as my guinea pig as it seemsto have the most issues with wifi. It has been very stable for at least 2 weeks now, running 6.5.0. I've upgraded to the latest builds on almost a daily basis (6.5.0.3 is currently installed) with similar results. All good! Now everything is converted back to Tasmota. :)

[gknops]

Oh wow. I know several people (including me) wasting a lot of time, energy and money because of this. Why are SetOption56 and SetOption57 not on by default? Without them the devices are nearly guaranteed to not do the right thing on multi-AP networks. And the downside would be a small overhead in startup time for others?

[mkfink]

One issue I had initially was that one or both of those settings were not compatible with hidden SSIDs (let's not debate the usefulness of that setting...) which would make it a really big breaking change for some people. Otherwise yeah, they're great when you have multiple APs and I set them on by default in user_config_override.h when I build.

[gknops]

Oh that makes sense, I can see how it could break hidden SSIDs. In that case the algorithm would need to have "connect blindly" as fallback when no APs are found after some time, but that could get messy. Might be an argument for an extra hint flag in the WiFi setup menu though, given what a hard to debug issues this causes on multi-AP/same-SSID/no-hidden-SSID networks.

[dan-cristian]

I have the same issue with Tasmota 8.x on sonoff basic not connecting to my multi node Asus Rt-ax88u and 3xLyra with same visible ssid. I noticed the issue occurs only when my sonoffs are closer to the main router (ax88u). Sonoff will not connect for more than 10 minutes, sometimes never. I managed to solve the problem by downgrading to tasmota 6.2.1. I tried also changing options 56 and 57 but no luck.