You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There're currently some ways to upload an OTA firmware to a board where espurna is already flahed:
Manually uploading it via the web UI
using platformio upload task
using telnet, by providing the URL to the firmware binary
However, all of these are not easily to use while running in an CI/CD toolchain:
The manual upload via the web UI can be scripted easily with curl based on a request sniff from Chrome brwoser, e.g., however, the upgrade endpoint used for this is not documented and not public api, which means, it can change at any time, which may makes this solution a bit unstable.
Using platformio requires the espurna board to have access to a specific port on the host computer. This is not always possible, let it be because of a firewall blocking all incoming requests or a containerized setup, where only outgoing requests are mapped through NAT to the container, but not incoming traffic (the board would not be able to request the firmarwa from the platformio opened port). Requiring the user to open the firewall or whatever blocks the access for this port, which is used more or less rarely and is otherwise open, doesn't sound like a good solution, either.
Using telnet requires the user to setup an http server somewhere just to serve the firmware binary, which is a huge overhead.
This issue requests a rather simple, client-driven, approach for uploading the firmware. It's more or less based on the first way to upload the firmware to the board via the web UI. There's already a REST API, which allows to set different values. It would be nice to have an upgrade endpoint there, too, which takes the firmware.bin as the payload and updates the board accordingly.
The easiest solution here would be, to make the /upgrade endpoint public API and document it so, however, I'm not sure, if this is the best way of doing it. But maybe it's behavior can be taken as an example, as it's working pretty well currently with the following cURL command:
Good tip. Current API implementation is too focused on sending and receiving simple values and it would require a complete rewrite to support blobs... I'm not doing this atm because I think your approach is good enough.
There're currently some ways to upload an OTA firmware to a board where espurna is already flahed:
However, all of these are not easily to use while running in an CI/CD toolchain:
This issue requests a rather simple, client-driven, approach for uploading the firmware. It's more or less based on the first way to upload the firmware to the board via the web UI. There's already a REST API, which allows to set different values. It would be nice to have an upgrade endpoint there, too, which takes the firmware.bin as the payload and updates the board accordingly.
The easiest solution here would be, to make the /upgrade endpoint public API and document it so, however, I'm not sure, if this is the best way of doing it. But maybe it's behavior can be taken as an example, as it's working pretty well currently with the following cURL command:
The text was updated successfully, but these errors were encountered: