FAQ
TL;DR: The reduced OpenBK7231T_App test build cut BK7231N firmware from 500 KB to 388 KB, and one tester confirmed it "boots ok" on multiple boards. This FAQ helps OpenBK7231T users validate smaller builds, preserve OTA safety, and check which drivers still work before merging custom or stripped firmware. [#21382317]
Why it matters: Smaller firmware images make room for more platforms, safer OTA updates, and clearer driver-set choices without losing core OpenBK functionality.
| Build or option |
Reported size / result |
Best fit |
| Public BK7231N release |
500 KB |
Full default feature set |
| Stripped BK7231N build |
388 KB |
Minimal core, MQTT kept earlier; HA removed in one test state |
| Earlier reduced RBL from PR #1500 |
405,200 bytes |
Early small-build validation |
| Empty HAL main |
280 KB |
Baseline SDK overhead only |
| W800 after SDK feature cuts |
~0.55 MB |
OTA-friendly W800 target |
Key insight: The thread shows the size work was viable because testers repeatedly confirmed boot, OTA, MQTT, LFS, and several drivers across BK7231N, BK7231T, W600, W800, LN882H, RTL87X0C, and others. The real risk was not basic boot, but edge cases around startup-command JSON, makefiles, and platform-specific SDK defaults.
Quick Facts
- PR #1500 produced a reduced
OpenBK7231N_1500_merge_f2af436bf134.rbl at 405,200 bytes, versus 500,800 bytes for public release 1.18.12. [#21381261]
- The BK7231N stripped build later dropped to 388 KB, then 376 KB after MQTT removal, and 335 KB after IR was disabled. [#21382838]
- On W800, default SDK features pushed the image to about 1 MB; disabling TLS and related HTTP-client options cut it to about 0.55 MB. [#21387301]
- OTA and runtime checks succeeded on real hardware: CB3S OTA from 1.18.13 worked, and LN OTA from 1.17.765 also kept BL0937, DS1820, LFS, NTP, and MQTT working. [#21384187]
- W600 software I2C and BMP280 were tested with explicit pins, including a working example using 25 24 9 10 11 236 after correcting bad-pin wiring. [#21386485]
How do I test the reduced-size OpenBK7231T_App build from PR #1500 on BK7231 over UART wires, and what should I verify first after flashing?
Flash the PR #1500 image over UART wires, then verify boot, web access, and at least one core driver. 1. Write the test build to BK7231 and power-cycle the board. 2. Confirm it boots, creates the app or panel, and accepts OTA or console access. 3. Check a known feature such as DHT, MQTT, or driver listing before testing edge cases. Early testers reported OTA from file-select working and later confirmed boot on WBR3, BK7231N, and BK7231T test boards.
[#21384037]
Why does a stripped OpenBK7231N build still take around 280 KB even with an almost empty main, and which SDK parts like WiFi or OTA are likely responsible?
Because the platform SDK still brings substantial baseline code even when OpenBK logic is nearly absent. The thread reports
280 KB for a BK7231N binary with an empty HAL main, versus
388 KB for a stripped OpenBK build and
500 KB for the latest public release. The discussion explicitly points to likely space users such as WiFi, OTA, and low-level SDK code in
driver/common/dd.c, which remain linked below the application layer.
[#21382317]
What commands are still required in OpenBK7231T if the WiFi, IP, and other configuration HTML pages are removed and everything must be configured from the console?
You still need console commands that fully replace web-page setup for networking and runtime control. The thread confirms WiFi can already be configured by command, and it discusses removing HTML pages only if all required text commands remain available. At minimum, the console must cover WiFi setup, IP-related configuration, driver startup, and OTA-safe recovery workflows, because the proposed lightweight panel may become a command-line-only HTML window.
[#21381294]
What is LittleFS (LFS) in OpenBK7231T, and why can files like autoexec.bat disappear after OTA or partition-size changes?
"LittleFS (LFS) is a lightweight flash filesystem that stores persistent files, startup scripts, and small user data across reboots, but its contents depend on partition layout and reserved flash size." Files like
autoexec.bat can disappear after OTA or size-layout changes because the filesystem area may shrink, move, or be recreated. One test on room lights kept core control working but lost
autoexec.bat, prompting a warning to add a user warning or shrink default LFS size again.
[#21384179]
What is HA or HASS Discovery in OpenBK7231T, and how do I check whether it still works after using a smaller firmware build?
"HA or HASS Discovery is a Home Assistant integration feature that auto-announces device entities over MQTT, letting Home Assistant detect sensors and controls without manual entity creation." After flashing a smaller build, verify it by enabling MQTT, watching Home Assistant or broker messages, and checking that discovery still appears after reboot. Testers explicitly confirmed that HA Discovery and LFS still worked on RTL87X0C in the reduced-build testing cycle.
[#21384099]
LED build vs metering build in OpenBK7231T: which driver set makes more sense for RGBCW devices compared with BL0942 or BL0937 power-monitoring devices?
An LED-focused build makes more sense for RGBCW lights, while a metering-focused build fits BL0942 or BL0937 power devices. The thread states these driver groups are strongly exclusive in practice, because classic LED drivers such as RGBCW PWM or SM2135 are usually not needed alongside energy-metering stacks like BL0942 and BL0937. That is why a proposed split included separate "LED" and "metering" predefined build sets for GitHub workflows.
[#21381298]
How can I list the drivers included in a specific OpenBK7231T firmware build using the startDriver anyNonExistingName trick?
Run
startDriver anyNonExistingName in the console to force OpenBK to print the available driver list for that firmware. The maintainer asked testers to use exactly that trick to manually verify which public drivers remained compiled in before merging the size-reduction PR. Testers then posted platform-specific driver lists for LN882H, BK7231N, BK7231T, ESP32 variants, W600, W800, BL602, and TR6260.
[#21384228]
Why does BL602 fail to compile drv_ir.cpp with 'Platform not defined' when PLATFORM_BL602 is only set in CFLAGS, and how should that define be passed for C++ files?
It fails because
drv_ir.cpp is a C++ file, but
PLATFORM_BL602 was only defined in
CFLAGS, not in the flags used for C++ compilation. The thread identifies the fix clearly: pass the define through
CXXFLAGS or
CPPFLAGS, for example
CXXFLAGS += -DPLATFORM_BL602=1. That change matches the observed error path, where
obk_config.h reached
#error "Platform not defined" inside a
.cpp compile.
[#21385028]
What causes Realterm to hold a W801 board in reset when opening the serial port, and which DTR or RTS setting fixes the no-UART-output problem?
Realterm can assert the modem-control line in a way that pulls the W801 reset pin low when the port opens. The maintainer measured RESET dropping from
3.3 V to 0 V on port open, which explained the silent UART. The fix was changing the relevant Realterm handshake control so opening the port no longer held reset active; once adjusted, the board printed normally and the problem disappeared.
[#21385223]
How do I troubleshoot OTA and web GUI failures on older OpenBK7231T builds when the new multiline startup command contains unescaped newline characters in JSON?
Clear the multiline startup command first, then retry OTA. Older builds do not escape newline characters as
\n in the JSON returned by the chip-info API, so the web app fails to parse platform info and cannot offer the OTA file selector correctly. The maintainer described this as a known bug and gave the direct workaround: remove the startup command text, then perform OTA.
[#21399371]
Why does downgrading from a PR build with a long multiline startup command to an older W800 release lead to a boot crash, and how can safe mode recover it?
The older W800 release cannot safely handle the long multiline startup data written by the PR build, so it may crash during boot. The thread shows a reproducible failure after OTA to release, including
Too many args, skipped all after 32nd and a CPU Exception 3. Recovery is simple: boot into safe mode, remove the stored startup command, and reboot. That clears the incompatible text and restores normal startup.
[#21387492]
How do I enable and test DHT or DS18B20 on W800 and W600 when the makefile is missing driver source files or platform-specific options?
Add the missing driver sources or platform flags to the platform makefile, rebuild, then test with a real sensor. On W800, DHT initially failed with undefined references until
drv_dht.c and
drv_dht_internal.c were added to
CSRCS; after that, DHT worked. On W600, DS18B20 was enabled for the first time during this work, though a small type issue still needed follow-up to avoid long-uptime timing problems.
[#21385914]
What is OpenWeatherMap support in OpenBK7231T, and how do I configure owm_setup, channel types, and owm_request from the console?
OpenWeatherMap support is a driver workflow that fetches weather data over HTTP and maps it into OpenBK channels. Configure it by starting
OpenWeatherMap, running
owm_setup <lat> <long> <APIkey>, assigning channel types such as
Temperature_div10,
Humidity, and
Pressure_div100, then binding them with
owm_channels and calling
owm_request. A posted working example used coordinates
40.7128 -74.0060 and channels
6, 7, and 8, and the maintainer confirmed, "All works."
[#21386446]
Why was the W800 firmware image so large with TLS and HTTP client features enabled by default, and which SDK options helped shrink it from about 1 MB to roughly 0.55 MB?
The W800 image was large because the SDK enabled HTTP client, HTTPS, SSL, and crypto-related features by default. The maintainer highlighted
TLS_CONFIG_HTTP_CLIENT,
TLS_CONFIG_HTTP_CLIENT_SECURE, and related options as size drivers, then reduced the image from about
1 MB to about
0.55 MB by disabling unnecessary SDK features. That cut made OTA practical again and explained why W800 binaries were oversized even before many OpenBK drivers were added.
[#21387301]
How do pin-name parsers like HAL_PIN_Find and Tokenizer_GetPin work in OpenBK7231T on W600 or W800, and how can I use names like PB8 and PB9 when starting drivers such as BMP280?
They let the console accept human-readable pin names and convert them to internal OBK pin indexes. The maintainer added
HAL_PIN_Find and
Tokenizer_GetPin for W600 and W800, then demonstrated driver startup with symbolic pins instead of numeric indexes. A working example was
backlog stopDriver BMP280 ; startDriver BMP280 PB9 PB8 9 10 11 236, which successfully started BMP280 using
PB9 and
PB8 as I2C-style pin arguments.
[#21387790]
Generated by the language model.
