maybe easier to use Dashboard replacement

[ThomasB]

Would you mind sending me the config.dat of the attic device.

Before I post it, I just want to confirm that sensitive info isn't in the config.dat file.

- Thomas

[ThomasB]

@chromo23, Good news! The task deletion issue isn't your problem.
@TD-er, Bad news. Seems ESPEasy has a task deletion bug that shows up when a device with a lot of tasks is rebooted.

- Thomas

[chromo23]

Before I post it, I just want to confirm that sensitive info isn't in the config.dat file.

All the sensitive data should be in the security.dat as far as I know.

@chromo23, Good news! The task deletion issue isn't your problem.

Good news indeed, so the config.dat is not necessary anymore.

@TD-er, Bad news. Seems ESPEasy has a task deletion bug that shows up when a device with a lot of tasks is rebooted.

Are the 36h already over?
I had a similar issue two day ago where my rules disappeared after saving. Not sure if this is related....

[Ath]

I've been using the latest (mega) code a lot lately, while working on a new plugin, using an ESP32-C6 that has all Devices/Tasks slots occupied, but haven't seen any loss of tasks after a reboot (not adding/changing tasks a lot, but rebooting a lot after updating the firmware...).

The issue mentioned doesn't make sense to me anyway, why would a recently added task being removed during/after a reboot (and not any other task?), feels more like unstable flash storage or power supply to me But I'm quite sure that's properly checked/validated.

[ThomasB]

I'm using the external antenna version of this ESP32 device:
https://www.aliexpress.us/item/3256806150187598.html

I did more debugging and things are much weirder than expected. I can modify some entries such as task names, value names, and value decimals, as well as the rules. Those survive a reboot. But adding new tasks or changing most task/hardware/config entries are lost after a reboot. That is to say, they happily exist until Tools->Reboot.

If the consensus is that the ESP32 has failed then I will do a device swap. But I'll wait for more comments before climbing the ladder.

By chance is there a config.dat viewer? Would be interesting to see what is being saved.

- Thomas

[TD-er]

How are these added?
Can you try to call the "save" command before reboot?
Also if the "save" returns almost immediately, it didn't save anything as it was deemed to be the same file content as when loaded.

And to be sure... You're not trying to edit stuff after restoring a tar upload and before a reboot?

[TD-er]

Saving rules does use the upload call and I guess EasyFetch also tries to save something via the same upload path.
Maybe there is something seriously wrong with the upload and then flushing to the file system?

[ThomasB]

I am adding them from the ESPEasy setup pages.

I tried using the Tools-Command->save this morning. No joy. Tried again just now, command executes immediately (no delay).

I'm not trying to edit stuff after restoring a tar upload and before a reboot.

Before we get too deep into this, I am going to configure another ESP32 with my setup. To prove the target device is not failing.

- Thomas

[TD-er]

Is it possible the ack of a save/submit request may get lost in transit due to poor wifi and then the browser (or impatient user ) may be retrying the save/submit again?
My theory is that this may run into a race condition regarding save/load actions if this can happen.

[ThomasB]

I configured another ESP32. It is a version with built-in antenna (attic unit has external antenna). EraseSDKwifi was performed, then cold boot.

Initial tests were without EasyFetch. I did not experience the lost settings problem.

But after I added EasyFetch the problem returned. So this is the smoking gun we needed.

Here's a screenshot of the file system, with EasyFetch loaded. Fetch.html.gz is an earlier version. Fetch1.html.gz is the latest version. Is memory usage OK, or is it too full with the three extra files?

screenshot1.jpg

- Thomas

[TD-er]

You can see on the sysinfo page how 'full' the file system is.
and if you like to see how the settings files are being used in charts, you can give the command 'meminfodetail' and after that every time you open the sysinfo page you will see extra in-depth info until you reboot.

[ThomasB]

Here is a screenshot. There's a lot of info to digest. Rather than trust my amateur analysis, I will need to lean on you Devs. Is there enough free ram and flash to create a new config.dat? Because this sure seems like modified configurations are not being saved after I added those three EasyFetch files.

[TD-er]

that was more about the partitioning to validate the flash size and file system size.
The free space is still text-only.

[ThomasB]

If you need any other information from me please let me know.

- Thomas

[TD-er]

Just the section regarding ESP Board and Storage of the sysinfo page.

This shows how fast the flash is running, what flash is found, and some info about how the flash might be connected to the ESP (in the ESP Board sections)

[ThomasB]

Screenshot of ESP Board and Storage. I think I see the problem, only 112K free. I have a feeling it needs to be >131K to create the new dat file. ?

