feature request - store settings to cookie/docker image

[marc-gist]

Would be great if one could store the settings he/she entered into the web interface for quick use later.

thanks for a great app!

[benzino77]

Will think about it. It is not so straightforward.
For now you can, download user_config_override.h file and use it in the next compilation (but performed by hand).

[marc-gist]

Will think about it. It is not so straightforward.
For now you can, download user_config_override.h file and use it in the next compilation (but performed by hand).

Some javascript should handle it no? Is there an easy way to upload the user_config_override.h?

[benzino77]

If you downloaded your user_config_override.h file from tasmocompiler, you can use it to manually compile tasmota. You can also use platformio.ini file provided by tasmocompiler at the end of compilation.

[marc-gist]

Thank you; however, that completely defeats the purpose of your wonderful docker! :(

[benzino77]

That's true. Let me think about it.

[jacobmyers-codeninja]

I think the best way to handle this would be to define a JSON structure that holds all the defined configuration data that you normally store in the state of the steps. What you could do is make a new step 1 called upload or something and allow the user to provide this JSON file (or skip to ignore it). The file can be read by the javascript and passed down as a prop into each step following and they can extract (if it exists) the config data for their step. IE: Wifi can look for the AP name and password data. This allows the user to provide a JSON, then just step through each step and adjust if desired, and then after the compile you could also provide a new JSON output with the final configuration object state data replicated.

I would see this very useful to include very commonly used config data in my own file I just provide at the start, and maybe tweak a few parameters. Generating the initial file would be as simple as walking through the UI once and I can save it off. This also starts to make it possible to have someone create and maintain JSON configs for maybe common device types.

The advantages to this type of setup is the docker container needs to store nothing new, it is all handled client side and is still relatively smooth operation from start to finish. Implementation wise this should be fairly straight forward as well, the uploader step just needs a callback into the parent for passing in new data, and you just need to define your JSON structure you want which I suspect would look very similar to your current steps (ie: theres a wifi section, features section, etc).

Ideally this data structure matches what I assume you post back to the compiler service itself, meaning it would then also be possible to reuse your container by external services that want a way to compile a bunch of firmware files at once. For instance I would like to be able to compile a bunch of firmwares with some variables replaced and store them somewhere to use for OTA updates (where I rename the firmware for that specific device). This makes it easy to mass compile and deploy firmwares with all my config data built in whenever a major release happens or I need to test a version on a selection of devices.

I am interested in learning about the current pieces and seeing what may be required to get something like this working, but from an initial look at everything I don't believe it should be too difficult. What are your thoughts on this @benzino77?

[benzino77]

To tell the truth I haven't think, one could use TasmoCompiler for mass compiling. When I was creating this tool I was thinking about home use cases where you have 10+ devices and you do not install them at the same time (just add devices to your home setup during your IOT world development). Every new device, you open TasmoCompiler GUI to prepare your custom bin file and you are doing it from time to time.

I left this issue open since April, because I do think that it might be interesting to implement such functionality. I was thinking of it rather as challenge more then crucial feature. But...
There is text field in fourth step Custom parameters which content will be written at the end of user_config_override.h file. This means that it will override any previous settings (you can define your WiFi creds in second step and override it by Custom parameters). You can prepare your base configuration and after successful compilation download user_config_override.h file. It contains ALL the settings you have entered. As it is a text file it can be modified and changed, then during each subsequent compilation the body (or parts of it) of user_config_override.h file can be pasted in the text field in Custom parameters step. Its structure is rather self describing (have a look at the provided example).

I realize that it is not as convenient as "upload your configuration", but for now it should/have to be enough - just ctrl+c - ctrl-v your settings.

The issue will be left open.

[claymore666]

I have developed a solution which is about 80% done, unfortunately this is my very first approach with Node.js and I am still learning.
In essence I have created a helper js file dealing with loading and saving the JSON config object to a file defined in the global config.js. I have taken the merged data object from the compile.js file which contains all values. When preparing all files for compilation its the time the user has clicked the compile button and the process of user data entry has ended. Then the save function is called via API.
The loading works similar, the data is handed over via the function through the API and on creation either the defaults or the file content is set. However here I am struggling a bit with debuging and getting the conversion to a JSON right.
But I am confident to provide a solution in a timely manner (because I am also annoyed of typing in my wlan credentials every time)
In general I see your approach and tendency to keep it as simple as possible, however I think there is a huge user community eager to have most config options available in the GUI - but I respect that you do not want the tool to head that way down the road.

[benzino77]

I would rather think of storing some information in localStorage:

localStorage.setItem('wifiSSID', 'myssid');
localStorage.setItem('wifiPass', 'mypassword');
localStorage.setItem('staticIP', true);
...

Then every time you open TasmoCompiler in the browser it can check if there is a key in localStorage (it is kev:value type of storage) and eventually fill some fields with values stored there.

localStorage.getItem('wifiSSID', 'myssid');
localStorage.getItem('wifiPass', 'mypassword');
localStorage.getItem('staticIP', true);
...

I use some by no mistake. I'm pretty sure that storing ALL settings will cause more problems than it can provide benefits. That is because features may change over time and be (especially between major version releases) incompatible between version of TasmoCompiler. On the other hand I'm pretty sure that storing WIFI config or static IP settings can be really, really handy. There has to be also implemented mechanism to wipe out those stored settings by providing "GUI element" for calling localStorage.clear(); (or its counterpart).

[claymore666]

yeah agree. i thought it would be handy just to store the form values. But we would need some logic checking the validity of those. I'll have a look at the localStorage concept and will focus on the WIFI first. Is it in your opinion an issue to store sensitive data unencrypted?

[benzino77]

Is it in your opinion an issue to store sensitive data unencrypted?

That is a good question. It will be plain text so someone with access to your browser (or browser data folder) could retrieve this information. Official documentation says that only the same origin can access data in localStorage - in other words every origin got its own localStorage.

[jerry1333]

Hi, I have an idea that might work and I think it should be relatively easy to implement.
How about adding a middle step between Tasmota sources and Wi-Fi setup.
This step let's call it "Load Configuration" should have one button to load the previously saved file user_config_override.h
Loading this file would configure all the fields from it, but allow further customization. If no file is selected, all values remain default.

This way, home users have the option to update their devices more easily (instead of typing all the data, now you keep one user_config file…), but it's hard enough to stop a mass build. It should work easy with all possible solutions like gitpod, docker and so on.

Any thoughts on this approach?