version 2.0.0dev12 rebooting frequently

[jpio123]

Steps to reproduce

I use 2.0.0dev12 software, version "testing" versior or own compiled normal realesae with PMSx003 plugin and Advanced HTTP controller included.
I connect PMS5003 sensor, configure device system info - uptime and PMS5003 dust sensor.
Report values to Nettemp software using Advanced HTTP.

Does the problem presist after powering off and on? (just resetting isnt enough sometimes)

Yes

Actual behavior

In this configuration ESP reboot very often, every few minutes. If I do not use HTTP Advanced controller and PMS sensor - only "system uptime" device when it works better but still reboot every 1-2 hours. Generally if I run esp without any devices that it works for some longer time, but adding anything makes software unstable. I attached graph of uptime and some logs.

If I use R148 version with the same hardware it works super-stable

System configuration

Hardware:

nodeMCU v3, clone of nodeMCU v3, clone of Wemos D1 mini pro
PMS5003 dust sensor

Software or git version:

2.0.0dev12

[papperone]

I really doubt somethign can be done with such poor info; I've many modules running 24/7, some still with R148 and all the rest with 2.0.0.dev10/11/12 and none of them shows that unstability, so definitely it's not a bug but something related to your specific config; having said that I believe this type of issues shoudl be discussed in the forum and not opening a GitHub issue that has zero chances to be solved here....

[TD-er]

Indeed,what @papperone suggests.
My first impression is to try another powersupply.

Dust sensors may have quite some peak in power usage.
Perhaps add a big capacitor for the power supply of the sensor.

[jpio123]

Hi,

maybe I could start this discussion on forum, but I'm sure it's some problem in software. I really doubt it is problem with power caused by dust sensor - I have tested many different power configurations even separate powet supply for dust sensor. I also tested setup with capacitor and nothing helps.

Please also keep in mind that my nodeMCU and Wemos Mini restarts even without any sensors.
I can see two different reasons of reboot in console. So today I run tests without any external sensors - only "system info - uptime" device that is sending data to http advanced controller.
I already have one crash after about 1 hour. Please see logfile.

no sensors.txt

[TD-er]

Hmm, can you also try it on another WiFi accesspoint, just to be sure?
And when you started a topic, please post a link to it.

[Marc26]

I updated the ESP12F firmware with ESPEasy_v2.0.0-dev12_normal_4096.bin version. only then reboot the system. Does not work anymore.
Additionally: 1 system had version 1.20 the other 2.0 dev 11. For all, only rebots. do not come into operation anymore.

Read out with putty:
ets Jan 8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09826c6d
~ld

and again, and again, etc.

[papperone]

I still don't think it's a software problem as not only me but many others use ESPeasy modules (NodeMCU, Wemos D1 Mini and self-assembled PCBs) and are not experiencing the instability you claim of here.
I have a brand new D1 Mini just plugged in this morning, flashed with 2.0.0-dev12 from Github (not self compiled) and attached a BME280 reporting temp via MQTT; still running flawlessly since 8.30am without a single reboot... I will keep it running just for the sake of testing for at least 48h

[jpio123]

TD-er: you mean to test another physical access point or just change SSID? I can do such test if you want.
papperone: Only difference for me is that I used test_4096 and own compiled normal_4096 but with advanced_http controller and pms_5003 plugin included. I'm waiting for next reboot with tcpdump running on controller and then I can do test with normal_4096 version without any test modules.

[TD-er]

@jpio123 Indeed, just another WiFi access point, preferably from another brand.
But if there is none, then it's hard to test :)
Judging from the log you attached, I got the impression there might be some unhandled disconnect situation. Even when it runs fine with another accesspoint, it could still mean there is some bug, but at least then we can narrow it down a little.

[jpio123]

Because last reboot was after HTTP connection failed:

SYS  : 63.00
HTTP : connection failed

Panic C:\Users\PK\.platformio\packages\framework-arduinoespressif8266\cores\esp8                                                                             266\core_esp8266_main.cpp:98 __yield

ctx: sys
sp: 3fff3a10 end: 3fffffb0 offset: 01b0

