Feature Request - ESP32 to send file

[krdarrah]

Hello - I'm using your code as a starting point for a project I'm thinking about where another ESP32 can act as the central to send the bin file. I'm the guy behind this board: https://espprogrammerdocs.readthedocs.io/en/latest/

So would be a nice fit if I can add BLE OTA to this... if you have time, let me know what you think... and in mean time I'll post my updates over here

[gb88]

Hi, it's a good point, I don't know if it's better to extend the function of your project or create a new one...just because your code is mainly for the complete programming and not for the OTA, anyway when I've some spare time I will work on it

[ParisMolver]

Hi there, I found this project and it is pretty incredible, I had so many surrounding bits together but without BLE OTA through web app, there was no magic without the possibility of FW updates.

This project suits me because ESP32 can have a max of 7 services and the default 0x1800/01 take up two. There is a better BLE file transfer library out there but it is more complex and consumes an entire service.

If you want more services, you need to go NRF, but that's not why I'm here. :)

I also have the same problem. I will hopefully be able to just reverse the transfer flow and split the library into FW update and file transfer. If I make any progress I will share my code.

File Receive (App to Device):
App Device
| |
|--- START_OTA/START_SPIFFS (COMMAND) -->|
|<-------------- ACK (COMMAND) ----------|
| |
|------ Send File Chunk 1 (RECV_FW) ---->|
|<-------------- ACK (RECV_FW) ----------|
| |
|------ Send File Chunk 2 (RECV_FW) ---->|
|<-------------- ACK (RECV_FW) ----------|
| ... |
|------ Send File Chunk N (RECV_FW) ---->|
|<-------------- ACK (RECV_FW) ----------|
| |
|----------- STOP_OTA (COMMAND) -------->|
|<-------------- ACK (COMMAND) ----------|

File Send (Device to App):
App Device
| |
|---- START_FILE_SEND (COMMAND) -------->|
|<------- FILE_INFO (COMMAND) -----------|
| |
|--- REQUEST_CHUNK 1 (COMMAND) --------->|
|<--- Send File Chunk 1 (RECV_FW) -------|
| |
|--- REQUEST_CHUNK 2 (COMMAND) --------->|
|<--- Send File Chunk 2 (RECV_FW) -------|
| ... |
|--- REQUEST_CHUNK N (COMMAND) --------->|
|<--- Send File Chunk N (RECV_FW) -------|
| |
|----- END_FILE_SEND (COMMAND) --------->|
|<-------------- ACK (COMMAND) ----------|

[gb88]

Thanks, the main interest is to start OTA from another ESP32 right?

[ParisMolver]

I will be forking the project as you have both the web app and the ota firmware and you may find file transfer out of scope. OTA also takes up a lot of memory so I need to reduce the amount of BLE libraries I use to accomplish my logger project. I think the problem I see with your wonderful project, and the OP probably saw too, is we just want 1 do it all file transfer library to fill in the gaps that the original arduino ble library can't fill due to scope.

I edited my previous comment to show how I understand it to work. I think if you reinterpret the RECV_FW characteristic to just a transfer line and the command characteristic as a control line you end up with the same simple solution you came up with, just that it works intuitively in both directions

[gb88]

Now i get the point, actually i've already implemented a file transfer protocol for BLE for a private project, and with some rework can be integrated in the OTA library, but the main point is to add the support only if the SD card or SPIFFS is used. But i think can be done. I know that the code is huge but is manly due to the BLE stack of Bluedroid. I've in the plan also to use Nimble to reduce the size.

[ParisMolver]

I think the Nimble and Bluedroid have the same function names so you just change your BLE class to be the Nimble type and there should be minimal code change.

With your project the app just pushes a file in segments by counting the acknowledge.

In reverse, the app could request the number of new records by giving the epoch of when it last downloaded from the device. It doesn't need an acknowledge this time because when it gets a new packet it increments its counter. If it gets stuck it just requests at the current counter.

I might be pushing my project into yours here but in the same sense, you could just get a full SPIFFS dump, or request a download with a FW command and have device to device OTA

[gb88]

Yes, but from my point of view is better to create a new service and a parallel project that can coexist with OTA to avoid to mess up the OTA.

[ParisMolver]

I've had time to digest and understand it better.

If you are just using the commands to control the transfer line, then the two projects could easily work together to control the command line. One of the things I am starting with is making it possible for a common command characteristic to interpret file request commands, OTA file commands, and generic commands (device restart, device FW/HW).

New GATT services and characteristics are a hot commodity on ESP32 and isolating your current work is probably the best play here so that you can continue to independently work on your project, whilst still making it easy to integrate into other projects.

Super excited to work with and improve on your work since it's the last thing I need to finish my project. Will keep you updated with any code I produce

[gb88]

Let me know about the progress

[M-D-777]

Hi，@ParisMolver

I'm planning to use this great BLE OTA library for my new project.

At the same time, I am also trying to implement file sending and more general commands based on this. I would like to ask if there is any progress on your project, thank you.