Flash Writes - on what is it based?

[chromo23]

Since i do a lot of testing (especially for easyfetch) i exceed the "daily flash write limit" several times a day.
So i looked how many flashwrites a change and a hit the submit button is causing. Sometimes its two sometimes three.
Now I'm wondering how these numbers come about.
What is a flash write cycle based on?

(And would it be hard to make an special build where all changes are only stored in ram. A special chromo23-easyfetch-developer-edition )

[TD-er]

There is a check for changes in checksum, to prevent saving unchanged settings.

There are several things that may be saved:
- Security Settings (every password like stuff, has checksum)
- SettingsStruct (almost all settings of ESPEasy, has checksum)
- ExtraTaskSettings (taskname/taskvarname/formula/nrdecimals, all at the bottom of the task pages)
- CustomTaskSettings (Used by some plugins, like those display plugins)

To see the whole list, including where it is stored in the config.dat file, run the command "meminfodetail"
Then open the sysinfo page and scroll to the bottom.

Each separate block described in that chart that has to be written will be counted as a flash write.

[chromo23]

run the command "meminfodetail"

Woooooooahhhhh...

[chromo23]

There is a check for changes in checksum, to prevent saving unchanged settings.

But maybe i have found a bug then?

When i open a Device (e.g. Dummy Device) and hit Submit > 2 flash writes > hit submit again (nothing changed) > 2 flash writes > and so on...

This shouldn’t happen than, right?

Edit:

(And would it be hard to make an special build where all changes are only stored in ram. A special chromo23-easyfetch-developer-edition )

And what do you think of this? Is this something easy to change. (i guess not but thought i ask anyway)

[TD-er]

Depends... the ExtraTaskSettings (the taskname/taskvaluename, etc) is cached. But when you save stuff, the caches are cleared.
And not sure what will be decided when the cache is cleared and you have not changed anything.
So it could be a "missed opportunity for optimization" when it does save it.
But on the other hand, it is always a trade-off between space/speed and making sure things work correctly and to be honest, I prefer the last one

On ESP32 we do have a lot more memory, so this could be used to check if things have changed, but again it also requires a lot of extra checks to see if the cache is still valid.

[TD-er]

What you could do, is you can increase the write count max to like 1000x.
But keep in mind this limit is there for a reason....

[TD-er]

Suggested define to use:

CUSTOM_FLASH_WRITE_LIMIT_YES_I_KNOW_WHAT_I_AM_DOING_IS_WRONG_BUT_LEAVE_ME_ALONE

[chromo23]

ResetFlashWriteCounter works just fine for me

[TD-er]

OK, you can call it from the rules to reset this periodically

[chromo23]

Jep.
And i gladly like to share the code:

resetflashwrite.gif (160.22 KiB) Viewed 1506 times

[TD-er]

The only thing missing is a goto....