[Must Read] V3 Project Plan & Features

Hello everyone!

It has been 3 years since I created this library and it has received unprecedented love from the open-source community which has been the driving force to keep enhancing this library.

Today marks as a stepping stone for V3 of ElegantOTA which will further reduce the size of webpage, add exciting new features, potential bug fixes with new optimized source code and most importantly support for new microcontrollers.

To make this possible, I'll need your help in figuring out what's best and what you guys need in ElegantOTA. So comment down any feature you feel is missing in ElegantOTA and I'll add it in my project plan.

Supporting New Platforms:
For past 3 years ElegantOTA has been stuck with ESP32 and ESP8266 but now I wish to increase the coverage of ElegantOTA so that more people can make use of it to update their microcontroller conveniently. If you know or work with any microcontroller ( other than ESP32 or ESP8266 ) that has OTA capability please write it down in the comments below. I'll look into it.

The microcontroller doesn't necessarily needs to have in-built WiFi, it can also be a NCP ( Network Co-Processor ) architecture like Nano 33 IoT.

@ayushsharma82

Hey, @ayushsharma82,
How about the compressed updates support? For esp8266 it's pretty easy out of the box since it's supported by eboot code, just need to add file format detection.
For esp32 you need some additional code to decompress an upload on the fly.
Not so long ago I've made a small lib implementing zlib-compressed OTA uploads for ESP32.
Should be pretty easy to adopt your project to use esp32-flashz. Let me know if you like the idea, I may come up with PoC PR or something.
Cheers!

@vortigont

@vortigont Good Idea! That will be much appreciated and it will also ensure quick uploads for those who are experiencing upload issues due to signal loss.

I'd like to be able to upload cryptographic keys at the first installation.
I don't have an exact workflow how this could be done, but on a conceptual level both encryption and signing would be nice.

Before uploading a new OTA file, the certificate has been deployed to the device as part of the initial installation.

ElegantOTA then require a file encrypted and/or signed with the private file. The device then cannot be updated without having access to the private certificate file.

@silverfisk

@silverfisk That will be a nice addition as well.

We can use an approach with AES128-CBC or AES256-CBC encryption where we have a logic to buffer incoming chunks from the HTTP server and pass the buffer with correct length for decryption on-the-fly. As with CBC based encryption we already know the block size, we will be able to decrypt the file as we receive it from the user.

I'm only concerned about the performance drawback which will be incurred due to decryption, I hope it doesn't deter the HTTP upload process.

Very nice overall suggestions from the community! Love it.

If anybody knows a public key cipher which can work with parallel computing ( decrypting ), then please do let us know. I really prefer public key cryptography in IoT.

Till then, I only see AES to work as it's successfully implemented on the hardware level and in SDK.

asymmetric crypto is veeery slow, so it is used only for key exchange for symmetric ciphers.
i.e. it makes no sense to encrypt/decrypt the firmware during upload and flashing. Only to sign the update and provide keys and certs.

@vortigont

@vortigont how slow are we talking?

At least signing would be nice to validate the binary. But if it's too slow to decrypt perhaps it's better to use HTTPS to encapsulate the payload in symmetric encryption?
The binary will still contain the WiFi password and be treated as a secret though.

@silverfisk

@silverfisk the difference is huge, 3-5 orders of magnitude or so
AES

openssl speed aes-128-cbc
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc    1724778.47k  2039762.90k  2088857.86k  2083973.46k  2101630.29k  2093569.37k

RSA

openssl speed rsa2048
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x18c05fdef3bfa7eb 
                                sign    verify    sign/s verify/s
rsa 2048 bits 0.000239s 0.000015s   4183.0  68721.9

actually I do not know any real life use case for asymmetric crypto other than KEX or signatures.

HTTPS for fw transfer is definitely right approach to secure the transfer itself. Other than this Espressif has all the required features for signed fw in their SDK, no need to reinvent the wheel. I'm not that deep into this area, mostly use open source firmware's for my needs :)

@vortigont

@vortigont Nice info regarding ciphers. Let's see if we can get at least the firmware signing integrated. Espressif does provide features like SecureBoot V2 and encryption but for ESP32 only. I'm going to make this library supported on other platforms as well so it will be a very important feature to have.

@ayushsharma82

@ayushsharma82
it's going to be a real pain to fit different arch'es into one lib, especially with things like encryption, lib dependencies, etc... You might wanna think twice about the design before stepping that sloppy road :) Might worth splitting the project into separate front-end/back-end parts. Well, anyway it's just a plans, isn't it? :)))

As for compression, I've done some dirty sketching and your front-end works pretty well with my flashz lib. Although there are some gaps that needs to be considered. Maybe open a discussion thread for this?

@vortigont

@vortigont You are pretty fast :)) I'll open a discussion thread. I did some renovations in past few days which switched the webpage from ancient 'Vuejs 2' to SvelteJS framework ( 73%~ size reduction - 54KB ( old ) to 15KB ( new ) ) and changed C++ library structure.

Do you want to wait for the changes to be live in a v3 branch? Or you can integrate it in the current version and I'll port it to V3 for you. ( whichever way you prefer )

Here's a sneak peak:

I'm a fairly new user of ElegantOTA, but I absolutely love it! Great work!

I did think of one thing I wish it did. Before I found this thread, I took a quick look at the source code and I am pretty sure this is not a current feature of ElegantOTA, so let me suggest here. My apologies if this has already been brought up before...

