logo elektroda
logo elektroda
X
logo elektroda

How to use OTA without HTTP server or Web Application

max4elektroda 3480 37

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.
ADVERTISEMENT
📢 Listen (AI):
  • ADVERTISEMENT
  • #32 21368279
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12330
    The changes seem acceptable. W800 OTA is a good addition. Is it ready to merge?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #33 21368643
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    p.kaczmarek2 wrote:
    Is it ready to merge?

    It is, but while reading it again, I might squeeze some more bytes, let me check again if it's possible. Thanks

    Added after 9 [hours] 33 [minutes]:

    Did some small changes, from my side it should be ready to merge now.
  • ADVERTISEMENT
  • #34 21369912
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12330
    Good job, I'm very happy with your recent contributions! Merged.

    I'll be testing some W800/W600 soon, so this ota may come handy.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #35 21370197
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    great job @max4elektroda
    OpenW600 user interface with configuration buttons and device information.

    lmk if you want to see others in action
  • #36 21370479
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Good to hear it's kind of useful ;-)
    maybe @divadiow I can ask for your support again to do some testing on my new try to separate NTP and clock as a requirement to use other clock sources.
    Its https://github.com/openshwprojects/OpenBK7231T_App/pull/1483

    Since it involves changes to many files, it's getting merge conflicts very fast meaning I have to do the PR again ans again...

    This PR should only relocate and rename functions and only do one simple change to the system: The "clock" is present even if it's not synced or ntp driver not started.
    This allows to drop the special handling, e.g. in json_interface.c implementing a "fake" NTP returning 0 in case NTP is not present.
    Code snippet from OpenBK7231T_App repository with NTP functions.

    This implementation (e.g. "Clock_GetCurrentTime()") will always report time 0 as time in this case, so we can drop this code.

    I also fixed code which I believe was in wrong "#ifdef"s in cmd_if.c: there was a mix up of bl0937 and ntp code, no problem if both is defined but not working, if only ntp is active.

    Prominent example: $yesterday and $today - they sound like ntp functions and where in NTP section, but they will return the energy consumption for yesterday/today, so they belong to the BL0397 section...

    So if you could do some tests if all time related functions still work as expected?
    Especially the advanced features like sunrise/sunset and events?
    Thanks to @p.kaczmarek2 we have some basic tests already done be selftests, so it's not totally wrong ;-)
  • #37 21370723
    divadiow
    Level 38  
    Posts: 4845
    Help: 421
    Rate: 853
    ooh ok. Sure. I'll see what I can do, it may not be for a couple of days now though, as I fear tomorrow will be a write-off after this eve ;)
  • #38 21371436
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    No problem, first things first!
    Happy new year!
📢 Listen (AI):

Topic summary

✨ The discussion revolves around the challenges and solutions related to Over-The-Air (OTA) updates for devices, particularly focusing on the LN882H and XR809 models. Users encountered issues with OTA stability when using the Firefox browser, attributed to SDK code discrepancies. The conversation explores whether a web app is necessary for OTA updates, especially in scenarios without internet access. Suggestions for improving the OTA process include implementing filename checks, providing feedback during updates, and ensuring compatibility with various platforms. The need for a structured approach to file naming and validation is emphasized to prevent device bricking. Additionally, there are discussions about the implementation of OTA features across different platforms, including Beken and BL602 devices.
Generated by the language model.

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.
ADVERTISEMENT