logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Hosting OpenBekenIOT Web App's 'Logs' function in the LittleFS of the Device (BK7231T)

jkwim 6141 60
Best answers

Can I enlarge LittleFS on a BK7231T to host the OpenBeken web app files locally, and will a larger LittleFS break OTA updates?

Yes — you can enlarge LittleFS with `lfs_format`, and OTA may erase the LittleFS contents, so keep a backup; it does not sound like a blocker if you can restore the files afterward [#20928195] A 128 kB LFS was not enough for the original unmodified web app files, and because LittleFS uses 4 kB blocks, you need to budget space per file in whole sectors rather than raw file size [#20930090] The thread’s working setup used about 212 kB (`0x34000`) and later even 196 kB (`0x30000`) after minifying the `.vue` files and `httpVueLoader.js`; the key missing file was `filesystem.vue`, and `startup.js` had to be pointed at `/api/lfs/` paths with `indexdevice.html`/`indexlocal.html` adjusted accordingly [#20944917][#20946139] Large-file uploads were unstable until a fix was added: a small RTOS delay in the file upload function made drag-and-drop uploads work reliably [#20941452] For the final result, the web app was served from the device itself, and the “Logs” and filesystem pages worked in a closed network [#20944917][#20947236]
Generated by the language model.
ADVERTISEMENT

Topic summary

✨ The discussion focuses on hosting the OpenBekenIOT Web App's 'Logs' function within the device's LittleFS filesystem on BK7231T and BK7231N devices. The default LittleFS size is 32kB, which is insufficient for hosting multiple web app files such as startup.js, httpVueLoader.js, vue.min.js, and logs.vue. Users experimented with increasing LittleFS size up to 256kB and 200kB (0x32000), with mixed success due to device reboots and low heap warnings during large file uploads. A key finding was that adding RTOS delays during file upload improved stability, as implemented in a test firmware build. Firmware upgrades to versions around 1.17.404 and above were recommended for better performance. Minification of JavaScript and Vue files significantly reduced storage requirements, enabling hosting within the constrained LittleFS space. The memory layout of BK7231T and BK7231N devices was reviewed to understand partitioning and avoid overwriting OTA or application partitions. Alternative hosting solutions suggested include running the web app on a NAS or router with OpenWrt. Further development includes moving LittleFS to external SPI flash chips (4-8MB) or SD cards to expand storage capacity for logs and web app files. Fast bitbang SPI implementations and increased LittleFS cache sizes were tested to improve performance. The community encourages creating tutorials for these solutions and ongoing firmware improvements to enhance stability and usability of hosting web apps directly on BK7231 devices.
Generated by the language model.

FAQ

TL;DR: With a 196–212 kB LittleFS and the upload fix, OpenBeken can host Logs locally; one tester confirmed it “works like a charm.” This FAQ helps BK7231T/BK7231N users run Logs and Filesystem pages inside a closed network without external hosting. [#20955109]

Why it matters: Hosting the WebApp on-device lets OpenBeken devices expose Logs and Filesystem pages even when the network has no internet or permanent NAS/Docker host.

Option Typical LittleFS target Result from the thread Main trade-off
Default internal LittleFS 32 kB Too small for the needed WebApp files Not enough space
Enlarged internal LittleFS 128–212 kB Works after path fixes and upload workarounds May trigger low-heap warnings or uploads failing
External SPI flash LittleFS 4–8 MB Under development in 2025 Much more space, slower for large files
SD card over SPI Much larger than flash chips Suggested, not implemented in-thread More space, more integration work

Key insight: The biggest blocker was not raw flash size alone. Large-file uploads became stable only after an RTOS delay was added, and final success also required correct /api/lfs/ paths plus inclusion of filesystem.vue.

Quick Facts

  • OpenBeken LittleFS used 4,096-byte blocks, so even tiny files could consume a full 4 kB block; real storage use was much higher than file size alone suggests. [#20930090]
  • A working self-hosted setup used 0x34000 = 212 kB LittleFS, then later shrank to 0x30000 = 196 kB after manual minification of .vue, JavaScript, and CSS content. [#20944917]
  • vue.min.js was about 92 kB, httpVueLoader.min.js was reduced from 10,890 bytes to 5,867 bytes, and these savings helped fit Logs plus Filesystem into internal flash. [#20928161]
  • Upload behavior differed by chip family: BK7231T devices were easier to fill reliably, while BK7231N often failed on direct upload of vue.min.js but could accept it via a .tar backup workaround. [#20942411]
  • OTA could erase LittleFS, but the thread confirmed you can back it up and restore it; OpenBeken also preserved the configured LittleFS size across one tester’s OTA cycle. [#20933489]

How do I host the OpenBekenIOT Web App Logs function directly from LittleFS on a BK7231T or BK7231N device?

Use a larger LittleFS, upload the required WebApp files, then point OpenBeken to indexdevice.html served from /api/lfs/. A confirmed working setup used 0x34000 LittleFS, modified startup.js paths, and configured the device WebApp URL to the on-device page. The final result loaded Logs and Filesystem from the device itself inside a closed network. [#20944917]

What is LittleFS in OpenBeken, and how is it used to store WebApp files on BK7231 devices?

“LittleFS” is a lightweight embedded filesystem that stores files in flash memory, uses fixed-size allocation blocks, and lets OpenBeken keep WebApp assets such as .js, .vue, HTML, and backup archives directly on the device. In this thread it was used to hold files like vue.min.js, startup.js, logs.vue, and filesystem.vue so the device could serve its own WebApp pages through /api/lfs/. [#20928161]

Why does a BK7231N or BK7231T device reboot when uploading a large file like vue.min.js to LittleFS?

The reboot happened because the upload path was unstable during long writes, especially for large files such as the 92 kB vue.min.js. Testing reproduced the issue, and adding an RTOS delay inside the file upload function improved stability. BK7231N remained harder than BK7231T, and some N devices still needed a .tar workaround after the fix. [#20941452]

How would increasing LittleFS to 128kB or more affect OTA updates and the risk of the filesystem being erased?

Increasing LittleFS can work, but OTA may erase the filesystem contents. The thread explicitly says this is acceptable if you keep a backup, because LittleFS backups can be downloaded and restored later. One tester also noticed that after OTA, files were wiped but the remembered configured LittleFS size still appeared as 0x40000 on the next format step. [#20933489]

Which WebApp files actually need to be stored in LittleFS to make the OpenBeken Logs page work in a closed network?

You need more than just the Logs component. The final working set included startup.js, vue.min.js, httpVueLoader.min.js, filesystem.vue, logs.vue, info.vue, myComponent.vue, and indexdevice.html; the author first failed because filesystem.vue was missing. That missing file was described as the most important omission in the earlier attempts. [#20944917]

What changes are required in startup.js, window.root, and window.device so indexdevice.html or indexlocal.html can load files from /api/lfs/?

Set window.root to /api/lfs/, set window.device to the device IP, and load startup.js from /api/lfs/startup.js. Then update startup.js so component paths use window.root+'logs.vue', window.root+'filesystem.vue', and similar on-device paths instead of external ones. Using / as window.root caused partial loading, while /api/lfs/ matched the working setup. [#20944917]

Why does LittleFS block size matter so much on OpenBeken, and how do 4KB blocks change the real space used by each file?

Block size matters because each file consumes whole 4,096-byte blocks, not exact byte counts. The thread explains that if a file occupies even 1 byte in a block, another file cannot reuse that remaining space, so sizing based only on raw file totals fails. A practical formula given was (((filesize div 4096) + 1) * 4096) for estimating space per file. [#20930090]

What’s the best way to calculate the LittleFS size needed for files like vue.min.js, httpVueLoader.js, logs.vue, and filesystem.vue on BK7231?

Calculate per-file space in 4 kB blocks, then add headroom. A direct rule from the thread was: (((filesize in bytes) div 4096) + 1) * 4096) for each file, then sum the results. That method explained why a file set totaling about 147 kB of real data still occupied about 156 kB in LittleFS. [#20931925]

How do I use lfs_format and lfs_size in OpenBeken to create and verify a larger LittleFS partition?

Use a format command, reboot if needed, then verify with lfs_size. 1. Run lfs_format 0x20000 or another target size. 2. Reboot the device after formatting. 3. Run lfs_size and confirm messages such as configured 0x20000. The thread shows this exact workflow for a 128 kB LittleFS on BK7231N. [#20928296]

What is an RTOS delay, and why did adding it to the OpenBeken file upload function improve LittleFS upload stability?

“RTOS delay” is a scheduler pause inside firmware code that briefly yields execution, reduces long uninterrupted loops, and helps watchdog, networking, or memory-sensitive tasks continue running during heavy operations. In this case, adding that delay inside the upload function stopped many mid-write reboots and let a tester drag and drop all WebApp files onto LittleFS successfully. [#20941452]

How can I work around large-file upload failures in OpenBeken by using tar backups or uploading the biggest files first?

Upload the largest files first, or move them through a LittleFS .tar backup instead of direct file upload. One tester copied vue.min.js to a BK7231T first, downloaded the resulting .tar, and then restored that archive onto a BK7231N, where direct upload had failed. Another practical note was that large files could take 30–40 seconds to copy. [#20942411]

Which firmware versions or test builds fixed the LittleFS upload instability on BK7231T and BK7231N modules?

The key fix was the test build from pull request 1056, named with delay_for_littlefs and later used as OpenBK7231N_1056_merge_ad333e21dec2 or similar board-specific binaries. It fully solved uploads on several BK7231T tests and improved BK7231N enough that a final 128 kB setup succeeded, though N still showed direct vue.min.js upload issues. [#20943770]

What causes the OpenBeken ‘Low heap warning’ after enlarging LittleFS, and how should that influence the filesystem size you choose?

The warning indicates memory pressure, so you should stop increasing LittleFS just because flash space exists. The thread reports Error:MAIN:Low heap warning! at 256 kB, also still at 212 kB and even 196 kB, which means the safest choice is the smallest filesystem that still fits your files. In practice, users converged on about 200–212 kB rather than 256 kB. [#20946139]

How can I minify JavaScript, CSS, and .vue files from the OpenBeken WebApp to fit the Logs and Filesystem pages into a smaller LittleFS partition?

Minify the contents inside <script> and <style> sections separately, then save the reduced .vue files under new names such as logs.min.vue. The thread reports shrinking httpVueLoader.min.js from 10,890 bytes to 5,867 bytes and reducing the whole LittleFS target from 212 kB to 196 kB. That made a self-hosted Logs plus Filesystem setup fit more comfortably. [#20946139]

SPI flash chips vs SD cards for external OpenBeken storage: which is better for hosting the web app and keeping larger log or measurement history files?

SPI flash chips were the practical choice in the thread, while SD cards were the larger-capacity idea. The developer chose spare SPI flash first because 4–8 MB was enough for measurement history and easier to wire on a proto board, but other participants preferred SD for much larger space and better fit for WebApp hosting plus long-term logs. Large-file speed on software SPI flash was still a concern. [#21587418]
Generated by the language model.
ADVERTISEMENT