Closed furyfire closed 8 years ago
I completely agree with this. And this would allow the developer to bypass the configuration mode, as this can be annoying if deploying a lot of devices. It will also simplify the API (reserveEeprom
and getEepromOffset
not needed anymore).
So:
homie/config.json
exist
normal
mode, else boot into config
modeconfig
modeDoes it sound good?
Sounds really good !
And if homie/ota exists boot into ota If the config file is invalid it should boot into config mode with the choice of downloading old config (so we have a future upgrade path)
The choice of downloading old config? You can simply send the old json to the /config
endpoint. I am not sure I understad what you mean!
During an upgrade to a newer release of Homie your old config file could become outdated. I was wondering if it would be useful for a GUI configuration tool to download the old config and be able to fix the issues behind the curtain before reapplying it to /config.
The config file format won't change that often when we go stable, only on breaking releases. This is an interesting idea for later, though!
It's stable on my side, could you please test?
Feel free to reopen if something is wrong!
As the configuration array continues to grow and there is currently very little control validation on the data stored in EEPROM (checksums, lengths etc) would it not be an idea to simply store the json config in the file system? https://github.com/esp8266/Arduino/blob/master/doc/filesystem.md
It would simplify development as the flashtool today can automatically include the file.
Validation of the config file could then be put in a shared module allowing Homie to drop back into config mode if the data is unusable.
We would also retrain backwards compatibility to some extend as the JSON format would be easier to parse with the already included ArduinoJSON lib
Adding an optional setup call, which would default to Homie.setConfig("home/config.json");