Tasmota: WiFiConfig 5 is not alternating APs

[fmarzocca]

Have you looked for this feature in other issues and in the docs?
Yes. Docs are wrong

Is your feature request related to a problem? Please describe.
My device is cabled into my burglar alarm, so it is very important to me that the wifi connection is always alive even in case of failure of one AP

Describe the solution you'd like
WiFiConfig 5 should disable Wi-Fi Manager and alternatively retry AP1 and AP2 until connected without rebooting

Describe alternatives you've considered
WiFiConfig 4, but it is not exactly the same need I have

Additional context
_Add any other context or screenshots about the feature request here._

(Please, remember to close the issue when the problem has been addressed)

The Wiki is wrong for WiFiCOnfig 5: It trys to connect to last AP used before, forever.

[ascillato]

Hi, just tested your issue and works as explained in the wiki.

I set wificonfig 5 and Ssid1 and password1 for one of my AP. Then I set ssid2 and password2 for my other AP. If I turn off the AP where Tasmota is connected, it switches to the other. Also viceversa works.

So, seems that there is something wrong on your credentials.

EDIT: Bug confirmed with latest codebase of development branch

[ascillato2]

Please, re test and watch the console output. You can use serial connection for troubleshooting if it is a nodemcu device.

[fmarzocca]

I retested continuously for 2 days. It just waits for the latest connected
AP.
Then I asked on Discord and I have been confirmed by Jason:

Jason2866 today at 18:34
@FabioMarzocca you are right wiki entry is wrong. It trys to connect to
last AP used before.

On Wed, Dec 25, 2019 at 9:19 PM Adrian Scillato [e-mail]
wrote:

Please, re test and watch the console output. You can use serial
connection for troubleshooting if it is a nodemcu device.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Tasmota/issues/7321?email_source=notifications&email_token=ACBCQ3TBVCCRB4SD5QQVDLLQ2O54FA5CNFSM4J7F7BTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHUS3EA#issuecomment-568929680,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBCQ3S7MZRAHOYJRFRJEMDQ2O54FANCNFSM4J7F7BTA
.

[fmarzocca]

this was the console output when AP 2 was switched off:

13:43:46 WIF: Connect failed as AP cannot be reached 13:43:46 WIF: Connecting to AP2 Saltydog_1ext in mode 11N as monitor-antifurto... 13:43:53 WIF: Connect failed as AP cannot be reached 13:43:53 WIF: Connecting to AP2 Saltydog_1ext in mode 11N as monitor-antifurto... 13:44:00 WIF: Connect failed as AP cannot be reached 13:44:00 WIF: Connecting to AP2 Saltydog_1ext in mode 11N as monitor-antifurto... 13:44:07 WIF: Connect failed as AP cannot be reached 13:44:07 WIF: Connecting to AP2 Saltydog_1ext in mode 11N as monitor-antifurto... 13:44:14 WIF: Connect failed as AP cannot be reached 13:44:14 WIF: Connecting to AP2 Saltydog_1ext in mode 11N as monitor-antifurto... 13:44:21 WIF: Connect failed as AP cannot be reached 13:44:21 WIF: Connecting to AP2 Saltydog_1ext in mode 11N as monitor-antifurto...

On Wed, Dec 25, 2019 at 9:42 PM Fabio Marzocca [e-mail] wrote:

I retested continuously for 2 days. It just waits for the latest connected
AP.
Then I asked on Discord and I have been confirmed by Jason:

Jason2866 today at 18:34
@FabioMarzocca you are right wiki entry is wrong. It trys to connect to
last AP used before.

On Wed, Dec 25, 2019 at 9:19 PM Adrian Scillato [e-mail]
wrote:

Please, re test and watch the console output. You can use serial
connection for troubleshooting if it is a nodemcu device.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Tasmota/issues/7321?email_source=notifications&email_token=ACBCQ3TBVCCRB4SD5QQVDLLQ2O54FA5CNFSM4J7F7BTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHUS3EA#issuecomment-568929680,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBCQ3S7MZRAHOYJRFRJEMDQ2O54FANCNFSM4J7F7BTA
.

[ascillato2]

If you run command AP, it returns which AP are you using. Please, try to run command AP 1 or AP 2 to force the AP change to see if that works. Thanks.

[ascillato]

Hi,

The docs are OK.

After testing latest codebase of the development branch, I could reproduce it. Previous versions of Tasmota works as the docs said. Some of the lasts commits have introduced a bug.

So, it is a bug.

Thanks for reporting :+1:

[ascillato]

@arendst

Wificonfig 5 behaves as Wificonfig 4. It tries to reconnect to the same AP without restarting. BUG.

Wificonfig 4 works fine. It tries to reconnect to the same AP without restarting.
Wificonfig 2 works fine. It shows up the Wifimanager, and then it tries to reconnect to the AP.
Wificonfig 0 works fine. It alternate APs restarting as expected.

[ascillato2]

@fmarzocca

