Tasmota: Fixed: Failing Sonoff LED - Upgrade power regulator

[ecsfang]

Hi!

I have two Sonoff LEDs running, and one of them seems to fail. It starts ok, but after a while it starts to restarts itself.
I have also noticed, that as soon as I redirect my browser to the web-server in the Sonoff, it also restarts. Using serialcom or MQTT seems to work, at least so I can communicate with the device.

Typically the log looks like this (after a restart and then trying to access the webserver via WiFi):

00:00:13 Wifi: Connect failed with AP incorrect password
00:00:13 Wifi: Connecting to AP2 TIGERGAP in mode 11N as kitchen_left-2505...
00:00:20 Wifi: Connect failed as AP cannot be reached
00:00:21 Wifi: Connect failed as AP cannot be reached
00:00:21 Wifi: Connecting to AP1 TIGERWOLF in mode 11N as kitchen_left-2505...
00:00:26 Wifi: Connected
00:00:26 HTTP: Webserver active on kitchen_left-2505 with IP address 1xx.xxx.xxx.xxx
19:25:17 MQTT: Attempting connection...
19:25:17 MQTT: Connected
19:25:17 MQTT: tele/kitchen_left/LWT = Online (retained)
19:25:17 MQTT: cmnd/kitchen_left/POWER = 
19:25:17 MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"3.9.19",     "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
19:25:17 MQTT: tele/kitchen_left/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_left-2505", "IPaddress":"1xx.xxx.xxx.xxx"}
19:25:18 MQTT: stat/kitchen_left/RESULT = {"POWER":"ON"}
19:25:18 MQTT: stat/kitchen_left/POWER = ON
19:25:25 MQTT: tele/kitchen_left/STATE = {"Time":"2017-02-28T19:25:25", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":56}}

Exception (29):
epc1=0x4021d3d6 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000010 depc=0x00000000

ctx: cont 
sp: 3fff1ff0 end: 3fff2300 offset: 01a0

>>>stack>>>
3fff2190:  00000000 00000000 00000000 00000000  
3fff21a0:  00000000 00000000 00000001 3fff02d8  
3fff21b0:  3fff02d7 3ffe8528 00000002 40211aef  
3fff21c0:  00000000 00000000 00000000 3fff3854  
3fff21d0:  0000000f 00000000 3fff4f3c 00000a5f  
3fff21e0:  00000a5b 00000001 3fff2230 4021be2f  
3fff21f0:  3fff11e8 00000178 00000178 40218558  
3fff2200:  00000001 00000001 3fff389c 4021ccfa  
3fff2210:  00000000 3fffdad0 3fff389c 4021854e  
3fff2220:  3fff389c 3fff39c4 3fff389c 4021858a  
3fff2230:  00000000 00000000 00000000 4021bf90  
3fff2240:  3fff389c 3fff39c4 3fff3984 4021861d  
3fff2250:  3fff4e64 0000000f 00000001 40215224  
3fff2260:  3fff39c4 00001388 3fff3984 00000001  
3fff2270:  00000001 40217abc 0000000f 4021cae4  
3fff2280:  00000000 00000000 3fff3984 3fff12cc  
3fff2290:  00000001 3fff39a8 3fff3984 402187a7  
3fff22a0:  3ffe9510 00000000 000003e8 00000000  
3fff22b0:  00000000 3fff4c9c 4021ca2c 3fff12e0  
3fff22c0:  3fffdad0 00000000 3fff12c4 40203fce  
3fff22d0:  00000000 00000000 00000001 40213fc8  
3fff22e0:  3fffdad0 00000000 3fff12c4 4021ca78  
3fff22f0:  feefeffe feefeffe 3fff12e0 40100718  
<<<stack<<<

 ets Jan  8 2013,rst cause:1, boot mode:(1,7)


 ets Jan  8 2013,rst cause:4, boot mode:(1,7)

wdt reset

I have tried to reflash, erasing the flash etc, but I always ends up in this scenario - with this device.
The other Sonoff LED I have, loaded with the same software seems to work fine.

I suspect bad hardware, anyone else with another opinion?

This is status after flash erase and default values loaded:

19:48:07 MQTT: stat/sonoff/STATUS = {"Status":{"Module":1, "FriendlyName":"Sonoff", "Topic":"sonoff", "ButtonTopic":"0", "Subtopic":"POWER", "Power":1, "PowerOnState":3, "LedState":1, "SaveData":1, "SaveState":1, "ButtonRetain":0, "PowerRetain":0}}
19:48:07 MQTT: stat/sonoff/STATUS1 = {"StatusPRM":{"Baudrate":115200, "GroupTopic":"sonoffs", "OtaUrl":"http://1xx.xxx.yyy.zzz:80/api/arduino/sonoff.ino.bin", "Uptime":0, "Sleep":0, "BootCount":3, "SaveCount":6}}
19:48:07 MQTT: stat/sonoff/STATUS2 = {"StatusFWR":{"Program":"3.9.19", "Boot":31, "SDK":"1.5.3(aec24ac9)"}}
19:48:07 MQTT: stat/sonoff/STATUS3 = {"StatusLOG":{"Seriallog":2, "Weblog":2, "Syslog":0, "LogHost":"1xx.xxx.xxx.xxx", "SSId1":"TIGERWOLF", "SSId2":"TIGERGATE", "TelePeriod":300}}
19:48:07 MQTT: stat/sonoff/STATUS4 = {"StatusMEM":{"ProgramSize":443, "Free":496, "Heap":28, "SpiffsStart":940, "SpiffsSize":64, "FlashSize":1024, "ProgramFlashSize":1024, "FlashChipMode",3}}
19:48:07 MQTT: stat/sonoff/STATUS5 = {"StatusNET":{"Host":"sonoff-2505", "IP":"1xx.xxx.xxx.xxx", "Gateway":"1xx.xxx.1.1", "Subnetmask":"255.255.255.0", "Mac":"xx.xx.xx:CC:09:C9", "Webserver":2, "WifiConfig":3}}
19:48:07 MQTT: stat/sonoff/STATUS6 = {"StatusMQT":{"Host":"1xx.xxx.yyy.zzz", "Port":1883, "ClientMask":"DVES_%06X", "Client":"DVES_CC09C9", "User":"DVES_USER", "MAX_PACKET_SIZE":512, "KEEPALIVE":15}}
19:48:07 MQTT: stat/sonoff/STATUS7 = {"StatusTIM":{"UTC":"Tue Feb 28 18:48:07 2017", "Local":"Tue Feb 28 19:48:07 2017", "StartDST":"Sun Mar 26 02:00:00 2017", "EndDST":"Sun Oct 29 03:00:00 2017", "Timezone":1}}
19:48:07 MQTT: stat/sonoff/STATUS10 = {"StatusSNS":{"Time":"2017-02-28T19:48:07"}}

(Another "problem" seen in the log that I see quite often, is that the first attempt(s) to connect to WiFi fails with incorrect password. The second (or third) attempt works. This shows up as many devices are connected to AP2, even if AP1 is closer and stronger ...)

Cheers!

[arendst]

I see your flashchipmode is 3 (esp8285). For the sonoff led a 2 should be used. Try command flashchipmode 2 and reflash using ota or web upgrade.

[ecsfang]

Hi!

I tried setting the mode, and then updated using OTA (from smadds binaries):

stat/kitchen_left/RESULT : msg.payload : string [19]
{"FlashChipMode":2}

stat/kitchen_left/RESULT : msg.payload : string [83]
{"Upgrade":"Version 3.9.19 from http://sonoff.maddox.co.uk/tasmota/sonoff.ino.bin"}

stat/kitchen_left/UPGRADE : msg.payload : string [22]
Successful. Restarting

stat/kitchen_left/RESULT : msg.payload : string [19]
{"FlashChipMode":2}

But, that results in the same problem as before ... ?

20:39:34 MQTT: stat/kitchen_left/POWER = ON
20:39:41 MQTT: tele/kitchen_left/STATE = {"Time":"2017-02-28T20:39:41", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":36}}
20:39:53 MQTT: stat/kitchen_left/RESULT = {"FlashChipMode":2}

Exception (29):
epc1=0x4021d3d6 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000010 depc=0x00000000

ctx: cont 
sp: 3fff1ff0 end: 3fff2300 offset: 01a0

I also noticed that the other device has flashchipmode 0 ... ?

20:43:04 CMND: flashchipmode
20:43:04 MQTT: stat/kitchen_right/RESULT = {"FlashChipMode":0}

[ecsfang]

Jepp, after some fiddeling back and forth, I have now made a clean flash, restored all settings and flashed via serial a build for 8266, and now it seems to work!
I must have flashed a build made for 8285 (build for the 4CH), and this put the device in a semi-state, i.e. almost working but not quite ... setting flashchipmode and upgrading via OTA didn't help.

Thanks for directing me into the right direction!
Cheers!

[ecsfang]

Hi again,

Is this expected behaviour on the Sonoff LED?
I saw that it blinked (restarted), and the log shows the following, that the device started because of hardware watchdog.
And look at the Uptime, it was not reset by the watchdog, should that not be reset if the device is restarted?

00:00:00 APP: Project sonoff Sonoff (Topic kitchen_left, Fallback DVES_CC09C9, GroupTopic sonoffleds) Version 3.9.22
00:00:00 Wifi: Connecting to AP2 TIGERGATE in mode 11N as kitchen_left-2505...
00:00:15 Wifi: Connect failed with AP timeout
00:00:15 Wifi: Connecting to AP1 TIGERWOLF in mode 11N as kitchen_left-2505...
00:00:20 Wifi: Connected
00:00:20 HTTP: Webserver active on kitchen_left-2505 with IP address 1xx.xxx.xxx.xxx
00:00:22 MQTT: Attempting connection...
07:02:15 MQTT: Connected
07:02:15 MQTT: tele/kitchen_left/LWT = Online (retained)
07:02:15 MQTT: cmnd/kitchen_left/POWER = 
07:02:15 MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"3.9.22", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
07:02:15 MQTT: tele/kitchen_left/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_left-2505", "IPaddress":"1xx.xxx.xxx.xxx"}
07:02:15 MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
07:02:16 MQTT: stat/kitchen_left/RESULT = {"POWER":"ON"}
07:02:16 MQTT: stat/kitchen_left/POWER = ON
07:02:23 MQTT: tele/kitchen_left/STATE = {"Time":"2017-03-03T07:02:23", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":38}}
07:02:30 MQTT: tele/kitchen_left/UPTIME = {"Time":"2017-03-03T07:02:30", "Uptime":1}

[arendst]

I prefer not to call it expected but I've noticed too that the Sonoff Led has an appetite for Hardware Watchdog timeouts. I can't figure out what the reason is and I thought it had something to do with the webserver. That's also the reason I implemented the Info3 message to get more info out of the reboots.

The uptime notice is a nice one as the reboot happened around xx:02:30 the time I increment the hourly uptime counter. As you can see at 07:02:23 it says Uptime 0 and at 07:02;30 it is incremented by one. Just a way of saving precious memory and code for more important features...

[ecsfang]

Ok, then I just continue to monitor the logs and see if I can get some more hints about whats going on :)
Its is not that common (compared to when I flashed the wrong software ... ;)).

And uptime - ok, then I get it - hehe!

Cheers!

[ecsfang]

Hi again!

Yes, still HW Watchdog every now and then, and very often I see the following problem as well:

00:00:00 APP: Project sonoff Sonoff (Topic kitchen_right, Fallback DVES_07261C, GroupTopic sonoffleds) Version 4.0.0
00:00:00 Wifi: Connecting to AP1 TIGERWOLF in mode 11N as kitchen_right-1564...
00:00:15 Wifi: Connect failed with AP timeout
00:00:15 Wifi: Connecting to AP2 TIGERGATE in mode 11N as kitchen_right-1564...
00:00:20 Wifi: Connected

Any idea why? AP 1 is the strongest Wifi, and I think it is the first attempts that fails. Sometime it is "connection timeout", sometime "Incorrect password" and sometimes "AP cannot be reached". Sometime it connects directly, sometime after several attempts. Is there a way of logging what actually happens there?
I'm using Webconfig 4, so I guess that all restarts I see is only because of HWWD.

[arendst]

Perhaps the latest version 4.0.1 can provide more stability as I leave more memory available for normal tasks. If you are using wemo or hue emulation too than this version should also provide more stability as it disables syslog if emulation is active.

The wifi part I've seen once and a while but reflashing or moving the box some inches usually solves it.

You might see more info when logging option 3 or4 is enabled.

[ecsfang]

One thing I noticed was that using MQTT to control the device works fine most of the time (except the sporadic HWWD restarts), but as soon as I try the web-interface the device restarts. Just by entering the ip-address in the browser is usually enough (I guess the browser do some pre-fetching) and that causes the device to restart. I will make a build, removing the web-server and see if that affects the stability.

[arendst]

Does it also happen with 4.0.1? Do you use Hue or Wemo?

[ecsfang]

Yes, but I will double-check - I tried to upgrade to 4.0.1 last night and I _think_ it upgraded ok, and that I still had the same problem. I have some time tonight to play around ... :)

