watchdog timer

[uxhamby]

HI,

I have an esp8266 on a Wemos D1 mini dev board, running a Dec 2023 version of ESPEASY, that is prone to locking up and becoming unresponsive. Although not life threatening, this is inconvenient and I am thinking about a watchdog timer for it.

Before I break out a 555 timer, I understand, from https://espeasy.readthedocs.io/en/lates ... Tools.html, that there are W/D timers built into the esp8266. Are they available through the ESPEASY web interface?

Thanks,

Brian H.

[Rob73]

I have a some of the D1 minis and I like using them. I have had some that were unreliable and I had a tough time troubleshooting their problems. Some modules with an identical setup would work fine while others would drop the wifi connection or mqtt connection or I just cant access the web interface. You may try another D1 mini and see if that solves your issue. I too am interested in reading about your watchdog project.



Rob

[TD-er]

The question is, how does it 'lock up'?
Is it still sending data to controllers?
Does it reply to pings?
Complete freeze, not even a watchdog reboot?

There are already several options built in, however some may of course only help if the ESP is still doing something.

For example, if there is a bug which puts the ESP in some infinite loop while calling delay() then it will not easily get out of this state.

But if the ESP is no longer able to reach other devices on the network, you could add the ping plugin (not yet available on ESP32) and if the ping does not return a few pings in a row you can try to call "wifidisconnect" or simply "reboot".

If ESPEasy can't reach a host (e.g. the host specified in a controller), you can set the "Connection Failure Threshold:" (Tools->Advanced)
The counter for this is incremented on every failed connect attempt and more slowly decremented if it succeeds.
When it reaches your set threshold, ESPEasy will reboot.

If you would periodically fetch some JSON from ESPEasy, you could add a sysinfo task and look at the web activity. (I think this one is also reset when loading JSON)

You can also let another ESPEasy node send out a p2p command or call some HTTP GET url to trigger an event on this ESPEasy node.
This event would then reset a timer.
If the timer reaches its set timeout, you can try to reboot via the rules.

[uxhamby]

When it locks up, I cannot ping it.

ConnectFailures always report 0.

I have just noticed this evening that some Clock#Time events are missing from the log:

Code: Select all

4310875: EVENT: Clock#Time=Thu,23:05
4324710: WD : Uptime 72 ConnectFailures 0 FreeMem 18472 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
4370875: EVENT: Clock#Time=Thu,23:06
4430875: EVENT: Clock#Time=Thu,23:07
4474710: WD : Uptime 75 ConnectFailures 0 FreeMem 17784 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
4490875: EVENT: Clock#Time=Thu,23:08
4610875: EVENT: Clock#Time=Thu,23:10
4624765: WD : Uptime 77 ConnectFailures 0 FreeMem 16664 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
4670875: EVENT: Clock#Time=Thu,23:11
4684710: WD : Uptime 78 ConnectFailures 0 FreeMem 12960 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
4834710: WD : Uptime 81 ConnectFailures 0 FreeMem 17952 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
4864710: WD : Uptime 81 ConnectFailures 0 FreeMem 17784 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
4970875: EVENT: Clock#Time=Thu,23:16
5044710: WD : Uptime 84 ConnectFailures 0 FreeMem 17160 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
5074710: WD : Uptime 85 ConnectFailures 0 FreeMem 17224 WiFiStatus: 3 ESPeasy internal wifi status: Conn. IP Init
5091071: EVENT: Clock#Time=Thu,23:18

This particular D1 Mini, worked well for several years under Tasmota and was only recently redeployed running ESPEasy.

Thoughts?

Brian H.

[TD-er]

Did you between moving from Tasmota to ESPEasy wipe the flash?

If not, can you try giving the command "erasesdkwifi" and then power cycle the board?

If that doesn't help, please backup all files on the file system, flash a blank image, re-flash the firmware and restore the files.

[Ath]

I have just noticed this evening that some Clock#Time events are missing from the log:

The weblog might do that, especially when the browser-tab doesn't have focus it doesn't get many CPU-cycles, so the javascript on the page is executed really slow (I'm talking to you, Chrome ), when watching the log via USB-serial you should be able to view the complete logging output.

[uxhamby]

Hi,

try giving the command "erasesdkwifi" and then power cycle the board?

Is this command documented somewhere?

Thanks,


Brian H.

[Ath]

Is this command documented somewhere?

In the commands documentation (scroll down a bit to find the yellow-highlighted command).

[TD-er]

Well the documentation is as sparse as can be, so let me explain it a bit more....

erasesdkwifi does erase the block on the flash memory where the closed source WiFi code made by Espressif stores the WiFi RF calibration data.
Between SDK versions the layout of this data has been changed a few times and they simply check for a checksum, not a version nr of this data.
So what could be perfectly fine calibration data for older SDK versions may be complete nonsense for newer SDK versions, resulting in unstable WiFi connections.

Using this is probably a lot easier than completely wiping the flash and starting over