FAQ
TL;DR: After tests on 11 platforms, the thread shifted from “put WiFi info on the main page” to “expose it in JSON first.” This FAQ helps OpenBeken users show BSSID, channel, and PowerSave safely without risking hard-to-recover OTA failures or cluttering the default UI. [#21603311]
Why it matters: OpenBeken users need accurate WiFi diagnostics, but the thread shows that UI placement, platform quirks, and recovery safety matter as much as the raw data.
| Approach |
What it shows |
Main advantage |
Main drawback |
| Main status page |
PowerSave or selected WiFi fields |
Fast, local, always visible |
Can overload the page |
| Separate debug page |
Full WiFi and hardware detail |
Cleaner main UI |
Extra navigation step |
| Web App using STATUS JSON |
Rich data, flexible layout, no reflashing for UI work |
Best long-term flexibility |
Some users do not want external Web App usage |
| LFS custom page / HTTP override |
Fully custom local UI |
Works locally on-device |
More setup and design work |
Key insight: The thread’s strongest consensus is to move detailed WiFi data into the Tasmota-style JSON API first, then decide how the built-in page or Web App should present it.
Quick Facts
- Early cross-platform testing reported SSID truncation on most tested targets, while LN882H and W600 were exceptions; W600 still showed an invalid trailing character on longer SSIDs. [#21073436]
- One contributor reduced the pins page from 90 kB to 9 kB, showing that UI and payload size were active design constraints during the discussion. [#21078302]
- A W800 with a wrong password retried WiFi association about once per minute and logged
WIFI_STA_AUTH_FAILED - 3, which matters for any future dual-SSID failover logic. [#21079433]
- A long-running LN882H clock test stayed up for 171 days, 10 hours and drifted by about 7 minutes, giving a concrete bound for uptime-based timekeeping accuracy. [#21602796]
- Final merge confidence came after testing on 11 platforms: BL602, LN882H, BK7231N, ESP32, W600, W800, BK7238, ECR6600, BK7231T, RTL8720CF, and XR809. [#21603311]
How can I show WiFi details like BSSID, channel, SSID, and PowerSave mode on the OpenBeken status page?
You can add new WiFi HAL functions, expose their values, and then choose the UI surface carefully. The thread ended with a narrower GUI plan: keep PowerSave on the main page if configured, and move BSSID and channel into Tasmota-style STATUS JSON instead of crowding the default page. That approach kept the built-in page smaller while still exposing data to the Web App or custom pages.
[#21078334]
Why does OpenBeken truncate or corrupt the SSID on some platforms like BL602, BK7231, or W600 while LN882H shows it correctly?
The thread points to platform-specific WiFi HAL handling, not a universal OpenBeken UI bug. A tester reported that all tested platforms truncated SSID except LN882H and W600, while W600 appended an invalid character unless the SSID was shorter. The proposed fix was to change string handling from
memcpy to
strcpy, and the author later considered dropping SSID display entirely because config already stores the known network name.
[#21075738]
What is BSSID in WiFi, and why is it useful for debugging which access point an OpenBeken device is connected to?
"BSSID" is a WiFi network identifier that names the specific radio interface of one access point, unlike an SSID, which names the shared network. It matters when you run multiple APs with the same SSID and need to know which one the device actually joined. The thread’s original request came from exactly that use case, because the author wanted to identify the real AP without needing a serial log.
[#21073220]
What is PowerSave mode in OpenBeken, and how can I tell which level an LN882H module is using?
PowerSave mode is a WiFi sleep setting, and LN882H was the platform that motivated exposing its level. The first post asked to show whether PowerSave was active and, on LN882H, which level was currently selected. Later discussion narrowed the GUI goal to showing only PowerSave on the main status page, while other WiFi details moved to STATUS JSON.
[#21078334]
Where should extra WiFi details live in OpenBeken: on the main status page, on a separate debug page, or only in the Web App?
The thread leans toward STATUS JSON plus Web App, with only high-value items on the main page. Several users said BSSID, channel, and SSID add too much detail to the front page, while PowerSave may still deserve visible placement. Others proposed a debug page, tooltips, or a separate detailed-information view, but the strongest consensus favored JSON first and UI second.
[#21077881]
How do I safely test an experimental OpenBeken firmware build with new WiFi HAL functions without risking an unrecoverable OTA brick?
Test only on hardware you can recover easily over UART. The original warning was explicit: use modules that can be reflashed if OTA becomes inaccessible. A safe workflow is: 1. Flash only devices with easy serial recovery. 2. Add failed-boot conditional protection before risky code. 3. Verify behavior on local hardware before wider rollout. That advice came before broad multi-platform testing started.
[#21073333]
Why would an OpenBeken device report channel 0 or an incorrect BSSID, especially on BL602, LN882H, or XR platforms?
Those bad values came from platform-specific WiFi library behavior and incomplete HAL support. BL602 was seen reporting channel 0, which the author called invalid for 2.4 GHz but typical as a startup placeholder when only SSID is known. LN882H also sometimes showed a valid-looking channel and AP MAC while actually being connected elsewhere, based on RSSI and serial-log verification. XR later needed fixes before BSSID became correct.
[#21073559]
How can I add BSSID and WiFi channel information to the Tasmota-style STATUS JSON in OpenBeken?
Add the values in the JSON status path instead of hardcoding placeholders. The discussion moved to
json_interface.c, where missing fields like
Heap,
SleepMode, BSSID, and channel could be filled from real HAL data. By July 10, 2025, a pull request specifically added BSSID and channel to STATUS output, with later fixes for XR behavior before merge.
[#21602507]
What is the Tasmota STATUS JSON API in OpenBeken, and how is it different from showing the same data directly on the built-in status page?
"Tasmota STATUS JSON API" is a device-side JSON interface that returns structured runtime data for tools and web clients, unlike the built-in status page, which renders fixed HTML directly on the module. In this thread, JSON became the preferred transport for BSSID, channel, and PowerSave because it avoids page clutter and lets the Web App render the same facts more flexibly.
[#21077839]
How do I develop and test OpenBeken Web App changes locally with Visual Studio Code and Live Server instead of reflashing firmware every time?
Use the Web App locally and point it at your device IP. The thread gave a simple workflow: 1. Install Visual Studio Code. 2. Run the Web App with the “Run with Live Server” plugin. 3. Open the local index file and change the IP to your device. That lets you see Web App changes in real time without reflashing firmware, as long as you only modify the front end.
[#21077881]
What is the current state of second SSID support in OpenBeken, and how is SSID1 versus SSID2 supposed to behave when the first network fails?
Second SSID support was unfinished during the thread. A maintainer stated clearly that the second SSID logic was still TODO, and the author then removed code that tried to retrieve the active SSID because it could only be SSID1 in practice. The suggested long-term path was to use configuration helpers for SSID1 and SSID2 once failover rules exist.
[#21078302]
How should OpenBeken handle dual-SSID failover when the AP is missing, the password is wrong, or SSID1 comes back after a temporary outage?
The thread says the hard part is policy, not coding. Open questions included whether to switch only when SSID1 disappears, whether wrong-password failures should trigger SSID2, and when to switch back after SSID1 returns. Real testing showed W800 retried a bad password roughly every 1 minute, which gives a concrete timing reference for any future threshold-based failover design.
[#21079433]
What troubleshooting steps help when XR809 or XR872 returns an empty BSSId or 'wlan info failed' in OpenBeken STATUS output?
Check the XR HAL path, then confirm the API return handling before blaming the UI. In the thread, XR872 initially returned an empty BSSId, XR809 later showed
wlan info failed, and maintainers traced it to how
wlan_sta_ap_info returned status. After fixes, XR809 on build
1689_merge_444d39530925 reported the expected BSSID correctly, proving the issue was implementation-specific.
[#21603260]
OpenBeken main page vs Web App for advanced status information — which approach is better for local-only users who do not want cloud or external hosting?
For local-only users, both paths are valid, but the thread recommends improving local options instead of forcing the external Web App. One participant said many users do not want Web App or any online dependency at all. The proposed compromise was better local Web App documentation, plus cleanup of the built-in landing page so advanced data still works for offline users.
[#21596150]
How can custom LFS index pages, HTTP override, REST API, or a future plugin store be used to build a cleaner OpenBeken UI with logs and richer device status?
They let you move UI complexity out of core firmware and into replaceable local pages. By July 2025, HTTP override could replace the default index page from LFS, keep the hardcoded state area, and add custom buttons or logs. A future plugin-store idea would download styles or pages into LFS automatically, while REST or STATUS JSON would provide the live data.
[#21602377]
Generated by the language model.