I decided to power off my raspberry with controller - to replicate this situation, but in this scenario nothing happeden - esp is still running:

WD   : Uptime 73 ConnectFailures 0 FreeMem 21448
WD   : Uptime 73 ConnectFailures 0 FreeMem 21448
SYS  : 73.00
WD   : Uptime 74 ConnectFailures 0 FreeMem 21448
WD   : Uptime 74 ConnectFailures 0 FreeMem 21448
SYS  : 74.00
HTTP : connection failed
WD   : Uptime 75 ConnectFailures 1 FreeMem 21448
WD   : Uptime 75 ConnectFailures 1 FreeMem 21448
SYS  : 75.00
WD   : Uptime 76 ConnectFailures 0 FreeMem 21448
WD   : Uptime 76 ConnectFailures 0 FreeMem 21448
SYS  : 76.00

I will leave it now to capture this on tpcdump.

Later I will do some test in different scenarios.

[papperone]

ok I have flashed now the test_4096 with same hardware as before and let's see...

[Marc26]

Later on:
eventually flashing again at 1.20. all reset (total reset)
Alright.
Now again via the tool in the esp firmware updated to ESPEasy_v2.0.0-dev12_normal_4096
Unfortunately, all data is lost. Reapply the esp.
This is not nice.

[papperone]

running the "test_4096" for more than 6 hours and no reboot (still just BME280 and MQTT as a controller)...

[jpio123]

Uhm, so what I'm doing wrong. Now I'm running without any controller configured and 72 minutes now without reboot. Maybe you can send me your image just to be sure?
I have in my home also Domoticz, so I can use it to test it with DHT22 sensor without http advanced controller.

Please take look at log from few hours and few reboots without sensor - just reporting uptime via http advanced. I have tcpdump of from controller, but there is nothing interesting:

You can see here uptime 64 minutes and than 2 minutes later uptime 0.
In console:
`SYS : 64.00
WD : Uptime 65 ConnectFailures 0 FreeMem 21592
WD : Uptime 65 ConnectFailures 0 FreeMem 21592
SYS : 65.00

Panic C:\Users\PK.platformio\packages\framework-arduinoespressif8266\cores\esp8266\core_esp8266_main.cpp:131 loop_task

ctx: sys
sp: 3ffffdd0 end: 3fffffb0 offset: 01b0

stack>>>
3fffff80: 401007ca 00000000 00000002 3fff2c00
3fffff90: 00000000 3fffdad0 3fff2bec 402033f1
3fffffa0: 3ffeaf98 40000f49 3fffdab0 40000f49
<<<stack<<<

ets Jan 8 2013,rst cause:4, boot mode:(3,6)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09826c6d
~ld
▒U

INIT : Booting version:
INIT : Warm boot #5
FS : Mounting...
FS : Mount successful, used 75802 bytes of 957314
INIT : Free RAM:24856
INIT : SPI not enabled
WIFI : AP Mode disabled
WIFI : AP Mode ssid will be ESP_Easy_0 with address 192.168.4.1
WIFI : Connecting PioNET_PLAY attempt #1
WIFI : Connected! IP: 10.255.255.204 (ESP_Easy_0)
WD : Uptime 0 ConnectFailures 0 FreeMem 21592
SYS : 0.00`

I think this could be problem with HTTP Advanced controller, but I think I was doing some test with PMS without reporting to controller - but I'm not sure I will check it on second esp.

[papperone]

I am using the last dev12 bin downloaded from GitHub, I have only MQTT as controller 1 and just one sensor... nothing special and no reboots...
I've really no idea as you tested already different power supplies and so far that is for me the main issue with ESP8266 modules which behaves strangely when not enough/proper juice; as you report log from the console, does it means you run it permanently connected to your PC?

[uzi18]

please add here screen with controller configuration 2017-11-12 22:12 GMT+01:00 papperone <notifications@github.com>:

…

