Writing/updating ConfigPortal values from code

[thorathome]

Me again @khoih-prog

I'm trying to give flexibility to these remote devices and want to be able to update the values of fields shown in the ConfigPortal directly from the code.

For example, I want to be able to change one or more values in the ConfigPortal's MenuItem array and have them written to EEPROM so they appear next time the device reboots, and in the ConfigPortal next time it appears. This may be more relevant with USE_DYNAMIC_PARAMETERS true.

Use case: I am getting char input from a Blynk Text Input widget and want to use that text for labels in other Blynk widgets. Today, this is set up in my ConfigPortal with USE_DYNAMIC_PARAMETERS true. It Would Be Nice to be able to save the new label values in EEPROM for continuity, have them show up after reboot and in the ConfigPortal.

Obviously not urgent. And it's already Friday night here. Thanks.

[khoih-prog]

I really don't fully understand your use-case and why we have to go extra miles to achieve what we can do with a much simpler way. I'm currently against this new feature as it might make the library unnecessarily over-complex for other users.

I think the better approach is to use EEPROM/SPIFFS/LittleFS directly to save/load those values, and use them directly in your use-cases, and you can achieve that easily in the application code. Certainly those values must have been taken from some Blynk Text Input, etc.

The dynamic params, besides Blynk Credentials, were designed for extra Credentials which are necessary for accessing / manipulating resources / dealing with other services, sites, etc. . For example MQTT, MySQL/MariaDB, WebSockets, Sinric / SinricPro, Alexa, Google Home, etc.

Please make your case better and more convincing as I have been wrong many times before.

[thorathome]

I think you are correct about complexity. I found our recent clearConfigData discussion/fix interesting because I had clean forgotten the details you reminded me of. The ConfigPortal meets your design objective of easily managing complex, admin-level info you outline.

I have been trying to use the ConfigPortal for user-managed info like widget labels, which is creating unnecessary complexity.

I do like your thought about being able to trigger a ConfigPortal from software without erasing everything, and will use that feature when it arrives, especially now that I can update everything OTA.

I'm also going to move some of my DYNAMIC_PARAMETERS work (and complexity) into EEPROM and use the Blynk App UX to manage those values beyond the initial software defaults. Better idea.

Thanks again for working on this useful library. I certainly appreciate it.

Be well. Best wishes.
@thorathome

[khoih-prog]

So I'm closing this issue now. BTW, I finished the first mods and tested successfully the lib with the new CP feature. Will release within several days.

The new feature will be

1. Non-persistent forced CP => you can force to enter the CP once, and clear the request even if you haven't changed /saved new info in the CP. After reset (HW or Virtual SW), the normal operation will resume w/t CP
2. Persistent forced CP => request will be cleared only after CP enterd and new data saved. Even reset w/o saving new data, the CP will re-appear until new data saved.
3. I guess you can also use double/multi reset feature with Virtual SW (by pressing the Virtual SW => reset => pressing the Virtual SW again within predetermined time => CP by DRD/MRD. This is currently supported.

[khoih-prog]

Another suggestion is to use LittleFS (highest priority for performance), then SPIFFS and avoid EEPROM in ESP32/ESP8266 because of life expectancy / wear, speed / performance.

The library is currently supporting LittleFS/SPIFFS besided EEPROM for both ESP32/ESP8266.

[thorathome]

You read my mind, @khoih-prog I'm using both ESP8266s and 32s, have almost updated everything to OTA.

Now I have to get up to speed on LittleFS!