logo elektroda
logo elektroda
X
logo elektroda

How to use OTA without HTTP server or Web Application

max4elektroda  37 3480 Cool? (+4)
📢 Listen (AI):

TL;DR

  • A simplified OTA upload path for OpenBK7231T_App sends firmware directly to /api/ota without a separate HTTP server or web application.
  • The browser page uses fetch() with a file input to POST the selected firmware file, then calls /index?restart=1 after a successful upload.
  • The change was tested on LN882H, BK7231N, ESP32 and W800, and OTA support was also added for W800.
  • The approach skips file validation and is less comfortable than drag-and-drop, but it offers a simple offline update method.
Generated by the language model.
Some time ago I struggled over the unstable OTA with LN882H when using Firefox browser.

If you are interested in the whole story, you can read most of it following this post:
https://www.elektroda.com/rtvforum/topic4028087-240.html#21312889

It turned out, there was an issue with the SDKs OTA code and, since OBK uses the OTA code slightly differently, the buffer could be filled with more data than the code expected. And accessing memory outside the allocated space is usually no good idea ;-)

It took me several days to find the culprit and so I spent quite some time looking to the OTA code.

Since I also made basic tests to verify the operation, I learned it's "only" sending an HTTP POST request to the according page of the device.

And this led to the question, if you always need the (very useful) Web App, "only" to do an update?
O.k, you may ask, why not? I often use a single connection to the device with no internet, so in order to use the App, you need to "host" it locally (e.g. with a docker installation).

Since newer Browsers all support "fetch()", I could do a simple addition to the OTA page to upload the firmware.

<p>Upload firmware file for OTA - !!!Be aware, no file check is done!!!<p>
<input id='otafile' type='file'> <input type='button' class='bred' onclick='doota();' value='DO OTA - No file check - reboot after OTA'>
<script>
function doota(){ 
   var input = document.getElementById('otafile');
   if (input.files[0]){
      fetch('/api/ota', {
         method: 'POST',
         body: input.files[0]}
      ).then((resp) => {
         if(resp.ok){
            console.log('ota successfull; rebooting');
            fetch('/index?restart=1');
         } 
         else console.log('ota not successfull');
      }
   }
   else alert('no file selected')
}
</script>

It's not so comfortable like using drag and drop in the App, there is no check for the file provided - but in the end it provides a very simple solution.

For now I could only test on the devices I own: LN882H, BK7231N, ESP32 and W800 (I added OTA for W800 while at it ;-).
Test for other platforms would be great.

The actual pull request is here:

https://github.com/openshwprojects/OpenBK7231T_App/pull/1471

Seeing it in action on a W800




PS: Since W800 code seems to have a simmilar problem like the LN882H code which needed some changes, I'm quite sure, this will be also an issue with W600. But since I don't own one, I didn't made changes here.
Maybe in a seperate PR

About Author
max4elektroda wrote 745 posts with rating 183 , helped 47 times. Been with us since 2024 year.

Comments

divadiow 19 Dec 2024 23:31

Oh nice work. Hopefully I can play with it on other platforms before going away for Christmas. I'm guessing XR809 is excluded from the above? The build doesn't generate the ota file to test anyway.... [Read more]

max4elektroda 20 Dec 2024 04:45

I can check the code, but it will be a theoretical look, for I can't test. Maybe the buffer problem again? [Read more]

divadiow 20 Dec 2024 08:37

oh no pressure, no one has XR809 it seems. Was just curious. :) Added after 39 [minutes]: W600 https://obrazki.elektroda.pl/1033411900_1734677973_thumb.jpg Added after 10 [minutes]: ... [Read more]

p.kaczmarek2 20 Dec 2024 08:48