I am using the last dev12 bin downloaded from GitHub, I have only MQTT as controller 1 and just one sensor... nothing special and no reboots... I've really no idea as you tested already different power supplies and so far that is for me the main issue with ESP8266 modules which behaves strangely when not enough/proper juice; as you report log from the console, does it means you run it permanently connected to your PC? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#582 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHOU7VWgfqRseAjTOV-nHk3eQeIM7aZks5s118qgaJpZM4Qal-z> .

[jpio123]

No, now I do it just to debug. And this is some clone of nodeMCU so it have some capacitor etc build in. Normally I use USB power supply - 1A and 2.1A and connect it to to 9-5V input on nodeMCU or connect it via step down 5v to 3.3v power module based on AMS1117 chip. Please keep in mind that on R148 it works super stable regardless of power source that I use. But on R148 version there is no http advanced - I use some special modified version with "nettemp" controller. I will let you know tomorrow how it behaves with PMS5003, DHT22 and DS18b20 all connected but without any controller configured.

[ShardanX]

I've just put together a new dust sensor PCB with a PMS7003, display, some NeoPixel status LEDs and a BME280. I'll let it run for awhile and report back

[jpio123]

Hi. I left for tonight 3 esp devices - one without sensors, second with PMS5003, third with PMS5003, DHT22 and DS18b20 - all of them as "standalone" and all of them have 8 hours uptime now.

So it seems we have some bug in HTTP Advanced controller. How can we debug this?

[Marc26]

I've loaded an esp12F with firmware R120. Then load the settings of an existing esp12F.
Checked, works.
Next, upload via http new firmware (ESPEasy_v2.0.0-dev12_dev_4096).
Then, as previously described, constantly reset.
Remedy: Reload ESP12F via breadboard with ESPEasy_v2.0.0-dev12_dev_4096.
Reload settings do not work now. firmware R120 writes in .txt
firmware ESPEasy_v2.0.0-dev12_dev_4096 required .dat

It seems strongly that a firmware update to ESPEasy_v2.0.0-dev12_dev_4096 causes serious problems through http issues.
My advice:
DO NOT upload via http!

Can anyone fix this? So safe to update the firmware via http without losing settings or worse, the system will continue to reset.

[TD-er]

I thought you had to rename the firmware dump to "config.dat"?

…

--- Verzonden vanaf laptop

On 13 November 2017 at 10:33, Marc26 ***@***.***> wrote: I've loaded an esp12F with firmware R120. Then load the settings of an existing esp12F. Checked, works. Next, upload via http new firmware (ESPEasy_v2.0.0-dev12_dev_4096). Then, as previously described, constantly reset. Remedy: Reload ESP12F via breadboard with ESPEasy_v2.0.0-dev12_dev_4096. Reload settings do not work now. firmware R120 writes in .txt firmware ESPEasy_v2.0.0-dev12_dev_4096 required .dat It seems strongly that a firmware update to ESPEasy_v2.0.0-dev12_dev_4096 causes serious problems through http issues. My advice: DO NOT upload via http! Can anyone fix this? So safe to update the firmware via http without losing settings or worse, the system will continue to reset. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#582 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADk9ln2AmhuW01qK3jcFv-ofAaoYfe2Nks5s2Az4gaJpZM4Qal-z> .

[Marc26]

That's right. Unfortunately, the values ​​are not read properly, valuable information is lost.

[ShardanX]

My dust sensor (2.0.0-DEV12 TESTING, sources Oct.25. 17) is running for 21 hours now. No issues, no reboots. I've configured my controler (FHEM HTTP) now and will report back.

[jpio123]

Ok, my ESP with PMS5003, DHT22 and DS18b20 but without Generic HTTP Advanced controller worked for 23 hours now. So we can assume that this works stable. Now I will do some test with controller, but we can clearly see that something is not working correctly in this controller module.

[papperone]

as we narrow down the issue (it seems) to the advanced HTTP controller and not dev12 being unstable maybe we shoudl close this issues as the titles it misleading and open a proper one?

[Grovkillen]

@jpio123 I will close this particular topic since it's not a problem with dev12 itself. Please open a new one regarding the unstable controller.

[jpio123]

I have opened discussion in the forum: http://www.letscontrolit.com/forum/viewtopic.php?f=6&t=3775