logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

max4elektroda 4128 64
Best answers

Czy można rozszerzyć stronę statusu OpenBeken o szczegóły Wi‑Fi, takie jak aktualny BSSID, kanał i tryb PowerSave, oraz czy takie zmiany działają też na innych platformach?

Tak — sensownym kierunkiem było przeniesienie dodatkowych danych Wi‑Fi do JSON API (Tasmota-like) i ewentualnie pokazanie ich w Web App, zamiast rozbudowywać główną stronę OBK [#21588291][#21077881] W praktyce BSSID i kanał zostały już dodane do JSON statusu, a SSID uznano za zbędne, bo zwykle można je odczytać z konfiguracji; na głównej stronie pozostawiono tylko PowerSave jako bardziej ogólną informację [#21075738][#21602507][#21678334] Testy pokazały, że na wielu platformach działa to poprawnie: RTL8720D zwracał poprawny JSON z Wifi/BSSId/Channel, a później potwierdzono działanie także na BL602, LN882H, BK7231N, ESP32, W600, W800, BK7238, ECR6600, BK7231T, RTL8720CF i XR809 [#21602660][#21603311] Na XR najpierw był problem z BSSID, ale został poprawiony przez cache BSSID w bloku `safeMode == 0`, po czym uznano zmiany za bezpieczne do scalenia [#21603163][#21603218][#21603333] Dodatkowo zwrócono uwagę, że trzymanie tych danych w JSON/Web App pozwala uniknąć rozdmuchiwania strony statusu i zachowuje kompatybilność z urządzeniami, które można łatwo odzyskać przez UART, jeśli coś pójdzie nie tak [#21073333][#21076301]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #31 21588757
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    I don't think it's strictly necessary to hide this information on the main page, at least not for security reasons. Anyone sharing a full screenshot should be aware of the "risks" of the information shared. And I think the information is useful. But I agree it might be a good idea to add something like a "hide" button, so this can be easily done. This will take some code and increase the size as a disadvantage.
  • ADVERTISEMENT
  • #32 21596150
    DeDaMrAz
    Level 22  
    Posts: 600
    Help: 34
    Rate: 128
    @max4elektroda

    Let's revisit this once more as I think it is about time to do some cleaning up of the OBK interface.

    @p.kaczmarek2

    Many users don't want to use webapp and that is the problematic factor (or allow their devices online at all) so we should do a better tutorial on the local docker (or whatever hosting type) for webapp or tidy up the OBK home/landing page.
  • #33 21596229
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    I think, we should do both: maybe a better/more prominent documentation of a local Webapp and a rework of main page.
    It's a pity I can't do some sample work on it, but my general approach would be to move information at least to the lower part, limiting information above the buttons (e.g. config size) and maybe add a possibility to collapse long output like channel values - if you have many channels to display).
    The part below the buttons could also be cleaned up, e.g by grouping information and show/hide them.

    As soon as possible I can try to "prototype" the idea, but it will probably not be possible for me until next week ...
  • ADVERTISEMENT
  • #34 21596265
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    I think that many users do not even realize that Web App is an external feature made in Javascript, so there is no problem with that.

    My current idea is to use Tasmota JSON to put all available information in the Web App and that's it.

    And the next step probably would be to try to add a button to web app that will automatically download web app to LFS and configure it to run on chip directly.

    Added after 41 [seconds]:

    I also have another idea. Maybe we should (or maybe we actually have it? Through widget driver?) allow custom widgets on main html panel and use them and tasmota json api for more info.
    Helpful post? Buy me a coffee.
  • #35 21596328
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    p.kaczmarek2 wrote:
    I also have another idea. Maybe we should (or maybe we actually have it? Through widget driver?) allow custom widgets on main html panel and use them and tasmota json api for more info.

    That's a good idea, maybe combined with some sort of a flag to decide, whether the HTTP output of a driver (XY_AppendInformationToHTTPIndexPage) is visible on main page or not? So user might decide to hide the status of a driver.
  • #36 21596363
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    Actually, why would anyone want to hide drivers information from the main page? I can't see any use case there. The only thing I can see are the potential problems where used has hidden it by accident and reports that drivers are not running.
    Helpful post? Buy me a coffee.
  • #37 21596409
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    I thought about this together with the idea of the possibility to customize the page with own output via widgets.
    In this case I could think of an "own status" making the drivers output pointless.
    E.g. when thinking about the output of 10 DS1820 sensors, I could think of a "handcrafted" compact version by widget or display actual time there, hiding the details about the NTP server serving the clock...

    But that's always individual what is seen as necessary...

    I think it would be a good thing to give an example output but don't have a PC to do so.
  • #38 21600019
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    Just as a discussion point on what I think we could use to possibly simplify main page.
    No PR, yet, just a first simple branch to check possibilities https://github.com/MaxineMuster/OpenBK7231T_App/tree/GUIstatus01 .

    Basic idea is to use <details>/<summary> elements.
    So you can collapse output if you don't actually need it.
    Main challenge was to keep track of which parts are opened and keep the state over the updates every second.

    Just to illustrate the possibilities:

    Main Page, MQTT only one line:
    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

    Main Page, MQTT with full output:
    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

    Main Page, no stats at all:
    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

    We can also group output, to "hide" multiple lines.

    The solution to keep track of the state of the <details> element might come useful for other cases:

    The state is not loaded to "state"-div directly, but into a hidden div "t_state". Then we scan all details of the actual "state" and "copy" the open-state to the corresponding elements in "t_state". Only after this we assign the content to "state" to avoid flickering.
    Not totally sure, but we maybe can also use this to remove the special handling for "charts"-driver (we a "flickering issue" from the regular updates here, too, and it was solved by moving the canvas below the "state" div).
  • #39 21601622
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    Is it open by default? Is open/close persistent? To be honest, I'd still keep it open all the time...

    I have another idea.
    Maybe we could use new LFS GZIP support (https://www.elektroda.com/rtvforum/topic4129516.html) and add ability to create custom index page in LFS? Then add some kind of "Plugin Store" to Web App, where people can create their own styles, pages, etc, for OBK and download them to device?

    That way you could create whole new UI without changing match in the core mechanism
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #40 21602126
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    p.kaczmarek2 wrote:
    Is it open by default? Is open/close persistent? To be honest, I'd still keep it open all the time...

    Yes, it's open by default, but as I said, this is just a demonstration what is possible. And it's just a proposal.

    I like the idea of a possible own UI - the main challenge will be a possibility to get the information to display.
  • #41 21602215
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    I am testing now HTTP override. If lets you to override default obk pages with LFS pages.
    https://github.com/openshwprojects/OpenBK7231...mmit/ce465a15e665af35fc23ac62e43ff7545e513633
    I am not yet sure about it, but maybe it could bring some more options, especially together with REST API.
    Helpful post? Buy me a coffee.
  • #42 21602242
    divadiow
    Level 38  
    Posts: 4980
    Help: 436
    Rate: 889
    The About page is a bit sad
    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices
  • #43 21602377
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    With current ENABLE_HTTP_OVERRIDE, this code in index.html in LFS can replace main page but keep hardcoded state div:
    Code: HTML, XML
    Log in, to see the code

    I think I could make this more dynamic with REST interface...

    Added after 1 [minutes]:

    This way I can easily add buttons:
    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

    Added after 6 [minutes]:

    Look, I can even integrate logs into main page now:

    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices
    Code: HTML, XML
    Log in, to see the code


    Added after 14 [minutes]:

    This will try to fetch from Tasmota API:
    Code: HTML, XML
    Log in, to see the code
    Helpful post? Buy me a coffee.
  • #44 21602410
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    That really looks very promising!
    p.kaczmarek2 wrote:
    can replace main page but keep hardcoded state div:

    I think this is the point to discuss: I don't know the solution, but the state div in its actual form is not flexible enough. It will kind of force you to keep the actual form of the main page.
    My still blurred idea would be the way you proposed some post ago:
    Define some possible output forms for a driver, and the driver will fill this template with data like name/heading, and, for a power template voltage, current, frequency...
    So a second power source will call a second instance.
    Environmental sensors can have a common template for temperature, humidity, pressure... and by providing (no) data a field (e.g. for pressure) is shown or not.


    Not sure if this is possible at all, but this way we could separate the representation from the data:
    As long as we don't add/remove a driver, the only data to transfer are the values, not the whole template.
    As a starting point we could try and see if html part of the drivers have some common parts or can be changed that way to generate a more universal template usable for multiple drivers.

    Then we fill these "templates" and in the updates we have all data present to use it for a different layout...
  • #45 21602485
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    I'm not sure, it works acceptable for now. Maybe let's start with json_interface.c ? Fill the missing placeholders?
    For example:
    Code: C / C++
    Log in, to see the code

    What is the unit of Heap in Tasmota? Is it in KB?

    Added after 1 [minutes]:

    So much to fill there.. BSSID...
    Helpful post? Buy me a coffee.
  • #47 21602509
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    Is it safe to merge? I want to get all pages fixed soon, for now, I am at the Web App stage, added Format button.

    I am thinking about something like OBK plugin store, where you click a button and it automatically downloads stuff to LFS
    Helpful post? Buy me a coffee.
  • #48 21602522
    insmod
    Level 31  
    Posts: 1383
    Help: 164
    Rate: 431
    >>21602509
    Not yet, there is no generic stub for now.
  • #49 21602530
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    You mean for one hal_wifi_generic.c , with weak linking? That's not the problem, I can add it before merge. I was more worried about potential crashes on not tested platforms.
    Helpful post? Buy me a coffee.
  • #50 21602538
    insmod
    Level 31  
    Posts: 1383
    Help: 164
    Rate: 431
    Well, i see that @divadiow tested most platforms and they worked.
    XR was not tested, because ENABLE_TASMOTA_JSON was not enabled (before my XR pull merge).
    And there is a merge conflict with XR wifi hal.

    Plus the way it is done now is rather cpu costly (data is refreshed each call, which is unneeded). I suggested to do it in WIFI_STA_CONNECTED callback, but no work was done yet.
  • #51 21602619
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    Ok, I added the changes you mentioned, can you check?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1689
    Currently I use default values from the start - maybe I will change it to zeroes... and I skip calls when in safe mode.

    Compilation didn't run yet, I will check in a moment if it's okay
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #52 21602660
    insmod
    Level 31  
    Posts: 1383
    Help: 164
    Rate: 431
    Works on RTL8720D
    Code: text Expand Select all Copy to clipboard
    {"Time":"1970-01-01T00:00:00","Uptime":"0T00:01:56","UptimeSec":116,"Heap":120,"SleepMode":"None","Sleep":0,"LoadAvg":99,"MqttCount":23,"POWER":"ON","Wifi":{"AP":1,"SSId":"xxxx","BSSId":"xx:d1:27:xx:xx:xx","Channel":13,"Mode":"11n","RSSI":58,"Signal":-71,"LinkCount":21,"Downtime":"0T06:13:34"}}


    Added after 4 [minutes]:

    Doesn't on XR872
    Code: text Expand Select all Copy to clipboard
    {"Time":"1970-01-01T00:00:00","Uptime":"0T00:00:34","UptimeSec":34,"Heap":237,"SleepMode":"None","Sleep":0,"LoadAvg":99,"MqttCount":23,"POWER":"ON","Wifi":{"AP":1,"SSId":"xxxx","BSSId":"","Channel":12,"Mode":"11n","RSSI":64,"Signal":-68,"LinkCount":21,"Downtime":"0T06:13:34"}}
  • #53 21602667
    divadiow
    Level 38  
    Posts: 4980
    Help: 436
    Rate: 889
    XR809 - 1689_merge_20588744531c

    Code: Text
    Log in, to see the code


    /cm?cmnd=STATUS%2011
  • #54 21602679
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    Sorry I didn't manage to complete this, thanks for your support and fixes!
  • #55 21602758
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    Not on XR? Interesting, I assumed hal_wifi_xradio.c is for that purpose?
    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices
    Unless... that would mean that wlan_sta_ap_info fails, maybe we can debug that.
    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices
    Helpful post? Buy me a coffee.
  • #56 21602796
    max4elektroda
    Level 24  
    Posts: 749
    Help: 48
    Rate: 184
    JSON output is also missing some correct time statements.
    Maybe this is my chance to ask for a review of PR#1623?

    Its out of sync, but since @p.kaczmarek2 and @insmod are adding new platforms and features so often, I can't keep track of this in all PRs ;-)
    I think it's mainly the new make system causing conflicts, but if you are willing to take a look, I will update it.

    Maybe a short summary of the ideas:
    Separate NTP and other time related functions, in order to allow other time sources.

    Switch from g_ntptime as "master" of the time to g_epochOnStartup to store, as the name suggests, the time at device startup.
    So actual time is (g_epochOnStartup + g_secondsElapsed). And since the latter is handled by the system anyway, we have a "clock" by only setting the startup time once.

    When using as a clock, g_secondsElapsed is not very accurate, it's some time I did the first tests, but it was about 2 minutes off - I'm not sure, but I think this was per week.
    On the other hand: It's (almost) "for free", the clock can be easily set e.g. by small JS-code or with a command and g_secondsElapsed is inceased every second.

    And we can enhance g_secondsElapsed if we sync it to systems xticks from time to time. I have a LN882H system running now for half a year (171 days, 10 hours ...) without adjusting the clock, the time is off approximately 7 minutes (I didn't set summertime, so it's running in UTC+1 while my PC uses DST):


    Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

    Code: text Expand Select all Copy to clipboard
    wget -q -O - "http://192.168.0.24" | grep -o  "Device CLOCK[^<]*" && date
Device CLOCK: Local Time: 2025-07-10 12:33:19 
Do 10. Jul 13:27:42 CEST 2025


    Not suitable to drive a nuclear plant, but o.k. for basic functions, especially if synced from time to time.

    If you would give it a look, I think we should "revive" the old thread here to discuss this "feature":
    https://www.elektroda.com/rtvforum/topic4046620.html

    Added after 12 [minutes]:

    p.kaczmarek2 wrote:
    Unless... that would mean that wlan_sta_ap_info fails, maybe we can debug that.

    I think we could also set this "error message" in advance (instead of bssid[0] = '\0 ; )
  • #57 21603127
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    Well, @max4elektroda , as usual. I love you contributions and I would love to merge them more, but I need:
    1. need to know extra flash footprint it introduces, hopefully it could be low or disabled by default
    2. need to have it tested by some people, maybe @divadiow and @DeDaMrAz can help
    As long as those two requirements are met, then I can merge it anytime.

    Maybe also @insmod could take a look at that.

    Ok, can anyone check XR BSSID now? Does it indicate that wlan_sta_ap_info is falling?
    Helpful post? Buy me a coffee.
  • #58 21603163
    divadiow
    Level 38  
    Posts: 4980
    Help: 436
    Rate: 889
    p.kaczmarek2 wrote:
    Ok, can anyone check XR BSSID now? Does it indicate that wlan_sta_ap_info is falling?

    with 1.18.134?

    Code: Text
    Log in, to see the code


    bssid is not ccorrect
  • #59 21603174
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14549
    Help: 654
    Rate: 12554
    This PR https://github.com/openshwprojects/OpenBK7231T_App/pull/1689
    Helpful post? Buy me a coffee.
  • #60 21603189
    divadiow
    Level 38  
    Posts: 4980
    Help: 436
    Rate: 889
    missed the new build. k
    1689_merge_820b2000dbac
    Code: Text
    Log in, to see the code
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on enhancing the OpenBeken (OBK) status page to display detailed WiFi information for OpenBeken devices, particularly focusing on LN882H modules. The main goal is to show the connected access point's BSSID, WiFi channel, and PowerSave mode level without relying on serial logs. Initial implementations added WiFi HAL functions to the status page, but concerns arose about cluttering the main page and privacy risks from displaying sensitive data like MAC addresses and SSIDs. Suggestions include making the feature optional via a flag, moving detailed info to a debug page, or integrating it into the JSON API for use in the Web App, similar to Tasmota's approach. Testing on various platforms (W600, W800, XR802, XR809) revealed issues such as truncated SSIDs, invalid channel reporting (e.g., channel 0 on BL602), and inconsistent AP information. The dual SSID logic remains unfinished and complex due to connection failover scenarios and network scanning limitations. The community emphasizes cautious rollout on easily re-flashable devices and prefers exposing PowerSave mode on the main page while relegating other WiFi details to JSON status or tooltips. The discussion also highlights the need for better user guidance on OBK features and the potential to leverage existing APIs to avoid increasing firmware size.
Generated by the language model.
Today's popular

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