Enhancing OBK Status Page with WiFi Details for OpenBeken Devices

When accessing an OpenBeken device without a serial log, I often miss some information.
E.g. I have multiple access points and would like to see, to which my module is connected.
Or: I would like to see if the device is using PowerSave and (with LN882H) which level.

So I tried to add some WiFi hal functions, to make this accessible.

On my LN882H it looks like this:


Since I only own LN882H modules, I would like some brave testers to try the images from this PR on other platforms.
https://github.com/openshwprojects/OpenBK7231T_App/pull/1216

Since I couldn't test them, I would suggest only to test on modules, which can be re-flashed easily (e.g via UART), if it might be inaccessible for an OTA update with this images...

Thanks for any feedback.

@divadiow @DeDaMrAz wanna take a look?

My first suggestion would be to put your code inside a conditional statement that checks for failed boots. This way you can make sure that you won't break devices even if your code has an error...

Futhermore... hmmm I see you made a feature to put a WiFi info on the main page just to later censor it before putting it on forum....
Maybe that's a sign that your feature should be enabled by a flag? Something like "show extra info"? So people can choose whether they show it or not?

Or maybe... maybe it could have been put in a driver? It would be even better than a flag...
And then you would just use:

all Build on May 7 2024 12:48:51 version 1216_merge_a66f326e5e17

all truncate SSID except LN882H and W600. W600 has invalid character at end but not if SSID is shorter

p.kaczmarek2 wrote:

>>21073333
Furthermore... hmmm I see you made a feature to put a WiFi info on the main page just to later censor it before putting it on forum....
Maybe that's a sign that your feature should be enabled by a flag? Something like "show extra info"? So people can choose whether they show it or not?

Yes, maybe I'm a bit paranoid, but I also censor MAC addresses, and they are on every status page, too

This is for sure something to put into some conditional section, but actually I only wanted to hear, if it is working at all, so it makes no sense to suppress the output in this stage.

I think putting it into a driver will just take too much space on the page - but that can be discussed, too.

@divadiow : Great, that you took the risk.
I'll take a look into this SSID issue - but even if it doesn't work - most people know what SSID they configured. Just the BSSID of the AP you are connected to is often some clicks away

