search

SOTAmat / SOTAcat

CAT control for Elecraft KX radios and SOTAMAT
https://sotamat.com
Other
9 stars 2 forks source link

Implement OTA updates #13

Open jeffkowalski opened 4 months ago

jeffkowalski commented 4 months ago

Brian says: OTA updates would be wonderful. However, we are nearly at the 2MB limit and OTA requires 3X the storage. We can double our memory because PlatformIO thinks our board only has 2MB of storage when in fact it has 4MB. We need to twiddle a setting.

jeffkowalski commented 3 months ago

Just some background: https://blog.espressif.com/ota-updates-framework-ab5438e30c12

brianmathews commented 3 months ago

Note, I found the bug where our module was being sensed as only 2MB Flash, when in fact we have 4MB flash. That issue was fixed in an earlier check-in. So OTA is very much possible now that we have access to the full 4MB.

jeffkowalski commented 3 months ago

I think that was fixed in 923b60148b2fe55c2a9f7a633c6099469deb784d I've been looking into OTA. One thing to decide - does the user upload a .bin that they've downloaded from somewhere, or should we "check for updates" against a known URL?

brianmathews commented 3 months ago

I would check for updates against a known location such as the sotamat.com web server. GitHub LFS does not allow us to purge old versions and storage counts against the free tier quota. Hence we should use some non-GitHub web server.

We also want to make the process as simple as possible for non-developers. Developers can build their own source from GitHub.

jeffkowalski commented 2 months ago

(Note to self, more background information) see https://gitlab.com/kevinwolfe/esp32_template/-/blob/87ca0ecd615115fdc33013d45b84a237da230575/main/main.c for example

jeffkowalski commented 2 months ago

@brianmathews Please give me a URL on sotamat.com where I can check for "official" releases of SOTAcat. I'd like to implement the "check for new version" feature, which is a component of OTA updates.

Ideally, official releases would have version and checksum encoding built into their filenames. The greatest version, or most-recently-dated version would could be used to determine freshness relative to the user's current version. The checksum would be used to validate the downloaded contents. That could be stored in a separate file (i.e. Vnnnnn-checksum.txt). Another thing to consider is perhaps having a "latest.txt" which contains the filename and checksum for the most recent release (or just the filename, if the checksum is embedded in it). That would greatly simplify client-side checking, but might complicate the release process.

brianmathews commented 2 months ago

You can name the file(s) anything you want. They will just be part of the Wordpress Media folder as files in the pattern:

https://sotamat.com/wp-content/uploads/YOUR-FILENAME-HERE

...and I am assuming that our releases are infrequent enough that we can just manually publish a new release after testing. If you want automated builds with automated deployment onto the Wordpress site, then we'd need to invest more thought into this.

jeffkowalski commented 2 months ago

Excellent. What will be the protocol for:

  1. Identifying release-able commit-points
  2. Building the code
  3. Uploading and naming the file. (who has access)
  4. Updating the "latest.txt" at the same place, if we assume to go that route. Can you envision a script for 2-4? MakeRelease.sh? ;)
brianmathews commented 2 months ago

For the 1-click WebSerial deployment that is on the https://sotamat.com/sotacat page, the BIN file and version files are already scripted and part of the build process. For OTA we can extend the build process to make the required files on every build. When we want to publish I just drag-n-drop the set of files into Wordpress's Media Bin and voila. If you look at how the current unified BIN file is made in the platformio.ini file and the respective Python build extensions to PlatformIO you can see how you can do something very similar. for 2,3,4: it's just I'd do 2,3,4 on every build (if it is fast) and simply put those assets in the .gitignore. I can drag-n-drop into Wordpress when we want a real "release".

jeffkowalski commented 2 months ago

We may want a different unified BIN that doesn't blow away settings in NVS. Maybe one that just packs code and web assets. Different build script?

On Wed, Apr 17, 2024 at 11:21 PM Brian Mathews @.***> wrote:

For the 1-click WebSerial deployment that is on the https://sotamat.com/sotacat page, the BIN file and version files are already scripted and part of the build process. For OTA we can extend the build process to make the required files on every build. When we want to publish I just drag-n-drop the set of files into Wordpress's Media Bin and voila. If you look at how the current unified BIN file is made in the platformio.ini file and the respective Python build extensions to PlatformIO you can see how you can do something very similar. for 2,3,4: it's just I'd do 2,3,4 on every build (if it is fast) and simply put those assets in the .gitignore. I can drag-n-drop into Wordpress when we want a real "release".

— Reply to this email directly, view it on GitHub https://github.com/SOTAmat/SOTAcat/issues/13#issuecomment-2063086412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN4MCE6QBZMWKKBGWJNMLY55Q73AVCNFSM6AAAAABDUHE25SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRTGA4DMNBRGI . You are receiving this because you authored the thread.Message ID: @.***>