Until the bug is solved, please use WIFICONFIG 0

That will behave as you want, alternating AP and disabling the wifimanager. The only thing is that in case of wifi lost, your device will restart and try to connect to the other AP, but that should not be a problem for you (3 or 4 seconds to reconnect in case of a failure of one of your APs).

WIFICONFIG 5 was intented to behave exactly as WIFICONFIG 0 but without restarting.

[arendst]

Gents, can you pls provide the output of status 0 so I can verify SetOption56 is not set.

[fmarzocca]

13:03:43 CMD: status 0 13:03:43 RSL: STATUS = {"Status":{"Module":18,"FriendlyName":["Monitor Antifurto"],"Topic":"sonoff","ButtonTopic":"0","Power":0,"PowerOnState":0,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[1,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}} 13:03:43 RSL: STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"1T02:27:29","StartupUTC":"2019-12-25T09:36:14","Sleep":50,"CfgHolder":4617,"BootCount":60,"SaveCount":124,"SaveAddress":"F7000"}} 13:03:43 RSL: STATUS2 = {"StatusFWR":{"Version":"6.6.0(release-sonoff)","BuildDateTime":"2019-07-06T13:10:20","Boot":31,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}} 13:03:43 RSL: STATUS3 = {"StatusLOG":{"SerialLog":1,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["Saltydog_1ext","Vodafone-saltydog"],"TelePeriod":3600,"Resolution":"558180C0","SetOption":["00008001","280500000100060000000000000000000000","00000000"]}} 13:03:43 RSL: STATUS4 = {"StatusMEM":{"ProgramSize":503,"Free":500,"Heap":14,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"146085","FlashMode":3,"Features":["00000809","0FDAE396","001783A0","22B617CD","01003BC0"]}} 13:03:43 RSL: STATUS5 = {"StatusNET":{"Hostname":"monitor-antifurto","IPAddress":"192.168.1.64","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"EC:FA:BC:51:85:3F","Webserver":2,"WifiConfig":4}} 13:03:43 RSL: STATUS7 = {"StatusTIM":{"UTC":"Thu Dec 26 12:03:43 2019","Local":"Thu Dec 26 13:03:43 2019","StartDST":"Sun Mar 31 01:00:00 2019","EndDST":"Sun Oct 27 02:00:00 2019","Timezone":99,"Sunrise":"08:42","Sunset":"16:58"}} 13:03:43 RSL: STATUS10 = {"StatusSNS":{"Time":"2019-12-26T13:03:43","Switch1":"OFF"}} 13:03:43 RSL: STATUS11 = {"StatusSTS":{"Time":"2019-12-26T13:03:43","Uptime":"1T02:27:29","Heap":14,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Saltydog_1ext","BSSId":"B0:39:56:F0:19:BF","Channel":5,"RSSI":70,"LinkCount":1,"Downtime":"0T00:00:03"}}}

[arendst]

@fmarzocca is the status 0 info from the device giving the issue? So using version 6.6.0.

[arendst]

Anyway. I see no problem or bug.

• Wificonfig 4 (Retry) alternates between AP's
• Wificonfig 5 (Wait) keeps looking for current AP.

Don't know if documentation is wrong but from the CHANGELOG.md you can see:

### 5.8.0 20170918

- Add option WIFI_WAIT (5) to command WifiConfig to allow connection retry to same AP without restart or update flash (#772, #869)

### 3.0.5 20161215

- Add option WIFI_RETRY (4) to command WifiConfig to allow connection retry to other AP without restart (#73)

On v8.1 it does exactly as noted before; 4 retries both AP's, 5 retries single AP.

[fmarzocca]

So, the Docs are wrong!

• Sent from my mobile phone. Sorry for typos -

Il Gio 26 Dic 2019, 13:49 Theo Arends [e-mail] ha scritto:

Anyway. I see no problem or bug.

• Wificonfig 4 (Retry) alternates between AP's
• Wificonfig 5 (Wait) keeps looking for current AP.

Don't know if documentation is wrong but from the CHANGELOG.md you can see:

5.8.0 20170918

• Add option WIFI_WAIT (5) to command WifiConfig to allow connection retry to same AP without restart or update flash (#772, #869)

On v8.1 it does exactly as noted before; 4 retries both AP's, 5 retries
single AP.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/arendst/Tasmota/issues/7321?email_source=notifications&email_token=ACBCQ3QGVPXMF4LBXAXGA3TQ2SR7PA5CNFSM4J7F7BTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHVRAHY#issuecomment-569053215,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBCQ3Q3QGBMUB4HYVZRPU3Q2SR7PANCNFSM4J7F7BTA
.

[arendst]

Correct. Docs are wrong.

[ascillato]

@fmarzocca

Docs has been corrected. So, what you need is:

WiFiConfig 4 disable Wi-Fi Manager and alternatively retry AP1 and AP2 until connected without rebooting

Thanks for reporting !!!!

[fmarzocca]

Thanks to all of you for the very fast correction!