Push ESP32 Over The Air Updates From GitHub

Let’s say you’re working on an ESP32 project to send off to your grandma; something she can just plug in and it will start automatically monitoring her plant’s water levels. But you discover a critical flaw in the firmware and need to update it. Does she send it back? Do you walk her through dropping the update via the Arduino IDE OTA? The easiest way would be to plan and use something like esp_ghota, an OTA framework by [Justin Hammond].

OTA (Over-The-Air) updates are a fantastic feature of the ESP32, and we’ve covered libraries that make it easy. But compared to those earlier projects, esp_ghota takes a different approach. Rather than hosting a web server where someone can drop a binary, it looks at GitHub releases. [Justin] had to include a streaming JSON parser, as GitHub API responses tend to be beefy. The workflow is straightforward, push a new commit to your main branch on GitHub, and the action will trigger, building a few different versions. Your little plant watering reminder at your grandma’s will check every so often to see if a new version has been pushed and can update with rollback on littlefs, fatfs, and spiffs filesystems.

It’s an incredible project that we suspect will be very useful for many folks to update their projects. [Justin] even includes an example GitHub action and a sample ESP32 project.

21 thoughts on “Push ESP32 Over The Air Updates From GitHub

    1. The esp bootloader can store multiple firmware images on flash and roll back to a “known” working image in case of failure (using a combination of watchdogs and flagging the currently running image as ok).
      You can even install a “factory” firmware image that is booted if all your “application” images fail.

      So with some careful thought you can get close to unbrickable.

  1. It looks like the only correctness checking is the SSL certificate used for the HTTPS connection? Which, assuming I’ve understood a very brief scan of the code, is a standard certificate bundle? I think this is good enough to ensure that you’re always going to get whatever image github is providing, but I’d kinda be happier with some additional safeguards against making sure that image isn’t something malicious…

    1. Agreed- I was looking through the code and unless espressif provides some sort of authentication under the hood, that currently isn’t implemented. I think it’s a somewhat reasonable approach as a man-in-the-middle isn’t impossible but the SSL makes it harder. Though I’m not sure what you need to do server validation. Based on the docs (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_http_client.html) you can turn on the secure element but I see in the code that the ESP x509 Certificate Bundle as referenced in the docs

      1. Author here: you have two options for this. The ESP can do “secure boot” type signing of firmware images and validate them when booting. This would happen outside of my library using the standard SDK/Bootloader.

        I’m also considering adding a SHASUM type file to each release, with a SHA of the firmware image. But this would only really be a defense against corrupted downloads. If someone hijacked GitHub it’s not going to help you.

  2. I believe the project name is misspelled in the article. esp_ghota not esp_ghosta. Nothing to do with ghosts, simply GitHubOTA.
    Otherwise, pretty nifty idea, gonna see if I can’t utilize it at some point.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.