[GH-ISSUE #249] Kentaylor Fork/ConfigOnSwitchFS: Values are not saved on SPIFFS #205

New issue

Closed

opened 2026-02-28 01:24:04 +03:00 by kerem · 2 comments

kerem commented

2026-02-28 01:24:04 +03:00

Owner

Originally created by @SensorsIot on GitHub (Nov 21, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/249

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...

Originally created by @SensorsIot on GitHub (Nov 21, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/249 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...

kerem closed this issue

2026-02-28 01:24:04 +03:00

kerem commented

2026-02-28 01:24:05 +03:00

Author

Owner

@kentaylor commented on GitHub (Nov 25, 2016):

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:

What @battika has done.
Do not provide the existing parameters from spiffs in the interface.
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.

@kentaylor commented on GitHub (Nov 25, 2016): Yes, it > is somehow misleading. when the > The writeConfigFile() is not called during when I press the "save" button. In [this example](https://github.com/kentaylor/WiFiManager/tree/master/examples/ConfigOnSwitchFS) writeConfigFile() is called after WiFiManager finishes. There is an alternative of using a [call back function](https://github.com/kentaylor/WiFiManager/blob/master/WiFiManager.h#L113) so that writeConfigFile() will be called as soon as the save button is pressed. [The example](https://github.com/kentaylor/WiFiManager/tree/master/examples/ConfigOnSwitchFS) 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](WiFiManagerParameter) 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](https://github.com/tzapu/WiFiManager/pull/157#issuecomment-261151047) 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](https://www.youtube.com/watch?v=UiAc3yYBsNU). I'd suggest looking at the @Squix [idea](http://blog.squix.org/2016/06/esp8266-continuous-delivery-pipeline-push-to-production.html) 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](http://configure.urremote.com/index.html) which would also be a useful addition to your current model.

kerem commented

2026-02-28 01:24:05 +03:00

Author

Owner

@SensorsIot commented on GitHub (Nov 25, 2016):

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

@SensorsIot commented on GitHub (Nov 25, 2016): 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