Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

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.

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

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

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.

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.

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.

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.

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:


Main Page, MQTT with full output:


Main Page, no stats at all:


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

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

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.

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.

The About page is a bit sad

With current ENABLE_HTTP_OVERRIDE, this code in index.html in LFS can replace main page but keep hardcoded state div:

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

Added after 1 [minutes]:

This way I can easily add buttons:


Added after 6 [minutes]:

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




Added after 14 [minutes]:

This will try to fetch from Tasmota API:

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

I'm not sure, it works acceptable for now. Maybe let's start with json_interface.c ? Fill the missing placeholders?
For example:

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

Added after 1 [minutes]:

So much to fill there.. BSSID...

>>21602485
BSSID and channel are already done: https://github.com/openshwprojects/OpenBK7231T_App/pull/1689

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

>>21602509
Not yet, there is no generic stub for now.

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.

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.

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

Works on RTL8720D


Added after 4 [minutes]:

Doesn't on XR872

XR809 - 1689_merge_20588744531c



/cm?cmnd=STATUS%2011

Sorry I didn't manage to complete this, thanks for your support and fixes!

Not on XR? Interesting, I assumed hal_wifi_xradio.c is for that purpose?

Unless... that would mean that wlan_sta_ap_info fails, maybe we can debug that.

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):






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 ; )

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?

p.kaczmarek2 wrote:

Ok, can anyone check XR BSSID now? Does it indicate that wlan_sta_ap_info is falling?

with 1.18.134?



bssid is not ccorrect

This PR https://github.com/openshwprojects/OpenBK7231T_App/pull/1689

missed the new build. k
1689_merge_820b2000dbac