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

Tasmota devices fail to reconnect to network after they are power cycled #7770

Closed
11 of 15 tasks
Fettkeewl opened this issue Feb 22, 2020 · 223 comments
Closed
11 of 15 tasks
Labels
awaiting feedback Action - Waiting for response or more information troubleshooting Type - Troubleshooting

Comments

@Fettkeewl
Copy link

PROBLEM DESCRIPTION

Sonoff devices with Tasmota firmware refuse to reconnect after power cycling them. As evident by serial output the devices just says "fails to connect to AP".
The only remedy is to reboot router, then all my tasmota devices that are stuck in a loop will connect instantly.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

  • Read the Contributing Guide and Policy and the Code of Conduct
  • Searched the problem in issues
  • Searched the problem in the docs
  • Searched the problem in the forum
  • Searched the problem in the chat
  • Device used (e.g., Sonoff Basic): Sonoff S55/T1/Mini
  • Tasmota binary firmware version number used: 8.1.0
    • Pre-compiled
    • Self-compiled
      • IDE / Compiler used: _____
  • Flashing tools used: Tasmotizer
  • Provide the output of command: Backlog Template; Module; GPIO 255:
  Configuration output here:
07:55:11 MQT: OfficeCeilingLamp/stat/RESULT = {"NAME":"Sonoff T1 1CH","GPIO":[17,255,255,255,0,0,0,0,21,56,0,0,0],"FLAG":0,"BASE":28}
07:55:11 MQT: OfficeCeilingLamp/stat/RESULT = {"Module":{"0":"Sonoff T1 1CH"}}
07:55:11 MQT: OfficeCeilingLamp/stat/RESULT = {"GPIO0":{"17":"Button1"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"0":"None"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"21":"Relay1"},"GPIO13":{"56":"Led1i"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}

  • If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
  Rules output here:


  • Provide the output of this command: Status 0:
  STATUS 0 output here:
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS = {"Status":{"Module":0,"FriendlyName":["SonoffT1-01"],"Topic":"OfficeCeilingLamp","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":0,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"tasmotas","OtaUrl":"http://thehackbox.org/tasmota/release/tasmota.bin","RestartReason":"Software/System restart","Uptime":"7T00:51:52","StartupUTC":"2020-02-15T06:04:23","Sleep":50,"CfgHolder":4617,"BootCount":10,"SaveCount":169,"SaveAddress":"FB000"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS2 = {"StatusFWR":{"Version":"8.1.0(tasmota)","BuildDateTime":"2019-12-25T12:33:25","Boot":31,"Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Hardware":"ESP8285","CR":"364/699"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["<RemovedForPrivacy>",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["000A8008","2805C8000100060000005A00000000000000","00000200","00000000"]}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS4 = {"StatusMEM":{"ProgramSize":566,"Free":436,"Heap":24,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","8FDAE397","043683A0","22B617CD","01001BC0","00007881"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,29","Sensors":"1,2,3,4,5,6,7,8,9,10,14,15,17,18,20,22,26,34"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS5 = {"StatusNET":{"Hostname":"SonoffT1-01","IPAddress":"<RemovedForPrivacy>","Gateway":"<RemovedForPrivacy>","Subnetmask":"255.255.255.0","DNSServer":"<RemovedForPrivacy>","Mac":"<RemovedForPrivacy>","Webserver":2,"WifiConfig":4}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS6 = {"StatusMQT":{"MqttHost":"<RemovedForPrivacy>","MqttPort":<RemovedForPrivacy>,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_BDA845","MqttUser":"<RemovedForPrivacy>","MqttCount":7,"MAX_PACKET_SIZE":1000,"KEEPALIVE":30}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS7 = {"StatusTIM":{"UTC":"Sat Feb 22 06:56:15 2020","Local":"Sat Feb 22 07:56:15 2020","StartDST":"Sun Mar 29 02:00:00 2020","EndDST":"Sun Oct 25 03:00:00 2020","Timezone":"+01:00","Sunrise":"07:46","Sunset":"18:21"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS10 = {"StatusSNS":{"Time":"2020-02-22T07:56:15"}}
07:56:15 MQT: OfficeCeilingLamp/stat/STATUS11 = {"StatusSTS":{"Time":"2020-02-22T07:56:15","Uptime":"7T00:51:52","UptimeSec":607912,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":7,"POWER":"ON","Wifi":{"AP":1,"SSId":"<RemovedForPrivacy>","BSSId":"<RemovedForPrivacy>","Channel":11,"RSSI":48,"Signal":-76,"LinkCount":6,"Downtime":"0T05:33:55"}}}

  • Provide the output of the Console log output when you experience your issue; if applicable:
    (Please use weblog 4 for more debug information)
  Console output here:


TO REPRODUCE

Power cycle any connected device

EXPECTED BEHAVIOUR

I expect the device to reconnect to my network after a powercycle, without having to reboot my router.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Router: ASUS RT-AC2900
Stock firmware: 3.0.0.4.384_81351

Theese issues are never a problem when I flash ESP devices with my own custom firmware

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

@Jason2866
Copy link
Collaborator

Probably your router is too blame. It stores leases (in arp table) which are not valid anymore.
Reduce lease time or manually delete stored (not valid) leases

@Fettkeewl
Copy link
Author

Why should this be an Tasmota only issue? No other devices experience the same issues. Further more all my tasmota devices are outside of my DHCP range and have static ips configured in the router

@s-hadinger
Copy link
Collaborator

There has been some wifi changes lately. Please try with the latest firmware and report if reconnection works.

Also try Reset 3, it may allows the device to reconnect once (I'm mostly curious if it works because I had a similar issue with failed reconnection for 15 seconds)

@Fettkeewl
Copy link
Author

Was already on the latest as stated, 8.1.0!
Reset 3 did nothing other than reboot the device and now it can't connect.
The device shows up in my router for 7-10 seconds then dissappears. It does this indefinitely until I reboot the router.
SmartSelect_20200222-124549_Chrome

@Jason2866
Copy link
Collaborator

@s-hadinger the used version from @Fettkeewl is release v.8.1.0.
This version uses the wifi set up which now is used again in the development branch.
Only in development branch was inbetween a other set up for wifi which was not good for some users.

Without a analysis of the network traffic (via wireshark for example) we cant help because
we dont have this issue.

May you give the development version a try, and try the latest development version with (stable!)
beta Arduino core. Availiable here http://thehackbox.org/tasmota/ and here http://thehackbox.org/tasmota/pre-2.7/

@Jason2866
Copy link
Collaborator

Jason2866 commented Feb 22, 2020

Static IP in router DOES mean you still use DHCP!
If the devices have real Static IPs. The IPs are set in the device AND there is NO entry in router for.
For testing delete the entry (in router) for a tasmota device which is behaving weird and configure
the static IP ONLY in the device.

@Fettkeewl
Copy link
Author

I will try the dev version and get back to you. In the meantime this is from my routers logs.

Feb 22 14:39:50 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:39:50 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:06 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:10 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:10 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:38 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:40:54 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:18 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:18 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:38 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:38 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc <MacRemoved>, status: 0, reason: d11 RC reserved (0)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc <MacRemoved>, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 22 14:41:55 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind <MacRemoved>, status: 0, reason: Class 2 frame received from nonauthenticated station (6)

@Fettkeewl
Copy link
Author

Fettkeewl commented Feb 22, 2020

Alright, I've tested 8.1.0.9. Sad to say I still have the same issues..
Sometimes power cycling works with reconnect but it would seem that if* the time span between turning it off and then on again grows to big, THEN the reconnect issues occur.

@ascillato2 ascillato2 added awaiting feedback Action - Waiting for response or more information troubleshooting Type - Troubleshooting labels Feb 22, 2020
@ascillato
Copy link
Contributor

Seems to be an ARP issue. Some settings in your router are conflicting with the config in your Tasmota device.

Do you have this issue if you delete the static IP entry from your router AND you set DHCP in your Tasmota device?

( to set DHCP in Tasmota use command IPADDRESS1 0.0.0.0 )

@ascillato
Copy link
Contributor

As Tasmota uses MQTT there is no real need for a fixed or static IP. And if you need to access the webui and you don't use mDNS, Tasmota is also reporting its IP by MQTT, so you can see the actual IP on your home automation software.

For example, if you use Home Assistant and autodiscovery, your Tasmota IP is populated automatically on the device properties.

@Fettkeewl
Copy link
Author

Seems to be an ARP issue. Some settings in your router are conflicting with the config in your Tasmota device.

Do you have this issue if you delete the static IP entry from your router AND you set DHCP in your Tasmota device?

( to set DHCP in Tasmota use command IPADDRESS1 0.0.0.0 )

I will try it, I have removed the bindings. Will evaluate and return with results :) thank you for your time

@Fettkeewl
Copy link
Author

Fettkeewl commented Feb 23, 2020

What a bummer.. Undoing my bindings did nothing.

  • Removed bindings yesterday on multiple devices
  • After my last post I had to leave so I unplugged my test-device
  • Prior to writing this I started up my test-device and it could not connect.. untill i rebooted router :< sigh!

Edit:
I do not seem to be the only one with this issue, using an ASUS.
Going to try and change bandwidth on my 2,4GHz to 20Mhz only and give it a go
https://www.snbforums.com/threads/ac86u-384-14_2-tasmota-sonoff-wifi-connection.61326/

@crispy78
Copy link

After updating to 8.1.0.9 I faced similar issues, all devices where acting like an AP instead of connecting to one. I’ve reset my AP’s and Router (UniFi AP-AC-Pro and Unifi Dream Machine) and gave all my devices a power cycle (switched the main circuit breaker in the home). After an unsuccessful attempt I remove the IP assignment from several devices (all devices are DHCP enabled) and did the same thing yet again. After that unsuccessful attempt I connected to the Tasmota devices, entered my WiFi settings and pulled an all-nighter to set things up again. That’s why I commented earlier that the 8.1.0.9 was the best factory reset ever. The best thing that came from this update is that I’ve now documented and automated my settings.

If your troubles came after updating to 8.1.0.9 I can agree that power cycling your AP’s, router and removing IP assignments doesn’t help getting the devices online again. I haven’t opened up my devices to retrieve logging, for that I have to apologize.

@Jason2866
Copy link
Collaborator

Give this version a try. Arduino Core! wifi handling changed. NO change in Tasmota code.

tasmota.bin.gz

@arendst
Copy link
Owner

arendst commented Feb 23, 2020

Guys, as there are many wifi related configuration options within Tasmota it's no use to reply here with remarks as

I have the same issue

Provide at least your SSID, Wificonfig, Setoption56 and SetOption57 settings to shine a constructive light over your issues.

For what it's worth, my Unifi AP's are perfectly able to re-connect to any power cycled device without issues with my settings of wificonfig 4, SetOption56 1, SetOption57 1 and only SSID1 set to the Unifi wifi network.

@Fettkeewl
Copy link
Author

Alright! Post flashing with Tasmotizer I have not done any special Wifi-related settings other than use the configurations available on the device website.

My AP's name is simple with no special characters: Siblin
I've only setup one AP on all my Tasmota devices.
Connected to a ASUS RT-AC2900 as mentioned before.

wificonfig was default 4.
Both SetOption56 -57 were default 0/OFF.
Changing -56 -57 to 1 did nothing.

I even had to revert those options as it was causing my Sonoff S55 to behave strange.

I set the highest level serial logging and turned of my device untill I saw the deauth messages in my routers syslog. After that I booted my device with serial monitoring and below is the result, never connecting.

00:00:01 WIF: Checking connection...
00:00:01 WIF: Attempting connection...
00:00:02 WIF: Checking connection...
00:00:02 WIF: Attempting connection...
00:00:04 WIF: Checking connection...
00:00:04 WIF: Attempting connection...
00:00:05 WIF: Checking connection...
00:00:05 WIF: Attempting connection...
00:00:06 WIF: Checking connection...
00:00:06 WIF: Attempting connection...
00:00:06 QPC: Reset
00:00:07 WIF: Checking connection...
00:00:07 WIF: Attempting connection...
00:00:08 WIF: Checking connection...
00:00:08 WIF: Attempting connection...
00:00:08 APP: Boot Count 32
00:00:08 CFG: Saved to flash at FB, Count 82, Bytes 4096
00:00:09 WIF: Checking connection...
00:00:09 WIF: Attempting connection...
00:00:10 WIF: Checking connection...
00:00:10 WIF: Attempting connection...
00:00:11 WIF: Checking connection...
00:00:11 WIF: Attempting connection...
00:00:12 WIF: Checking connection...
00:00:12 WIF: Attempting connection...
00:00:13 WIF: Checking connection...
00:00:13 WIF: Attempting connection...
00:00:14 WIF: Checking connection...
00:00:14 WIF: Attempting connection...
00:00:15 WIF: Checking connection...
00:00:15 WIF: Attempting connection...
00:00:16 WIF: Checking connection...
00:00:16 WIF: Attempting connection...
00:00:17 WIF: Checking connection...
00:00:17 WIF: Attempting connection...
00:00:18 WIF: Checking connection...
00:00:18 WIF: Attempting connection...
00:00:19 WIF: Checking connection...
00:00:19 WIF: Attempting connection...
00:00:20 WIF: Checking connection...
00:00:20 WIF: Connect failed with AP timeout
00:00:20 WIF: Connecting to AP1 Siblin in mode 11N as S55-01...
00:00:21 WIF: Checking connection...
00:00:21 WIF: Attempting connection...
00:00:22 WIF: Checking connection...
00:00:22 WIF: Attempting connection...
00:00:24 WIF: Checking connection...
00:00:24 WIF: Attempting connection...
00:00:25 WIF: Checking connection...
00:00:25 WIF: Attempting connection...
00:00:26 WIF: Checking connection...
00:00:26 WIF: Attempting connection...
00:00:27 WIF: Checking connection...
00:00:27 WIF: Attempting connection...
00:00:28 WIF: Checking connection...
00:00:28 WIF: Attempting connection...
00:00:28 RSL: SonoffS55-01/tele/HASS_STATE = {"Version":"8.1.0(tasmota)","BuildDateTime":"2019-12-25T12:33:25","Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Module":"Sonoff S55","RestartReason":"Power on","Uptime":"0T00:00:30","WiFi LinkCount":0,"WiFi Downtime":"0T00:00:00","MqttCount":0,"BootCount":32,"SaveCount":82,"IPAddress":"(IP unset)","RSSI":"68","LoadAvg":19}
00:00:29 WIF: Checking connection...
00:00:29 WIF: Attempting connection...
00:00:30 WIF: Checking connection...
00:00:30 WIF: Attempting connection...
00:00:31 WIF: Checking connection...
00:00:31 WIF: Attempting connection...
00:00:32 WIF: Checking connection...
00:00:32 WIF: Attempting connection...
00:00:33 WIF: Checking connection...
00:00:33 WIF: Attempting connection...
00:00:34 WIF: Checking connection...
00:00:34 WIF: Attempting connection...
00:00:35 WIF: Checking connection...
00:00:35 WIF: Attempting connection...
00:00:36 WIF: Checking connection...
00:00:36 WIF: Attempting connection...
00:00:37 WIF: Checking connection...
00:00:37 WIF: Attempting connection...
00:00:38 WIF: Checking connection...
00:00:38 WIF: Attempting connection...
00:00:39 WIF: Checking connection...
00:00:39 WIF: Attempting connection...
00:00:40 WIF: Checking connection...
00:00:40 WIF: Connect failed with AP timeout
00:00:41 WIF: Checking connection...
00:00:41 WIF: Attempting connection...
00:00:41 WIF: Connecting to AP1 Siblin in mode 11N as S55-01...
00:00:42 WIF: Checking connection...
00:00:42 WIF: Attempting connection...
00:00:43 WIF: Checking connection...
00:00:43 WIF: Attempting connection...
00:00:45 WIF: Checking connection...
00:00:45 WIF: Attempting connection...
00:00:46 WIF: Checking connection...
00:00:46 WIF: Attempting connection...
00:00:47 WIF: Checking connection...
00:00:47 WIF: Attempting connection...
00:00:48 WIF: Checking connection...
00:00:48 WIF: Attempting connection...
00:00:49 WIF: Checking connection...
00:00:49 WIF: Attempting connection...
00:00:50 WIF: Checking connection...
00:00:50 WIF: Attempting connection...
00:00:51 WIF: Checking connection...
00:00:51 WIF: Attempting connection...
00:00:52 WIF: Checking connection...
00:00:52 WIF: Attempting connection...
00:00:53 WIF: Checking connection...
00:00:53 WIF: Attempting connection...
00:00:54 WIF: Checking connection...
00:00:54 WIF: Attempting connection...
00:00:55 WIF: Checking connection...
00:00:55 WIF: Attempting connection...
00:00:56 WIF: Checking connection...
00:00:56 WIF: Attempting connection...
00:00:57 WIF: Checking connection...
00:00:57 WIF: Attempting connection...
00:00:58 WIF: Checking connection...
00:00:58 WIF: Attempting connection...
00:00:58 RSL: SonoffS55-01/tele/HASS_STATE = {"Version":"8.1.0(tasmota)","BuildDateTime":"2019-12-25T12:33:25","Core":"2_6_1","SDK":"2.2.2-dev(38a443e)","Module":"Sonoff S55","RestartReason":"Power on","Uptime":"0T00:01:00","WiFi LinkCount":0,"WiFi Downtime":"0T00:00:00","MqttCount":0,"BootCount":32,"SaveCount":82,"IPAddress":"(IP unset)","RSSI":"60","LoadAvg":19}
00:00:59 WIF: Checking connection...
00:00:59 WIF: Attempting connection...
00:01:00 WIF: Checking connection...
00:01:00 WIF: Attempting connection...
00:01:01 WIF: Checking connection...
00:01:01 WIF: Connect failed with AP timeout
00:01:01 WIF: Connecting to AP1 Siblin in mode 11N as S55-01...
00:01:02 WIF: Checking connection...
00:01:02 WIF: Attempting connection...
00:01:03 WIF: Checking connection...
00:01:03 WIF: Attempting connection...
00:01:05 WIF: Checking connection...
00:01:05 WIF: Attempting connection...
00:01:06 WIF: Checking connection...
00:01:06 WIF: Attempting connection...
00:01:07 WIF: Checking connection...
00:01:07 WIF: Attempting connection...
00:01:08 WIF: Checking connection...
00:01:08 WIF: Attempting connection...
00:01:09 WIF: Checking connection...
00:01:09 WIF: Attempting connection...
00:01:10 WIF: Checking connection...
00:01:10 WIF: Attempting connection...
00:01:11 WIF: Checking connection...
00:01:11 WIF: Attempting connection...
00:01:12 WIF: Checking connection...
00:01:12 WIF: Attempting connection...
00:01:13 WIF: Checking connection...
00:01:13 WIF: Attempting connection...
00:01:14 WIF: Checking connection...
00:01:14 WIF: Attempting connection...
00:01:15 WIF: Checking connection...
00:01:15 WIF: Attempting connection...
00:01:16 WIF: Checking connection...
00:01:16 WIF: Attempting connection...

@Jason2866
Copy link
Collaborator

@Fettkeewl have you tried the version i have uploaded?

@Fettkeewl
Copy link
Author

@Fettkeewl have you tried the version i have uploaded?

Sorry Jason, have not had the time, been away most of the day since my last post! Will give it a go either tonight or tomorrow depending on my kid 😛

@Fettkeewl
Copy link
Author

Alright @Jason2866 , I've been trying it out, the version you provided. No dice.
Still the same behaviour. I even tried
Wificonfig 0 and 5. Made no difference.
There is a timespan of 3-5 minutes of offline activity it seems, before the devices get blocked from reconnecting. If I pull the power and return it within some minutes it does reconnect.

The reason this is a problem, is that I'm thinking of using a 2 device setup. 1 Sonoff S55 to controll the power to my cars engineheater, which in turn is also connected to an outlet inside the car for the coupé heater. The Coupé heater I want to put an Sonoff Basic R3 on and have it only power up when I turn the engine heater(s55) on, this is to controll and monitor temperature inside of the car itself. This will never be possible if the R3 with tasmota can't reconnect to my wifi

It's not desired to be force to: Turn S55 on -> reboot router, only to gain control of the R3 inside the car.

@Fettkeewl
Copy link
Author

No other things I can try? Been waiting for a reply
@arendst @Jason2866

@Jason2866
Copy link
Collaborator

Take a look in your router docs if there is something you can do how ARP is handeled
See issue #7098 (comment) your
issue looks similar. Mikrotik routers do not have any problems anymore with enabling ARP treatment
The naming (Multicast helper) for Mikrotik is missleading.

@miazza99
Copy link

Just to tell you that I have the same issue with my Tasmota SonOff devices on ASUS RT86U.
Switching OFF the 2.4 and again ON after a few seconds seems to fix the problem as rebooting the router. This is not the solution but it might help in uderstanding.

@Jason2866
Copy link
Collaborator

@miazza99 Doing that will probably erase DHCP ARP entrys too.

You cant try lowering the DHCP lease time to 5 minutes.
Check if the devices connect after the lease time is over

@miazza99
Copy link

OK. I will try when back home next week. In any case I'm still wondering why the issue seems onlt related to Tasmota devices while all other wifi devices are well connecting.
I did not test very much SonOff with original FW but as far as I remember I did not experience any similar problem before flashing Tasmota.

@Jason2866
Copy link
Collaborator

Jason2866 commented Feb 27, 2020

Other Asus routers had already issues before. See #2643 (comment)
May you try things helped there. Such problems does only affect clients needing this function(s).
So working many other devices does not mean the router has no bug.
AND original Sonoff firmware does not have features needing this functions in router

@Jason2866
Copy link
Collaborator

Can you post a screenshot from the Professional settings page and the IPTV settings page
of you Asus router?

@Fettkeewl
Copy link
Author

Fettkeewl commented Feb 27, 2020

Heres mine, printed as pdf, since I'm not home, this was the easiest way through team viewer on my phone :P
ASUS Wireless Router RT-AC2900 - IPTV.pdf
ASUS Wireless Router RT-AC2900 - Professional.pdf

Edit:
It's all stock settings

@miazza99
Copy link

These are mine.

Wireless Professional
IPTV

@barbudor
Copy link
Contributor

Unless you self compiled to set such a password, default tasmota own SSID is password less

@miazza99
Copy link

This is out of this topic. Anyhow you can flash all the divices at the same time with the Tasmota massive upgrade tool.

@1d4rk
Copy link

1d4rk commented Jan 27, 2023

@arendst There is a new release of ESP8266/Arduino ver.3.1.1 (and 3.1.0) https://github.com/esp8266/Arduino/releases/tag/3.1.1 which uses the new ESPRESSIF/ESP8266_NONOS_SDK v3.0.5 library. This library supports the WMM/WME functionality so it should solve all the Wi-Fi connection problems with all routers as reported above.
Please can you add and test this new library in TASMOTA firmware?

@Jason2866
Copy link
Collaborator

Jason2866 commented Jan 27, 2023

@1d4rk Tasmota is Open Source. If you want to test something just do it. If you have promising results you are welcome to present.
Background: We did so many tests and tries and had a lot of troubles to get the esp8266 WiFi stable. We won't burn time for this again without verified testing is done before from a user which has the issue.
In the past we tried the 3.0 NonOs SDK variant, and it was buggy. It is not new, just another try to get the well known not solved issues solved. I highly doubt NonOs 3.0.x will help.

@1d4rk
Copy link

1d4rk commented Jan 31, 2023

@Jason2866 @arendst I tested the new ESP8266 Arduino core 3.1.1 (based on nonos_SDK v3.0.5) with a nodeMCU ESP8266 12E board. I inserted a webServer just to check the correct functionality during these days.
Using this new library, the connection was stable in 802.11n mode (WMM is shown in the router client info as well) and all worked without any issue, no disconnection occurred. Previously I needed to force 802.11g mode to work correctly.
Please is it possible to compile Tasmota using this new library for testing purposes? In this way more people can test also this new library.
Or if possible, could you suggest how compile it using this new library? For me, reading the official Tasmota Compiling Guide, it was not clear how to change nonos_sdk library...

@Jason2866
Copy link
Collaborator

@1d4rk What platformio setup have you used for your test Sketch?
We can pick the relevant settings from there.

@1d4rk
Copy link

1d4rk commented Jan 31, 2023

@1d4rk What platformio setup have you used for your test Sketch? We can pick the relevant settings from there.

I used Arduino IDE 1.8.19.
Is it possible to compile the binary in the cloud using Gitpod and change nonos_SDK?

@Jason2866
Copy link
Collaborator

Yes, it is possible to use Gitpod to compile Tasmota. Using latest Arduino core with NonOs SDK is probably not a 5 minutes job. One thing i know what has changed is the use of delay. Since Tasmota is highly optimized, and the used framework has changes which are not in standard Arduino frameworks, expect some development work ahead. Highly doubt Tasmota will work satisfying even after a successful compile.

@drrossum
Copy link

@Jason2866 you created a test build with Arduino 3.0.3 in 2021:
#13623 (comment)
I remember trying that build and it seemed to work OK then. It just didn't solve the wifi issues I was having.

Can that setup not be used with v3.0.5?

@Jason2866
Copy link
Collaborator

Jason2866 commented Jan 31, 2023

Yes, that's the one to be used and add the settings to use the NonOs SDK 3.0.5
Maybe i have time tomorrow to try. Will post the setup.

@Jason2866
Copy link
Collaborator

@1d4rk @drrossum This branch has the setup to use latest Arduino Core with NonOs SDK 3.0.5
https://github.com/Jason2866/Tasmota/tree/Core3
Can be run with Gitpod. Compile does fail since changes in core. Will do no further work on this.

@ragaskar
Copy link

Just for others (who may have not read this whole thread): tl;dr: Wifi 3 fixed my issues. More below:

I am running a ASUS RT-AC86U w/ Merlin firmware (WMM on, fwiw, and older firmware -- 384.19, because I saw stability problems with the newer firmware).

I have experienced this flapping problem with Tasmota devices for what seems like forever (it's ... probably after I switched to using the ASUS, tho). I was setting up some new Teckin SP20 devices (bought in 2019 and never flashed) today and was having the same flapping problem: every restart, the device will show up on the Wireless Log on the ASUS for about 15 seconds, then vanish and reconnect. Generally this happens for 20 - 30 minutes before it hits a stable connection and you can continue configuring it.

I ran across this thread again (I think I've seen it earlier), and noticed the suggestion to use Wifi 3. At least for me, this seems to have fixed my problem, at least with the flapping on restarts. After setting "Wifi 3" on the device I was working on, it restarted several times and reconnected immediately each time. Amazing! I haven't messed with my other devices, but next time I see problems with them I will.

@DidierFirst
Copy link

Just to add my 2 cents on this recurring discussion...

I got sonoff basic switches. When upgrading from tasmota 12.2 to upper version, half of my switches never reconnected to wifi AP. I had to connect to serial console, and even this was frustrating as I could see the "Couldn't connect to AP" messages in loop for hours, but couldn't interact with firmware as input command line simply wasn't working. Only solution left was to reflash tasmota to 12.2 version, and regain normal control on the switch. Even emergency reset of parameters wouldn't change anything, and the tasmota wifi on 192.168.4.1 never delivers an address when connecting on it.

As I'm having a bit of obstination, I couldn't find the link between failing and non failing switches after upgrade, until I noticed finally that all basic switches with ESP8266EX were failing to upgrade and behave properly, and all others work as usual with 12.3 or 12.4.

Of course, the sonoff Zigbee gateway with an ESP8266EX inside works like a charm with 12.4.0(zbbridge) version. So... if a genious has an idea ...

@ry-dgel
Copy link

ry-dgel commented Mar 12, 2023

I just encountered similar problems with multiple tasmota and esphome devices suddenly having connectivity problems and spewing out a wide range of wi-fi errors.

After trying a bunch of troubleshooting steps to no avail, I saw my router had automatically started broadcasting on channel 11, at the end of the frequency range in NA. So I tried changing this to 5, closer to the middle and everything seems to be working again. Might be that there's some extra interference at this range, or the ESP chips don't handle the slightly higher frequencies well.

@sfromis
Copy link
Contributor

sfromis commented Mar 12, 2023

What channel works best will typically depend on congestion of channels, more than the actual frequency. At least with Android devices, I find it beneficial to run a Wifi Analyzer app graphically showing which AP you have nearby on which part of the band, including ones not owned by you.

@ry-dgel
Copy link

ry-dgel commented Mar 12, 2023

I agree, though looking at the Status 0 logs in the OP, you can see that they were also connecting to channel 11. Possibly a coincidence...

@tablatronix
Copy link

I know that if you have multiple esp next to each other and some in softap mode it is enough to cause connection issues..

@rolupusoru
Copy link

rolupusoru commented Mar 15, 2023 via email

@LucidEye
Copy link

My apologies again.. please disregard my previous post. I had deleted it, but you apparently answered as I was deleting it. The problem I was having was my own fault. The ESP and Tasmota were doing exactly what I programmed them to do. The cause was actually that I had used the backlog command to perform all of my settings at once, and I forgot to disable DeepSleepTime... so the unit was going into deepsleep mode for 5 minutes and then waking up for 15 seconds. This obviously gave the outward appearance of the same disconnect problem mentioned in the original post. Again, my apologies for such a silly mistake, but it is something others might want to double check when they see this behavior.

@rsribeiro
Copy link

Just to add my 2 cents on this recurring discussion...

I got sonoff basic switches. When upgrading from tasmota 12.2 to upper version, half of my switches never reconnected to wifi AP. I had to connect to serial console, and even this was frustrating as I could see the "Couldn't connect to AP" messages in loop for hours, but couldn't interact with firmware as input command line simply wasn't working. Only solution left was to reflash tasmota to 12.2 version, and regain normal control on the switch. Even emergency reset of parameters wouldn't change anything, and the tasmota wifi on 192.168.4.1 never delivers an address when connecting on it.

As I'm having a bit of obstination, I couldn't find the link between failing and non failing switches after upgrade, until I noticed finally that all basic switches with ESP8266EX were failing to upgrade and behave properly, and all others work as usual with 12.3 or 12.4.

Of course, the sonoff Zigbee gateway with an ESP8266EX inside works like a charm with 12.4.0(zbbridge) version. So... if a genious has an idea ...

Exactly what was happening with me. Everything went back to normal once I downgraded my EXP8266EX devices to 12.2.0

@rolupusoru
Copy link

I'm at peace with all my ESP devices on manual IP asignment. The're running like this for more than a year with no problems whatsoever.after reset they connect seamlessly. Have stopped trying to figure out the root cause long time ago. It's not a tasmota problem, but somewhere deep in the arduino core.

@dan-cristian
Copy link

dan-cristian commented Apr 7, 2023 via email

@yarikoptic
Copy link

yarikoptic commented Dec 27, 2023

what "wifi 3" do you mean? By "on device" I assume it was meant the tasmota device, but I found only the entry for the secondary Wifi connection but otherwise no other settings, e.g. no way (in webui at least) to assign static IP/netmask.

edit: found this Q&A #13623 (comment) which mentions that wifi 3 is a command to be ran in the console! Now I just need to manage that "device" to reconnect at least once ;)

Also "MAC wifi blacklisting" makes little sense - don't we want the "device" to be connected and not blacklisted?

@miazza99
Copy link

Also "MAC wifi blacklisting" makes little sense - don't we want the "device" to be connected and not blacklisted?
It does not make sense but blaklisting the MAC in the 5GHz band seems to have an effect on this issue.

@llopez
Copy link

llopez commented Apr 4, 2024

Is there any resolution for this problem? I am having the same problem with my sonoff tasmota. At the moment I am using the latest version 13.4.0. The devices connect after rebooting the router.

@miazza99
Copy link

miazza99 commented Apr 4, 2024

Is there any resolution for this problem? I am having the same problem with my sonoff tasmota. At the moment I am using the latest version 13.4.0. The devices connect after rebooting the router.

The summary of the discussion is that the reason is not fully undrstood.
The working workaround is:

  1. define a fixed IP in the SonOff Tasmota device
  2. ban the SonOff Tasmota device MAC ADDRESS in the 5Ghz wifi band (it's a nonsense but ...)
    With the above I have 10 devices well working and stable since years now.

@billfor
Copy link

billfor commented Apr 4, 2024

Wifi 3 should work. And I think there was a discussion about the particular version of the library used if you read around. It's probably not going to be fixed for a while. Use the wifi 3 command.

@miazza99
Copy link

miazza99 commented Apr 4, 2024

I forgot this Wifi 3 command:
#7770 (comment)
This also helps.

@llopez
Copy link

llopez commented Apr 4, 2024

thanks.

I will try Wifi 3 with one device and then I will campare the results with the rest :)

@RCarlsonMD
Copy link

Had the same problem but setting wifi 3 command did the trick. Had to set the Asus 2.4ghz wireless mode from "Auto" to "Legacy" for the initial connection and then used console to set wifi 3. After wifi 3 is set, change "Legacy" back to "Auto". My Martin Jerry Smart Plugs don't seem to support Wireless Mode N even with Tasmota 13.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback Action - Waiting for response or more information troubleshooting Type - Troubleshooting
Projects
None yet
Development

No branches or pull requests