Very nice, but we need a simple filename check like: <script> function doota() { var input = document.getElementById('otafile'); if (input.files[0]) { var filename = input.files[0].name; ... [Read more]

divadiow 20 Dec 2024 09:03

Generally though, I did recently wonder about a small note in the web app OTA tab about OTA not being for XR809 and now TR6260. And now that would apply to this new feature. Added after 11 [minutes]:... [Read more]

p.kaczmarek2 20 Dec 2024 09:04

This new "alternate OTA" message could be improved. Maybe something like "developer OTA - use Web App [LINK] instead if possible". [Read more]

divadiow 20 Dec 2024 09:34

Back to main testing. There's a problem with BK-T OTA https://obrazki.elektroda.pl/5046196200_1734683635_thumb.jpg Flashed back to Tuya factory from 0x11000-200000 after that and started again.... [Read more]

max4elektroda 20 Dec 2024 09:44

Sure, there is much room for improvement ;-) First thing will be a simple accept=".<OTA extension>" based on the platform. Regarding N/T discussion @pkaczmarek2 : Do you recall any reason for... [Read more]

divadiow 20 Dec 2024 09:44

(also I can redo other platforms with log view if wanted) [Read more]

max4elektroda 20 Dec 2024 09:47

Maybe my testing super hero @divadiow could test if the artifacts whith the "tuned" header work as OTA for Beken N and T as expected? [Read more]

p.kaczmarek2 20 Dec 2024 09:54

@max4elektroda It's Beken leftover, we can change it if it helps @divadiow https://obrazki.elektroda.pl/6386424600_1734684523_bigthumb.jpg https://obrazki.elektroda.pl/6451114600_1734684584_bigthumb.jpg... [Read more]

divadiow 20 Dec 2024 09:59

yes did you just need to wait longer and first attempt would have flashed OK? oh! interesting. I could try with another T real device I guess, I only have one T module loose. Or maybe I blow... [Read more]

p.kaczmarek2 20 Dec 2024 10:01

on the first attempt I clicked the button like 5 times so I expect that something has messed up in OTA partition, maybe concurrent HTTP POSTs (or what is used there) wrote file parts in random order etc... [Read more]

max4elektroda 20 Dec 2024 10:33

O.k. I see, first thing to do is some kind of feedback. You don't even see the most obvoius things sometimes ;-) [Read more]

p.kaczmarek2 20 Dec 2024 11:41

I'd just.... hide/disable those OTA fields when OTA is active. There is no possibly scenario when they are needed when OTA is already running. So... 1. when sending your OTA, refresh whole page 2.... [Read more]

max4elektroda 20 Dec 2024 13:14

Thanks for your suggestions, I'll try later. In the meantime I wrote a simple function to check rbl updates, here for N version, if we can agree on setting product in rbl-header (just as a complete page... [Read more]

divadiow 20 Dec 2024 15:48

bitbang erased and reflashed a Tuya T factory. Now OTAs fine, so false alarm. https://obrazki.elektroda.pl/7134542100_1734703067_thumb.jpg That app partition error is interesting, I've never... [Read more]

max4elektroda 20 Dec 2024 16:15

Nope, this was just to alter the variables in the rbl header of Beken N/T devices. This way it's easy to distinguish between the images. Thanks for testing, looks like this doesn't break the images,... [Read more]

max4elektroda 21 Dec 2024 18:11

After thinking about this again, I would like to discuss this "request". My arguments: 1. OBK devices are "single user devices" - you will usually not see multiple users access one device. 2. OTA... [Read more]

FAQ

TL;DR: In about 30 seconds, the new built-in OTA page lets OpenBeken users update firmware with a browser file upload and a simple POST request, no hosted Web App required. As one developer put it, "only" sending an HTTP POST request is enough. It solves offline flashing for single-device setups on LN882H, BK7231N/T, ESP32, W800, and more. [#21355226]

Why it matters: This gives OpenBK users a practical offline OTA path when they have only a direct device connection and no local HTTP hosting.

Method Needs hosted Web App Offline-friendly File checks UX feedback
Web App OTA Yes Limited unless hosted locally Better established Better drag-and-drop
Built-in developer OTA page No Yes Initially minimal, later improved Initially weak, later modal-based
Raw HTTP POST to /api/ota No Yes None by itself None by itself

Key insight: The breakthrough was not a new OTA protocol. It was realizing the device already accepts a standard browser upload to /api/ota, so OpenBeken could add a lightweight built-in OTA page instead of depending on a separate web application. [#21355226]

Quick Facts

  • Initial testing covered 4 platforms directly owned by the author: LN882H, BK7231N, ESP32, and W800. W800 OTA support was added during the work. [#21355226]
  • OTA on OpenBK devices takes about 30 s total, and the device stays responsive for roughly 10–15 s of that time. That short visible window is why missing UI feedback caused repeated clicks. [#21357676]
  • One browser-side validation prototype read only the first 32 bytes of the selected file to inspect RBL magic and platform markers before upload. [#21356155]
  • A proposed UI fix was to block duplicate submissions: if OTA is already active, refresh the page and show a large "Already running" message instead of exposing upload controls again. [#21356037]
  • Cross-platform protection exists on some chips: when a W600 OTA image is sent to W800, the update fails with Error:OTA:Image header check failed instead of flashing. [#21359775]

How can I perform OTA firmware updates in OpenBK7231T_App without using the Web App, HTTP server hosting, or a separate local web application?

You can use the device’s built-in web page and upload the firmware directly from the browser. The method adds a file input and a button, then sends the selected file with fetch('/api/ota', { method: 'POST', body: file }). 1. Open the device page. 2. Select the OTA file. 3. Click the OTA button and let the device reboot. This was created for single-device, no-internet setups where hosting the Web App locally is inconvenient. [#21355226]

What is OTA in the context of OpenBK/OpenBeken devices, and how does the built-in browser upload method work?

OTA is a firmware update process that writes a new image over the network instead of UART flashing. The built-in method works by sending one HTTP POST request from the browser to /api/ota, with the firmware file as the request body. If the response is OK, the page can trigger /index?restart=1 to reboot. That makes the new page a thin client over the same device-side OTA mechanism already used by the Web App. [#21355226]

Why was OTA unstable on the LN882H in Firefox, and what SDK buffer issue was identified as the cause?

OTA was unstable because the LN882H SDK OTA code could receive more data than its buffer handling expected. OpenBK used the OTA code slightly differently, and that allowed the buffer to fill past the allocated space. The developer traced the bug after several days of debugging and identified an out-of-bounds memory access. That explains why Firefox-triggered OTA behaved inconsistently until the SDK-side handling was reviewed. [#21355226]

What is an RBL file in Beken OTA updates, and why does its header matter for BK7231N and BK7231T safety checks?

"RBL" is a Beken OTA firmware container that stores the image plus a fixed header, including magic bytes, metadata, and identity fields. That header matters because BK7231N and BK7231T originally used a generic app name, which made them harder to distinguish safely during OTA. The thread showed the RBL header layout and proposed using a real platform name in the name field so browser-side or tool-side checks can reject the wrong image earlier. [#21355867]

OpenBK Web App OTA vs the new built-in developer OTA page: which approach is better for offline flashing and why?

The built-in developer OTA page is better for offline flashing when you have only a direct device connection. It runs from the device itself, so you do not need to host the Web App locally with Docker or another HTTP server. The Web App still offers a nicer drag-and-drop experience and more mature checks. A core maintainer suggested labeling the built-in path as a developer OTA and recommending the Web App when available. [#21355823]

Why can flashing a BK7231N RBL onto a BK7231T device brick it, and what filename or header checks help prevent that?

It can brick the device because the internal Beken RBL check does not reliably distinguish BK7231N from BK7231T images. A maintainer explicitly warned that this limitation can brick hardware if the wrong RBL is accepted. The proposed protection was simple but effective: require a platform-specific filename prefix made at compile time, and later improve the RBL header so the image carries the real platform name instead of generic app. [#21355803]

Which platforms were tested with the alternate OTA upload feature in OpenBK7231T_App, and what platform limitations were reported for XR809 and TR6260?

The alternate OTA upload was directly tested on LN882H, BK7231N, ESP32, and W800. W600 was then tested by another participant and shown working. XR809 was reported as a known non-working OTA platform because its SDK fetches the file but the update still fails. Another participant noted the Web App already warns for XR809 and now TR6260, so the same limitation should also be reflected in this new built-in feature. [#21355815]

How should OTA file validation be implemented in the browser for OpenBeken devices: extension filtering, filename templates, or firmware header inspection?

The thread ended up favoring strict filename template checks as the practical default. Early suggestions included extension filtering such as .rbl, .bin.xz, or .img, plus deeper firmware header inspection for Beken RBL files. After more discussion, the author proposed matching platform-specific names like /OpenLN882H_.*_OTA.bin/, showing a warning on mismatch, and blocking upload when the name does not fit. That gives broad coverage without heavy per-platform parsing logic. [#21359223]

What feedback should the OpenBeken web UI show during OTA so users do not click the upload button multiple times or start concurrent POST requests?

The UI should immediately lock out repeated actions and show clear OTA state. One maintainer proposed three concrete steps: 1. refresh the whole page when OTA starts, 2. if OTA is running, show a big Already running message, 3. display OTA progress HTML on every page, not only the index page. This prevents multiple button presses while the upload is still active and reduces accidental concurrent POST requests. [#21356037]

Why might BK7231T OTA appear to do nothing at first, and how can lack of progress feedback mislead users during flashing?

BK7231T OTA can look idle because the upload starts without visible confirmation. Testers reported clicking the button and seeing nothing happen, even though the transfer later completed and the device rebooted on the old or new firmware. That missing feedback encouraged repeated clicks. One maintainer then warned that clicking the button five times on the first attempt may have corrupted the OTA partition through overlapping submissions or out-of-order writes. [#21355896]

What changes were proposed to the Beken RBL header so BK7231N and BK7231T images can be distinguished more safely during OTA?

The proposal was to stop using the generic app part name and write the real platform into the RBL header name field. Test artifacts showed headers changed from app to OpenBK7231N or OpenBK7231T, making browser-side checks and tool-based checks much safer. The author confirmed this did not break the images in testing. That change turns header inspection into a useful platform discriminator instead of a weak generic marker. [#21356373]

Which BL602 firmware file should be selected for OTA in OpenBeken when several build artifacts contain 'ota' in the filename?

Use the .bin.xz.ota file for BL602 OTA. A tester answered this directly when asked which of several artifacts containing ota was correct. That clarification matters because BL602 builds may contain multiple output files, and selecting the wrong one defeats simple extension-based filtering. In this case, the OTA target format is the compressed .bin.xz.ota artifact, not a generic .img or plain .bin. [#21357691]

How does OpenBeken decide which OTA file extension to accept on each platform, such as .rbl, .bin, .bin.xz.ota, or .img?

OpenBeken maps the accepted OTA extension to the platform. The thread examples were: Beken uses .rbl, LN882H uses .bin, BL602 uses .bin.xz.ota, and many other OTA-capable platforms use .img. Later, the implementation moved that mapping into per-platform configuration so the web UI could render the correct accept= value automatically. That keeps file dialogs aligned with the actual OTA artifact expected by each target. [#21360349]

What happens when a W600 OTA image is flashed to a W800 device, and how does image header verification handle cross-platform mistakes?

The OTA update fails instead of flashing successfully. The author tested the W600-to-W800 mismatch path and reported a direct error: Error:OTA:Image header check failed. That means this platform pair has content-level verification beyond filename filtering. So even if a wrong file slips past the browser accept rule or a user forces the upload, the device-side image header check still blocks the cross-platform mistake. [#21359775]

Why was the OBK_OTA_EXTENSION define moved into obk_config.h, and how does that simplify adding OTA support for new platforms?

It was moved into obk_config.h to centralize per-platform OTA file rules in one place. The author replaced NO_PLATFORM_OTA with #ifndef OBK_OTA_EXTENSION, then defined OBK_OTA_EXTENSION for each OTA-capable target. That lets http_fns.c use one generic line for the file input instead of a long block of platform-specific #if checks. The result is simpler maintenance and a cleaner path when adding support for a new chip. [#21360349]
Generated by the language model.
%}