logo elektroda
logo elektroda
X
logo elektroda

How to use OTA without HTTP server or Web Application

max4elektroda 3477 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):
  • 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

    Cool? Ranking DIY
    About Author
    max4elektroda
    Level 24  
    Offline 
    max4elektroda wrote 745 posts with rating 183, helped 47 times. Been with us since 2024 year.
  • ADVERTISEMENT
  • #2 21355605
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    max4elektroda wrote:
    added OTA for W800 while at it


    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. Ref: https://www.elektroda.com/rtvforum/topic4055254.html#21131128
  • #3 21355700
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I can check the code, but it will be a theoretical look, for I can't test.
    Maybe the buffer problem again?
  • ADVERTISEMENT
  • Helpful post
    #4 21355740
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    oh no pressure, no one has XR809 it seems. Was just curious. :)

    Added after 39 [minutes]:

    W600
    OpenW600 user interface for OTA file updates.

    Added after 10 [minutes]:

    OpenBL602 website for OTA firmware update.

    Added after 15 [minutes]:

    Screenshot of the OpenESP32S3_DAA2CE60 webpage for OTA updates.

    Added after 11 [minutes]:

    I guess my main feedback is the obvious bits already mentioned, of course bearing in mind it is a WIP

    -ota file sanity check
    -ota file extension filter on open dialog box - eg *.rbl, *.bin.xz
    -no feedback about submission/start
    -no obvious progress (in the case of Beken flash address feedback)
  • #5 21355803
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12329
    Very nice, but we need a simple filename check like:
    Code: Javascript
    Log in, to see the code

    This is needed for BK7231T and BK7231N because their internal RBL check is not able to check if RBL is for T or N and can brick device.

    Just replace "SOMETHING_HERE" with firmware prefix made at compile time from existing defines and it will be good.

    Added after 2 [minutes]:

    divadiow wrote:

    I'm guessing XR809 is excluded from the above? The build doesn't generate the ota file to test anyway. Ref: https://www.elektroda.com/rtvforum/topic4055254.html#21131128

    XR809 OTA was never working. I've tried many times, the XR809 SDK code seems to fetch the OTA file but OTA fails somehow. You can see my debug prints here:
    https://github.com/openshwprojects/OpenXR809/commit/6da576fdb1f2899a28f5d24696a9b9d48efefad6
    Helpful post? Buy me a coffee.
  • #6 21355815
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    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]:

    here's BK-N ->T brick, just cos I wanted to see it.
    OTA update interface for OpenBK7231N device with connection logs and system information.
  • #7 21355823
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12329
    This new "alternate OTA" message could be improved. Maybe something like "developer OTA - use Web App [LINK] instead if possible".
    Helpful post? Buy me a coffee.
  • #8 21355858
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    Back to main testing. There's a problem with BK-T OTA

    Screenshot of the console logs and OpenBK7231T web interface.

    Flashed back to Tuya factory from 0x11000-200000 after that and started again. Same.
  • #9 21355867
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Sure, there is much room for improvement ;-)
    First thing will be a simple accept=".<OTA extension>" based on the platform.

    Regarding N/T discussion @p.kaczmarek2 : Do you recall any reason for setting the "partname" in the OTA files to "app" instead of the platform?

    It seems this code is correct: https://github.com/tiancj/rtt_ota_tools/blob/...3a9877f3bef25a1df2a0de352857/ota_tools.c#L33:

    struct rt_ota_rbl_hdr {
       char     magic[4];      // 0x0
       uint32_t algo;      // 0x4
       uint32_t timestamp; // 0x8
       char     name[16];      // 0xc
       char     version[24];   // 0x1c
       char     sn[24];      // 0x34
       uint32_t crc32;      // 0x4c
       uint32_t hash;      // 0x50
       uint32_t size_raw;   // 0x54
       uint32_t size_package; // 0x58
       uint32_t info_crc32; // 0x5c
    };
    




    If we changed at least "name" to the real platform, I think we could do a simlpe test for this case.
    Original headers look like this:
    $ head -n 1 OpenBK7231N*.rbl | hexdump -C
    00000000  52 42 4c 00 02 01 00 00  f8 0f 0e 67 61 70 70 00  |RBL........gapp.|
    00000010  80 7b cf 48 d0 7f 00 00  70 a4 56 02 2d 6f 00 00  |.{.H....p.V.-o..|
    00000020  80 b4 56 02 00 00 00 00  0d 20 ba 48 d0 7f 00 00  |..V...... .H....|
    00000030  a0 38 cf 48 30 30 30 30  30 30 30 30 30 30 30 30  |.8.H000000000000|
    00000040  30 30 30 30 30 30 30 30  30 30 30 00 59 8f 31 af  |00000000000.Y.1.|
    00000050  4f f6 04 da e9 5a 0c 00  a0 bd 07 00 c8 3d 77 22  |O....Z.......=w"|
    00000060  47 1e e0 7b 04 d2 26 53  9e b7 ef fa 82 ec 47 74  |G..{..&S......Gt|
    00000070  86 c7 7d 85 6e 7f 0c b8  69 72 d3 39 78 c1 43 da  |..}.n...ir.9x.C.|
    00000080  d7 5d 87 11 0f 33 4f f6  0a                       |.]...3O..|
    00000089
    $ head -n 1 OpenBK7231T*.rbl | hexdump -C
    00000000  52 42 4c 00 02 01 00 00  08 10 0e 67 61 70 70 00  |RBL........gapp.|
    00000010  80 3b e6 d1 a6 7f 00 00  70 44 05 01 2d 6f 00 00  |.;......pD..-o..|
    00000020  80 54 05 01 00 00 00 00  0d e0 d0 d1 a6 7f 00 00  |.T..............|
    00000030  a0 f8 e5 d1 30 30 30 30  30 30 30 30 30 30 30 30  |....000000000000|
    00000040  30 30 30 30 30 30 30 30  30 30 30 00 a7 f7 85 92  |00000000000.....|
    00000050  e4 59 ca 55 c9 7f 0c 00  b0 c6 07 00 43 e8 30 da  |.Y.U........C.0.|
    00000060  25 6d 5d d9 12 ca b6 1e  b9 c4 86 46 c6 42 ca 99  |%m]........F.B..|
    00000070  6c 3a 5c 92 3a bd fb 9a  f9 f9 3c eb 80 1e cd eb  |l:\.:.....<.....|
    00000080  75 f7 34 86 59 91 e2 36  c4 c8 e5 d0 bb 9a a2 0d  |u.4.Y..6........|
    00000090  c9 42 da e2 82 ed b0 4c  65 54 aa 1a 25 dd 97 55  |.B.....LeT..%..U|
    000000a0  47 d6 9c 8e de 2d 16 d0  72 c9 74 5e 60 5f f4 83  |G....-..r.t^`_..|
    000000b0  74 73 57 87 6c 94 3b 1e  bb d5 9c 65 ef 45 fe e8  |tsW.l.;....e.E..|
    000000c0  88 8a 3f 74 48 3b 47 2a  77 61 05 7a 38 63 d0 9d  |..?tH;G*wa.z8c..|
    000000d0  0b 4a b3 08 4d 5e c1 a8  86 68 e5 02 e0 53 fb 7e  |.J..M^...h...S.~|
    000000e0  3c e5 23 17 b8 34 69 96  4f 51 da d0 1a 04 69 75  |<.#..4i.OQ....iu|
    000000f0  09 2a 0c 62 2b 53 1c 64  95 2a e9 af 7f dc 06 85  |.*.b+S.d.*......|
    00000100  c4 3c 66 d4 b5 93 71 f4  90 0a                    |.<f...q...|
    0000010a
    



    Tried to change this in https://github.com/MaxineMuster/OpenBK7231T_App/tree/Beken_FIX_OTA_Header

    with the branch (Artifacts from here: https://github.com/MaxineMuster/OpenBK7231T_App/actions/runs/12427880330 ):
    
    $ head -n 1 OpenBK7231N_*.rbl | hexdump -C
    00000000  52 42 4c 00 02 01 00 00  b1 28 65 67 4f 70 65 6e  |RBL......(egOpen|
    00000010  42 4b 37 32 33 31 4e 00  70 94 e3 00 42 65 6b 65  |BK7231N.p...Beke|
    00000020  6e 5f 46 49 58 5f 4f 54  41 5f 48 65 61 64 65 72  |n_FIX_OTA_Header|
    00000030  5f 64 37 33 30 30 30 30  30 30 30 30 30 30 30 30  |_d73000000000000|
    00000040  30 30 30 30 30 30 30 30  30 30 30 00 2f d4 5b 2a  |00000000000./.[*|
    00000050  8a e2 a4 60 49 51 0c 00  80 b7 07 00 b3 7e 13 97  |...`IQ.......~..|
    00000060  ad 31 16 30 1b 27 2b 0f  a9 b2 8c 30 6d 8a e9 90  |.1.0.'+....0m...|
    00000070  53 ae b1 5b a6 78 18 b2  7c 3e 49 6f fd f8 02 85  |S..[.x..|>Io....|
    00000080  47 d5 f3 15 86 80 ab 56  4d b8 c0 f8 51 2c 95 76  |G......VM...Q,.v|
    00000090  02 4a 15 2f e9 c5 03 ad  37 1d d2 06 63 99 b0 a0  |.J./....7...c...|
    000000a0  09 ad 89 96 50 2a fd 11  2c 7a c2 97 fe 18 bc 94  |....P*..,z......|
    000000b0  9f ed 04 10 da 75 93 24  e2 f4 0a                 |.....u.$...|
    000000bb
    $ head -n 1 OpenBK7231T_*.rbl | hexdump -C
    00000000  52 42 4c 00 02 01 00 00  a2 28 65 67 4f 70 65 6e  |RBL......(egOpen|
    00000010  42 4b 37 32 33 31 54 00  70 84 dc 00 42 65 6b 65  |BK7231T.p...Beke|
    00000020  6e 5f 46 49 58 5f 4f 54  41 5f 48 65 61 64 65 72  |n_FIX_OTA_Header|
    00000030  5f 64 37 33 30 30 30 30  30 30 30 30 30 30 30 30  |_d73000000000000|
    00000040  30 30 30 30 30 30 30 30  30 30 30 00 45 91 87 53  |00000000000.E..S|
    00000050  6b ba 3e 9f 29 76 0c 00  60 c1 07 00 02 0b ee 7d  |k.>.)v..`......}|
    00000060  02 f7 95 71 45 a0 e3 1f  c8 ce a7 15 79 d3 f9 65  |...qE.......y..e|
    00000070  08 75 77 3b 83 fb a1 ee  ed c0 a7 a5 89 c7 ab a3  |.uw;............|
    00000080  8d c8 8e cf 38 3b 44 68  99 96 2e 49 58 36 7b cf  |....8;Dh...IX6{.|
    00000090  80 7e eb b1 a6 94 85 6a  6b 2c cb be 99 c4 64 77  |.~.....jk,....dw|
    000000a0  ab d9 8c 35 04 9c 9a 2c  48 ac 8e 9a 84 d3 33 f7  |...5...,H.....3.|
    000000b0  21 04 8f 6d e8 4b 7f f8  f0 1d 6a 10 a8 a3 b4 b5  |!..m.K....j.....|
    000000c0  dc 08 27 fb a2 27 7f 31  41 73 7c c4 4b 79 94 5f  |..'..'.1As|.Ky._|
    000000d0  de 47 bb b9 3c 7e b3 c3  e7 b3 21 09 d6 dd ba 56  |.G..<~....!....V|
    000000e0  cc fe bc 8f ef ba 5a 2d  1d 1f cf ac 52 5d 2d 5a  |......Z-....R]-Z|
    000000f0  c8 29 18 50 4c 62 16 e7  f7 2f 05 2f b7 ed 29 d9  |.).PLb..././..).|
    00000100  64 c6 e8 0c 64 f9 e7 44  f7 aa c1 06 38 bc 2a 0a  |d...d..D....8.*.|
    00000110
  • ADVERTISEMENT
  • #10 21355869
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    (also I can redo other platforms with log view if wanted)
  • #11 21355872
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    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?
  • #12 21355884
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12329
    @max4elektroda It's Beken leftover, we can change it if it helps

    @divadiow
    Screenshot of the user interface for BK7231T device settings and Form1 application window.
    Screenshot of the firmware update interface for BK7231T_FourRelays.
    I click on button and nothing happens, is this the mentioned "lack of feedback"?
    Screenshot of OTA update interface for BK7231T_FourRelays with console errors.
    Uh, I did it several times, device rebooted on old firmware:
    Screenshot of BK7231T_FourRelays web interface with OTA options.
    Ah I see, it works, but without a feedback.
    We need to put that OTA message on EVERY page, not just index:
    Device user interface with restart button.
    Nice, it worked, but on like third attempt?
    Screenshot of an interface displaying device information and action buttons.

    So it breaks T for you @divadiow but works for me?
    Helpful post? Buy me a coffee.
  • #13 21355888
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    p.kaczmarek2 wrote:
    I click on button and nothing happens, is this the mentioned "lack of feedback"?

    yes

    did you just need to wait longer and first attempt would have flashed OK?

    p.kaczmarek2 wrote:
    So it breaks T for you @divadiow but works for me?


    oh! interesting. I could try with another T real device I guess, I only have one T module loose. Or maybe I blow the T flash away with an SPI restore in case there's something odd about my BL.

    Added after 2 [minutes]:

    >>21355872

    :D
    will do soon
  • #14 21355896
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12329
    divadiow wrote:


    did you just need to wait longer and first attempt would have flashed OK?

    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 etc
    Helpful post? Buy me a coffee.
  • #15 21355936
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    O.k. I see, first thing to do is some kind of feedback. You don't even see the most obvoius things sometimes ;-)
  • #16 21356037
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12329
    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. when refreshing OTA pages, check is OTA running, if it's running, just print simple message "Already running"
    3. put OTA progress html on EVERY page, not just on index. Make font bigger
    Helpful post? Buy me a coffee.
  • #17 21356155
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    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 since test is done on HTTP-Client side):

    <!DOCTYPE html>
    <html>
    <body>
    
    
    <p>Upload firmware file for OTA - !!!Be aware, no file check is done!!!<p>
    <input id='otafile' type='file' accept='.rbl'>
    <input type='button' class='bred' onclick='doota();' value='DO OTA - No file check - reboot after OTA'>
    
    
    <div id="hint"></div>
    <script>
    var input = document.getElementById('otafile');
    var hint= document.getElementById('hint');
    const RBL_Magic = "RBL"; 
    const CHIP_Magic = "OpenBK7231N";
    
    function doota(){ 
       var infile=input.files[0];
       if (infile && infile.name.startsWith(CHIP_Magic)){
          fetch('/api/ota', {
             method: 'POST',
             body: infile}
          ).then((resp) => {
             if(resp.ok){
                console.log('ota successfull; rebooting');
                fetch('/index?restart=1');
             } 
             else console.log('ota not successfull');
          })
       }
       else alert(infile? 'filename must start with '+CHIP_Magic : 'no file selected' )
    }
    
    input.addEventListener('change', function(event) {
         const file = event.target.files[0];
            if (!file) {
                alert("No file selected.");
                return;
            }
            const reader = new FileReader();
            reader.onload = function(e) {
             const text = e.target.result;
             // Check for magic characters
             const Magic1 = text.slice(0, 3);
             const Magic2 = text.slice(12, 23);
    
             if (Magic1!=RBL_Magic) {
                TEXT = "<br><b>Selected file doesn't look like a Beken rbl file!</b> Magic '" +  RBL_Magic + "' not found in header! (Found: '" +Magic1+"')" ;
             } else if (Magic2!=CHIP_Magic) TEXT = "Be sure to select the correct file for your device!<br> Newer images should contain the string '" +  CHIP_Magic + "' which is not found in header! (Found: '" +Magic2+"')";
             
             if (Magic1 != RBL_Magic || Magic2 != CHIP_Magic) {
                hint.innerHTML="Please check the selected file before uploading: " + TEXT;
             } else hint.innerHTML="";
            };
                reader.onerror = function() {
                    alert("Error reading file");
                };
                // Only read the first 32 bytes of the file
                const blob = file.slice(0, 32);
                reader.readAsText(blob);
            });
          
          
          
          
    
    </script>
    
    
    
    
    </body>
    </html>
  • #18 21356281
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    divadiow wrote:
    Or maybe I blow the T flash away with an SPI restore in case there's something odd about my BL.


    bitbang erased and reflashed a Tuya T factory. Now OTAs fine, so false alarm.

    Screenshot showing console logs and OpenBK7231T web interface with OTA options.

    That app partition error is interesting, I've never seen it before. And it happens with the web gui OTA.

    By coincidence this came up elsewhere on the net yesterday in a query by @piotrszulc1

    Code: Text
    Log in, to see the code


    Code: Text
    Log in, to see the code


    Added after 46 [minutes]:

    >>21355867

    should PR Beken_FIX_OTA_Header_d7318437ef82 have the new OTA feature?

    Web page showing OTA update option for OpenBK7231T.
  • ADVERTISEMENT
  • #19 21356373
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    divadiow wrote:
    should PR Beken_FIX_OTA_Header_d7318437ef82 have the new OTA feature?

    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, that are good news!
  • #20 21357676
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    p.kaczmarek2 wrote:
    2. when refreshing OTA pages, check is OTA running, if it's running, just print simple message "Already running"
    3. put OTA progress html on EVERY page, not just on index. Make font bigger

    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 takes about 30 seconds, maybe 10 to 15 seconds of this time the device is responsive

    So any OTA progress can bee seen by the person who started OTA (hence should know about) for max 15 seconds.

    So maybe my "new approach" will be enough: Simply showing a modal dialog for 30 seconds and then switch to main page.










    Added after 8 [minutes]:

    I also added some more testing code for Beken devices - it will not only check the filename but inspect the firmware file.
    This will be especially useful, if we allow the platform inside the rbl header (as proposed in Post #9).

    @divadiow can you please tell me, which OTA file is used for BL602? There are several files with "ota" in filename.
    (I didn't get my own devices, the first time for me ali insisting they delivered an item I never received :-()
  • Helpful post
    #21 21357691
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    Yes. .bin.xz.ota
  • #22 21357701
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    So my guess was o.k.:
    Screenshot of a code fragment from GitHub regarding the #if PLATFORM_BL602 condition, highlighted with a red ellipse.
  • #23 21358243
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    After another night thinking about this, I think I'll change it again to only do some strict name checking:
    So we will only accept files matching the given structure of names, e.g for "LN882H" a file name matching
    /OpenLN882H_.*_OTA.bin/
    This can be done for all platforms and we can drop the file reading for Beken (maybe take it as another measure of security to the App?)
    Before I start coding: what do you think about this approach?
  • #24 21358423
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14400
    Help: 650
    Rate: 12329
    It's acceptable, if user goes out of his way to rename BK7231N RBL to BK7231T instead of downloading a correct binary, then he can take responsibility of bricking...
    Helpful post? Buy me a coffee.
  • #25 21359223
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I changed the file checks. Now you will
    1. get a hint, if selected file doesn't match the given "template"
    2. can't upload a file not matching.

    Two examples with W800 and ESP32S2:







    Added after 16 [minutes]:

    Screenshot of a webpage displaying information about WinTest_3145CAFF.
  • #26 21359539
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21359223
    Regarding last commit, NO_PLATFORM_OTA is good, should reduce binary size a little on non-OTA chips.
    OTA_EXT is unneeded, for example in RTL i added "_ota" only so that images would be picked by github workflows.

    On most platforms, verification by name is unneeded, as verification is done after flash (BL602, LN882H, ESP, RTL, W600?). I just tried to flash C2 image to C3, and this it the result: boot_comm: mismatch chip ID, expected 5, found 12
    But it doesn't really matter, because disabling it only for some chips will increase the amount of ifdefs, reducing the code readability.

    I still suggest setting OTA_ACCEPT to ".img" in #else, and removing elifs for ESP, RTL, W600 and W800.
    Then, there will be no need to add another elif when porting to a new platform.

    In webapp, chipset verification is done like this:
                        if (this.chipset){
                            if(this.chipset=="BL602") {
                                 this.otaFileExtension = ".bin.xz.ota";
                            } else if(this.chipset=="LN882H") {
                                 this.otaFileExtension = ".bin";
                            } else if(this.chipSetUsesRBL()) {
                                 this.otaFileExtension = ".rbl";
                            } else {
                                 this.otaFileExtension = ".img";
                            }

    I didn't want to open another pull for the webapp, so i just used the .img extension for ota images on the platforms i ported.

    Btw, what would happen if W600 ota image is flashed to W800, and vice versa? Does the verification working?
  • #27 21359775
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Actually, we could indeed get rid of OTA_EXT, as long as XR809 keeps "non OTA": The UART image is named "OpenXR809_<whatever>.img" while all other platforms use ".img" as OTA.
    I just wanted to be a little more rigid in checking the names, and, as long as we need two checks per platform, I found it clearer to put both in a define, even if the ".img" is shared between several platforms.

    If we don't check for a possible "ota" indication in the file name, the accept check can indeed be simplified.

    To get rid of the defines inside the code: What would you think about a "PLATFORM_OTA_EXTENSION" in obk_config.h ?
    This way it's more straight forward what to do for a new platform?

    Then it depends on the way you like this sort of things:

    do a #define for all platforms or
    do a #define only for "non .img" platforms and add an "#ifndef at the end for a default

    insmod wrote:
    Btw, what would happen if W600 ota image is flashed to W800, and vice versa? Does the verification working?


    In which case? Web App? "My" code? HTTP GET?

    Anyway: If you get the OTA to accept a file for W600 on W800 (that's the only one I can check) update will fail:
    Error:OTA:Image header check failed


    Added after 36 [minutes]:

    max4elektroda wrote:
    Actually, we could indeed get rid of OTA_EXT,

    There is also LN882H where both firmware files use ".bin" ending, only OTA using "_OTA.bin"
  • #28 21359841
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    XR809 doesn't really matter, as it doesn't have ota implemented, as even if we remove NO_PLATFORM_OTA, it will just do nothing.

    NO_PLATFORM_OTA in my opinion is better than PLATFORM_OTA_EXTENSION, mainly because there are more devices with ota, than without.
    And defining it is more cosmetical than functional, because even if someone forgot to put it in config, nothing would change, save for a little heavier binary.

    I prefer defines only for non .img, but instead of #infdef just keep the #else, because what if in some sdk code it will be defined? I encountered a similar thing with BIT_SET in TR6260 sdk, causing setting flags to not work.
  • #29 21359855
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    insmod wrote:
    NO_PLATFORM_OTA in my opinion is better than PLATFORM_OTA_EXTENSION

    Oh, sorry, I didn't make myself clear:
    I intended this as a replacement for the #defines inside "http_fns.c" for the "OTA_ACCEPT".

    Something like this in obk_config.h:
    
    [...]
    #elif PLATFORM_W600
    [...]
    #define PLATFORM_OTA_EXTENSION   ".img"
    
    #elif PLATFORM_BL602
    [...]
    #define PLATFORM_OTA_EXTENSION   ".bin.xz.ota"
    
    #elif PLATFORM_LN882H
    [...]
    #define PLATFORM_OTA_EXTENSION   ".bin"
    
    #elif PLATFORM_BEKEN
    [...]
    #define PLATFORM_OTA_EXTENSION   ".rbl"
    [...]


    And in http_fns.c we don't need any #defines for this case, but only need

    poststr(request, "<input id='otafile' type='file'accept='" PLATFORM_OTA_EXTENSION "'>");

    It won't reduce code, but simply puts it together in one place.
  • #30 21359860
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21359855 Ah, then it's ok. And with this, NO_PLATFORM_OTA can be removed. But maybe rename it to OBK_OTA_EXTENSION, so it is guaranteed that it won't be overridden? I don't know how it is for BL602, but for esp and rtl it doesn't matter what the extension is, just the content of the file.
📢 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