Copyright ©

Mongoose OS Forum


Persisting AWS IoT Config Between Flashes

Hey all, I've been exploring Mongoose OS on an ESP8266 for use in an upcoming internal product and it's been great so far. I'm using mos build, mos flash, and mos aws-iot-setup to handle the firmware compilation and AWS provisioning steps, but every time I build and flash a new firmware, the system falls back to whatever default settings that don't work with AWS.

I've tried dumping some of the config files after mos aws-iot-setup gets run and adding those to my configs along with some certs for testing, but it always fails to use software ECDSA to connect (I haven't set up an ATECC508A module yet).

The ideal workflow I'm building towards would be:

  • Send a copy of the firmware to PCB Assembly house
  • Use a build script flashes/tests our production firmware
  • Provision the device with a limited AWS policy
  • At some point in the future, call the Mongoose OS RPC over MQTT (through AWS) to initiate an OTA update

If there's a better way to do any of this, I'd love to hear it, I'm just working off of what I've found reading through the codebase and your documentation.



  • SergeySergey Dublin, Ireland
    edited February 2017

    It's perfectly possible to restore the config after flash.

    • Dump.
    mos aws-iot-setup .....
    mos get aws-iot-XXX.crt.pem > aws-iot-XXX.crt.pem
    mos get aws-iot-XXX.key.pem > aws-iot-XXX.key.pem
    mos get ca-verisign-ecc-g2.crt.pem > ca-verisign-ecc-g2.crt.pem
    mos config-get > saved_config.json
    • Reflash.

    • Restore config:

    mos put aws-iot-XXX.crt.pem
    mos put aws-iot-XXX.key.pem
    mos put ca-verisign-ecc-g2.crt.pem
    # order is important - firt copy files, then reference them in the config
    mos config-set mqtt.ssl_ca_cert=ca-verisign-ecc-g2.crt.pem mqtt.ssl_cert=aws-iot-XXX.crt.pem mqtt.ssl_key=aws-iot-XXX.key.pem
    mos wifi .....
  • Thanks! That helps with the local workflow.

    Is there a way to ensure that those configs are still set after an OTA update though? I'd like to constrain the device to only talk over secure MQTT connections, but if I initiate an OTA update after it's deployed remotely, and it flashes over those settings, I won't be able to communicate with it at all.

  • SergeySergey Dublin, Ireland
    edited February 2017

    Flashing replaces everything, full stop.

    OTA works differently. A firmware consists of binary code and a filesystem. When OTA happens, a new firmware is written to the second "partition", or slot. You can check what slots is in use by mos call OTA.GetBootState. The filesystem of the new firmware, however, gets MERGED with the old filesystem. And the merging logic is this:

    1. A new empty filesystem is created
    2. Files from the old FS are copied over
    3. Files from the new firmware are copied on top, overwriting existing files

    Thus, if you want to preserve files during OTA, make sure that new firmware does NOT have files with the same names.

    Note, the configuration overrides file, conf.json, is NOT present in the firmware, thus all custom-made config settings, including MQTT config , etc, are PRESERVED during OTA. This is the biggest difference with re-flashing.

  • rojerrojer Dublin, Ireland

    slight correction: new filesystem is flashed from the OTA image and files that are not present are copied over from the old one. this will preserve certificates and configuration, as long as they are not present on the new OTA image.

Sign In or Register to comment.