Automated settings restore

[davidskeck]

Hello,

I've been wondering if it would be possible to create a script that runs at build time to automatically set a few things.

It could set lat/long, date, time + some offset to allow for reassembly of the watch, and some things like world clock timezones, timeout of the watch/light, etc.

Would this even be possible? I tried to find a place to set some of these, but I'm not sure where to look for everything.

A user could, for example, set their desired settings in JSON file and the initial setting could be inserted into the code where appropriate. Just something I've been thinking about.

[joeycastillo]

I love this idea and there are a couple of places where I think it could hook in nicely. For situations where we want a given firmware to have certain presets, we could do it at build time; for example, the Deep Space Now firmware uses the MOVEMENT_CUSTOM_BOOT_COMMANDS definition to preset the World Clocks to Goldstone, Madrid and Canberra. Stargazer does something similar to preset the LED to red for night vision reasons.

Location is something I've thought about, but I don't think it would make a huge amount of sense to be compiled in. Instead I wonder if we could add it as a command the wearer could issue after flashing the firmware. Now that we have 7-8 kilobytes of nonvolatile storage (in the LFS branch), I could see either writing a lat/lon to a text file that we parse, or adding a command like setloc 40.70, -73.95 that would write the location to a hidden file that Movement could expect to read in at boot. Right now Movement just reads from the USB serial console and lets the "filesystem.c" file parse out a command (itself a pattern I'm not wild about). But if we gave Movement more of a command line interface while plugged in to USB, we could let folks store all kinds of settings on the filesystem that watch faces could then read back when installed in a watch case.

Date+time offset, perhaps we could add a "save" option somewhere in settings that would write the current configuration to the file system, and a "load" option that would read it back out after i.e. disassembling to replace the battery?

[davidskeck]

Oh nice! I love LFS! I have used that on another project and it was a wonderful filesystem.

I like the idea of putting the location, time, and possible future data into files via command. That makes a lot of sense and would, as you said, persist across battery replacements which is nice.

In the meantime, if you have any questions about LFS let me know and I'll field them as best as I can. The issues page for that project is pretty active as well.