[ecsfang]

I was unclear in my last comment: I'm _not_ using Hue or Wemo (if they are default enabled they are included), but _Yes_, I think it happens with 4.0.1 - that is what I will double-check tonight!
Sorry for the confusion!

[ecsfang]

Ok, now I have checked, and yes, I'm getting the same problem with 4.0.1.
I have now disabled Webserver etc, and it then behaves much better (at least so far), but still I see HWWD now and then (I have two devices who behaves similar, so I suspect the software):

Mar  6 19:58:26 kitchen_left-2505 ESP-MQTT: Attempting connection...
Mar  6 19:58:26 kitchen_left-2505 ESP-MQTT: Connected
Mar  6 19:58:26 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/LWT = Online (retained)
Mar  6 19:58:26 kitchen_left-2505 ESP-MQTT: cmnd/kitchen_left/POWER = 
Mar  6 19:58:26 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.1", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
Mar  6 19:58:26 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar  6 19:58:27 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/RESULT = {"POWER":"ON"}
Mar  6 19:58:27 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/POWER = ON
Mar  6 19:58:34 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/STATE = {"Time":"2017-03-06T19:58:34", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":26}}

I also got one of these:

Mar  6 18:48:49 kitchen_left-2505 ESP-MQTT: Connected
Mar  6 18:48:49 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/LWT = Online (retained)
Mar  6 18:48:49 kitchen_left-2505 ESP-MQTT: cmnd/kitchen_left/POWER = 
Mar  6 18:48:49 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.1", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
Mar  6 18:48:49 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Fatal exception:0 flag:2 (EXCEPTION) epc1:0x40201ee5 epc2:0x00000000 epc3:0x00000000 excvaddr:0x3ffffe60 depc:0x000
Mar  6 18:48:50 kitchen_left-2505 ESP-RTC: (UTC) Mon Mar 06 17:48:50 2017

Status 0 is as follows:

Mar  6 20:08:18 kitchen_left-2505 ESP-APP: Serial logging disabled
Mar  6 20:08:23 kitchen_left-2505 ESP-RSLT: Receive topic cmnd/kitchen_left/status, data size 1, data 0
Mar  6 20:08:23 kitchen_left-2505 ESP-RSLT: DataCb Topic kitchen_left, Group 0, Index 1, Type STATUS, Data 0 (0)
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS = {"Status":{"Module":11, "FriendlyName":"Sonoff", "Topic":"kitchen_left", "ButtonTopic":"0", "Subtopic":"POWER", "Power":1, "PowerOnState":3, "LedState":1, "SaveData":1, "SaveState":1, "ButtonRetain":0, "PowerRetain":0}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS1 = {"StatusPRM":{"Baudrate":115200, "GroupTopic":"sonoffleds", "OtaUrl":"http://1xx.xxx.xxx.xxx:80/api/arduino/sonoff.ino.bin", "Uptime":1, "Sleep":0, "BootCount":102, "SaveCount":146}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS2 = {"StatusFWR":{"Program":"4.0.1", "Boot":31, "SDK":"1.5.3(aec24ac9)"}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS3 = {"StatusLOG":{"Seriallog":2, "Weblog":4, "Syslog":4, "LogHost":"1xx.xxx.xxx.xxx", "SSId1":"TIGERWOLF", "SSId2":"TIGERGATE", "TelePeriod":300}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS4 = {"StatusMEM":{"ProgramSize":364, "Free":572, "Heap":37, "SpiffsStart":940, "SpiffsSize":64, "FlashSize":1024, "ProgramFlashSize":1024, "FlashChipMode":2}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS5 = {"StatusNET":{"Host":"kitchen_left-2505", "IP":"1yy.yyy.yyy.yyy", "Gateway":"1yy.yyy.1.1", "Subnetmask":"255.255.255.0", "Mac":"zz:zz:zz:CC:09:C9", "Webserver":2, "WifiConfig":4}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS6 = {"StatusMQT":{"Host":"192.168.1.72", "Port":1883, "ClientMask":"DVES_%06X", "Client":"DVES_CC09C9", "User":"DVES_USER", "MAX_PACKET_SIZE":512, "KEEPALIVE":15}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS7 = {"StatusTIM":{"UTC":"Mon Mar 06 19:08:23 2017", "Local":"Mon Mar 06 20:08:23 2017", "StartDST":"Sun Mar 26 02:00:00 2017", "EndDST":"Sun Oct 29 03:00:00 2017", "Timezone":1}}
Mar  6 20:08:24 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/STATUS10 = {"StatusSNS":{"Time":"2017-03-06T20:08:23"}}
Mar  6 20:08:25 kitchen_left-2505 ESP-Wifi: Checking connection...
Mar  6 20:08:25 kitchen_left-2505 ESP-Wifi: Connected

[ecsfang]

Now I have flashed the original 4.0.1, with Webserver enabled, and it is just as stable as without ... :S
One HWWD, and one other restart in almost two hours ... AND the Webserver works fine from a browser.
I don't like the idea that software gets better if you flash it several times, but this is how it feels at the moment. Or is the moon just in another place right now? :)
I'll give it some days runtime and count the number of restarts ...

[arendst]

I see you are using logging option 4. Do you use it all the time? If so it impacts the analogwrite interrupts used by the leds.

Do you see a difference in wdts if you use only one of the two led colors? ie color 0022 uses only the warm leds while color 2200 uses only the cold leds. In those cases only one of the two analogwrite ports is being used with half the amount of interrupts.

[ecsfang]

I increased it earlier, but I can lower the logging to 2.
No, I have not tried with different ports (colors), right now both are being used (0x80FF).
But, right now I have 2+ in uptime on both devices - never happened before - touch wood ... ;)
Should it start to generate wdt again I will try that approach and see if it makes a difference.

[ecsfang]

No, didn't see any difference using only one port.
By the way - setting color 0022 ends up as 0021 in the log (and 0080 as 007F):

Mar  7 19:45:21 kitchen_left-2505 ESP-MQTT: stat/kitchen_left/RESULT = {"Color":"0021"}

Apart from the wdt's, I see many exceptions (0, 9 and 28). In this log I only extracted the INFO3 messages from the two devices:

Mar  7 17:31:35 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Power on"}
Mar  7 17:32:14 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Power on"}
Mar  7 17:35:41 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Fatal exception:28 flag:2 (EXCEPTION) epc1:0x402505e7 epc2:0x00000000 epc3:0x00000024 excvaddr:0x00000024 depc:0x00
Mar  7 19:42:14 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Fatal exception:0 flag:2 (EXCEPTION) epc1:0x4021e8a1 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x000
Mar  7 19:42:59 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar  7 19:44:19 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar  7 19:48:47 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar  7 19:49:46 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar  7 19:51:18 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar  7 20:09:45 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Hardware Watchdog"}
Mar  7 20:20:39 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Fatal exception:9 flag:2 (EXCEPTION) epc1:0x4022e15f epc2:0x00000000 epc3:0x00000000 excvaddr:0x401055ab depc:0x000
Mar  7 20:38:42 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Fatal exception:9 flag:2 (EXCEPTION) epc1:0x4022e154 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000036 depc:0x000
Mar  7 20:43:58 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Fatal exception:0 flag:2 (EXCEPTION) epc1:0x4022e240 epc2:0x00000000 epc3:0x00000000 excvaddr:0x401055ab depc:0x000
Mar  7 21:47:39 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Hardware Watchdog"}

Sometimes it can last for quite a while, sometimes there are many wdt in a row ...

[arendst]

Color is adjusted by the dimmer value and as color is 255 and dimmer is 100 some digits do get lost.

Today I used your color code of 80FF for over 8 hours (lots of energy used today) but no wdt or any exception received. In fact it is running for over 24 hours without any anomaly...

It looks like you have a power problem with so many different exceptions.

Do you see this on both of your sonoff led devices?
'''
22:31:51 MQTT: domoticz/in = {"idx":159,"nvalue":2,"svalue":"6"}
22:31:51 MQTT: domoticz/in = {"idx":159,"nvalue":1,"svalue":""}
22:31:51 MQTT: stat/led1/RESULT = {"POWER":"ON"}
22:31:51 MQTT: stat/led1/POWER = ON
22:33:04 MQTT: domoticz/in = {"idx":159,"nvalue":2,"svalue":"6"}
22:33:04 MQTT: domoticz/in = {"idx":159,"nvalue":0,"svalue":""}
22:33:04 MQTT: stat/led1/RESULT = {"POWER":"OFF"}
22:33:04 MQTT: stat/led1/POWER = OFF
22:33:19 MQTT: tele/led1/STATE = {"Time":"2017-03-07T22:33:19", "Uptime":31, "POWER":"OFF", "Wifi":{"AP":2, "SSID":"indebuurt2", "RSSI":76}}
''''

[ecsfang]

Ok, thanks for the explanation, then I know.
Yes, both devices behaves the same, even if one of them (left) is worse then the other.

[ecsfang]

Maybe I just buy 2 new devices and check with them, maybe I just was unlucky and got two from a bad batch ...
In the mean time (postage take a while from over there) I could go through all solder joints etc, so there is no obvious problem on the board itself - it is quite a modern house, and I have no reason to assume noise or something similar on the powerline.
Had it just been one out of the two it would have been much more easy to swallow the idea of bad hardware. But, I as use to say, you get what you pay for ... ;)

[ecsfang]

Been playing around a bit with different settings. Most of the time, the MTBR (Mean Time Between Restarts) is about 5 minutes ... :P Sometimes as low as a couple of seconds, sometimes up to 15-20 minutes (on the "good one", the "bad one" is seldom above 5 min MTBR).

I even had one case where the device was reset (at least module, topic and grouptopic was back to default values (basic/sonoff/sonoffs), but AP's etc was still there), after a restart.

The settings I have been using are Speed=4, Fade=on, Ledtable=on, Dimmer=70, Color=80FF, Syslog=4. I'm not toggling the power nor changing the dimmer, the device has just been turned on.

In my last build, I decreased the ANALOG_WRITE_FREQ down to 100, and right now it is very stable. After 3 hours of runtime I have no yet had a single restart on any of the two devices!
Not only that, but the Webserver is included and has been running flawless as well ... knock wood!
The blinking is hardly visible, but I will try to increase it somewhat tomorrow and see how that goes.

[Nayar]

Think I'm having the same problem maybe here. One of my Sonoff Pow is restarting every 2/3 minutes. My logs on Graylog is like this.

{"Started":"Fatal exception:9 flag:2 (EXCEPTION) epc1:0x40105e99 epc2:0x00000000 epc3:0x00000000 excvaddr:0x3ffea785 depc:0x00000000"}

It was restarting very often last week. Then stabilised, to uptime like 24 hours.

[AlexTransit]

Do you use the button to turn on / off?
I use clasic sonoff
Connected it to the LED driver. (I use a relay to power the driver) (set device to sonoff led.)
Previously there was instability in the work.
Changed the initialization and the problem is gone.
I gave the code, but it was not used.
If you need I can give it again :)

[ecsfang]

Hi, I use a physical button to turn the power on/off to the Sonoff Led.
Please describe the changes you made and why.
In my case, it feels a bit like different flashings give different results. I.e. using different settings (e.g. PWM freq) gives different results, but changing back to "good" values sometimes still give bad result. Right now it works ok, several hours of uptime between HWWDs.
Cheers, Thomas

[AlexTransit]

https://github.com/AlexTransit/Sonoff-Tasmota/tree/Stove-Lamp

[pnuding]

I've got the same issue here.
When it fails it will usually just go blinking on/off without connecting to the network anymore. Sometimes it instead goes cycling through different brightness levels, but that's rare.
Recovery usually requires unplugging it for a few minutes - less than that and it will come back up just as unstable. After being unplugged some minutes It sometimes works just fine for a day or two, and then it keeps falling over every few minutes forcing me to unplug it altogether.
Firmware is 4.04 - me sad :(

[ecsfang]

Hi @AlexTransit!
Thanks for sharing the code! :)
It is not clear to me how you connected the devices, could you share some more info?
As I understand, you are using a Sonoff LED, but you control it by using a Sonoff Basic and let the relay power the Sonoff Led?
In my case I use a normal wall-switch to power the Sonoff Led on/off. What would be the difference?
You said you changed the initialization code - was that in the Sonoff Led?
I noticed that you increased the frequency of the PWM to 4000, right now I'm running 100Hz, 400 and above gives to many watchdogs.
You also changed the ledtable so that "ledtable[i] == i". Why? That is exactly the same as using "ledtable off". With the original ledtable you get a dimmer value that is more adopted to the eye.
I'm just curious how you got it to work, since I'm running out of ideas with my blinking Led ...

[AlexTransit]

Sorry for bad english

I connected (Sonof BASIC) to the driver (https://world.taobao.com/item/520535650186.htm?fromSite=main&spm=a312a.7700824.w4002-15876392919.12.JI4rdg)
PWM of this driver worked for 4kHz
I connected GPIO13 for white light and GPIO14 for warm light standard relay (GPIO12) turns on the driver power
There was a problem with the standard firmware.
Enabled relay processing
Changed the frequency, and everything began to work stably.
If the web server dimmer is enabled less than 100, then occasionally it may blink.
If the webserver = 0 everything works perfectly.

Why did I change the ledtable?
Experimented. Thought to make a very smooth slow inclusion.
But it did not work.

Ask if something is unclear

[arendst]

@ecsfang (Thomas) by using the latest Arduino-esp8266 pwm core files I think the Sonoff Led becomes more stable. In the Experimental repository (https://github.com/arendst/Experimental/tree/master/sonoff-4.0.6a) you find version 4.0.6a with additional core files in the sonoff directory. Just leave them in the sonoff directory and recompile with your current Arduino-esp8266 set and upload to your Sonoff Led.

Please let me know if it brings any stability to your Sonoff Led

[ecsfang]

Hi Theo!
Thanks, I will do that as soon as I have the possibility! I've been following the threads and was looking into this or similar solution to try it out. Right now, with 100Hz etc, it is quite stable, but every now and then it restarts with different reasons. I'll be back with my results!
Thanks again for your efforts and help!
Cheers!

[ecsfang]

Did som small tests, and it appears as before ... :(
(Dimmer 50, fade on, speed 4, ledtable on, but just turning the leds on (not powering on/off).

This is the result (4.0.6k - just changed frequency to 432):

Mar 19 08:42:33 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.6k", "FallbackTopic":"DVES_07261C", "GroupTopic":"sonoffleds"}
Mar 19 08:42:33 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_right-1564", "IPaddress":"192.168.1.238"}
Mar 19 08:42:33 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Software/System restart"}
Mar 19 08:42:33 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.6k", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
Mar 19 08:42:33 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_left-2505", "IPaddress":"192.168.1.239"}
Mar 19 08:42:33 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Software/System restart"}
Mar 19 08:48:20 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.6k", "FallbackTopic":"DVES_07261C", "GroupTopic":"sonoffleds"}
Mar 19 08:48:20 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_right-1564", "IPaddress":"192.168.1.238"}
Mar 19 08:48:20 kitchen_right-1564 ESP-MQTT: tele/kitchen_right/INFO3 = {"Started":"Hardware Watchdog"}
Mar 19 09:01:28 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.6k", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
Mar 19 09:01:28 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_left-2505", "IPaddress":"192.168.1.239"}
Mar 19 09:01:28 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar 19 09:02:26 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.6k", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
Mar 19 09:02:26 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_left-2505", "IPaddress":"192.168.1.239"}
Mar 19 09:02:26 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Hardware Watchdog"}
Mar 19 09:06:36 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.6k", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
Mar 19 09:06:36 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_left-2505", "IPaddress":"192.168.1.239"}
Mar 19 09:06:36 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Blocked Loop"}
Mar 19 09:08:36 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO1 = {"Module":"Sonoff LED", "Version":"4.0.6k", "FallbackTopic":"DVES_CC09C9", "GroupTopic":"sonoffleds"}
Mar 19 09:08:36 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO2 = {"WebserverMode":"Admin", "Hostname":"kitchen_left-2505", "IPaddress":"192.168.1.239"}
Mar 19 09:08:36 kitchen_left-2505 ESP-MQTT: tele/kitchen_left/INFO3 = {"Started":"Fatal exception:0 flag:2 (EXCEPTION) epc1:0x40230e00 epc2:0x00000000 epc3:0x4000467b excvaddr:0x40230d34 depc:0x000

[davidelang]

This may be a silly question, but what is line voltage where you are? The sonoff
modules work to levels far below their rated voltage, but at the lower voltages
'strange things can happen' and the sonoff led is rated to require 200+v line

[ecsfang]

Nothing is silly 😋
It is normal Swedish voltage, 220V.
Again, one of them is worse (left), but both have similar problems. I have two new on its way, but it still feels as a sw problem. Maybe a combination of settings?
Cheers!

[pnuding]

Here also no success - I think the crashes also lead to some corruption of the configuration stored in Flash. At least here after the last crash the Sonoff LED came back with all its settings forgotten.
Interestingly updating to 4.0.6a was only working somewhat after I flashed it with a cable. Updating OTA led to a Sonoff that said it had 4.0.6a but was wildly unstable
(mains voltage here in Barcelona around 218-224V)

[davidelang]

if a OTA update is wildly unstable, it's possible that there is confusion about
the config. Try holding the button for 4 seconds or issuing the reset 1 or reset
2 commands to force it to switch to the compiled-in user_config.h settings

[pnuding]

I've not been able to regain access to the unstable Sonoff - neither the typical wifi config (4x press) or the 4 second reset got it to reconnect or let me configure wifi, it just blinks the LEDs briefly and that's the only response. I'll flash it all over one of these days

[arendst]

And after a few hours with color 407F (dimmer 50) my sonoff led starts rebooting over and over again. I opened the case and found parts really hot around the esp8266. I installed the serial interface and see what happens. It may all come down to overheating...

[ecsfang]

Yesterday I ran several hours without any problems (4.0.7) using 1kHz, color 80FF and dimmer 100. Well, one or two HWWD on the unit that always has been worse of the two I have ... :P
Now, I guess that dimmer 100 result in the driver being on all the time, so I guess that that is not a valid case (from an interrupt point of view), but I guess that the driver would be just as hot (or hotter) as with dimmer 50 ... or?
On the other hand, I had days when it looked good, but after a while, the rebooting started to appear, which again might point to a heating problem ... i.e. the combination of many interrupt and heat might be the core problem.

[arendst]

Changed color to 7F7F (dimmer 50%) max pulses with 50% duty cycle. Mounted the TH10 sensor externally on the Sonoff Led and start monitoring temperature. 49 degrees Celsius and rising while the Sonoff Led Vcc is slowly going down from 3.104 to 3.078 ...

[pnuding]

With 4.06a it was stable while i was on color 88ff, but when later I had it dimmed to 1% it failed after a short amount of time. And true, it had gotten quite hot. In fact I noticed I usually cannot restart it immediately but need to wait some minutes - if heat is the problem that would explain it

[hamwong]

so does issue confirm were due to over heat?

[pnuding]

I think there's something else going on but I am not sure what. I've now ripped out the ESP8266 board from one of the Sonoff LEDs and instead I've wired it up with a generic ESP-12F module outside the case (so removed from any internal heat sources) and it wasn't stable either. Within minutes I had it in a state where I needed to reflash from a computer :(
Could it be that we get interference from the (relatively high voltage) output circuit and that messes things up when reading/writing flash?
Maybe one could try an experimental version that turns the LEDs off and waits for a moment before accessing flash

[pnuding]

OK, looks like it's bad power. At least on my two Sonoff LED the 3,3V power supply to the ESP8266 board is dropping to to low voltages every now and then, which is when things fall apart. That issue might have always been there and I just didn't notice because I ran it very briefly before flashing. I've tried with a proper power supply and it has so far run for a full day without trouble... Will still experiment a bit more and come back here

[ecsfang]

Do you mean bad power on the input side of the Sonoff LED, or bad power out from the internal power supply to the ESP?
I just received two new units from ITead, maybe I should measure a bit on these before I try to use them.
I have not really checked the input power, but mine are connected to mains in my house, and in general this is a very stable power source (220V/50Hz).
As the two new units are new and not flashed with Tasmota, I could also try and run the original software (EWeLink) for a while and see how it behaves.

[pnuding]

Bad power from the internal power supply to the ESP - if things are working mine are around 3V, if things go bad they dive as low as 1.8V or oscillate which sends the ESP into a frenzy of aborted startups (and the LEDs go flashing around in weird patterns).

I suspect that interference from the PWM of the LED power outputs is messing with the power supply:

I first tried with a small chinese 3.3V switch-mode power supply that I've had lying around. It powers an ESP just fine but when I connected GPIO12/14 to the driver it started oscillating wildly.
Running it off a lab power supply in contrast worked like a charm.

It might be that some PWM frequencies resonate more with the power supply and that's why changes there made a difference in the past.
If you check the new Sonoff LEDs with the original firmware, can you find out at what frequency they drive the PWM?

[ecsfang]

Sure, I will try to do that :)

[arendst]

@ecsfang please do.

I now also have an unstable situation caused by esp8266 power supply. I monitored both temperature (th10), netvoltage (pow) and adc voltage of Sonoff led. As my netvoltage is low (<215V) it takes longer before it fails. As soon as I power up the led to color 4080 the Vcc starts lowering slowly eventually leading to reboots and finally hang. The temperature is then around 54C.

Apart from the fact that it gets hot the 3V3 for the esp8266 is just not stable.

I suggest to leave at least one of the new units running with itead software and try to find out the frequencies and volrtages at all possible dimmer settings.

[hamwong]

my sonoff LED turn more unstable when upgrade firmware from 4.0.5 to 4.1.1
LED mostly turn 3 times more to "freeze" and power reset is required.
I have been disable most of addon in user_config.h like i2c, remote, ws2812 for LED

[hamwong]

I think it's lot more than 3 times, as you can see, VCC drop from 3.1 to 2.6 in 3 minutes, than it restart by itself, while later, it will turn freeze, case not that worse when in firmware 4.0.5

21:50:02 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-02T21:50:02", "Uptime":0, "Vcc":3.126, "POWER":"OFF", "Wifi":{"AP":2, "SSID":"Ham2", "RSSI":66}}
21:50:03 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON"}
21:50:03 MQTT: stat/sonoff-LED/POWER = ON
21:51:03 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-02T21:51:03", "Uptime":0, "Vcc":2.840, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham2", "RSSI":66}}
21:52:03 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-02T21:52:03", "Uptime":0, "Vcc":2.658, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham2", "RSSI":64}}

[AlexTransit]

You are using Sonoff led device?
Can the problem in hardwire?

I use myself Sonoff Basic
Connected to the driver with a dimmer ( set device as Sonoff led)
I have not got problems.
Only if the dimmer> 15 <100 then the temperature of the diodes is higher

[arendst]

It's not a firmware error. It's a hardware error caused by crappy power supply design feeding the onboard ESP8266. It gets worse when the PWM frequency is raised to 1000Hz as happened in later versions. In 4.0.5 it was set to 432Hz.

[hamwong]

I understand it not your software issue, just try to let you know case get worse when PWM set to 1000Hz in my case, in fact kind of wonder, @ecsfang did you test on your Sonoff LED with original firmware have same issue or not? if correct PWM frequency can avoid this issue happen, unless we able to found the correct PWM freq, I might go for a try as @AlexTransit advised, actually I have the same thinking by past few days as no matter in 4.0.5 or 4.1.1 all have unstable issue, just the matter of how quick it will happen, or should I try will lower PWM freq first? what is the lowest PWM value which can be acceptable?

[hamwong]

Hi, @AlexTransit
do you mind share how do you setup sonoff basic with Sonoff LED strip? did you modify the code when set as LED? as GPIO should be difference...
sonoff LED turn so unstable after about 2 weeks operation (it's on at 50% dimmer for about 15 hours per day).

[AlexTransit]

I took the driver with a dimmer (radio frequency remote control)
The fall of control.
Took the Sonoff base
Connected GIPO 13 and 14
The built-in relay disconnects the power from the driver.
Frequency FPM 4000
And everything works fine.

If the dimmer is> 15 or <100, the diodes become very hot.
Most likely, the driver does not have PFC
Use 10% or 100% :)

[ecsfang]

(Sorry - I turned my values upside down, but now the text should be correct! :))

Ok, now I have been measuring on a virgin Sonoff LED.
The frequency is always about 910Hz, and the pulse typically looks like this (dimmer at about 50%):

In the eWeLink-app, there are 21 steps on the dimmer, and for each step there is one first pulse which differs in length, and they are all followed by a small pulse for 76us (except 3 steps: 11, 14 and step 19).
The first pulse have the following length for the different step:
Correction, this is from 100% (step 21) down to step 1 (low dimmer)!
52, 226, 308, 255, 274, 290, 322, 414, 364, 394, 492, 460, 492, 538, 586, 632, 708, 804, 880, 892 and 940 us.
(Note that a more correct value is 76us added to these numbers, except for step 11, 14 and 19 that is.)

The picture shows step 12, and a more correct value on the pulsewidth is 394us (not 404us as shown in the picture.)

The voltage starts at about 142V at low dimmer and goes down to about 117V from step 12 and onwards (i.e. step 12 up to 21 (100%) all start from 117V). During the pulse, the voltage drops immedietely down to 84V in all cases, and then continue to fall down during the pulse. At step 1, the voltage goes down to about 10V, at step 12 down to 36V and at 100% down to about 60V.

The color can in the app only be changed between 00FF, FF00 and FFFF, i.e. I can't independantly change the color. It is either on or off (warm and/or cold), and the pulse looks the same for each channel.

Is there something else I should try to measure while I have access to an oscilloscope (which I just have borrowed for this)?

Cheers,
Thomas

[ecsfang]

I have not yet (during about 5 hours playing with it) seen any flickering at all, but _once_ while I was away, the led had turned off and the device was offline. Toggling the power to the device turned it on again .. hm.

[ecsfang]

Hi @arendst and @pnuding, any comments on this? I still have the scope so I could assist in measuring something else if needed :)

[pnuding]

I've had a look at where the 3.3V are coming from. It's a 7533-1 linear regulator, which is specified for just 100mA, rather tight for the current spikes of the 8266. Also it runs on roughly 13V input, so it has to dissipate more than 1 Watt. I'll do some logging of input & output voltage tomorrow while it's running but my guess is that it's choking on its own heat and thus dropping the output...
Could it be that the original FW is using power save modes more aggressively and hence not stressing the regulator that much?

[arendst]

@ecsfang Thomas nice info! So it seems to use PWM at 910Hz what can easily be changed in my software if it would made any difference...

It would be nice to see what my software does if you select color FF00 or 00FF and change the dimmer every 5 steps as seems to be the case wirh iTead. You could even change my frequency for version 4.1.x in sonoff.ino line 107 #define PWM_FREQ from 100 to 910.

Remember that my color values will change on every dimmer setting as that's how the Arduino Analogwrite PWM pulse period is defined.

[ecsfang]

Sure, I will update this unit with Tasmota and do a similar measurement with 910Hz.

[arendst]

@ecsfang from you comment about FF00, 00FF and FFFF it makes sense to select only equal colors using my software. So on your most crappy Sonoff Led try to use only color 00xx, xx00 or xxxx instead of color like 80FF. This makes both PWM outputs either equal or one of them is off which might lead to less temperature and better power management. I've been running with color bfbf for a while and I see the VCC power being a lot more stable (above 3.150V) then it was with different colors where it went down to 2.920 before it broke down.

[ecsfang]

Hi @arendst !
Yes, I have been running with 00FF for quite a while (two weeks?) on my original SonoffLEDS, and it works quite well. Restarts maybe every second hour or so, but I hope we can tweak it a little bit more ;)

I have now flashed Tasmota (changed freq to 910Hz) into the unit I'm measuring on, and one thing that strikes me right away is the dropping of the voltage to the leds.
The following two pictures are with 10% and 50% dimmer, and the timing etc looks good. But look at the lower voltage (i.e. when the led is turned off). With the original software this lower voltage was very stable, it went down to 10V with the lowest dimmer, and about 40V at about 50%. In this case, the voltage is fluctuating, not randomly, but swings between 10 up to 84V ... hm.

This is the 10% (dimmer 10) case:

And dimmer 50 case:

[ecsfang]

Note that this pattern repeats every 20ms, which corresponds to 50Hz, i.e. out mains frequency.
This pattern I didn't see at all with the original sw, and right now my unit want talk to me, just locks and restarts ... :(

[arendst]

Interesting! I need to investigate arduino analogwrite...

[ecsfang]

Hi again!
Now I've taken it apart and measured on the actual output from the ESP down to the driver board.
GPIO 14 and 12 looks almost identical between eWeLink and Tasmota apart from the extra spike that can be seen in the first picture above. This could be interpreted as eWeLink sw first quickly turn on and off the pin, and then 76us later turn on the actual PWM pulse.
The Voltage on the GPIO pins (12+14) is only 680mV, but is a nice square wave in both cases.
Apart from GND and 3.3V, there are also the 3 other GPIOS (4, 5 and 15). In both cases, these pins seems to follow the GPIO 12 and 14, but in the eWeLink case, these pins seems more stable. But in the Tasmota case, they seems to be "floating". E.g. the voltage level goes from 640mV (1% dimmer) down to 150mV at 100%. In the eWeLink case, the voltage is stable at 680mV.
How are the pins defined? Could it be that they are undefined?
I configured these 3 pins as LED2-4, and the output is now well defined (0V), and so far (knock wood) the unit has been stable (using color 3475) ...
I have defined the pins on my other Sonoff LEDs, and will check the syslog later this evening, now I have to leave them off for a while ...

Still can't explain the changing voltage (50Hz) during the off cycle ... I also measured on my second new device (which I will keep as a reference with the eWeLink software), and it dropped the voltage fine and steady as in the first picture - and the Tasmota device goes up and down as in the last two pictures. Strange ...

[arendst]

Sounds promising! When the GPIO 4, 5 and 15 are not used they are not configured and most probably float as you noticed. I'll try the same with my unit and see how it goes.

In the meantime I've just borrowed an old Tektronix 2465 oscilloscope we used to use to calibrate mainframe clock timing and disk head cateye alignment (that old? Yes that old)

This gives me also a view of things and maybe I can do something about it in software.

[ecsfang]

Great!

I was also using an "old" Tektronix, a 3032 ... good old workhorses they are ;)
For the LEDs, I just measured the voltage over the led (cutting through the red/white/black wires), and for the ESP, I soldered a pin to the GND on the board.
The pinout for the ESP-board corresponds to the following picture (if seen from the underside of the driver board): http://dl.itead.cc/sonoff_led/PWMLED_ESP8266_Module_Wiring_Instruction.png (rx/tx is of course on the other side)

Cheers,
Thomas

[arendst]

Just took the following pictures showing me reflected and Tasmota with 910Hz PWM and dimmer 50% almost equal to iTead:

The same but now with both channels set to same color and lower voltage but without your 50Hz component.

So I can't see your 50Hz interference.

[ecsfang]

Looks much better - and this was measured over the leds?
E.g. between red and white/black wire?
I don't (yet) want to reflash the single unit with eWeLink, but maybe I could try one of the older units and check there.
Anyhow, I can't explain how this could be, since the PWM signals looks ok. Had it not been that it looked ok before I flashed Tasmota, I would have blamed a faulty device 😕
And, nor do I see this on the power or ground into the ESP-board, so I don't see the consequences.
Lets look somewhere else... 😝

[arendst]

Yes with open box and just where the three wires are connected so over the leds (Red gnd).

Did you perhaps moved the box after flashing tasmota near to another 50Hz device?
How is your test with color 3475 and three fake leds doing?

[ecsfang]

@arendst, the setup was the same, same wires, same mains outlets etc, just different software.
But I'll try to reproduce or find the source of the disturbance. As of now, it is always there, no matter how I measure - so it's a pitty I can't restore the original image and verify (at least for myself) ...

I'm not at home, so I have to wait until later tonight to run some more longer test with the new settings.
And with your setup - have you noticed any difference when initializing the 3 GPIOs?

[arendst]

If you still have one original Sonoff Led with software left you could try to make a copy of the software and blow in the just tasmotaed one.
I use python and the tool https://github.com/espressif/esptool with the following command line to make a copy of the complete flash (1GB):

esptool.py --port com3 read_flash 0x00000 0x100000 image1G.bin

and write it with:

esptoolpy --port COM3 write_flash 0x00000 image1G.bin

Although I wasn't able to use the ewelink app though. YMMV.

[ecsfang]

Sure thing! Since I have two units to play with, I could at least experiment a bit and try to restore the device!
Thanks for the tip!

[pnuding]

Regarding the 3.3V voltage stability: As suspected the 7533-1 LDO eventually buckles under the heat and drops the output - its input stays fairly stable around 11-13V.
So if after all the waveform magic there's still stability issues it might be an idea to swap that for something bigger.

I also checked what was happening to the Sonoff LED that I had shot into being unresponsive. Indeed the flash configuration was borked and it wasn't resettable via the button, only a "reset 1" via serial finally cleaned it up

[ecsfang]

No, there is more into this then just floating GPIOs. In the "nice&kind" case (e.g. color 00ff) I was able to run my two old units the whole evening without any restarts, so according to this little test it seems to be a _little_ bit better. But using a more random color (like 3475) caused at least my "worst" unit to restart and shutdown quite frequently (sometimes I had to powercycle the unit to get it up and running again).
Hopefully I will be able to do a more thoroughly examination of the boards during the weekend, both trying to restore original sw and looking for the 50Hz interference.
Maybe changing the LDO is one way forward as @pnuding is suggesting?
(Fortunately this is fun and educational - otherwise I would have thrown away the crap ... ;))

[arendst]

As iTead software only supports FF00, 00FF or FFFF I suggest you only use equal colors during testing to stay as near as possible to the ITEAD situation. So you should not use colors like 3475 but only 3434 or 7575 or 0075 or 7500 etc. during testing.

It would be great if all my color options would work but apparently that's a bridge too far...

[hamwong]

When I set 910 at 4.1.1 and dimmer on 100% (Color FF00), LED stable for almost all day, at least it no longer offline for 1 day and VCC stable at between 3.029 - 3.049, mostly at 3.032, I will try dimmer 50% for coming day and see will it turn unstable again.

[hamwong]

when dimmer set to 50, VCC immediately drop

00:04:37 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:04:37", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:05:37 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:05:37", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:06:37 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:06:37", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:07:37 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:07:37", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:08:42 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:08:42", "Uptime":36, "Vcc":3.049, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:09:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:09:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:10:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:10:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:11:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:11:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:12:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:12:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
00:13:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:13:43", "Uptime":36, "Vcc":3.039, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:14:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:14:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:15:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:15:43", "Uptime":36, "Vcc":3.028, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:16:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:16:43", "Uptime":36, "Vcc":3.024, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":82}}
00:17:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:17:43", "Uptime":36, "Vcc":3.028, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:18:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:18:43", "Uptime":36, "Vcc":3.028, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:19:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:19:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:20:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:20:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:21:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:21:43", "Uptime":36, "Vcc":3.030, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:22:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:22:43", "Uptime":36, "Vcc":3.029, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:23:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:23:43", "Uptime":36, "Vcc":3.031, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:24:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:24:43", "Uptime":36, "Vcc":3.028, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:25:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:25:43", "Uptime":36, "Vcc":3.028, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:26:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:26:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
00:27:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:27:43", "Uptime":36, "Vcc":3.030, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":84}}
00:28:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:28:43", "Uptime":36, "Vcc":3.032, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:29:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:29:43", "Uptime":36, "Vcc":3.030, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:30:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:30:43", "Uptime":36, "Vcc":3.030, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:31:43 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:31:43", "Uptime":36, "Vcc":3.030, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:33:56 CMND: dimmer 50
00:33:56 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":50, "Color":"7F00"}
00:34:03 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":50, "Color":"7F00"}
00:34:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:34:45", "Uptime":36, "Vcc":2.962, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:35:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:35:45", "Uptime":36, "Vcc":2.929, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:36:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:36:45", "Uptime":36, "Vcc":2.918, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:37:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:37:45", "Uptime":36, "Vcc":2.918, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:38:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:38:45", "Uptime":36, "Vcc":2.916, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
00:39:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:39:45", "Uptime":36, "Vcc":2.914, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:40:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:40:45", "Uptime":36, "Vcc":2.910, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
00:41:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:41:45", "Uptime":36, "Vcc":2.910, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":82}}
00:42:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:42:45", "Uptime":36, "Vcc":2.888, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":94}}
00:43:19 MQTT: stat/sonoff-LED/RESULT = {"POWER":"OFF"}
00:43:19 MQTT: stat/sonoff-LED/POWER = OFF
00:43:19 MQTT: stat/sonoff-LED/RESULT = {"POWER":"OFF", "Dimmer":0, "Color":"0000"}
00:43:20 MQTT: stat/sonoff-LED/RESULT = {"POWER":"OFF", "Dimmer":0, "Color":"0000"}
00:43:28 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON"}
00:43:28 MQTT: stat/sonoff-LED/POWER = ON
00:43:28 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":30, "Color":"4C00"}
00:43:36 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":30, "Color":"4C00"}
00:43:45 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T00:43:45", "Uptime":36, "Vcc":2.670, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}

