-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Condition changed to "offline" spontaneously, after being online. #70
Comments
Hello @ostrya, Yesterday I was very happy with your solution, but unfortunately, I found another issue, while running some tests. I understood that the behavior of the detection principle has changed in recent updates. Am I correct? My problem: If I disconnect from my Wifi, I receive an "offline" message instantly. If I connect to my Wifi again, I receive an "online" message, but (aprox.) 30 seconds after that an "offline" message is published and the app remains in this state.. Can you have a look. All log filrs are attached. 1725623018724.log [Edit] Forget those 30 seconds, it is even 4-5 seconds and also after reboot is has problem to publish "online". Best regards |
Hi @FireWizard52 , sorry to hear that it still does not work as expected. Yes, you are right - the current logic is that regardless of the publishing frequency, as soon as the device connects to or disconnects from a Wi-Fi, a message is sent. And from the logs, it looks like there are still issues with detecting the Wi-Fi name. Repeatedly, there is a In addition, there is your point about sending offline messages immediately. If situations like yours, i.e. disconnecting and re-connecting within a few seconds, happen frequently, we probably want to introduce a waiting time between detecting the disconnect and sending an offline message. I'll need to look into that as well. |
good evening @ostrya , Thank you for your quick response. For your information The MQTT server (broker) is a local one and so the route will change. The waiting time is probably a good idea, as, because of the connected/disconnected cycle and vice versa. the network topology changes. Perhaps a small waiting time will already be sufficient However I did not disconnect and reconnect within seconds. Mostly it was more than a minute. Another issue is that, this test I did, was switching off and on the WiFi on my phone . This might be different from leaving the area and getting out of WiFi range, but leaving the WiFi "on". Perhaps something to consider. [Edit] No, it makes no difference. Also when leaving the area the phone transmits "offline", which is correct, but returning and entering the area, results in an "online" message and then switching back to "offline". So the behavior of leaving and returning the area and switching "Off"and "On" the WiFi. |
The main issue is that wifi manager sometimes returns a disconnected WifiInfo object rather than null, which was wrongly detected as being connected to a new "<unknown ssid>" network. This is addressed by additionally checking the supplicant state of the network for state COMPLETED. Also for SDK < 31 we cannot really rely on the WifiManager giving data in sync to the Callback events, as we have no guarantees about that from AOSP. The best we can do is (similar to the Broadcast solution for SDK < 23), regardless of event type, always to check the current SSID and assume connect when it's present and disconnect when it's absent. Since this causes duplicate events, the last known SSID is statically persisted in the WifiEventConsumer, and the event is only propagated if the SSID actually changes.
I hope I got it now. There were several issues I had overlooked, but it should work now with the next release. In any case, please keep an eye out for the restart issue, that should still work as before. If it persists, please create a new issue for that. |
Hi @ostrya, I waited a couple of weeks, before to report the results of the latest release 2.6.3, as I was too quick the last time. I can confirm that the app detects the "Home" network correctly and it reports [online]. However this is not the case, if I leave my house, e.g. to do some shopping. After I leave that network, it will properly display as connectedWifi "N/A", until I arrive at home, after it will detect the "Home" network and will report [online]. So the detection of the connection to my Home Network is okay, but the detection of the disconnection is not working. This is the same, if connected to a foreign network. It gives [offline] and the SSID, which is correct, as it is not my home network, but it does not disconnect that foreign network and does not show N/A. Regards |
Sorry that it still does not work, and thanks for the update. So it looks like my changes are not working as intended. I guess I will need to go back to detecting the WiFi network in a time-based manner. |
Since the network callback solution does not work due to race conditions, we additionally read the wifi during publishing again. Hopefully, this should give us the best of both worlds. Also, do not store the connected wifi into a preference, since we do not want it to survive app restarts - who knows how long the app was not running, most likely the wifi has changed in the meantime. relates to #70
Hi @FireWizard52, do you see any changes with the new version 2.6.4? |
Hello Kai, I wasn't aware that version 2.6.4 had been released. So I did not monitor it consequently, but now I saw that it was actually installed on the phone. I checked in the log al the times, that I was sure, that I was not connected to my own wifi. The result was, what I expected and my first impression is that the issue has been solved now. Before closing this issue, I suggest to keep it open for another couple of days. In the meantime, I will monitor its behavior. Thanks again |
Google has published the new release 2.6.2 in the Google Play store.
I updated the app to this version and everything works again as before.
Thank you very much for your quick response and solving this issue.
Best regards
Originally posted by @FireWizard52 in #69 (comment)
The text was updated successfully, but these errors were encountered: