[Request] OTA Update via URL

[D3R-ST3FAN]

Is your feature request related to a problem? Please describe.

I have a couple of neighbors that now also run OpenDTU.
They are not into self compiling (they are using the Olimex POE Variant).
I do compile binaries for them and make it available via a URL.
But they still have do the OTA Upload via WebIF.

What about OTA Update via URL? Like e.g. tasmota does.

Describe the solution you'd like

introduce a field to provide an OTA URL and an Update button.

Describe alternatives you've considered

No response

Additional context

No response

[stefan123t]

Tasmota uses safeboot to ensure OTA update via OTA URL does not break things.

See OTA_URL and OtaUrl in

• https://github.com/arendst/Tasmota/tree/master/tasmota/berry/modules/Partition_Wizard/partition_wizard.be
• https://github.com/arendst/Tasmota/tree/master/tasmota/berry/animate_demo/leds_animation.be

I do not know if we have enough space for app0 and app1 partitions to store two firmware images side-by-side ?

[CommanderRedYT]

@stefan123t It is a/b partitions, right? I know that the esp-idf has some flag for marking a partition as good.

When you use this, it is initially marked as bad, so in case something crashes, the bootloader goes back to the old image.

The code can do checks and when it thinks its valid (and maybe after 1 minute) and then mark the partition.

https://docs.espressif.com/projects/esp-idf/en/v5.3.1/esp32/api-reference/system/ota.html#app-rollback

[stefan123t]

@CommanderRedYT thanks for adding the ESP-IDF context. I thought that there is two boot environments provided by so called safeboot in Tasmota. But this explains the underlying working principle, Thanks!
For me the question is more how big can we make such an app image. If we consider 4MB of the average ESP32 flash mem, it can be max 2x~1.8MB to leave some slack for the safeboot loader and the basic pin_mapping.json and config.json on the SPIFFS.
At the moment we start to require 8MB ESP32S3 for eg OpenDTU-OnBattery in order to fit all the extra functionality, ie this might work then but nly on a newer ESP32S3 with 16MB for such large app images.
Maybe this ratio gets a bit better if we can source out the NLS strings into some shared dictionary / JSON archive that we can import into the Vue app. See PR #1679 / #1830 for @tbnobody|s forthcoming ideas into that direction.

[CommanderRedYT]

https://github.com/tbnobody/OpenDTU/blob/master/partitions_custom_4mb.csv

I believe this is the partition table. I would propose the following.

We have two options:

a)

Our chip is 4MB. We can easily allow for two app partitions, however things like more languages can be disabled and added via language packs at runtime. (Maybe be able to swap one language with another? Also maybe client side only?)

b)

Our chip is 8MB or larger. We can store all the information in a app partition so we do not need language packs.

Both variants do not need this safeboot as the functionality is part of esp-idf.

Safeboot is different to a/b partitions as it only uses one app partition (which therefore can be larger).

With safeboot I see two problems:

1. It cannot perform a rollback. Right now, if implemented, we can add a button to switch app partitions and therefore allow the user to rollback to the previously installed firmware.

2. It would require to update the partition table. In theory, you can even do this via OTA but I would recommend to not do that.

FYI @tbnobody maybe this helps with deciding how to proceed