Light went off due to no motion detected, when on again, LED turn offline immediately
Also tried dimmer 10, also offline after short while,
but looks works when below 10, I tried dimmer 9

01:15:50 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":9, "Color":"1600"}
01:15:50 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":9, "Color":"1600"}
01:16:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:16:34", "Uptime":0, "Vcc":3.038, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
01:17:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:17:34", "Uptime":0, "Vcc":3.006, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:18:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:18:34", "Uptime":0, "Vcc":2.980, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
01:19:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:19:34", "Uptime":0, "Vcc":2.963, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:20:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:20:34", "Uptime":0, "Vcc":2.950, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:21:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:21:34", "Uptime":0, "Vcc":2.936, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:22:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:22:34", "Uptime":0, "Vcc":2.884, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":84}}
01:23:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:23:34", "Uptime":0, "Vcc":2.911, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:24:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:24:34", "Uptime":0, "Vcc":2.905, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:25:19 APP: Serial logging disabled
01:25:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:25:34", "Uptime":0, "Vcc":2.888, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":100}}
01:26:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:26:34", "Uptime":0, "Vcc":2.888, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:27:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:27:34", "Uptime":0, "Vcc":2.886, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
01:28:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:28:34", "Uptime":0, "Vcc":2.880, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
01:29:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:29:34", "Uptime":0, "Vcc":2.876, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
01:30:12 MQTT: stat/sonoff-LED/RESULT = {"POWER":"OFF"}
01:30:12 MQTT: stat/sonoff-LED/POWER = OFF
01:30:12 MQTT: stat/sonoff-LED/RESULT = {"POWER":"OFF", "Dimmer":0, "Color":"0000"}
01:30:12 MQTT: stat/sonoff-LED/RESULT = {"POWER":"OFF", "Dimmer":0, "Color":"0000"}
01:30:20 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON"}
01:30:20 MQTT: stat/sonoff-LED/POWER = ON
01:30:20 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":30, "Color":"4C00"}
01:30:26 MQTT: stat/sonoff-LED/RESULT = {"POWER":"ON", "Dimmer":30, "Color":"4C00"}
01:30:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:30:34", "Uptime":0, "Vcc":2.815, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
01:31:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:31:34", "Uptime":0, "Vcc":2.732, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
01:32:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:32:34", "Uptime":0, "Vcc":2.693, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:33:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:33:34", "Uptime":0, "Vcc":2.806, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:36:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:36:34", "Uptime":0, "Vcc":2.924, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:37:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:37:34", "Uptime":0, "Vcc":2.861, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:38:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:38:34", "Uptime":0, "Vcc":2.858, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:39:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:39:34", "Uptime":0, "Vcc":2.848, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:40:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:40:34", "Uptime":0, "Vcc":2.840, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":88}}
01:41:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:41:34", "Uptime":0, "Vcc":2.844, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:42:34 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:42:34", "Uptime":0, "Vcc":2.844, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:43:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:43:34", "Uptime":0, "Vcc":2.850, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:44:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:44:35", "Uptime":0, "Vcc":2.832, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:45:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:45:35", "Uptime":0, "Vcc":2.836, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:46:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:46:35", "Uptime":0, "Vcc":2.831, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:47:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:47:35", "Uptime":0, "Vcc":2.818, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":90}}
01:48:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:48:35", "Uptime":0, "Vcc":2.836, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}
01:49:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:49:35", "Uptime":0, "Vcc":2.863, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":84}}
01:50:35 MQTT: tele/sonoff-LED/STATE = {"Time":"2017-04-07T01:50:35", "Uptime":0, "Vcc":2.858, "POWER":"ON", "Wifi":{"AP":2, "SSID":"Ham", "RSSI":86}}

