lars-t-hansen
commented
1 year ago For esp32 another option is to use the on-board SPI flash file system, SPIFFS. In the simple case this is pretty straightforward and importantly it can be scripted (using the pio CLI). Basically, place the config in firmware-arduino/config.txt, then do pio run -t buildfs; pio run -t upload to upload code and data. In the application, it is possible to open this file using the SPIFFS module and it can then be parsed as per usual. On a LoRa build where there are no "user" settings we might not use the parameter store at all, though that's a separate matter. Later, the binary can be updated separately (I think).
https://randomnerdtutorials.com/esp32-vs-code-platformio-spiffs/
So far, that seems to require the code and build system to be around, and that's unfortunate, but nevertheless it makes it possible to keep code and secrets separate and only combine them during the upload process, with a script. It is also nice in that only somebody with access to the code can change the config (of course, the code is all open source now so a bit of a moot point).
As shown in issue #32, a lot of the code and data used by the device has to do with TLS/HTTP/TCP/UDP/IP/WiFi. For a LoRa version this code can all go away if we find an alternative for the WEBCONFIG option, ie, running the device in Access Point mode and connecting to it over the web so that a config can be uploaded and user prefs can be set.
In truth, in LoRa mode there aren't that many user prefs left - mostly the ability to configure the location on the device independently of what's being set in the backend tables. That functionality is pretty dodgy to begin with - the backend tables could just as easily be the authority on where the device is located. [Edit: the location ID was removed from the device in #56.] The main function of configuration is therefore to set those values that are necessary for connecting to the backend over LoRa / MQTT; any additional configuration can be obtained from the backend over that channel, even with LoRa.
We should look into what a configuration mechanism could look like that does not depend on running an HTTP server. Most likely this is some type of file upload to the device with a programmer, or maybe a mode where the device reads the config over I2C or SPI. (The button we have would work fine for placing the system in this mode. The device would go into I2C slave mode, say, and advertise a known address, and then just wait. An RPi connected to it by I2C could then just upload the config bytes. The typical config would be small. And this is scriptable.)