And: at least for my LN882H I had some times, where the displayed information was simply wrong. It showed a valid pair of channel and APs MAC, but it was in fact connected to another AP (could be verified by the (correct) rssi , which didn't match the shown AP (and by the serial log proving, it connected to another AP).
There is something strange with LN882Hs wifi lib...

Are the other ones showing correct values (channel and BSSID) in your case?
Thanks for your support!

max4elektroda wrote:

Are the other ones showing correct values (channel and BSSID) in your case?

BSSID is as expected for all. Regarding the channel, my Mikrotik doesn't seem to give me the frequency or channel for each client so I cannot say if they're all correct. The BL602 though says channel 0 which isn't a valid 2.4ghz channel?

Thanks, I think I might just drop SSID (this is known and can be taken from the config - would only be interesting in case you have 2 SSIDs configured).
Channel 0 is not valid, but usually given to configure startup with only SSID and an unknown channel.
But maybe you can give the new Version a try (I used strcpy instead of memcpy here)?

Added after 1 [hours] 4 [minutes]:

and my first flash to a new W800

I think it's too much detail already on the front page. I suggest moving all this except maybe power to some other debug page

something like Tasmota, complete with flash ID, size, chip detected

Yes, that's a good point and I fully agree that BSSID, channel, and SSID are not of interest in most cases, and my suggestion would have been the same, only leaving PowerSave mode in regular status.
On the other hand: I did put them in one line with existing information for every "appendInformationToHttpIndexPage" takes even more space.
My first goal was to verify the function of the new functions and as far as I can see, it works o.k., only feedback for an XR802 is missing.
For the other details I can think of a debug page, removing them fully from the GUI and introducing a command or, my actual idea, hiding it in a mouseover/tooltip.
That will make it accessible on the main page (something I personally would like) but not visible hence not overloading this already loaded page.
The drawback: It's not clear on the first look that there is some "hidden" information present.
But maybe that is a general idea to streamline the main page and hide information like config size, reboot reason ...
On a separate "detailed information" or "debug" page or in tooltips...

Added after 51 [minutes]:

Just a quick hack to show what I mean by information hidden in a "tooltip", if this is not clear (mouse pointer is over "WiFi" - not shown in screenshot):

We have users that still don't know we have Flags menu in Config, or don't know that we have Startup and then ask how to configure start value of relay, so I am not sure that a popup menu in "onmouseover" event is a good idea...

Maybe we should just use existing API - the Tasmota STATUS command we have implemented - and just access it from the Web App, and show all info in the Web App? That way we don't even have to extend the binary size of obk, as the web app is on github:
https://github.com/OpenBekenIOT/webapp/tree/gh-pages

p.kaczmarek2 wrote:

We have users that still don't know we have Flags menu in Config, or don't know that we have Startup

Yes. This is interesting. And partly why I started to add some basic links to my signature. It's quite overwhelming as a new user. I don't mind taking time to understand things but sometimes you need a little helping ramp into the whole world of something new.

That's more of comment about OpenBeken in general though I guess rather than this new feature specifically.

Shame on me. I once reasoned, why there are so many "fake" entries in the json code (replying with hard coded values) and didn't take the first view there to see, that I only had to change the code there to answer with actual values.
At least BSSID and Channel are present here, so this information doesn't need to be integrated to the GUI.
And maybe PowerSave can be integrated in STATUS as well, in StatusSTS (as sleep mode or if it's possible to add other fields) or, for this might be interesting for more users, displaying the PowerSave value in the main Page is o.k.

So maybe let's agree together on updating the JSON code for Tasmota and then doing your feature in the Web App, @max4elektroda ? I can help.

Get Visual Code and use "Run with live server" plugin to get Web App running locally. Use the local index file with IP (change IP to point towards your device) for development.

It's very easy, you get changes updated in realtime, no firmware flashing needed (as long as you are changing only the web app)

I'm not sure about the "feature", but my first step will be to integrate the results of the "new functions" in hal_wifi code to the corresponding status messages in the JSON code.
Then we can discuss further, if/how this can be integrated in the app.
I could also think of displaying the result of the status queries in the GUI, too.
But first things first.

Added after 11 [minutes]:

p.kaczmarek2 wrote:

a popup menu in "onmouseover" event

Just to clarify: I didn't make that much of code, it's just a simple title="BSSID=..."
which I like as a simple way for explanations, hints ...


Added after 5 [hours] 31 [minutes]:

Just a dumb question: Is the second SSID used in any case?
On a quick search I didn't find any code which accessed it?!?
I don't need to waste code for a function trying to retrieve the actual SSID in, if it can only be SSID1
Thanks!

Second SSID is unfinished, it's logic is TODO, you can help us with that if you have some time.

Today I am optimizing pins page, it already went down from 90kB to 9kB.

p.kaczmarek2 wrote:

it already went down from 90kB to 9kB

Good man

O.k., then I think for now I can remove the code to retrieve SSID. Even if logic for a second SSID is there, it might be easier to use CFG_GetWiFiSSID()/CFG_GetWiFiSSID2() then.
Just pushed the first changes to the PR (displaying only PowerSave mode on GUI [if it's configured]).
BSSID and WiFi channel are in JSON status.

I count on brave @divadiow for some tests again .
@p.kaczmarek2 do you know someone who could test XR809 code?
I tried to code "HAL_GetWifiStrength()" and "HAL_PrintNetworkInfo()" here, too, but can't test it...

Yes. I'll be home again tomorrow to test all again. I'm looking to get an XR809 but that's probably a week away at least, so no help yet.

Added after 2 [minutes]:

Also assumes the water sensor I'm looking at still comes with XR809

I have one or two XR809's somewhere, but I would need to look for them and I already have a queue of tasks waiting (including a lamp sent to me by @HalliHallo ), so I think I will attend to them first. There aren't much XR809 devices around, it seems to be the most rare platform.

I hope that dual SSID logic would be implemented soon, but it will be tricky. We would need to agree on some kind of threshold when to switch, idk, when connection to first SSID fails for 20 seconds or something? And then what, stay on SSID2 until SSID2 diseappers?

I fully agree - the actual coding should be much easier than the "logic" for it:

Should you switch to SSID2 in any case if connection fails or only if SSID1 is not present?
And especially the case you mentioned: What if SSID1 is temporarily out of order and is restored later?
We would probably need to make a network scan, and that is only available on some platforms (it's some time ago, so I don't recall my efforts in detail, but I didn't manage to succeed on my LN882H).
And: is the network scan possible during operation, or is the scan disruptive?

And what will the behaviour be if SSID1 is up but the password entered is wrong or password is changed on router without updating OBK. Will it know to switch or will it just keep trying SSID1. Does it keep trying now or just once? I'm not home to check.

all 1216_merge_0c97efa515cf

Added after 17 [minutes]:

divadiow wrote:

Does it keep trying now or just once? I'm not home to check.

yes. after changing ssid pw the W800 tries to connect approximately once every minute

What if you change SSID itself, and the target AP does not exist?

The message you've shown originates from here:

Maybe we could put there a change of current SSID? In this conditional block?

p.kaczmarek2 wrote:

What if you change SSID itself, and the target AP does not exist?

it still does please wait connect net...... every minute

"please wait connect net..." is not the message from the OBK, it's from the underlying SDK on that particular platform

divadiow wrote:

Also assumes the water sensor I'm looking at still comes with XR809

lame. bought 4 door sensor/water leak devices that looked like XR809 candidates. 3x CBUs and 1 CB3S

Actually CBUs are great, they have P16 routed out. You can use them for WS2812B LEDs.

and the device chassis makes quite a neat little package for adding USB power and adapting for small footprint LED deployment I guess.

> I see you made a feature to put a WiFi info on the main page just to later censor it before putting it on forum....
> Maybe that's a sign that your feature should be enabled by a flag? Something like "show extra info"?

Using either a MAC address of a device or an AP, an SSID or a BSSID, you can sometimes pin down a very precise physical location.

The current status page already leaks the MAC in the name of the device and by giving the actual MAC, so if any censoring should happen, MACs should be included.

There are even *public* databases that can be used for this.

This thread was linked in the issue where I requested BSSID to be visible on the main page for debugging - https://github.com/openshwprojects/OpenBK7231T_App/issues/1683

OP tried to censor the info, and still left out the MAC in the name of the device, and used a blurring alg which seems susceptible to being deciphered, so I'd agree with having a "Show extra/sensitive info" button.

Very nice! My suggestion is to add all necessary info to JSON API (Tasmota-like) and then just use this API in the Web App