Open xjikka opened 6 months ago
It's not yet implemented, as you found out correctly. Maybe a hint in GUI would be helpful
It's not yet implemented, as you found out correctly. Maybe a hint in GUI would be helpful
I agree. Maybe some change like this:
http_fns.zip (not tested, just suggestion)
Anyway, I need SSID2 and will make some simple changes in the code to make it working somehow. If it's at least somewhat usable, I'll post it here.
I have SSID2 simple mod done. It is tested on BK7231N, but with these simple changes it should work on any platform.
How does it work: It tries g_SSIDSwitchAfterTry times to connect to the SSID and if it fails it switches to SSID2 (if set) and so on after 3 more failed attempts back to SSID and so on.
Here are the differences: https://github.com/openshwprojects/OpenBK7231T_App/compare/main...xjikka:OpenBK7231T_App:ssid2mod
If You will find it OK, I can submit these changes here.
Thanks for your code!
My personal approach would be a bit different, I would make the first SSID "preferred" so in pseudo code (I will "rename" SSID to SSID1 to get it clearer ;-)): Every time I try to connect to WiFi, first try SSID1 and increment a counter If counter > threshold, also try SSID2
If WiFi is connected, reset counter.
But I hope it's o.k. if I give some feedback on your code? Because I think it could be simplified in some points:
// static int g_SSIDactual = 0; // 0=firsttime 1=ssid1 2=ssid2
static int g_SSIDactual = 0; // make it easy - default to first SSID --> no need for "if (g_SSIDactual == 0)"
// to save some caclulation, use 0 and 1 (it's easy to "toggle" between 0 and 1) 0=SSID1 1=SSID2
with this "change" (0=SSID1 and 1=SSID2) the check can be very short:
void CheckForSSID12_Switch() {
#if ALLOW_SSID2
// nothing to do if SSID2 is unset or we are below counter
if ( (CFG_GetWiFiSSID2() == "") || ( g_SSIDSwitchCnt++ <= g_SSIDSwitchAfterTry) ) return;
// if we are here, SSID2 is set AND counter is over number of tries, so do the switch ;-)
g_SSIDSwitchCnt = 0; // reset counter
g_SSIDactual ^= 1; // toggle value 0 ^ 1 = 1 and 1 ^ 1 = 0
ADDLOGF_INFO("WiFi SSID: switching to SSID%i\r\n",g_SSIDactual+1);
#endif
}
Not tested, just coded ;-)
Of course, "CFG_GetWiFiSSIDX()" and "CFG_GetWiFiPassX()" need modification, to to reflect 0 and 1 (instead of 1 and 2) for SSID and SSID2
Once again, I really appreciate your code, it's meant as a positive feedback.
I understand, but the reason for int g_SSIDactual = 0=first time was that: We know that the WiFi connection has not been started yet We can parametrically change the preferred SSID by simply adding preferred SSID as a parameter We can possibly have multiple SSIDs (3,4...)
For example, if it is a device that changes location, then if there is a prefered SSID parameter, the preferred SSID could be changed by script when device changes location. Switching to another SSID usually takes about 1 minute after restart.
... but even with more SSIDs I don't see why we can't simply set the SSID to the (wished) preferred SSID and then start the process. In "my" proposal: If you prefer SSID2, set g_SSIDactual=1 once, before starting the process.
So a "set_preferred_ssid" would mean: "g_SSIDactual= (preferred SSID) ;g_SSIDSwitchCnt = 0;"
OK. I agree. The power is in simplicity. I will change it.
BTW: Even if you want to go for more than 2 SSIDs in the future, I would propose to "start" with 0 for SSID1. Then "next SSID" would be "(g_SSIDactual+1)%numberOfSSIDs"
very good job guys, thank you, but here is one issue to fix:
(CFG_GetWiFiSSID2() == "")
this will not work, it's C, you are comparing pointers. It will always be false. You need to do:
(CFG_GetWiFiSSID2()[0] == 0)
to check for empty strings.
Apart from that, seems good so far, open PR when you're ready
very good job guys, thank you, but here is one issue to fix: (CFG_GetWiFiSSID2() == "") this will not work, it's C, you are comparing pointers. It will always be false. You need to do: (CFG_GetWiFiSSID2()[0] == 0) to check for empty strings.
Apart from that, seems good so far, open PR when you're ready
Thanks, I'm 95% Pascal+SQL and 5% the others ;-) But I'll do my best to change it ;-)
I have SSID2 simple mod done. It is tested on BK7231N, but with these simple changes it should work on any platform.
How does it work: It tries g_SSIDSwitchAfterTry times to connect to the SSID and if it fails it switches to SSID2 (if set) and so on after 3 more failed attempts back to SSID and so on.
Here are the differences: xjikka/OpenBK7231T_App@main...ssid2mod
very nice. good 1st steps!
just a suggestion: on tasmota there is also a fallback to AP mode if none of the SSIDs arent available (on case of wrong pw or low signal). for 120s the default AP pops up and waits for connection. when time´s up it switches to SSID scan mode again. so you are able to recover you device in almost any case.
Just as a quick feedback: It's not working on LN882H :-(
but probably thats not related to your code but something more general - WiFi is done by libs which are not always handling things the same way....
I'm trying to dig into this issue
o.k., it took some time, but I figured out some issues with the actual code (at least on LN882H):
The "culprit" is the function void Main_ConnectToWiFiNow()
in user_main.c.
This is the actual code (including the "X"-functions introduced here (e.g. CFG_GetWiFiSSIDX()
instead of CFG_GetWiFiSSID()
):
void Main_ConnectToWiFiNow() {
const char* wifi_ssid, * wifi_pass;
g_bOpenAccessPointMode = 0;
CheckForSSID12_Switch();
wifi_ssid = CFG_GetWiFiSSIDX();
wifi_pass = CFG_GetWiFiPassX();
HAL_ConnectToWiFi(wifi_ssid, wifi_pass,&g_cfg.staticIP);
// register function to get callbacks about wifi changes.
HAL_WiFi_SetupStatusCallback(Main_OnWiFiStatusChange);
ADDLOGF_DEBUG("Registered for wifi changes\r\n");
g_connectToWiFi = 0;
}
I changed this to:
void Main_ConnectToWiFiNow() {
const char* wifi_ssid, * wifi_pass;
g_bOpenAccessPointMode = 0;
CheckForSSID12_Switch();
wifi_ssid = CFG_GetWiFiSSIDX();
wifi_pass = CFG_GetWiFiPassX();
// register function to get callbacks about wifi changes ..
// ... but do it, before calling HAL_ConnectToWiFi(),
// otherwise callbacks are not possible (e.g. WIFI_STA_CONNECTING can never be called )!!
HAL_WiFi_SetupStatusCallback(Main_OnWiFiStatusChange);
ADDLOGF_INFO("Registered for wifi changes\r\n");
ADDLOGF_INFO("Connecting to SSID [%s]\r\n", wifi_ssid);
HAL_ConnectToWiFi(wifi_ssid, wifi_pass,&g_cfg.staticIP);
// don't set g_connectToWiFi = 0; here!
// this would overwrite any changes, e.g. from Main_OnWiFiStatusChange !
// so don't do this here, but e.g. set in Main_OnWiFiStatusChange if connected!!!
}
the changes are:
Move the line setting callback function.
The actual code will set this after doing the call to connect - so (in my case) the connecting phase was never returned - so the increase of g_connectToWiFi
here was never called.
After this change, this call was possible (and g_connectToWiFi
was set to 120) but directly overwritten by the last line (setting it to 0).
The result was, that after the first call to Main_ConnectToWiFiNow()
it was never again called (for if (g_connectToWiFi)
was never true again.
I hope, I understood the mechanism right, then the original code did not worked, as expected?
With the change above, it works for me (together with an additional g_connectToWiFi = 0;
in Main_OnWiFiStatusChange
when WiFi is connected:
case WIFI_STA_CONNECTED:
g_bHasWiFiConnected = 1;
g_connectToWiFi = 0;
ADDLOGF_INFO("Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - %i\r\n", code);
Since this is a crucial code I would ask for "someone" who knows the code (openshwprojects ?!?) to take a look. I will open a PR then ...
Since this is a crucial code I would ask for "someone" who knows the code (openshwprojects ?!?) to take a look. I will open a PR then ...
Agreed, the hardest thing is always to understand how the original programmer meant it and how it is supposed to work. I originally had a similar variant as MaxineMuster with direct HAL_ConnectToWiFi, but in certain situations it ended up with a reset. So I tried adding HAL_DisconnectFromWifi() but then sometimes it didn't connect again.
Careful with this Connect and Disconnect.
I've posted updates to https://github.com/openshwprojects/OpenBK7231T_App/compare/main...xjikka:OpenBK7231T_App:ssid2mod Tested on BK7231N ONLY (using code including connect changes for LN882H by @MaxineMuster)
@g6094199 - Automatic switching to AP is not a good idea, in case of random WiFi unavailability (and subsequent switching to AP mode), the module would only be available via AP - it would no longer connect to normal WiFi without a restart.
as is said, the AP should be with a timer of e.g. 120 sec an should teh switch back to client mode again.n this will prevent your mentioned problem.
@g6094199 I also think this would be a good feature, but at the moment I can't think about a working solution for this: Since OBK supports quite a range of platforms, at least for the one I know best, I couldn't think of a solution:
Enabling AP mode is only a possibility during startup (if on day 32 WiFi fails at 10:43, who knows that up to 10:45 you can use the AP). So it depends on only on the visibility of a SSID, but accessing the WiFi scan results isn't possible for "my" platform. So if implemented, it would be a feature only for few device platforms. If it's intended to cover also unsuccessful connection attempts(wrong password), this will take a long, unpredictable time, so you have to try the AP for quite some time... My conclusion: if access to data from network scan would be available for all platforms, that might be a good feature. From what is possible now, I think the actual solution (entering safe mode after multiple unsuccessful starts in a row) is a good one, sufficient for most cases.
thx for the feedback
When we want to test second SSID on alpha app version? 🙃
When we want to test second SSID on alpha app version? 🙃
I'll prepare binaries asap. Be patient.
Asap is over ;-) here the binaries. Hope everything is ok, compiled using docker image. https://github.com/xjikka/OpenBK7231T_App_Old/releases/tag/SSID2mod
Alpha version for testing purposes only, do not use it in "live" devices. Based on the main 1.17.592
I only tested the OpenBK7231N version OpenBK7231N_dev_20240527_195910.rbl and on an simple Tuya Smart Switch device only.
Why do you want to open AP if there is no WiFi? It sounds like a terrible security threat. Many people are living in flats with neighbours, so you're telling me that when something happens to my WiFi (or even if there is a range issue), the device will revert back to AP so neighbours can connect it and mess with it?
in which cases will be switched to AP mode an when will this happen? in cases when there is something terribly wrong. this needs you attention anyways.
if there will be this feature in the future, this can made to be en/disabled.....
but to tell a userstory: you have a 3 phase powermeter with openbeken corrected to mains. in case there is something wrong with the wifi pw or config you have to shut down the hole house. remove the unit. power the house again. open the unit flash openbeken again. and do vis versa. if you are NOT allowed to do electrical work (which most of you are denied), you need an electritian...this can take days and will cost a fortune ;-) with AP mode you can fix the problem within minutes without touching anything.
Why do you want to open AP if there is no WiFi? It sounds like a terrible security threat. Many people are living in flats with neighbours, so you're telling me that when something happens to my WiFi (or even if there is a range issue), the device will revert back to AP so neighbours can connect it and mess with it?
Not me, it was "feature request" from @g6094199 https://github.com/openshwprojects/OpenBK7231T_App/issues/1246#issuecomment-2133121713 and I disagree with that https://github.com/openshwprojects/OpenBK7231T_App/issues/1246#issuecomment-2134008846.
in which cases will be switched to AP mode an when will this happen? in cases when there is something terribly wrong. this needs you attention anyways.
if there will be this feature in the future, this can made to be en/disabled.....
but to tell a userstory: you have a 3 phase powermeter with openbeken corrected to mains. in case there is something wrong with the wifi pw or config you have to shut down the hole house. remove the unit. power the house again. open the unit flash openbeken again. and do vis versa. if you are NOT allowed to do electrical work (which most of you are denied), you need an electritian...this can take days and will cost a fortune ;-) with AP mode you can fix the problem within minutes without touching anything.
Maybe the right way can be some "user script", when no WiFi, start AP over Command. I don't know, if it is possible for now, but if I need something special like that, I'd do it this way. Using autoexec.bat. like addChangeHandler WiFiState != 4 mode_wifi_ap (script)
but to tell a userstory: you have a 3 phase powermeter with openbeken corrected to mains. in case there is something wrong with the wifi pw or config you have to shut down the hole house. remove the unit. power the house again. open the unit flash openbeken again. and do vis versa.
I think this is a special case, for even your proposal (open AP for a short period of time) would mean you need to be aware of the problem right from the beginning to connect during the 2 minutes or so. But I agree, there should be a solution, something like the userscript proposed, or if the device has a physical button, you may do something with long pressing it...
Maybe "your" request should be something like a "configured AP" so if there is no WiFi, the device opens an AP, but not the standard open AP, but an AP with a configured passphrase. That could be a solution, but only an special config, for you would need to decide, what to do then: Stay in AP mode? try to connect to the SSIDs after some time again? And you would need timers in the later case...
I am trying to use SSID2 with no success. It always connects to SSID1 only (CFG_GetWiFiSSID() and CFG_GetWiFiPass()). I couldn't find code in the source code that uses CFG_GetWiFiSSID2() and CFG_GetWiFiPass2(). Is SSID2 solved somehow differently, or is it not yet implemented?