logo elektroda
logo elektroda
X
logo elektroda

ESP8266 (ESP-07), DHT22, web server - After some time, the page does not display.

sq9etc 4125 52
Best answers

Why does my ESP8266 web page stop displaying after 1–2 days even though the board still seems alive?

The most likely causes are a hanging DHT22 read, a blocking/memory issue in the sketch, or the ESP losing its Wi‑Fi/client state, so the first thing to check is whether the ESP is still pingable when the page stops loading [#18568097] [#18567925] The original code does not check the Wi‑Fi client status in `loop()` at all, so if the module is in STA mode that can leave the web page unreachable even though the ESP is still running [#18568097] Several replies also point to the DHT sensor itself: it can occasionally hang, and using a better ESP-oriented library such as DHTesp was suggested for better diagnostics [#18567925] [#18569094] Another likely source of instability is the watchdog / memory handling around NTP and `String` processing; polling the NTP server every 10 seconds caused Soft WDT resets in one test, while changing synchronization to once per day let the code run for over 3 days [#18598097] [#18627478] If you reset the module from code, use `ESP.restart()` rather than `ESP.reset()`, and also check free heap for leaks and power-supply/memory-size issues [#18589435] [#18613691] [#18587599]
Generated by the language model.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
  • #1 18567706
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    I copied the program alive from this page:
    ESP8266 DHT11/DHT22 Temperature and Humidity Web Server with Arduino IDE .

    Unfortunately, after a long time (1 - 2 days) the web page stops displaying in the browser. You can see that the device is alive, as the blue LED on the board flashes when messages are sent to the serial port.
    Has anyone encountered a similar case and can make any suggestions?
    The circuit is connected as shown in this diagram:
    Link .
  • ADVERTISEMENT
  • #2 18567857
    Anonymous
    Level 1  
  • ADVERTISEMENT
  • #3 18567925
    kaczakat
    Level 34  
    Posts: 1748
    Help: 317
    Rate: 229
    Board Language: polish
    Check the performance of the site by sending some counter seconds. This will eliminate the hanging caused by DHT. Sometimes someone complains that every now and then the sensor can hang up and only unplugging the power supply helps. I haven't noticed this, but I haven't tested the operational stability for a long time. Such sensor can be powered from uC pin and if it stops responding do ON/OFF. But this needs to be handled somehow in code.
    Helpful post? Buy me a coffee.
  • #4 18568097
    Anonymous
    Level 1  
  • #5 18569011
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    khoam wrote:
    With what version of the ESP8266 board manager did you compile this program? The latest version is 2.6.3.
    .
    Where can this be checked? Arduino IDE 1.8.12 As for the version of the ESP8266 support library that displays in the board manager, yes, it is version 2.6.3.
  • #6 18569026
    Anonymous
    Level 1  
  • #7 18569030
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    kaczakat wrote:
    Sometimes someone complains that every now and then the sensor can hang up and only unplugging the power supply helps.
    .
    I also have this problem. When I combined the linked program with this Network Time Protocol I had this effect. I added myself a date and time display on the page in addition to temperature and humidity. After a few tens of minutes, up to a few hours, the readings from the DHT would stop appearing and the time would change. I added something such that when 3 times the sensor would not return the correct values I would do an ESP.reset. Unfortunately this did not help. I had to switch the power to the circuit off and on. After that it worked for a while and then it was the same thing again. I had the module reset over and over again after every three failed attempts to read from the DHT.

    Added after 4 [minutes]: .

    khoam wrote:
    sq9etc wrote:
    When it comes to the version of the ESP8266 support library that displays in the board manager, yes, it is version 2.6.3.
    .
    Yes, that's what I meant. Try testing pinging to ESP when you don't have access to the site.

    I hadn't thought of that ping, that's a thought. If it happens I'll check it out. For now it has been working for almost two days.
  • #8 18569094
    Anonymous
    Level 1  
  • #9 18569192
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    Possibly, maybe I'll check at some point. But this behaviour of the sensor suggests that it's not a software problem, well unless it's the sensor's firmware. After a reset I think everything should re-initialise and work normally.
  • #10 18586389
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    sq9etc wrote:
    kaczakat wrote:
    Sometimes someone complains that every now and then the sensor can hang up and only unplugging the power helps.
    .
    I also have this problem. When I combined the linked program with this Network Time Protocol I had this effect. I added myself a date and time display on the page in addition to temperature and humidity. After a few tens of minutes, up to a few hours, the readings from the DHT would stop appearing and the time would change. I added something such that when 3 times the sensor would not return the correct values I would do an ESP.reset. Unfortunately this did not help. I had to switch the power to the circuit off and on. After that it worked for a while and then it was the same thing again. The module reset over and over again after every three failed attempts to read from the DHT.
    .
    This happened to me again today.
    This is what a snippet of a dump to a file from RealTerma looks like:
    ...
    Local time: 2020-04-03 07:20:49
    Temperature: 22.00ÂşC
    Humidity: 48.70%
    020-04-03 07:20:49
    
    
    Local time: 2020-04-03 07:20:59
    Temperature: 22.00ÂşC
    Humidity: 48.70%
    
    Soft WDT reset
    
    >>>stack>>>
    
    ctx: sys
    sp: 3fffed40 end: 3fffffb0 offset: 01b0
    3fffeef0:  40242a1c efd8a1fc 60000600 4021223d  
    3fffef00:  00000000 3ffed558 00000000 00000000  
    3fffef10:  40231530 3ffed558 3ffee510 60000600  
    ...
    3fffff90:  3fffdad0 00000000 3ffeed50 40100229  
    3fffffa0:  3fffdad0 00000000 3ffeed50 402088e5  
    <<<stack<<<
    
     ets Jan  8 2013,rst cause:2, boot mode:(3,7)
    
    load 0x4010f000, len 1392, room 16 
    tail 0
    chksum 0xd0
    csum 0xd0
    v3d128e5c
    ~ld
    Starting UDP
    Local port:	123
    
    Time server IP:	194.146.251.100
    
    Sending NTP request ...
    
    Sending NTP request ...
    NTP response:	1585898481
    
    Local time: 2020-04-03 07:21:21
    Failed to read from DHT sensor!
    Failed to read from DHT sensor!
    020-04-03 07:21:21
    
    NTP response:	1585898486
    
    Local time: 2020-04-03 07:21:26
    Failed to read from DHT sensor!
    Failed to read from DHT sensor!
    020-04-03 07:21:26
    
    NTP response:	1585898496
    
    Local time: 2020-04-03 07:21:36
    Failed to read from DHT sensor!
    Failed to read from DHT sensor!
    ˙
     ets Jan  8 2013,rst cause:2, boot mode:(3,7)
    
    load 0x4010f000, len 1392, room 16 
    tail 0
    chksum 0xd0
    csum 0xd0
    v3d128e5c
    ~ld
    Starting UDP
    Local port:	123
    
    Time server IP:	194.146.251.100
    
    Sending NTP request ...
    
    Sending NTP request ...
    NTP response:	1585898511
    
    Local time: 2020-04-03 07:21:51
    Failed to read from DHT sensor!
    Failed to read from DHT sensor!
    020-04-03 07:21:51
    
    NTP response:	1585898516
    
    Local time: 2020-04-03 07:21:56
    Failed to read from DHT sensor!
    Failed to read from DHT sensor!
    020-04-03 07:21:56
    
    NTP response:	1585898526
    
    Local time: 2020-04-03 07:22:06
    Failed to read from DHT sensor!
    Failed to read from DHT sensor!
    ˙
     ets Jan  8 2013,rst cause:2, boot mode:(3,7)
    ...
    
    .
    It looks like Watch Dog worked, but for what reason I don't know. Maybe there was a delayed response from the NTP server. However, this does not excuse the fact that after a reset the sensor can no longer get along.
  • #11 18586604
    Anonymous
    Level 1  
  • #12 18587599
    oskar777

    Level 26  
    Posts: 1264
    Help: 76
    Rate: 243
    Board Language: polish
    I had a similar problem with the DHT as for the ESP-7 I selected the wrong amount of memory. Sometimes it is also a power supply problem.
    Company Account:
    Oskar-info
    Gidzińskiego 24/1, Warszawa, 02-293 | Tel.: 501XXXXXX (Show) | Company Website: http://oskar-info.pl
  • ADVERTISEMENT
  • #13 18587948
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    khoam wrote:
    .
    It would be good if you could show how you 'linked' this, particularly in the loop().

    Code:
    main.cpp
    Code: C / C++
    Log in, to see the code


    WiFi.h
    Code: C / C++
    Log in, to see the code


    WiFi.cpp
    Code: C / C++
    Log in, to see the code
    .
    khoam wrote:
    <br>
    sq9etc wrote:
    This, however, does not excuse the fact that after a reset you can no longer get along with the sensor.
    .
    A bit of an excuse, given that after a Soft WDT Reset there is "rubbish" left in RAM.

    I also do ESP.reset() there.
  • #14 18589435
    Anonymous
    Level 1  
  • #15 18590612
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    khoam wrote:
    What are the RAM occupancy statistics after compilation?
    .
    36 %. What can be done so that this compilation message window does not close by itself in Atom? It's difficult to see this memory occupation, because it closes immediately.

    Added after 9 [hours] 5 [minutes]: .

    yield() didn't help. I will still see with replacing ESP.reset() with ESP.restart().
  • #16 18592493
    Anonymous
    Level 1  
  • #17 18592514
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    khoam wrote:
    Has the program crashed and performed a Soft WTD Reset? Or did the program fail to resume correctly after forcing ESP.reset()? These are two different things.
    .
    I don't know that, because I didn't have the bug plugged in. The effect was that after a while it stopped reading DHT22 as before. I can only suspect that the cause was the same, i.e. Soft WDT Reset.
  • #18 18592528
    Anonymous
    Level 1  
  • #19 18595248
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    After the changes:
    -adding yield() where you suggested,
    -replacing ESP.reset() to ESP.restart(),

    is the same, ie:
    -the soft WDT reset occurs,
    -after the above it is not possible to get along with the DHT22, ESP.restart() does not help for lack of communication with the sensor.
  • #20 18595375
    Anonymous
    Level 1  
  • #21 18595416
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    khoam wrote:
    sq9etc wrote:
    it is the same, ie:
    -Soft WDT reset occurs,
    .
    Also after the last temperature and humidity values have been correctly displayed (vide post #10)?
    .
    Exactly like this.
    khoam wrote:
    After what time did this Soft WDT Reset occur?
    .
    First time after 1h 18m of operation, second time after almost 4 hours of correct operation.
  • #22 18595472
    Anonymous
    Level 1  
  • #23 18597673
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    khoam wrote:
    OK, that leaves one point to be clarified. I refer to the first code from post #13.
    What specifically did you want to achieve by using the variables dHTReadingErrorsCount and prevDHTReadingErrorsCount ? On what state of these variables did you want to make the circuit reset dependent and in what situation?
    What I see in the code is ;)
    .

    After three failed attempts to read the sensor, a reset is to be performed. With that said, if the temperature and humidity fail to be read in one cycle then I count this as one error. Therefore I entered two variables and incremented dHTReadingErrorsCount when reading the humidity, only when I failed to do so when reading the temperature. Hence the condition:
    Code: C / C++
    Log in, to see the code
    .
  • #24 18597882
    krzbor
    Level 29  
    Posts: 1731
    Help: 40
    Rate: 1042
    Board Language: polish
    I had a program on the ESP that sometimes rebooted (several times a day). The ESP was working with the SIM800. I decided that interference from GSM was the culprit. However, I had to tweak the program and the reboots were almost all the time. Eventually I determined that the problem was due to returning 'String' as the result of a function - it should work, but it didn't. I solved the problem by stopping the function returning the "String" value - the "String" is now passed to the function by reference and everything started working. There is a "processor" function in your code that returns a String. Perhaps the same problem as mine is also occurring?
  • #25 18598097
    Anonymous
    Level 1  
  • #26 18598668
    krzbor
    Level 29  
    Posts: 1731
    Help: 40
    Rate: 1042
    Board Language: polish
    Indeed, I hadn't noticed that the function was a callback. My experience with the String object was that if a function returns this object and it is assigned to a global variable, it is OK (this is how I have it in other projects). The problem arose when the result of a function returning a String was stored in another function in a local variable - in other words, stack handling came into play. Since we have a callback here, this situation also occurs.
  • #27 18598763
    Anonymous
    Level 1  
  • ADVERTISEMENT
  • #28 18613509
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    khoam wrote:
    sq9etc wrote:
    After three unsuccessful attempts to read the sensor, a reset is to be performed.

    Regardless of how long a period of time they occurred?
    .
    An apt point, although in my case when the sensor stopped reading, it was on amen.

    Added after 4 [minutes]: .
    I replaced Send_P with Send, but nothing changed, i.e. after tens of minutes the sensor stopped responding.
    I commented out the part of the code responsible for retrieving and converting the time to text. Instead, I display myself the number of readings since the module started. At the moment there are 5080 readings, which means everything has been working for more than 14 hours. I continue to have three variables displayed as I had. So that doesn't look like some kind of string problem to me.
  • #29 18613691
    Anonymous
    Level 1  
  • #30 18627478
    sq9etc
    Level 12  
    Posts: 228
    Help: 11
    Rate: 15
    Board Language: polish
    I debugged a piece of code converting time from a uint32_t type variable to a text string, and in this form the program ran for over 3 days.
    In the original version, quickly put together from the two, which I presented on the listing, there was one uncool thing. Namely, the time server was queried as often as the sensor, i.e. every 10 seconds.
    I have now changed this so that the synchronisation occurs once a day after midnight according to winter time. So far it has worked since evening. I hope that this way it will already work stably for a long time. I wonder what the time divergence will be at the end of the day. I increment the time myself every sensor reading, i.e. every 10 s.

Topic summary

✨ The discussion revolves around issues faced with an ESP8266 (ESP-07) web server setup using a DHT22 sensor, where the web page ceases to display after a period of 1-2 days. Users suggest various troubleshooting steps, including checking the ESP8266 board manager version (2.6.3), monitoring the DHT sensor's performance, and ensuring the WiFi client status is checked in the loop function. Recommendations include using the DHTesp library for better error diagnostics, implementing a reset mechanism after multiple failed sensor readings, and optimizing memory usage to prevent soft WDT resets. The conversation also touches on potential memory leaks and the importance of proper string handling in the code to avoid crashes.
Generated by the language model.

FAQ

TL;DR: 36 % heap usage was reported; “yield() didn’t help” [Elektroda, sq9etc, post #18590612] The lock-ups trace to Soft-WDT resets triggered by blocking code, small string buffers and DHT22 time-outs [Elektroda, khoam, post #18589435] Why it matters: Fixing these three issues keeps an ESP8266+DHT22 web server stable for weeks instead of hours.

Quick Facts

• Soft-WDT fires after ≈3.2 s of blocked processing [Espressif SDK, 2016]. • DHT22 max update rate: 0.5 Hz (one read every 2 s) [Aosong Datasheet]. • ESP8266 core 2.6.3 requires ≥50 kB free heap for AsyncWebServer [ESP8266 Core Docs]. • ESP.restart() closes sockets; ESP.reset() does not [Elektroda, khoam, post #18589435]

Why does the ESP8266 web page disappear after 1–2 days?

Because blocking tasks (NTP request + DHT read) stall the loop longer than the 3.2 s watchdog window; Soft-WDT resets follow, and the DHT library then fails to re-initialise, so the page never finishes its template substitution [Elektroda, sq9etc, post #18586389]

What triggers Soft-WDT resets on ESP8266?

Any code path that blocks >3.2 s without yield() or delay(), including long UDP waits or heavy String operations, will trip the watchdog [Espressif SDK, 2016].

How do I stop the DHT22 from freezing?

  1. Power the sensor from a spare GPIO.
  2. If read() returns NaN three times, set the pin LOW 1 s then HIGH.
  3. Re-initialise the library. This cycle revives most lock-ups without rebooting the ESP [Elektroda, kaczakat, post #18567925]

Which DHT library is best for ESP8266?

Use BeeGee-Tokyo’s DHTesp; it reports checksum errors, distinguishes time-outs and needs fewer delayMicroseconds calls than Adafruit_DHT [Elektroda, khoam, post #18569094]

Does polling an NTP server every 10 s hurt stability?

Yes. Each UDP round-trip allocates ~1 kB; constant polling fragments heap and raises reset risk. Reducing sync to once per 24 h kept the system up >3 days [Elektroda, sq9etc, post #18627478]

How large should my dateTime buffer be?

Allocate at least 20 bytes: “YYYY-MM-DD hh:mm:ss\0”. Declaring it as char[20] prevents sprintf from overrunning heap and corrupting adjacent variables [Elektroda, khoam, post #18627634]

Why is using char* = "literal" risky?

Multiple identical literals may be stored once in flash; three char* variables can therefore point to the same read-only address. Writing through any of them invokes undefined behaviour and causes random crashes [Elektroda, LED5W, post #18632200]

ESP.reset() vs ESP.restart() – which is safer?

ESP.restart() performs a clean software reset: it closes TCP/UDP sockets, flushes serial and sets RF to safe state. ESP.reset() forces a hardware reset without cleanup and leaves RAM artifacts that confuse peripherals [Elektroda, khoam, post #18589435]

How can I monitor memory leaks at runtime?

Call ESP.getFreeHeap() each loop and print or log the value. A healthy AsyncWebServer sketch stays within ±2 kB over hours. A steady downward trend signals leaks in String or UDP handling [Elektroda, khoam, post #18613691]

What board settings matter for the ESP-07 module?

Choose flash size that matches the module (8 Mbit for ESP-07) and enable ‘qio’ mode; wrong settings caused spontaneous reboots in tests [Elektroda, oskar777, post #18587599]

Can power supply issues mimic sensor freezes?

Yes. DHT22 draws up to 2.5 mA during conversion; unstable 3.3 V rails can corrupt its one-wire timing, leading to read failures that persist until power-cycled [Aosong Datasheet; Elektroda, kaczakat, #18567925].

What’s the safest way to serve dynamic strings in AsyncWebServer?

Reserve a global String with .reserve(64) once, fill it, then call request->send(200,"text/plain",globalStr). This avoids per-request heap churn that crashes under load [Elektroda, khoam, post #18598097]

Edge-case: What happens if I read the DHT faster than 2 seconds?

The sensor replies with the last sample and may pull the data line low for >80 ms, blocking interrupts and eventually triggering Soft-WDT resets [Aosong Datasheet; Elektroda, sq9etc, #18595416].
Generated by the language model.
ADVERTISEMENT