Sonoff Basic lost connection to Wifi after upgrading from 12.2.0 to 12.3.1

HectorDRR commented 1 year ago

PROBLEM DESCRIPTION

A clear and concise description of what the problem is. I tried to upgrade my Sonoff Basic to the latest version (12.3.1) from 11.0.0 but after upgrade, my sonoff basic didn't connect to my wifi. I've tryed to do a recover and it shows the AP and I can connect but setting up a manual ip address in my moibile because it didn't get IP from the Sonoff. Connect to 192.168.4.1 and I see the normal menu where it detect my network and my wifi password is correct. I save the configuration but after restart the problem is the same. It didn' connect and the led get flasing forever.

REQUESTED INFORMATION

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

[x] Read the Contributing Guide and Policy and the Code of Conduct
[x] Searched the problem in issues
[x] Searched the problem in discussions
[x] Searched the problem in the docs
[x] Searched the problem in the chat
[x] Device used (e.g., Sonoff Basic): Sonoff Basic
[x] Tasmota binary firmware version number used: 12.3.1
- [x] Pre-compiled
- [ ] Self-compiled
[x] Flashing tools used: OTA

[x] Provide the output of command: Backlog Template; Module; GPIO 255:


Configuration output here:
14:53:08.650 MQT: stat/bomba/RESULT = {"NAME":"Generic","GPIO":[1,1,1,1,1,1,1,1,1,1,1,1,1,1],"FLAG":0,"BASE":18}
14:53:08.871 MQT: stat/bomba/RESULT = {"Module":{"1":"Sonoff Basic"}}
14:53:09.126 MQT: stat/bomba/RESULT = {"GPIO0":{"32":"Button1"},"GPIO1":{"0":"None"},"GPIO2":{"0":"None"},"GPIO3":{"0":"None"},"GPIO4":{"0":"None"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"224":"Relay1"},"GPIO13":{"320":"Led_i1"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"},"GPIO17":{"0":"None"}}

- [x] If using rules, provide the output of this command: `Backlog Rule1; Rule2; Rule3`:
```lua
  Rules output here:
14:54:17.075 MQT: stat/bomba/RESULT = {"Rule1":{"State":"ON","Once":"OFF","StopOnError":"OFF","Length":87,"Free":424,"Rules":"on system#Boot do backlog pulsetime1 150; Mem1 0 endon on Time#Minute=0 do mem1 0 endon"}}
14:54:17.299 MQT: stat/bomba/RESULT = {"Rule2":{"State":"OFF","Once":"OFF","StopOnError":"OFF","Length":0,"Free":511,"Rules":""}}
14:54:17.550 MQT: stat/bomba/RESULT = {"Rule3":{"State":"OFF","Once":"OFF","StopOnError":"OFF","Length":0,"Free":511,"Rules":""}}

[x] Provide the output of this command: Status 0:


STATUS 0 output here:
14:54:45.026 MQT: stat/bomba/STATUS = {"Status":{"Module":1,"DeviceName":"Bomba","FriendlyName":["Bomba"],"Topic":"bomba","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0,"StatusRetain":0}}
14:54:45.065 MQT: stat/bomba/STATUS1 = {"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"sonoffs","OtaUrl":"http://ota.tasmota.com/tasmota/release-12.3.1/tasmota.bin.gz","RestartReason":"Power On","Uptime":"0T00:02:06","StartupUTC":"2022-12-24T14:52:39","Sleep":50,"CfgHolder":4617,"BootCount":13,"BCResetTime":"2020-05-07T18:12:03","SaveCount":39,"SaveAddress":"F9000"}}
14:54:45.099 MQT: stat/bomba/STATUS2 = {"StatusFWR":{"Version":"12.2.0(tasmota)","BuildDateTime":"2022-10-17T08:39:23","Boot":31,"Core":"2_7_4_9","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"424/699"}}
14:54:45.123 MQT: stat/bomba/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":2,"LogHost":"192.168.3.8","LogPort":514,"SSId":["Hector",""],"TelePeriod":3600,"Resolution":"558180C0","SetOption":["00008009","2805C80001000600003C5AFF002800000000","00000080","00006000","00004000","00000000"]}}
14:54:45.159 MQT: stat/bomba/STATUS4 = {"StatusMEM":{"ProgramSize":626,"Free":376,"Heap":26,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"1440E0","FlashFrequency":40,"FlashMode":"DOUT","Features":["00000809","8F9AC787","04368001","000000CF","010013C0","C000F981","00004004","00001000","54000020","00000000"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37,45,62","Sensors":"1,2,3,4,5,6"}}
14:54:45.202 MQT: stat/bomba/STATUS5 = {"StatusNET":{"Hostname":"bomba","IPAddress":"192.168.3.10","Gateway":"192.168.3.1","Subnetmask":"255.255.255.0","DNSServer1":"192.168.3.6","DNSServer2":"0.0.0.0","Mac":"2C:3A:E8:07:C9:CB","Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":17.0}}
14:54:45.228 MQT: stat/bomba/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.3.12","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_07C9CB","MqttUser":"DVES_USER","MqttCount":1,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
14:54:45.253 MQT: stat/bomba/STATUS7 = {"StatusTIM":{"UTC":"2022-12-24T14:54:45","Local":"2022-12-24T14:54:45","StartDST":"2022-03-27T02:00:00","EndDST":"2022-10-30T03:00:00","Timezone":99,"Sunrise":"07:42","Sunset":"15:56"}}
14:54:45.275 MQT: stat/bomba/STATUS10 = {"StatusSNS":{"Time":"2022-12-24T14:54:45"}}
14:54:45.290 MQT: stat/bomba/STATUS11 = {"StatusSTS":{"Time":"2022-12-24T14:54:45","Uptime":"0T00:02:06","UptimeSec":126,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Hector","BSSId":"98:97:D1:A6:A3:6E","Channel":11,"Mode":"11n","RSSI":22,"Signal":-89,"LinkCount":1,"Downtime":"0T00:00:06"}}}

- [ ] Set `weblog` to 4 and then, when you experience your issue, provide the output of the Console log:
```lua
  Console output here:

TO REPRODUCE

Steps to reproduce the behavior: Upgrade to 12.3.1. Upgrading to 12.2.0 gives no problem.

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen. Upgrading ato 12.3.1 must work normally but after do it, the sonoff can't connect to wifi.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here. I've tested one by one from 11.0.0 until 12.3.1. All versions works ok except 12.3.1

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

arendst commented 1 year ago

More users seem to have problems with "older" Sonoff devices. I noticed too that after upgrading to v12.3.1 sometimes makes wifi connections difficult and/or ota downloads fail with timeouts.

I've done some testing by reverting changes introduced in v12.3.1 from v12.2.0 but I still haven't found the culprit. It sometimes works correctly for hours, then it stops working for a while.

I noticed this on Sonoff Basic and T1 devices.

As a test you might want to try the tasmota-lite.bin version and see if this works better.

HectorDRR commented 1 year ago

While I'm reading your comment, I have the sonoff in front of me connected with the serial programmer, because I had to flash by serial to be abe to recover, and it has been working correct from 15 minutes ago and now I've seen how it disconnect from Wifi and get led flashing and get disconnected and after several seconds, it get connected again 14:54:45.290 MQT: stat/bomba/STATUS11 = {"StatusSTS":{"Time":"2022-12-24T14:54:45","Uptime":"0T00:02:06","UptimeSec":126,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Hector","BSSId":"98:97:D1:A6:A3:6E","Channel":11,"Mode":"11n","RSSI":22,"Signal":-89,"LinkCount":1,"Downtime":"0T00:00:06"}}} 15:02:39.639 APP: Serial logging disabled 15:07:26.855 WIF: Connecting to AP1 Hector Channel 11 BSSId 98:97:D1:A6:A3:6E in mode 11n as bomba... 15:07:36.801 WIF: Connect failed as AP cannot be reached 15:07:37.140 WIF: Connecting to AP1 Hector in mode 11n as bomba... 15:07:47.020 WIF: Connect failed as AP cannot be reached 15:07:48.021 WIF: Connect failed as AP cannot be reached 15:07:48.360 WIF: Connecting to AP1 Hector in mode 11n as bomba... 15:07:59.004 WIF: Connected 15:07:59.255 MQT: Attempting connection... 15:07:59.466 MQT: Connect failed to 192.168.3.12:1883, rc -2. Retry in 10 sec 15:08:10.540 MQT: Attempting connection... 15:08:10.560 MQT: Connected 15:08:10.564 MQT: tele/bomba/LWT = Online (retained) 15:08:10.567 MQT: cmnd/bomba/POWER = 15:08:10.794 MQT: stat/bomba/RESULT = {"POWER":"OFF"} 15:08:10.797 MQT: stat/bomba/POWER = OFF I'll try latest tasmota-lite-bin as recommended

HectorDRR commented 1 year ago

Tasmota-lite-bin 12.3.1 upgraded without problem and connected to the Wifi.

00:00:00.001 HDW: ESP8266EX 00:00:00.047 CFG: Loaded from flash at FB, Count 42 00:00:00.211 QPC: Reset 00:00:00.224 Project tasmota - Bomba Version 12.3.1(lite)-2_7_4_9(2022-12-16T10:28:11) 00:00:00.863 WIF: Connecting to AP1 Hector Channel 11 BSSId 98:97:D1:A6:A3:6E in mode 11n as bomba... 00:00:05.504 WIF: Connected 00:00:05.755 HTP: Web server active on bomba with IP address 192.168.3.10 15:13:26.352 MQT: Attempting connection... 15:13:26.384 MQT: Connected 15:13:26.388 MQT: tele/bomba/LWT = Online (retained) 15:13:26.389 MQT: cmnd/bomba/POWER = 15:13:26.394 MQT: tele/bomba/INFO1 = {"Info1":{"Module":"Sonoff Basic","Version":"12.3.1(lite)","FallbackTopic":"cmnd/DVES_07C9CB_fb/","GroupTopic":"cmnd/sonoffs/"}} 15:13:26.408 MQT: tele/bomba/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"bomba","IPAddress":"192.168.3.10"}} 15:13:26.416 MQT: tele/bomba/INFO3 = {"Info3":{"RestartReason":"Software/System restart","BootCount":14}} 15:13:26.424 MQT: stat/bomba/RESULT = {"POWER":"OFF"} 15:13:26.426 MQT: stat/bomba/POWER = OFF 15:13:26.440 RUL: SYSTEM#BOOT performs "backlog pulsetime1 150; Mem1 0" 15:13:26.481 MQT: stat/bomba/RESULT = {"PulseTime1":{"Set":150,"Remaining":150}} 15:13:27.097 MQT: stat/bomba/RESULT = {"Mem1":"0"} 15:13:31.287 MQT: tele/bomba/STATE = {"Time":"2022-12-24T15:13:31","Uptime":"0T00:00:13","UptimeSec":13,"Vcc":3.514,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Hector","BSSId":"98:97:D1:A6:A3:6E","Channel":11,"Mode":"11n","RSSI":12,"Signal":-94,"LinkCount":1,"Downtime":"0T00:00:07"}} 15:14:12.774 MQT: Attempting connection... 15:14:12.796 MQT: Connected 15:14:12.799 MQT: tele/bomba/LWT = Online (retained) 15:14:12.801 MQT: cmnd/bomba/POWER = 15:14:16.907 MQT: stat/bomba/RESULT = {"POWER":"OFF"} 15:14:16.909 MQT: stat/bomba/POWER = OFF

HectorDRR commented 1 year ago

I've disconnected power and connect again and it has been a while trying to reconnect until it has worked. The Sonoff has not been moved from his place in front of me and at 5 m from the router. 00:00:00.001 HDW: ESP8266EX 00:00:00.050 CFG: Loaded from flash at FA, Count 44 00:00:00.056 QPC: Count 1 00:00:00.066 Project tasmota - Bomba Version 12.3.1(lite)-2_7_4_9(2022-12-16T10:28:11) 00:00:00.556 WIF: Connecting to AP1 Hector Channel 11 BSSId 98:97:D1:A6:A3:6E in mode 11n as bomba... 00:00:06.480 QPC: Reset 00:00:12.764 WIF: Connect failed 00:00:13.102 WIF: Connecting to AP1 Hector in mode 11n as bomba... 00:00:23.033 WIF: Connect failed as AP cannot be reached 00:00:24.033 WIF: Connect failed as AP cannot be reached 00:00:24.370 WIF: Connecting to AP1 Hector in mode 11n as bomba... 00:00:34.262 WIF: Connect failed as AP cannot be reached 00:00:35.262 WIF: Connect failed as AP cannot be reached 00:00:35.599 WIF: Connecting to AP1 Hector in mode 11n as bomba... 00:00:45.532 WIF: Connect failed as AP cannot be reached 00:00:46.534 WIF: Connect failed as AP cannot be reached 00:00:46.871 WIF: Connecting to AP1 Hector in mode 11n as bomba... 00:00:59.013 WIF: Connected 00:00:59.264 HTP: Web server active on bomba with IP address 192.168.3.10 00:01:00.274 MQT: Attempting connection... 00:01:00.305 MQT: Connected 00:01:00.309 MQT: tele/bomba/LWT = Online (retained) 00:01:00.310 MQT: cmnd/bomba/POWER = 00:01:00.315 MQT: tele/bomba/INFO1 = {"Info1":{"Module":"Sonoff Basic","Version":"12.3.1(lite)","FallbackTopic":"cmnd/DVES_07C9CB_fb/","GroupTopic":"cmnd/sonoffs/"}} 00:01:00.330 MQT: tele/bomba/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"bomba","IPAddress":"192.168.3.10"}} 00:01:00.337 MQT: tele/bomba/INFO3 = {"Info3":{"RestartReason":"Power On","BootCount":16}} 00:01:00.345 MQT: stat/bomba/RESULT = {"POWER":"OFF"} 00:01:00.346 MQT: stat/bomba/POWER = OFF 00:01:00.360 RUL: SYSTEM#BOOT performs "backlog pulsetime1 150; Mem1 0" 00:01:00.402 MQT: stat/bomba/RESULT = {"PulseTime1":{"Set":150,"Remaining":150}} 00:01:00.604 MQT: stat/bomba/RESULT = {"Mem1":"0"} 00:01:04.784 MQT: tele/bomba/STATE = {"Time":"1970-01-01T00:01:04","Uptime":"0T00:01:07","UptimeSec":67,"Vcc":3.495,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"Hector","BSSId":"98:97:D1:A6:A3:6E","Channel":11,"Mode":"11n","RSSI":12,"Signal":-94,"LinkCount":1,"Downtime":"0T00:01:01"}} 15:23:17.536 MQT: Attempting connection... 15:23:17.566 MQT: Connected 15:23:17.570 MQT: tele/bomba/LWT = Online (retained) 15:23:17.572 MQT: cmnd/bomba/POWER = 15:23:17.791 MQT: stat/bomba/RESULT = {"POWER":"OFF"} 15:23:17.794 MQT: stat/bomba/POWER = OFF 15:23:22.424 MQT: stat/bomba/RESULT = {"POWER":"OFF"} 15:23:22.426 MQT: stat/bomba/POWER = OFF 15:24:03.521 MQT: Attempting connection... 15:24:03.540 MQT: Connected 15:24:03.543 MQT: tele/bomba/LWT = Online (retained) 15:24:03.546 MQT: cmnd/bomba/POWER = 15:24:09.845 MQT: stat/bomba/RESULT = {"POWER":"OFF"} 15:24:09.847 MQT: stat/bomba/POWER = OFF

I'll put it back at this original place, controlling a pump for recirculate hot water before we get a shower, and I'll try to monitorize if there is more wifi problems.

I'll let my others Sonoff Dual and Sonoff TH with version 12.2.0 for a while until confirm the problem with this firm is solved.

Thanks for your support and greetings for your great work with Tasmota!

Happy Christmas!

grischard commented 1 year ago

I'm having a similar issue with tasmota nodes not grabbing an ip address from dhcp. They get the subnet, etc., but don't grab the ip address.

The logs when I first try to connect are a bit different - endless loops of 'Connect failed':

18:18:32.692 -> 00:03:20.856 WIF: Connecting to AP1 my-AP1 in mode 11n as tasmota-D071E8-4584...
18:18:44.974 -> 00:03:32.523 WIF: Connect failed with AP timeout

As a workaround, I can 'force' them to connect by setting ipaddress1 192.168.1.x manually:

18:22:22.539 -> 00:07:00.132 CMD: ipaddress
18:22:22.539 -> 00:07:00.138 RSL: RESULT = {"IPAddress1":"0.0.0.0 (0.0.0.0)","IPAddress2":"192.168.1.1","IPAddress3":"255.255.255.0","IPAddress4":"192.168.1.1","IPAddress5":"0.0.0.0"}

…

18:22:32.159 -> 00:07:09.144 CMD: ipaddress1 192.168.1.49
18:22:32.159 -> 00:07:09.149 RSL: RESULT = {"IPAddress1":"192.168.1.49 (0.0.0.0)"}
18:23:13.960 -> 00:00:04.012 CMD: restart 1
18:23:13.960 -> 00:00:04.015 RSL: RESULT = {"Restart":"Restarting"}

…

18:23:16.988 -> 00:00:00.548 WIF: Connecting to AP1 GUACAMOLE.BE in mode 11n as tasmota-D071E8-4584...
18:23:19.812 -> 00:00:03.279 CMD: ipaddress
18:23:19.812 -> 00:00:03.284 RSL: RESULT = {"IPAddress1":"192.168.1.49 (192.168.1.49)","IPAddress2":"192.168.1.1","IPAddress3":"255.255.255.0","IPAddress4":"192.168.1.1","IPAddress5":"0.0.0.0"}
18:23:21.221 -> 00:00:04.503 WIF: Connected

My dhcp server is dnsmasq 2.87 running on openwrt. A packet capture there shows that the dhcp server receives a dhcp discover from tasmota, sends a dhcp offer, but never hears back with a dhcp request.

I'm attaching a packet capture:

tasmota-dhcp.dmp.gz

Extreme79 commented 1 year ago

Same issue here. I upgraded to 12.3.1 a sonoff th16. No more connection to the wifi. After a reset I was able to connect to the tasmota recover ssid. I uploaded the config backup and I lost connection again. Reset. Tasmota's AP connection. Manual Wifi setup.. connection lost again. Notice: the sonoff is able to connect to my phone in wifi tethering mode near the sonoff, with the same ssid and pwd I have in my home.. very strange. Another reset and a firmware downgrade, uploading the same config backup.. bring the device up n the network again.

stefanbode commented 1 year ago

I have this issue that some devices lost connection and do no reconnect already in 12.1. My first guess was an issue with the new Fritzbox 7490AX router but this is unlikely because the repeaters did not change. I also do not have the problem on all devices. Some work great some not. i changed some to wifimode 2, but cannot see that this really makes a difference. anyhow all of them connect correctly AFTER a power off cycle

arendst commented 1 year ago

@HectorDRR I see this issue is already being hijacked by others so let's continue by calling you directly.

I still cannot stable reproduce the network issue from v12.3.1 on sonoff. What I did is adding debug SetOption177 to disable a feature introduced in v12.3.1. Pls try to load latest dev release and enable SO177 1. This disables a feature running during the sleep period which might make the Sonoffs using too much power resulting in wifi stability errors.

Bournetoride commented 1 year ago

"This disables a feature running during the sleep period which might make the Sonoffs using too much power resulting in wifi stability errors." I noticed something similar on my sonoff basic running 12.0.2.1 , turning off dynamic sleep worked for me

grischard commented 1 year ago

@arendst sorry for the hijack! Should I open a separate issue?

stefanbode commented 1 year ago

Let me check on the dynamic sleep. Just for test

bhp20 commented 1 year ago

I had the same problem (upgrading to 12.3.1 OTA) on an old Sonoff Basic R2 V1.0. (BTW, two other same vintage Sonoff's upgraded with no problem). I had to remove the Sonoff from the wall (of course, the two Sonoffs with no problem were external!) to reflash (using an FTD1232 and Tasmotizer). This worked. However, Tasmotizer only allows .bin, and I've been using .bin.gz files for a while; I didn't notice that the last .bin I had was ver 11, until after I squeezed everything back into the wall. When I upgraded (OTA) to the latest, it failed again. This time I reflashed (via hardwire FTD1232) with the newest firmware (12.3.1.2) which is working. I am concerned about upgrading OTA next time (I never want to pull the module out of the wall again). The Sonoff that didn't upgrade has a different configuration than the two that upgraded - it has a capacitive touch switch. Hope that this helps.

mikep1998 commented 1 year ago

FYI I'm having the same problem with a D1mini just upgraded to 12.3.1.2 and now can not connect to router.

mikep1998 commented 1 year ago

After a couple of hours it was able to connect.

stefanbode commented 1 year ago

Following changes: 12.3.1.2 got offline after some days. Reboot and setoption60 1. No problems until now. Now changed back setoption60 0 and setoption177 1. Will see if the device stay online

stefanbode commented 1 year ago

ok the device got OFFLINE because of weak network but recovers without problems after the network was in reach again. Maybe this helps for debugging. setoption 177 == 1

stefanbode commented 1 year ago

I do not understand why the downtime is still low. This is definitely wrong. The device was OFFLINE for several hours. Looks for me like the device is not recognizing the problem.

stefanbode commented 1 year ago

Device is offline again since 15min. No ping possible anymore.

Jason2866 commented 1 year ago

Is it a Sonoff Basic R2? If yes, best solution is too ditch in the bin. Device is a design fail in every aspect. Power supply is way to weak to power the esp reliable. Next thermal design of esp and flash chip. The esp is mounted to heat the flash. Have a user example where this damaged the flash. Replaced the flash and device was functional again. BUT esp gets to hot because it is not powered correctly and the esp seems to try to compensate this. So power supply is stressed more. Bad powering is resulting in wifi issues. This is a known dependency of the esp8266. So if the device connects to wifi without issues when powered via USB serial adapter, the power supply is to blame. Replace or fix the power supply and the device will work.

Jason2866 commented 1 year ago

I do not understand why the downtime is still low. This is definitely wrong. The device was OFFLINE for several hours. Looks for me like the device is not recognizing the problem.

@stefanbode device was just not connected to WiFi (since bad powering), so this is correct. The horrible rssi happens when power supply is bad. The device goes offline because WiFi connection gets worse because of bad powering.

Jason2866 commented 1 year ago

For the Sonoff Basic R2 the last working Tasmota version is v12.2.x Reason: Later version has more features which has more MCU load, and needs more current. The poor weak power supply of the R2 can’t handle this.

Jason2866 commented 1 year ago

Please check if you have set sleep 20 at least. Sleep is needed for the R2 !! If there are still issues do reset 3 afterwards. Wait until steady LED goes off and disconnect device. Wait a few seconds and conect device to power again. After the reset 3 the wifi signal should be good.

Yes, it is a Sonoff Basic R2. It has a 4MB flash, since the orig. flash was defect. Did I say already that the R2 is crap and build of cheapest parts...

Extreme79 commented 1 year ago

For the Sonoff Basic R2 the last working Tasmota version is v12.2.x Reason: Later version has more features which has more MCU load, and needs more current. The poor weak power supply of the R2 can’t handle this.

Also valid for sonoff TH16 (where I have the same issue)?

Jason2866 commented 1 year ago

How old is the TH16? All my Sonoff Basic i had in use are dead. The won’t last long. This Sonoff devices are built from cheapest components and hardware design is bleeding edge. Repaired a few for testing (always power supply)… No Sonoff Basic or sort off anymore in productive use. There are way better alternatives for the Sonoff Basics. We do no issue hunting when only the cheap Sonoff devices fail. The are the issue!

wchulze commented 1 year ago

I've been using 24 Sonoff Basics in all versions for 4 years with Tasmota without a failure or problem. If Tasmota no longer works for Sonoff the "S" in the name Tasmota is no longer valid. A new name would be a good indication of the situation. That's not meant to be taken seriously. Please provide versions with less software load. Because the original Sonoff software is adapted to the hardware. The problem is therefore not in the hardware but in the Tasmota software, that does not fit.

Jason2866 commented 1 year ago

@wchulze There is a liteversion. Tasmota–lite. We can’t do more. Your devices will probably all work with v12.3.1 As shown before latest Tasmota does run on my known very bad flaky R2 too.

The „s“ in Tasmota is just historic. Ideas for reuse of the „s“ in naming are welcome.

P.S. Lucky you are with your Basics!

sfromis commented 1 year ago

As the Sonoff Basic R2 is a even worse device than the older Sonoff Basic, which was the starting point of Tasmota, Tasmota was not downgraded to the crappy R2.

Jason2866 commented 1 year ago

How about. Tasmota. (T)heo (A)rendst (S)mart (M)qtt (OTA) ?

wchulze commented 1 year ago

@Jason2866 Good idea. The Lite version is only available in English. How can I compile it - locally - into another interface language? Previously, in older versions I could set a compiler switch.

barbudor commented 1 year ago

Everything is in https://tasmota.github.io/docs/Compile-your-build/

The easiest way for local compile is installing Jason's Portable VSCode package which include everything

Jason2866 commented 1 year ago

[env:tasmota-lite-de]
build_flags             = ${env.build_flags} -DFIRMWARE_LITE -DMY_LANGUAGE=de_DE
lib_extra_dirs          =

Extreme79 commented 1 year ago

How old is the TH16? All my Sonoff Basic i had in use are dead. The won’t last long.

Mine was bought 3yrs ago and used to drive a fridge compressor. I solved reinstalling a previous firmware, not a real problem.. Newer firmware is not really needed. It's more like curiosity about the issue that not a real need. Because in my case with the new firmware I got no connection on the router BUT, placing my phone as Hotspot, configured as my router... Bum! Got the sonoff connected to the phone and perfectly usable.

This mean that the issue is not, probably, linked to what I can read above.

Jason2866 commented 1 year ago

@Extreme79 Probably a router DHCP cache issue. Delete cache (easiest restart Router) and it will connect. Not related.

wchulze commented 1 year ago

@barbudor Thank,s for info, but I know. @Jason2866 Got it. Now the PID controller fails to compile due to missing timeprop.h now. Maybe I have to open an new issue.

Extreme79 commented 1 year ago

@Extreme79 Probably a router DHCP cache issue. Delete cache (easiest restart Router) and it will connect. Not related.

I think not. I obviously already tested a router reboot and also a reduced dhcp lease time, but nothing works (all my iot devices has a static dhcp assignment by Mac address, but anyway same issue disabling static ip assignment). The only way to get it back connected, it's to downgrade the firmware.

Oh. And it's not some AP compatibility related. I have multiple access points, Openwrt based, an outdoor TPLink, main router netgear d7000 before and zyxel vmg8623-t50b actually. With the new firmware I'm able to connect only to my phone as Hotspot near the device. If you can point me in some direction I can try to export some logs, if you are interested.

Jason2866 commented 1 year ago

@Extreme79 okay, but not related to this.

Jason2866 commented 1 year ago

@barbudor Thank,s for info, but I know. @Jason2866 Got it. Now the PID controller fails to compile due to missing timeprop.h now. Maybe I have to open an new issue.

Tasmota–lite can not include specific stuff. It is as it is. Nothing can be added.

Jason2866 commented 1 year ago

@Extreme79 please open a discussion with many infos. Code for DNS resolving has changed.

wunderbaum commented 1 year ago

I have the same issue with my wemos-boards. As I wanted to experiment with the new LD2410 sensor, I had to compile my own firmware on benzino77s compiler page. I only choose Alexa, HomeAssistant, mDNS, Web Interface, Rules and Timers. And I added: #define USE_LD2410 to the user_config_override. The firmware was only 588k large and I was able to flash it to a wemos-board. But it cannot connect to my WLAN. Every firmware-version lower than 12.3.1 worked perfect. What can I do to get a better result?

Jason2866 commented 1 year ago

@wunderbaum if you say Wemos you probably mean Wemos D1 mini clones. The other known trouble makers. Search for weak LDO Wemos D1 mini. You will find many hits. One https://www.reddit.com/r/esp8266/comments/9iizx4/warning_clone_wemos_d1_minis_with_only_150ma_33v/ Solution replace the too weak onboard 3.3V LDO used on nearly all clones, with a 500mA type which is used on the orig. Wemos D1 mini. That's all.

wunderbaum commented 1 year ago

@Jason2866 Ah ok. Its just a cheap Wemos (not mini). I took it out of the foil and flashed it. Then I tried the previous versions and they all worked. The LDO is an AMS1117.

I just found such a bad SonoffDuals that I happened to update a few days ago. It runs! Sonoff Dual R2 Gastspots Program Version 12.3.1(tasmota) Build Date & Time 2022-12-16T10:28:17 Core/SDK Version 2_7_4_9/2.2.2-dev(38a443e) Uptime 4T07:05:23

Something severe must have been changed. I understand that some old devices can't be fit new features any more, so I point out that there should be some kind of check that nobody renders his/hers device to death, especially when its behind tons of concrete.

Jason2866 commented 1 year ago

@wunderbaum It is a sort of a NodeMCU. Should work. Have no device with this behaviour. Without a device where the behaviour is reproducible it is not possible to find the reason for. Not saying there is maybe a change which does generate that. Nothing mandatory changed in Tasmota. The Arduino Core is untouched since many releases. So we can not say anything which causes that.

Jason2866 commented 1 year ago

@wunderbaum can you please test if the latest development Tasmota.bin if the English NOT localised one is working? We had an issue in the past where a special character in the language file (not the German Version) did broke Tasmota firmware.

wunderbaum commented 1 year ago

@Jason2866 I tried this one: http://ota.tasmota.com/tasmota/tasmota.bin (12.3.1.5) on that wemos. Still the same. I tried a shelly1, too. That works. Both where connected via USB-Adapter of my PC, so shelly without mains.

Jason2866 commented 1 year ago

Do you have an oscilloscope? If yes could you check the 3.3V directly on the esp8266? Searching for spikes and drops.

wunderbaum commented 1 year ago

I have access to one, but not tonight. I try to connect one soon and do some measurements. We have a Rigol 1052 in the lab I hope.

stefanbode commented 1 year ago

I used the AMS1117 in many of my projects so far without any problems. If it is a fake one, maybe this can cause the issue. Additional I see two problems: some users are even not able to connect the first time and others like me get connected most time but have a non recoverable lost after some time. But all is 12.3 related as far as I can see. If power consumption is significant higher in 12.3 this might explain the LDO stuff. Most devices deliver enough in 5V but this means nothing if the LDO fail to provide the current. But here a capacitor on the 3.3V rail really should work and fix it. If it is the problem....

wunderbaum commented 1 year ago

Good morning, I oscilloscoped two wemos, one with 12.2.0, and the other one with 12.3.1.5. There was no difference on 3.3V pin. At least for my eye. When I do a reset 1, I can see the AP for configuration, but I do not get an IP. In 12.2.0, I get one.

Jason2866 commented 1 year ago

The part where an AP is opened needs the most current. The behaviour with connection issues to wifi or not seeing an device AP is typical for powering issues. The defect Sonoff R2 which I got from an user had an (defect) XMC flash chip. After replacing it started badly working again. Seeing bad wifi rssi. If powered from extern rssi is perfect. Maybe XMC flash are somehow related to this issue? Would be interesting to replace the XMC flash against a Winbond flash. To see if there is a chance. Always have not a good feeling seeing HF designs without a metall shield... You can try to reduce tx transmit power to a very low level. If this helps the device has problems related to powering and/or antenna design. Antenna not matching causes reflections and results in bad wifi and need much current. What stefanbode said, many designs do penny pinching and left out needed caps. Ones needed for stabilising and small HF blocking ones.

wunderbaum commented 1 year ago

But what is causing this high demand for current as it worked in all previous versions? How can I reduce the TX power?

arendst / Tasmota