Kentaylor Fork/ConfigOnSwitchFS: Values are not saved on SPIFFS

[SensorsIot]

I use the original example and enter different values in fields. Then I save and check again. All changes are there as expected. Then, I reboot. After this reboot, the old values are there. The writeConfigFile() is not called during when I press the "save" button. It is only saved if I press "Exit". This is somehow misleading. Save for me means, it is persisted...

[kentaylor]

Yes, it

is somehow misleading.

when the

The writeConfigFile() is not called during when I press the "save" button.

In this example writeConfigFile() is called after WiFiManager finishes. There is an alternative of using a call back function so that writeConfigFile() will be called as soon as the save button is pressed.

The example was contributed by @battika and I can see why he has not made writeConfigFile() a callback. If he did it would require the WiFiManagerParameter declarations to be global but because he uses values in the declaration that are read from spiffs he can't do that. So the alternatives I see are:

1. What @battika has done.
2. Do not provide the existing parameters from spiffs in the interface.
3. Add methods to the WiFiManagerParameter class to update parameters.

Perhaps others can provide more insight. I am reluctant to do 3 because I'm thinking to remove this functionality from the https://github.com/kentaylor/WiFiManager/ version and have suggested it be removed from the @tzapu version also. I've had no feedback on that suggestion so would appreciate your views.

I'm a fan of the @SensorsIot videos and guess the interest in WiFiManager is related to video 78. I'd suggest looking at the @Squix idea of having sketches automatically deployed to devices in the field simply by committing source to GitHub. I'm guessing @Squix has a Swiss accent too. An essential component of that model is something like the IOT Configurator which would also be a useful addition to your current model.

[SensorsIot]

Thanks for your answer! I also like your library and it is currently part of the IOTappstore infrastructure.
I will investigate in your proposals and come back, if I do not find a solution.
In the version of the iotappstore I am working right now, there is a portal and you upload the MAC address of your device and your binary file, and in a "project", you combine the two. Then, if your ESP calls the address of the store, it automatically gets the newest file if necessary (MD5 comparison). For that reason, I have to separate code and configuration data completely. And this is, why I use your functionality extensively.
I had problem with your library when I used it in conjunction with a webserver application. It did not show the captive portal screen. So, I separated the config completely from the app and always boot in between. The handover is done with a variable in RTC memory. Now, it is stable and fast.
I also do not use SPIFFS. I use a memory structure which is then transferred to EEPROM. Very simple.

typedef struct {
char boardName[STRUCT_CHAR_ARRAY_SIZE];
char IOTappStore1[STRUCT_CHAR_ARRAY_SIZE];
char IOTappStorePHP1[STRUCT_CHAR_ARRAY_SIZE];
char IOTappStore2[STRUCT_CHAR_ARRAY_SIZE];
char IOTappStorePHP2[STRUCT_CHAR_ARRAY_SIZE];
// insert NEW CONSTANTS according boardname example HERE!
char magicBytes[4];
} strConfig;

void writeConfig() {
DEBUG_PRINTLN("Writing Config--------------------------------");
EEPROM.begin(EEPROM_SIZE);
config.magicBytes[0] = MAGICBYTES[0];
config.magicBytes[1] = MAGICBYTES[1];
config.magicBytes[2] = MAGICBYTES[2];

for (unsigned int t = 0; t < sizeof(config); t++) EEPROM.write(t, ((char)&config + t)); // could be replaces by EEPROM. put if stable
EEPROM.end();
}
boolean readConfig() {
ret=false;
if (EEPROM.read(magicBytesBegin) == MAGICBYTES[0] && EEPROM.read(magicBytesBegin + 1) == MAGICBYTES[1] && EEPROM.read(magicBytesBegin + 2) == MAGICBYTES[2]) {
DEBUG_PRINTLN("Configuration found");
for (unsigned int t = 0; t < sizeof(config); t++) ((char)&config + t) = EEPROM.read(t); // could be replaces by EEPROM. get if stable
EEPROM.end();
boardName = String(config.boardName);
IOTappStore1 = String(config.IOTappStore1);
IOTappStorePHP1 = String(config.IOTappStorePHP1);
IOTappStore2 = String(config.IOTappStore2);
IOTappStorePHP2 = String(config.IOTappStorePHP2);
ret = true;

} else {
DEBUG_PRINTLN("Configurarion NOT FOUND!!!!");
writeConfig(); // write the default values
}
return ret
}
The magic bytes are used to check, if there is something useful in the EEPROM