Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random or configurable wait time for WIFI_[RETRY|WAIT] to avoid connection problems #2089

Closed
willyk0 opened this issue Mar 5, 2018 · 8 comments
Labels
enhancement Type - Enhancement that will be worked on fixed Result - The work on the issue has ended

Comments

@willyk0
Copy link

willyk0 commented Mar 5, 2018

I have about 15 Sonoff Basics at home (Tasmota up to date) and I've experienced connection problems with power outages (I've caused lots of them this days manipulating my electrical installation). When the power comes back, every sonoff tries to connect to my wifi at exactly the same time... and routers usually don't behave very well with this and many of them fail to connect (in fact, if they have the "wifi manager" mode configured with WifiConfig 2, they fall in AP mode until they restart themselves). So, I configured WIFI_WAIT (WifiConfig 5) in order to retry the same AP later. I've seen in code that the wait time is a fixed value:

#define WIFI_RETRY_SEC 30

So, what happens? After wait time, all sonoffs which failed are trying to reconnect to wifi... exactly at the same time again, so many of them fail again... and so, until everyone is configured a bunch of minutes later.

I thought perhaps it would be a good idea to change the wait time with a random value between 15 and 45 secs, or making it a configurable variable instead of a fixed hardcoded constant so I could configure my sonoffs with different values avoiding this problem.

Or maybe I should spend money in a better Access Point :) (currently TP-LINK Archer C9)

@jeylites
Copy link

jeylites commented Mar 6, 2018

I’m in the same situation. Need clarification on solve this issue

@aferraz
Copy link

aferraz commented Mar 6, 2018

This is a good idea, maybe even MQTT configurable so you can differentiate retry time.

@CommodoreWhite
Copy link

Easiest to base the delay on the unique device id

@jeylites
Copy link

jeylites commented Mar 6, 2018

Where is the delay function at?

@arendst arendst added the enhancement Type - Enhancement that will be worked on label Mar 9, 2018
arendst added a commit that referenced this issue Mar 11, 2018
5.12.0e
 * Add additional time offset to Wifi Retry based on device mac
address (#2089)
@arendst arendst added the fixed Result - The work on the issue has ended label Mar 14, 2018
@titomontes
Copy link

titomontes commented Apr 16, 2018

Hello,

How was this issue solved? I´m very interested, because I have the exact same problem. PLease don´t tell me I have to reflash all my sonoffs (20+)...

Sorry for the edit, I just don´t want to pollute. I just found:

#define WIFI_CONFIG_TOOL WIFI_WPSCONFIG // [WifiConfig] Default tool if wifi fails to connect
// (WIFI_RESTART, WIFI_SMARTCONFIG, WIFI_MANAGER, WIFI_WPSCONFIG, WIFI_RETRY, WIFI_WAIT)

Is this where I can just set the wifi to wait any number of minutes before attempting connection?

@ascillato
Copy link
Contributor

In the file support.ino there is the key #define WIFI_RETRY_OFFSET_SEC 20 // seconds

curzon01 pushed a commit to curzon01/Tasmota that referenced this issue Sep 6, 2018
5.12.0e
 * Add additional time offset to Wifi Retry based on device mac
address (arendst#2089)
@khriss75
Copy link

Sorry for this other message, but I don't understand the solution. I have the same problem with more than 20 devices. Can you confirm that the solution is to re-flash all devices with #define WIFI_RETRY_OFFSET_SEC 20 // seconds changing "20" with other different numbers for each devices? No possible via MQTT (like mqttretry...)? I'm on 6.3 firmware.

@ascillato
Copy link
Contributor

Hi @khriss75

This issue is too old. A lot of things has changed since then.

Please, if you have a similar problem, update first to latest and try again. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Type - Enhancement that will be worked on fixed Result - The work on the issue has ended
Projects
None yet
Development

No branches or pull requests

8 participants