esp loopt vast

2 Tips: Gebruik geen delays maar een Statemachine en gebruik de Watchdog functie.

Een knipperend ledje kan je helpen of de boel echt vastgelopen is of in een eindeloze loop draait (deadlock). Gaat meestal het snelst.
(je kunt dan het ledje aan/uit verplaatsen in diverse routines tot je de dader hebt gevonden, ledje gaat dan niet meer uit...)

ik heb de 4leds van de ESP toegevoegd, hopelijk volgende maand resultaat (screen_update,calculatePrintTime, getsolardata en updateboiler).
1 fysieke led, en 3 gewone uitgangen. met een voltmeter kan ik dan wel kijken welke uitgang actief staat als die vastzit

het duurt een maand voor ik resultaat heb en voor hetzelfde loopt er iets fout in de ESP zelf waardoor die at random in een subroutine vastloopt. ik weet alvast dat de loop niet meer draait, maar interrupts wel nog.

op het display krijg je elke 5sec een puntje die bijkomt, en die stopt, de boel hangt echt vast. die regels staan in de loop zelf. dus de loop wordt niet meer uitgevoerd.

  if (updateTimer % 4 == 0) {  //15puntjes
    u8g2.print("_");
    u8g2.sendBuffer();
  }

als de loop niet meer doorloopt, zet die niks meer op scherm.
2de punt: ik krijg WEL reactie van de browser, dus dat gedeelte doet het nog, alleen hangt het scherm vast. ik kan niks veranderen alsook de tijd staat stil.
dus het subroutine dat de webserver beheert, draait nog, maar krijgt geen aangepaste tijden meer. die zitten ook in de loop.
elke 60keer door de loop is (met een delay van 1000) gaat die hier door

  if (updateTimer % 60 == 0) {  //60
    calculPrintTime();
    ...
    totalTime++;

en word de tijd verhoogt.

calculate printtime doet hetvolgende dan voor die de output serieel wegschrijft

  cHour = int(totalTime / 60);
  cMin = int(totalTime % 60);

in de webbrowser hangt de tijd vast op 4:01, wat wil zeggen dat cMin niet geupdate wordt en de loop dus niet meer draait.
ergens loopt de ESP vast en doet niks van loop() meer maar de interrupts doen het wel aangezien de webserver nog reageert

server.on("/", HTTP_GET, [](AsyncWebServerRequest *request) {
    //request->send(LittleFS, "/index.html", "text/html");
    request->send_P(200, "text/html", index_html);
  });

  server.on("/reboot", HTTP_GET, [](AsyncWebServerRequest *request) {
    request->send_P(200, "text/html", reboot_html);  //, processor);
    delay(2000);
    ESP.restart();
  });

helaas ben ik vergeten om de 'reboot' via webbrowser eens te runnen om te zien of die dan nog herstart.
ga er eens over denken om eventueel de laatste 'serial.prints' in een array te houden en die via de webbrowser weer te geven. dan weet ik tenminste wat de esp nog deed voor die ermee stopte.

ik ben al ettelijke maanden aan het zoeken waarom die vastloopt. meestal merk ik het als het douchewater koud is en die al meer dan een dag vast zat. dan warmt de boel ook niet meer.
ik monitor ook het netwerk, maar aangezien de webbrowser gewoon antwoord, zie ik ook niet dat die vastzit

Op zondag 27 april 2025 11:00:49 schreef Roland van Leusden:
2 Tips: Gebruik geen delays maar een Statemachine en gebruik de Watchdog functie.

er zit maar 1 delay in, om ervoor te zorgen dat die geen 15 000x per sec door mijn loop heen raast om niks te doen, maar altijd gewoon 1sec wacht.
de webserver dat 1sec vertraagd boeit me ook weinig.
heb ooit eens 1 fout gemaakt in mijn code waarbij die meer dan 1000x een ntp request stuurde, dus heb liever 1 vaste delay van 1seconde in een loop. dan kan die alvast dergelijke fouten niet meer doen

Timer interrupt gebruiken is altijd een veel betere oplossing als een vaste delay...
Als je op het scherm info zet over welke routine 'bezocht' werd op het moment van hangen weet je ook waar het zit...

scherm is te klein en zit al vol data.
maar heb 1 led en 3 uitgangen her en der in procedures hoog en laag gezet. kan dus wel zien door de uitgangen te meten welk proces vast zit.
hopelijk volgende maand meer info

Een tellertje van 0x00 tot 0xFF kost maar weinig ruimte. Iedere keer ophogen bij bezoek van een nieuwe routine en aan het begin van de loop resetten.
Voor 2 digits zal toch nog wel plaats zijn?

die uitgangen hebben een conflict gegeven en esp start niet meer op, ook geen ota update meer, dus de boel mogen demonteren om met usb weer te flashen.

aangezien de webserver draait, kan ik daar wel een variabele inzetten. de tijd komt erin, dus als ik daar een karakter A-F toevoeg, weet ik waar die 'zat' bij het vastlopen.
die waarde zal niet meer veranderen (zoals de tijd) maar wordt wel weergegeven

hier dus in 'getsolardata'. dus het lukt. nu krijg ik altijd loop te zien. hopelijk binnen 30dagen dus de vastlopende procedure

[Bericht gewijzigd door fcapri op zondag 27 april 2025 12:07:49 (14%)]

't Is vaak een 'deadlock': geen echte vastloper maar 'loopen' in een bepaalde onvoorziene situatie waar 'ie niet meer uit komt.
(meestal veroorzaakt doordat niet alle mogelijke uitkomsten van een actie goed zijn afgevangen, er moet altijd een 'time-out' zijn)

Waar ik even snel aan dacht zou het millis() overrun kunnen zijn. Dat gebeurt om de ca 49 dagen. Maar het kan ook een andere variabele zijn die een overrun heeft.

Een variabele overrun 'loopt' toch automatisch terug naar 0x00?

JA dat wel maar als je bv de variabele wilt vergelijken met een vorige waarde + offset dan gebeurd dat niet meer of duurt heel lang.

Op zondag 27 april 2025 13:42:45 schreef Arco:
Een variabele overrun 'loopt' toch automatisch terug naar 0x00?

Ja, maar als je de compare verkeerd doet, dan kom je nooit meer aan iets wat moet gebeuren toe:

Vergelijk:

   if (next <= millis ()) {    
       do_something ();
       next = next + 1000; 
   }

met

    if ((millis() - next) <= 0) {
        do_something ();
        next = next + 1000; 
    }

Merk op dat ik next steeds met precies 1000 ophoog. De bedoeling is dat als ik zo nu en dan 100 ms te laat dit stukje code doe, de do_something () nog steeds gemiddeld 1x per sec wordt gedaan. Niet minder niet vaker.

Deze twee werken 49 dagen precies identiek... En dan....

Wordt next gelijk aan maxint - <een beetje> , en millis () loopt over voordat je opnieuw hebt kunnen checken. Nu is millis weer terug klein en next is heel groot. Dus next < millis () is de komende 49 dagen dus nooit waar.

Subtiel is dat in de tweede stukje code millis() - next ook een wraparound kent en WEL kleiner dan nul wordt dan-en-alleen-dan zodra er weer een seconde verstreken is.

Kortom, het is lastig om dit soort programmeer-fouten te debuggen als je niet super-focussed bent op deze wraparound complicatie.

Ik denk van mezelf dat ik me hiervan bewust ben en dat ik probeer het in 1x goed te programmeren. En toch leert de ervaring dat ik het wel eens fout doe.

ik gebruik geen millis.

1 delay van 1000ms in de loop.
als de loop 60x gedraaid heeft, doet die dingen. dus elke minuut is er actie.

geen andere delays, geen millis, geen ander nasty dingen. heel basic spul

het enige is de ntp die de boel zou kunnen verzieken, maar daar zit volgens mij ook een timeout op zou er geen antwoord komen

Als je de serverpool 'pool.ntp.org' gebruikt is er weinig kans op problemen.

NTPClient timeClient(ntpUDP, "pool.ntp.org", utcOffsetInSeconds);

die librarie zal wel in orde zijn

Je gebruikt zelf dan wel geen millis() maar weet je dat ook voor onderstaande code?

  if (updateTimer < 1) {  //get internet time every hour
    updateTime();
    updateTimer = 3600;
    runtime++;

Echter ik bedoelde niet enkel millis() maar ook of het mogelijk is of er een andere variabele in overrun gaat.
Als het millis() zou zijn dat zou het ook om de ongeveer 49 dagen moeten gebeuren.

En je hebt gelijk als er maar 1 delay is zit mag dat van mij ook op die manier. Het gaat erom dat je je bewust bent van het blokkerende karakter van een delay maar als je 1 seconde niets wilt doen dan is dit precies wat het moet doen.

ja, die code is als volgt.
ik lees de ntp van het internet, die zou nu 18:36 zijn. 18h komt in cHour en 36 komt in cMin.
dan zet ik 3600 in updatetimer en aan het einde van mijn loop staat er updateTimer--;

als die minder dan 1 wordt (of zelf negatief) ga ik weet een ntp request doen.
dus elk uur doe ik een update van de ntp tijd.

zou die loop vastlopen, blijft die in zijn eigen tijd draaien.

runtime++ is dan voor de volgende if loop.
als die 360x door deze ntp loop is gegaan, dan doet die een restart van de ESP.
of zijnde: na 15dagen reboot die.
want ik sukkel al een tijdje dat die na lange tijd vastloopt (1maand dus).
halfweg de maand heeft die een correcte reboot gedaan, nu liep die dus na 14dagen weer vast

Het zijn altijd de details die vervelend doen.

Bijv

updateTimer--

Als die updateTimer een unsigned long is dan gaat hij van 0 naar 4294967296.
En dan duurt het wel even voordat hij weer 0 wordt.

Het gebruik van strings is altijd al tricky. Houdt ook eens je heap size bij. Vooral de minimale heap. Mogelijk gaat het daar fout.

In de NTP librarie zit ook een 'renew' optie, waar je kan ingeven om de hoeveel tijd je een update wil doen.

Bijvoorbeeld uit de DateTime.h file van de ESPDateTime librarie.

  /**
   * @brief Begin ntp sync to update system time
   *
   * @param timeOutMs ntp request timeout
   * @return true if timestamp updated and valid
   * @return false if timestamp not valid
   */
  inline bool begin(const unsigned int timeOutMs = DEFAULT_TIMEOUT) {
    return isTimeValid() || forceUpdate(timeOutMs);
  }

Die DEFAULT_TIMEOUT is dan

  /**
   * @brief NTP Request default timeout: 10 seconds
   *
   */
  constexpr static unsigned int DEFAULT_TIMEOUT = 10 * 1000;  // milliseconds

Ook forceUpdate heeft dezelfde variabele als optie. Deze gebruiken is altijd een optie en hoef je het zelf niet bij te houden.

Een ESP is altijd heel gevoelig naar te gebruiken IO bij het opstarten. Altijd goed controleren.

Het boeit me weinig dat een ESP x maal per seconde door zijn code gaat. Bij een delay() loopt die ook rondjes op de achtergrond.

OTA gebruik ik nooit voor een update. Wel http update. On line voldoende voorbeelden beschikbaar.

Op zondag 27 april 2025 17:50:47 schreef fcapri:
ik gebruik geen millis.

Ik bedoel niet te hinten dat jij millis () gebruikt. Ik reageer op Arco die zei dat de wraparound gewoon moet blijven werken.

In arduino (gebruik je dat? Weet ik niet eens) kan je iets in mijn voorbeeld op twee manieren schrijven en dat ziet er equivalent uit, maar juist bij overflows is het toch verschillend.

Maar omdat je ding dus nu een dag of 29 heeft gedraaid en niet 49.5 of precies de helft daarvan denk ik niet dat je met de overflow van een milliseconde teller te maken hebt.

Dingen die makkelijk "fout" te doen zijn is het alloceren van wat geheugen en vergeten het vrij te geven. Dan kan het zomaar zijn dat de boel na XXX tijd ineens "out of memory" gaat.

Als dat in de NTP code zou zitten kan je een hint krijgen dat dit zo is door de NTP-retry op 2 minuten te zetten. Als ie dan na 1 of 2 dagen crasht heb je de hint dat het zoiets is.

Maar het kan ook zomaar in de rest van de code zitten. IK weet het niet. Je zult moeten debuggen. Je eerste doel moet zijn om te kijken of je het vaker kan triggeren. Iedere keer een maand moeten wachten voordat je "ok dat was het ook niet" kan roepen gaat uiteindelijk lang duren.

Worst-case zit het in iets als: "ALS er een retransmit moet gebeuren omdat er eenpakketje zoek is geraakt, DAN lekt er xxx bytes aan geheugen". Dan is het helemaal onvoorspelbaar.

Als het vrij-geheugen gerelateerd is, dan kan je een manier verzinnen om het vrije geheugen te rapporteren. Blijft dat mooi constant: Goed zo. Neemt het langzaam af, dan heb je daar dus je probleem.

Op zondag 27 april 2025 09:12:53 schreef fcapri:
mijn boiler sturing draait op een esp8266 met een 0.96" TFT scherm.
op regelmatige tijd loopt die vast.
vanmorgen zat die vast op 4h01 smorgens.
de vorige keer dat die vastliep was 30maart om 18h20 savonds.

Loopt het vast op regelmatige of onregelmatige tijdstippen? Denk niet alleen aan dezelfde kloktijd, maar ook aan de de tijd tussen (her-)starten en vastlopen.

Ik heb ook last van 'n vastlopende ESP, maar dat lijkt niet direct op jouw probleem. Bij mijn ESP probleem verdenk ik in de eerste plaats de voeding die misschien soms te veel inzakt tijdens WiFi acties van de ESP en dan het vastlopen veroorzaakt, maar ik ben er nog niet aan toegekomen om in die richting te testen. Ik weet ook niet of een 'brown-out' de ESP kan laten vastlopen.

Ik zag al wat goede suggesties voorbijkomen zoals gebruiken van Ledjes. Ik gebruik vaak seriële output in de verschillende routines. Als je die oppikt (Arduino serial monitor) dan heb je in ieder geval een historie en hoef je niet naast je ESP te gaan zitten om de ledjes te volgen.

In ieder geval zullen de millis() het niet zijn als je het netjes gedaan hebt. Begintijd aftrekken van millis() "if millis()-starttijd > 3245)" gaat gewoon goed, ook al loopt de millis() teller over. Je 'starttijd' moet wel van het type 'unsigned long' zijn (24 bits zonder sign-bit) anders gaat het wel fout. 3245 in het voorbeeld mag ook een variabele of constant zijn.

voeding is het bij mij niet. als de boiler draait, staat een relais bekrachtigd. het vastlopen was om 4h snachts en 18h savonds.
de boiler warmt maar tussen 10h en 16h. dus de voeding verdenk ik niet omdat ze op die momenten het minste doet.

ik merkte al dat de esp soms vastloopt als het douchewater koud was, dan was die de dag ervoor dus uitgevallen.
ik heb het al een aantal keer gehad nu, denk dat die boiler versie en esp nu ongeveer een jaar oud is.
omdat ik vermoed dat het ongeveer een maand is, en ik een overflow van de millis verdenk (zit misschien in 1 of andere librarie gebruikt), heb ik die nu laten rebooten na 15dagen (360uur).

begin van de maand zat ik in china, en heb ik de tijdsklok allemaal uit gezet. als die reboot dan komt die weer op beginpositie waarbij die warmt om 10h, 11h, 15h en 16h. kom terug uit china en staat idd op die positie, dus de restart is wel degelijk gebeurt en dan begint alles opnieuw. nogmaal zou die vandaag of morgen rebooten, maar liep eergisteren dus vast.

de webbrowser werkt nog, maar de tijd staat stil (dus geen loop meer en geen ntp requests).
paar maand terug had ik de restart functie ook al geprogrammeerd zodat ik die via browser kon herstarten. 2dagen geleden niet aan gedacht helaas omdat ik ondertussen dus ook de software heb herschreven dat die reboot na 15dagen.
ik zou de boel op 7dagen kunnen zetten en dan zou het ook van de baan moeten zijn maar wil het nu eerder gaan oplossen. ik vermoed dat het random is tussen een 13-30dagen dat die vastloopt. vroeger zou ik zeggen dat het meer dan 3weken is, maar daar is nu bewezen dat het ook op 13dagen kan

Op zondag 27 april 2025 21:19:38 schreef rew:

In arduino (gebruik je dat? Weet ik niet eens) kan je iets in mijn voorbeeld op twee manieren schrijven en dat ziet er equivalent uit, maar juist bij overflows is het toch verschillend.

Maar omdat je ding dus nu een dag of 29 heeft gedraaid en niet 49.5 of precies de helft daarvan denk ik niet dat je met de overflow van een milliseconde teller te maken hebt.

ja, arduino programmeersoftware. ik dacht ook al aan millies, daarom de restart na 15dagen, maar nu liep die vast op 13dagen, het is dus meer at random en niet specifiek na 30dagen ofzo en al helemaal niet op 49,5. dat vermoeden had ik zelf ook al.
heb toen een reboot functie in de browser geschreven om die remote toch te kunnen rebooten zodat het douchewater tenminste warm is.
nu is het wat onbetrouwbaar.
op een jaar tijd zo 1keer koud water gehad, dus het valt nog mee, maar plezant is anders
vroeger had ik een tijdklok en dat werkte al jaren goed, deze esp communiceert met zonnepanelen en zal dus ook warmen als er teveel energie is. en dat is enorm handig. gebeurt vaak dat er van 9h tot 12h volop zon is, maar de boel stond geprogrammeerd van 13-17h en alles kwam uit het net toen

[Bericht gewijzigd door fcapri op dinsdag 29 april 2025 07:52:06 (28%)]

Volgens mij heb je wel een aantal raspberry's draaien. Maak daar een log server van en laat al je ESP daar hun log regels dumpen. Kun je altijd terugkijken wat er gebeurt is.

Ik kan mij herinneren dat ik een keer iets soortgelijks had, waar de combinatie van de ntp client library en U8G2 library een probleem was. Als ik één van de twee gebruikte ging het goed. (Je kunt U8G2 uitschakelen en zoals gesuggereerd naar je RPi loggen, al was het maar om te kijken of het ermee te maken heeft.)
Nooit kunnen vinden, maar de NTP library vervangen door eztime.
Had nog meer voordelen, want (Als ik me goed herinner) zit de automatische overschakeling van/naar zomertijd niet in de ntp library.