[TD-er]

Hmm 112kB free might be a problem here as the settings file is 128k and LittleFS needs to rewrite the entire file when making changes.

If this really is the issue, then we really must speed up splitting the settings file into separate smaller ones.

Can you try to reproduce save issues when working with at least 128k + 16k free space?

[ThomasB]

I deleted the older unneeded EasyFetch file. Now 128K free. And the problem is gone.

- Thomas

[TD-er]

OK, so probably it is caused by "disk full".

So while you're going to buy an ESP with 8 or 16M flash, Ton and I have to think about how to fix this by splitting the settings file.
I think a quick fix can be to split it into 2 chunks.
For this I refer to the first chart of "Layout Settings File".
As you can see, there is a large area upto the 32k mark where you don't see any color.
From 32k to 96k there are 2 chunks of 1k per task.
The chart doesn't show what is stored from 96k to 128k, so if that's still empty, we should get rid of it.
Then the first part upto 32k does have at least 16k of unused space.

So I think the easiest fix for now would be to split it into 2 files and thus save about 48k in used space and also make saving quite a lot faster.

[ThomasB]

Thanks for assisting with this unusual settings problem. Besides your proposed solution, perhaps a "disk full" warning message can be displayed when there's not enough room.

Now to return to the original issue. That is, the EasyFetch random stalls/hangs.

- Thomas

[chromo23]

Now to return to the original issue. That is, the EasyFetch random stalls/hangs.

I just uploaded a newer version of easyfetch (20250505/1) addressing this issue.
You should get an update notification. If you press OK it downloads a new fetch.html.gz file and reloads the page.

[ThomasB]

Thank you for the new release. It's installed and running.

On the previous version I typically saw a reboot every 15-20 minutes. So let's see how the latest release does. Fingers are crossed that it is a winner.

- Thomas

[TD-er]

We are also looking into other issues which might be ESPEasy related.
So if this isn't the winner... yet, it might be when we finally found out what bothers Safari loading pages.

[ThomasB]

It's been running for an hour. No reboots. No stalls. I'm optimistic that we might have a winner.

I looked at the patch. The reset interval is now 5.5 Sec. So it seems TD-er's hunch was on target.

- Thomas

[chromo23]

I looked at the patch. The reset interval is now 5.5 Sec. So it seems TD-er's hunch was on target.

Yes it was. I also added a check that requests do not start to overlap and keep piling up...
If nothing else is coming up I can make this "new" easyfetch the default version and start to write a small documentation ( my favorite part )

[TD-er]

Great!

Still I will continue making some work-around to other causes for waits/stalls with other browsers like Chrome/Firefox.

[ThomasB]

It's been about four hours and it has rebooted twice. That's not bad.

The reboots started after I enabled EasyFetch charting. I will try to confirm it is the cause, but this will take a couple days.

- Thomas

[chromo23]

The reboots started after I enabled EasyFetch charting.

Hmmmm.. that's interesting since the charts have nothing to do with easyfetch accessing ESPEasy.
Another mystery that needs to be solved

I will wait here patiently for your findings....

Edit: In the info section of the /tools tab you can find the reboot reason. Would be nice to know and maybe helps to find out what's happening...

[TD-er]

How much space is left on the file system?

[ThomasB]

In the info section of the /tools tab you can find the reboot reason. Would be nice to know and maybe helps to find out what's happening...

Reset Reason: CPU0: Software reset CPU CPU1: Software reset CPU
Last Action before Reboot: PLUGIN_READ: Task FURNACE

How much space is left on the file system?

Without EasyFetch Charting:
Free RAM: 166080 [byte] (147008 - )
Heap Max Free Block: 110592 [byte]
Free Stack: 6644 [byte] (2340 - )
Little FS Size: 316 [kB] (128 kB free)

With Charting:
Free RAM: 173720 [byte] (147008 - )
Heap Max Free Block: 110592 [byte]
Free Stack: 6644 [byte] (2340 - )
Little FS Size: 316 [kB] (128 kB free)

- Thomas

[TD-er]

What plugin is used for the task "FURNACE" ?

Also I think 128k is not enough. Especially on a fragmented file system.

I will check to see what I can do with at least the last 32k.
Maybe I can truncate it.

And if it is possible, you can also do this yourself using some tool like dd.
Just download the config.dat file, cut of the last 32k and upload the file again to ESPEasy's file system
Make sure to not change anything before rebooting after upload of the file.

Please first download a backup as a tar file.