My ESP32 apps often use a LCD display. When the OTA update executes, the LCD just goes blank until the ESP32 reboots on the newly downloaded .bin file.

I would like to be able to flash a message on the LCD stating that an OTA update is in progress, please wait. Not sure the best way to implement this, but one would be to add the ability to register a callback function pointer. By default, this function pointer would be null so nothing would be any different from now. But if the app had registered the function pointer, the function would get called one or more times (you decide) to inform the application that an OTA update is starting, finished, rebooting, whatever. You will know far better than I what state ElegantOTA goes through internally and will know which states it may be useful for the app to know about. I also would not have the callback function pass any actual message text; I think it would be better to simply pass an integer value that has one or more values defined. Let the app itself create the message it wants to display based on this integer code, the type of output device it has access to, etc.

Another advantage of this would be for apps that have some sort of logging mechanism, or work in conjunction with other processors via MQTT. It would allow the app to log the OTA occurrence, broadcast a MQTT message, etc.

It would be SUPER nice (but definitely an extra) if information on the .bin file that is being installed was passed; perhaps file name, file update timestamp, etc. I assume (from much low-level prior experience with HTTP on other platforms) that there is probably already a way to get info on the remote client (the IP address) that executed the OTA.

As many of you I integrated this library into my project and it worked flawlessly in a matter of minutes.
The only lack I feel in my project is that when file is being uploaded it doesn't pass any file name or firmware type inspection before flashing. The firmware type is defined by 'radio' button only.
I afraid that someone of my project users will select 'Firmware' type but upload 'Filesystem' bin file (or vise versa).
Am I missing anything?

I use version 2.2.6 with some custom modifications.
I wanted to modify JS code to perform some basic file name check, but the code seems too complicated for me.
Even if file name will be transferred to the host controller for local inspection, it will be great.

@dmitrykez

@dmitrykez I like your idea and I thought I would expand on it.

It would be great if something like you would upload a zip file which would contain a config file and the firmware or file system or both. The config file would contain the names of the firmware/filesystem to be applied and a md5/sha hash for each file which the esp32 could compare to the hash listed in the config file. If the hashes do not match then the upgrade would not be completed and you would have to re upload. The config file could also possibly contain version numbers so it could only apply newer versions and not older version.

@doanerock

@doanerock For debug purposes I need to downgrade sometimes.
But all the rest is exactly what I thought.

Hello,

I have tried your library on the ESP8266 and liked it very much. However, I would like to migrate my project to the raspberry pi pico W now. Can you provide a version for this micro? I would be ready to test...

@DiverBW

@DiverBW , Someone recently created a pull request with exactly these "callbacks" added in the code. Soon I'll release it under the same v2 source.

Thanks for the comment!

Hi is it possible to not require STA mode but say, use AP mode so that a client (eg. Smartphone could connect with the sole purpose of performing a remote upload? I have used elegant no problems in my own wifi LAN (and a commercially available alternative supporting remote OTA over the internet) but in some use cases there is no wifi LAN, or at least none with access permission or credentials known. A workaround is a small battery powered wifi router I have to carry with me; but surely this could be done in software?

@robhellstrom

@robhellstrom I was thinking the same and then integrate it with a WiFiManager as well so the AP mode has one entry point to set both the WiFi and do an OTA upgrade.
In my particular case this would be nice for hard to reach ESPs that dont always have a router available.
Also in regular operation i switch off the WiFi to save power and i dont even create instances for WiFi Manager etc. to have a bigger heap/stack.

Hi, it will be great to be able to call the url with all variables already in it: IP + FW filename and then the FW update starts automatically without further screen input and button presses

e.g.
ip/update/ x??x "fw filename & path" + button submitted

By sending the URL to the browser the IP should be started and the fw file selected and added and start the OTA automatically.

Perhaps a 2nd page to call without any nice to haves or graphics even to speed up the process.
i.e. you have now "IP/update". 2nd page will be "IP/aupdate". then add on the URL the file name and the FW update starts as soon as URL is submitted

A bit update on the previous V3 plan. It is now divided in 2 phases.

Phase 1 is already done where I update the library to include improvements, UI optimization and gear it towards almost all wireless platforms instead of just focusing on ESP devices.

Phase 2 will commence in a few months where Cloud support will be added to the library.

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

This issue was closed because it has been stalled for 5 days with no activity.

Navigation Menu

[Must Read] V3 Project Plan & Features #86

24 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Must Read] V3 Project Plan & Features #86

Description

Activity

vortigont commented on Jun 27, 2022

ayushsharma82 commented on Jun 28, 2022

silverfisk commented on Jun 29, 2022

ayushsharma82 commented on Jun 30, 2022

ayushsharma82 commented on Jun 30, 2022

vortigont commented on Jun 30, 2022

silverfisk commented on Jun 30, 2022

vortigont commented on Jul 1, 2022

ayushsharma82 commented on Jul 1, 2022

vortigont commented on Jul 1, 2022

ayushsharma82 commented on Jul 1, 2022

24 remaining items

DiverBW commented on Oct 15, 2022

dmitrykez commented on Oct 21, 2022

doanerock commented on Oct 22, 2022

dmitrykez commented on Oct 22, 2022

mclane commented on Nov 3, 2022

ayushsharma82 commented on Apr 23, 2023

robhellstrom commented on May 8, 2023

wimmatthijs commented on May 12, 2023

MikeF5J commented on Jul 28, 2023

ayushsharma82 commented on Sep 23, 2023

github-actions commented on Jul 2, 2024

github-actions commented on Jul 8, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions