Problems with Sonoff powered by AC voltage.

[Sean H]

Is anyone experiencing this: I have a few Sonoff basics that I've flashed with various firmware packages, (Sonoff-HomeAssistant, Sonoff-Wemo, and Sonoff-Tasmota), on the first two firmwares, I can boot up and test them when they're still powered by the FTDI cable and they work great. On any of the firmwares, as soon as I disconnect them and hook up to AC power, I start having immediate problems with responsiveness and wireless connection. When I ping I get a lot of errors and packet loss. Even the physical button fails to be recognized by the firmware when toggled repeatedly. It seems like the DC power supply isn't able to keep up. Has anyone else noticed this?

Here's my ping results:

PING 192.168.1.122 (192.168.1.122): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=80.041 ms

64 bytes from 192.168.1.122: icmp_seq=3 ttl=128 time=98.025 ms

Request timeout for icmp_seq 4

64 bytes from 192.168.1.122: icmp_seq=5 ttl=128 time=8.095 ms

Request timeout for icmp_seq 6

Request timeout for icmp_seq 7

Request timeout for icmp_seq 8

64 bytes from 192.168.1.122: icmp_seq=9 ttl=128 time=113.290 ms

64 bytes from 192.168.1.122: icmp_seq=10 ttl=128 time=33.799 ms

64 bytes from 192.168.1.122: icmp_seq=11 ttl=128 time=78.605 ms

64 bytes from 192.168.1.122: icmp_seq=12 ttl=128 time=72.956 ms

Request timeout for icmp_seq 13

Request timeout for icmp_seq 14

64 bytes from 192.168.1.122: icmp_seq=15 ttl=128 time=6.607 ms

64 bytes from 192.168.1.122: icmp_seq=16 ttl=128 time=2.945 ms

64 bytes from 192.168.1.122: icmp_seq=17 ttl=128 time=8.931 ms

Request timeout for icmp_seq 18

64 bytes from 192.168.1.122: icmp_seq=19 ttl=128 time=107.572 ms

64 bytes from 192.168.1.122: icmp_seq=20 ttl=128 time=23.324 ms

64 bytes from 192.168.1.122: icmp_seq=21 ttl=128 time=4.827 ms

64 bytes from 192.168.1.122: icmp_seq=22 ttl=128 time=12.412 ms

64 bytes from 192.168.1.122: icmp_seq=23 ttl=128 time=4.881 ms

64 bytes from 192.168.1.122: icmp_seq=24 ttl=128 time=4.737 ms

^C

--- 192.168.1.122 ping statistics ---

25 packets transmitted, 16 packets received, 36.0% packet loss

round-trip min/avg/max/stddev = 2.945/41.315/113.290/40.865 ms

Connected to FTDI cable I get zero packet loss and around 5-10 ms speeds.

[and...@gmail.com]

I've had the exact same problem!
I disabled as many features as I could when flashing, namely the webserver which I really wanted to use for management, and I do not have that issue anymore. It's a shame, it would have been so awesome to be able to use all the features:/ 

Someone please help?

[Pǝtǝr FlCKlNGER]

It seems like I had an problem similar to your's.

Yesterday I updated my sonoff touch from Tasmota 2.0.14 to Tasmota 2.0.20. After that, I got serious problems with this switch, it is not stable, hardly to reach by the webpage and it begins to switching the relay arbitrarily. After powering off by switching the fuse at the apartments fuse box, the sonoff doesn't work anymore, no light, no connection, no reaction. After removing the ESP8285 circuit board and connecting to the FTDI, it isn't booting completely, it persists in a state like "try to connect network" (or similar). After that, I tried to reflash the board with an older version (that worked for the last 14 days at this board) but all my attemps aborted with the message "espcomm_upload_mem failed".
So I took new circuit board from a completely new sonoff touch, flashed it with 2.0.14, tested it power supplied at the FTDI adapter the worked properly and after that installed it to wall switch case... and what happened: after a few seconds the relay begins to switch arbitrarily without touching the switch and the small blue LED is blinking.

Some weeks ago, the same behaviour occured at another sonoff basic, that I relaced by a working one (was Tasmota 2.0.9). The only difference was, that this module wasn't completly defect.

I guess there is a strange problem with the power supply board. Maybe it could be fixed by a additional capacitor? Perhaps someone with an oszilloscope can analyse the quality of the voltage/current?

[David Lang]

I would guess that you are at a marginal area for wifi and when you are powering things via AC there is just enough noise to cause the wifi connection to be unreliable. if there is no wifi, the local switch works, but if there is poor wifi, it can get stuck in connecting-to-mqtt mode and not respond.

David Lang

[Pǝtǝr FlCKlNGER]

Nope David, sorry it isn't the signal level!

I've got it now. It's the crappy soldered PCB. The last capacitor (470uF) had a cold solder joint. At two of my three sonoff touch this capacitor was not connected to the PCB. It has the job to spend energy at "bad times" and to filter voltage peaks. This explains the unreliable connection/cpu state and why one of my ESP8285 died.

Attached you can see the cold solder joint and how I fixed it. Now it works well and stable.