Fixed: Failing Sonoff LED - Upgrade power regulator #122
Comments
|
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. |
|
Hi! I tried setting the mode, and then updated using OTA (from smadds binaries): But, that results in the same problem as before ... ? I also noticed that the other device has flashchipmode 0 ... ? |
|
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! Thanks for directing me into the right direction! |
|
Hi again, Is this expected behaviour on the Sonoff LED? |
|
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... |
|
Ok, then I just continue to monitor the logs and see if I can get some more hints about whats going on :) And uptime - ok, then I get it - hehe! Cheers! |
4.0.0 20170303 * Add define to remove config migration code for versions below 3.0 (See Wiki-Upgrade-Migration path) * Free memory by switching from String to char[] * Raised Sonoff Led PWM frequency from 200Hz to 432Hz in search of stability (hardware watchdog timeouts) (#122) * Increase message size and suggested minimum MQTT_MAX_PACKET_SIZE to 512 (#114, #124) * Remove runtime warning message regarding MQTT_MAX_PACKET_SIZE too small as it is now moved to compile time (#124) * Fix possible panics with web console and http commands while UDP syslog is active (#127) * Add optional static IP address (#129) * Add define ENERGY_RESOLUTION in user_config.h to allow user control over precision (#136)
|
Hi again! Yes, still HW Watchdog every now and then, and very often I see the following problem as well: 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? |
|
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. |
|
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. |
|
Does it also happen with 4.0.1? Do you use Hue or Wemo? |
|
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 ... :) |
|
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! |
|
Ok, now I have checked, and yes, I'm getting the same problem with 4.0.1. I also got one of these: Status 0 is as follows: |
|
Now I have flashed the original 4.0.1, with Webserver enabled, and it is just as stable as without ... :S |
|
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. |
|
I increased it earlier, but I can lower the logging to 2. |
|
No, didn't see any difference using only one port. 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: Sometimes it can last for quite a while, sometimes there are many wdt in a row ... |
|
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? |
|
Ok, thanks for the explanation, then I know. |
|
Maybe I just buy 2 new devices and check with them, maybe I just was unlucky and got two from a bad batch ... |
|
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! |
|
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.
It was restarting very often last week. Then stabilised, to uptime like 24 hours.
|
|
Do you use the button to turn on / off? |
|
Hi, I use a physical button to turn the power on/off to the Sonoff Led. |
4.1.3 20170410 * Add user configuarble GPIO to module S20 Socket and Slampher * Add support for Sonoff SC (#112) * Set PWM frequency from 1000Hz to 910Hz as used on iTead Sonoff Led firmware (#122) * Set Sonoff Led unconfigured floating outputs to 0 to reduce exceptions due to power supply instabilities (#122) * Add Access Point Mac Address to Status 11 and Telemetry (#329) * Fix DS18B20 negative temperature readings (#334)
4.1.3 20170410 * Add user configuarble GPIO to module S20 Socket and Slampher * Add support for Sonoff SC (#112) * Set PWM frequency from 1000Hz to 910Hz as used on iTead Sonoff Led firmware (#122) * Set Sonoff Led unconfigured floating outputs to 0 to reduce exceptions due to power supply instabilities (#122) * Add Access Point Mac Address to Status 11 and Telemetry (#329) * Fix DS18B20 negative temperature readings (#334)
|
Without hardware modifications I still have issues running 4.1.3. |
|
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 believe itead also realize hardware is not designed well, LED series have been stop selling on web or taobao(Official) since few weeks ago. |
|
I'll take a few pictures, sure! so far 47 hours uptime and counting... :) |
|
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.
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á! So, now only remains to run it for a longer time, and see how it copes, so far no restarts at all :) |
|
It should also be noted that I still have seen some restart when I play with different color combinations. I'll update after the weekend with my findings - if I see any other problems, or if it is stable enough for me :) Cheers, |
|
Thanks Thomas! I've only managed crappy pictures of my setup. Yours are much clearer! What I've done: 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 |
|
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. |
|
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 :) |
|
Hey Theo, still running stable here so yes, I think it's now safe to declare this a good solution. Yay! :) |
|
Hi Theo! |
|
Hi, |
arendst
changed the title
|
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 |
|
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 :-( |
|
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 |
|
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... |
|
Is the LM1117 working with high temperatures? |
|
The LM1085 is working ok with 54 C but that's quite hot for led light... |
|
Accidentally bought this one L1117:
|
4.0.0 20170303 * Add define to remove config migration code for versions below 3.0 (See Wiki-Upgrade-Migration path) * Free memory by switching from String to char[] * Raised Sonoff Led PWM frequency from 200Hz to 432Hz in search of stability (hardware watchdog timeouts) (arendst#122) * Increase message size and suggested minimum MQTT_MAX_PACKET_SIZE to 512 (arendst#114, arendst#124) * Remove runtime warning message regarding MQTT_MAX_PACKET_SIZE too small as it is now moved to compile time (arendst#124) * Fix possible panics with web console and http commands while UDP syslog is active (arendst#127) * Add optional static IP address (arendst#129) * Add define ENERGY_RESOLUTION in user_config.h to allow user control over precision (arendst#136)
4.1.3 20170410 * Add user configuarble GPIO to module S20 Socket and Slampher * Add support for Sonoff SC (arendst#112) * Set PWM frequency from 1000Hz to 910Hz as used on iTead Sonoff Led firmware (arendst#122) * Set Sonoff Led unconfigured floating outputs to 0 to reduce exceptions due to power supply instabilities (arendst#122) * Add Access Point Mac Address to Status 11 and Telemetry (arendst#329) * Fix DS18B20 negative temperature readings (arendst#334)
4.1.3 20170410 * Add user configuarble GPIO to module S20 Socket and Slampher * Add support for Sonoff SC (arendst#112) * Set PWM frequency from 1000Hz to 910Hz as used on iTead Sonoff Led firmware (arendst#122) * Set Sonoff Led unconfigured floating outputs to 0 to reduce exceptions due to power supply instabilities (arendst#122) * Add Access Point Mac Address to Status 11 and Telemetry (arendst#329) * Fix DS18B20 negative temperature readings (arendst#334)
4.1.3 20170410 * Add user configuarble GPIO to module S20 Socket and Slampher * Add support for Sonoff SC (arendst#112) * Set PWM frequency from 1000Hz to 910Hz as used on iTead Sonoff Led firmware (arendst#122) * Set Sonoff Led unconfigured floating outputs to 0 to reduce exceptions due to power supply instabilities (arendst#122) * Add Access Point Mac Address to Status 11 and Telemetry (arendst#329) * Fix DS18B20 negative temperature readings (arendst#334)
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):
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:
(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!
The text was updated successfully, but these errors were encountered: