Open alekslt opened 5 years ago
Veldig hyggelig at du velger å bruke tid på dette!
Current head 33fb1f9 on master should have a timer-based watchdog-style implementation for ESP8266 as well now. My presumption on why we see a hang is that we run until a network error occurs, giving us a error on write(). Some code relying on transmitting data may have a tight loop around this without a timeout resulting in an infinite loop. PubSubClient calls yield in it's loop, feeding the normal watchdog-timer, and the same behavior may exist other places. With this last commit we haven't fixed the root cause, but we should recover.
We can probably shave down our watchdog timeout parameter from current 60 to 10-30 to recover quicker.
Veldig hyggelig at du velger å bruke tid på dette!
@AageEilertsen Takker. Jeg har ikke noe "tidsakslerende" test-rig for dette problemet, så dessverre tar det litt tid. Det lukter også at problemet muligens ligger i tredjepartskode, som nevnt i kommentaren ovenfor, så tar litt ekstra tid å feilsøke. Satser uansett nå på at jeg nærmer meg noe fungerende recovery-kode som skal få restarta og tatt seg inn ved feil. På ESP32 så opptrer problemet som nevnt med en god del dagers mellomrom, men om det er som du har opplevd såpass mye hyppigere på ESP8266 kan det være aktuelt å teste litt mer på den, for å få ut mer info, samt å kutte ned på timeout-koden så vi mister minst mulig meldinger fra HAN. Uansett. Du kan ta en pull/nedlasting igjen og teste på om det hjelper på stabilitet.
The ESP device hangs after a week or so and stops reading data/transmitting. The Serial debug-log shows:
[E][WiFiClient.cpp:346] write(): 104
Will need to insert a proper timer-based watchdog-timer to reboot in such circumstances instead of the "soft" one that is dependent on a functioning control flow-loop.