[pnuding]

Without hardware modifications I still have issues running 4.1.3.
Yesterday I've now ripped out the 7533-1 regulator of one of the Sonoff LED I have and connecter a big (TO220 case) 1117 regulator outside the case. As expected it gets ridiculously hot but so far the device has been stable at low dimmer settings and an odd colour setting for more than 24 hours.
If this remains stable I'll use some buck converter instead of the linear regulator so we don't get this much heat in the first place.
I'll report back again if it's still stable for the next days

[ecsfang]

Good news, I have some LM1117 in the post coming my way; I thought of doing the same experiment. I haven't thought about the heat though...
I have also been measuring the voltage, and it is obvious that after a while, the temperature rises which result in lower voltage, and bigger problems I have - and that it is quite big difference between different devices.

[hamwong]

I believe itead also realize hardware is not designed well, LED series have been stop selling on web or taobao(Official) since few weeks ago.

[hamwong]

@pnuding @ecsfang will you mind create a video howto or pic howto with detail step so people with no electronic knowledge can replicate your modification way? a simple electronic schematic is difficult for us.

[pnuding]

I'll take a few pictures, sure! so far 47 hours uptime and counting... :)

[ecsfang]

Ok, I'll try to explain how I did. Please note that this shows just how I did this, and I take no responsibility for any failures or other problems that might occur if you try to repeat what I have done.

As mentioned earlier I bought some LM1117mp-3.3 in a SOT package (since it was very similar to the original 7533 in form and size, but it is a little bit larger and two pins are swapped (Vout and Vin), so I could not just replace the driver just like that.

First picture shows the original 7533 in place, note that I have removed the capacitor (the two holes in the circle - it is a 470uF 10V connected between GND and Vout, i.e. on the 3.3V side).

Second picture shows the pcb with the 7533 removed and the pads cleaned somewhat,

The SOT package has three pins on one side (GND, Vout and Vin). The big tab on the other side is also connected to the Vout. To simplify for me, I just removed the middle pin (the smaller Vout pin) and soldered GND and Vin to the old pads.
_Remember that Vout and Vin are swapped, so the right-most pin should be connected to the middle pad, and the middle pin (tab) connected to the rightmost pad on the pcb._

And then I added a small wire, connecting the Vout to the big tab on the device. It was easier to solder the wire to the hole instead of to the old pad). This shows the final placement of the LM1117 on the pcb.

And finally, I just had to reinsert the capacitor _(note the orientation - the minus (-) side of the capacitor should be connected to gnd)_.

Put it all back into the box and connect the LEDs and mains and voilá!
Right now I have just been running for almost 2 hours, but the voltage is VERY stable at about 3.16V! With the old 7533, the voltage sometimes dropped down to 2.6V and was very affected by temperature: turn the LEDs on, and you could really see in real-time the voltage drop ...

So, now only remains to run it for a longer time, and see how it copes, so far no restarts at all :)
I did ran one yesterday for several hours to check the temperature on the LM1117. Yes, it got hot, but not burning hot - I had no thermometer, but I could touch the device without burning myself, it just felt hot, so I don't think it gets hotter than the old one.
This was quite "un-scientifically" done - and be careful - _never put your fingers close to the pcb without disconnecting the mains first!_

17:57:17 MQTT: tele/kitchen_left/STATE = {"Time":"2017-04-21T17:57:17", "Uptime":0, "Vcc":3.160, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":56, "APMac":"90:94:E4:39:B1:2C"}}
18:02:00 MQTT: tele/kitchen_left/UPTIME = {"Time":"2017-04-21T18:02:00", "Uptime":1}
18:02:17 MQTT: tele/kitchen_left/STATE = {"Time":"2017-04-21T18:02:17", "Uptime":1, "Vcc":3.160, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":56, "APMac":"90:94:E4:39:B1:2C"}}
18:07:18 MQTT: tele/kitchen_left/STATE = {"Time":"2017-04-21T18:07:18", "Uptime":1, "Vcc":3.160, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":54, "APMac":"90:94:E4:39:B1:2C"}}
18:12:18 MQTT: tele/kitchen_left/STATE = {"Time":"2017-04-21T18:12:18", "Uptime":1, "Vcc":3.160, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":52, "APMac":"90:94:E4:39:B1:2C"}}
18:17:18 MQTT: tele/kitchen_left/STATE = {"Time":"2017-04-21T18:17:18", "Uptime":1, "Vcc":3.160, "POWER":"ON", "Wifi":{"AP":1, "SSID":"TIGERWOLF", "RSSI":56, "APMac":"90:94:E4:39:B1:2C"}}

[ecsfang]

It should also be noted that I still have seen some restart when I play with different color combinations.
Right now I'm just using "color 00FF" - which failed every now and then with the 7533, but so far (knock wood) there has been no restarts at all with this configuration ("wife happy").
So, these restarts (different color combinations) are not (as I can see) related to the voltage, but rather some timing problem.

I'll update after the weekend with my findings - if I see any other problems, or if it is stable enough for me :)

Cheers,
Thomas

[pnuding]

Thanks Thomas! I've only managed crappy pictures of my setup. Yours are much clearer!

What I've done:
Since my 1117 is the big TO220 format, I couldn't nicely solder it in place.
So I attached three wires to it and connected them to the solder pads of the 7533-1.
Again, important to remember that the input and output pins of the 1117 are switched compared to the 7533-1.
So I connected
-the left pin of the 1117 to the left solder pad
-the right pin of the 1117 to the middle solder pad
-the middle pin of the 1117 to the right solder pad

It's been almost a week now and I've not had a single restart. I use color 88ff here which previously gave me boatload of trouble and the device has been through at least a hundred brightness changes

[pnuding]

PS: I wrapped the wire connections to the 1117's pins in shrink tube and also the whole regulator so I could drop it into the case after all. Since it would inevitably touch other components I needed it to be insulated nicely.

[ecsfang]

Thanks @pnuding, I had the opportunity to use a microscope, and took some pictures through the eyepiece with my handheld Xperia phone. A bit hard to get the angle right, but they came out quite ok :)
So far mine (I modified all 4 units I have) has also been very stable, not a single restart yet - still not so many hours runtime but enough to say that it is much better than before ;)

[arendst]

@ecsfang and @pnuding can we conclude that changing the 7533 by a better suited voltage regulator solves the issues observed?

If so I'll add your great pictures and workaround to the Wiki for all to know.

[pnuding]

Hey Theo, still running stable here so yes, I think it's now safe to declare this a good solution. Yay! :)

[ecsfang]

Hi Theo!
Yes, in my case it is much better, I've been running for some week now, and it is much more stable!
But (isn't there always a but?), I've seen some sporadic restarts (on one unit of two, few = counted on my left hands fingers) which according to the log was due to HWWD (hardware watchdog). Why I see these I don't know, but I don't think they are related to the voltage. The voltage is very very stable (+/-.05V).
In my opinion you could close this issue for now.
Best regards,
Thomas

[timtimsson]

Hi,
i changed also the 7533 to a LM1085IT-3.3(TO220) - it was not so easy for me , becase TO220 ist very big and the pins was also changed - but now it works perfect....

[arendst]

It took a while but today I finally installed a TS1117 the @ecsfang Thomas way and it seems to hold just fine. Power is indeed stable now at 3.226V

Thnx for your experiments and great pictures

[arendst]

Well I'm afraid my TS1117 is not up for the task.... First I ran Color 00FF when the device got as hot as 60 degress C. When I tried to change color it started to reboot with status "power on" so it's not a software reboot.

After it was cooled down to 37 degrees I tried again with color 0016 and at 40 degrees it started to reboot again.

Looking at the specs of the TS1117 I see it only allows 12V input voltage so that's probably too low. I'll order a LM1117 in TO-220 package and try again :-(

[pnuding]

You can also use one of those little MP2307-based step down converter modules they sell from china. They handle even such steep input voltage differences nicely without heat. They're rapidly becoming my favorite way of powering ESP8266s and with the adjustable output voltage they're also useful for all sorts of other cases

[arendst]

Today I replaced the failing TS1117 with a LM1085-3.3 in TO-220 package.

It seems to work for at least two hours with temperature rising to 54 degrees C. Will continue to monitor...

[ageorgios]

Is the LM1117 working with high temperatures?
Are there any other alternatives?

[arendst]

The LM1085 is working ok with 54 C but that's quite hot for led light...

[ageorgios]

Accidentally bought this one L1117:
Does it do the work? If yes how to make the connections?