-
-
Notifications
You must be signed in to change notification settings - Fork 79
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
WifiHelper and NetworkHelpers should be able to be called multiple times after a Disconnect #1421
Comments
What I'm trying to solve here is the ability, at least for Wifi to be able to retry. This is in the context of using improv-wifi (see https://www.improv-wifi.com. If by mistake, you enter the wrong elements, it won't connect. Also, I am turning this feature on only when it does not connect properly after a bit of time. So I'm a bit doomed, if I want to use the helper to do so. |
I agree. Just wanted to make sure that you had the full context 😁 |
We really need the ability to retry. I prefer |
+1 for ability to retry, Now i'm always restarting device after connection to Wifi failed. Setting up "WiFi manager with fallback" with current approach may be tricky - with retries should be pretty easy (retry N times, when all fails then create AP with WWW interface for new credentials) |
This may require a redesign and implementation of the network glue and boot sequence. |
And on the side note: yes it's painful to setup properly without the helper and in those configuration cases where we want all to be automatic and transparent. There maybe manual setup to be done instead of using the helper. Helper is here to help in 95% of the cases, now, what we're trying to all achieve is falling in the 5%, so some manual adjustments are ok. But yes, I would also prefer the helper to cover the 5% left percents ;-) |
I have add this NetworkHelper.ResetInstance(); and it seems to work when calling the ConnectDHCP multiple times. |
@josesimoes the unit tests are always resetting everything and they seems to work :-) So shall we just use it as it's proven to work on the tests? |
What is happening in the unit test is cheating... 😅 and it works because the device connects to that wifi AP and remains there. All tests run smoothly one after the other as you know. Sure, we can remove this code preventing multiple calls. That will work for some situations, and we'll start getting complains deriving from others... |
Whatever the solution, I am of the opinion that multiple attempts to connect to WIFI is desirable. This is especially when the WIFI SSID and Password is entered via a Web Portal or BLE. User entry errors are expected. |
After investigations, even with the WiFi helper run a first time, I found a nice pattern to have it working still properly. I've been improving the WiFi AP samples with it. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Library/API/IoT binding
System.Net and System.Device.Wifi
Visual Studio version
No response
.NET nanoFramework extension version
No response
Target name(s)
No response
Firmware version
No response
Device capabilities
No response
Description
When calling multiple time the
WifiNetworkHelper.ConnectDhcp
or any function ultimately callingNetworkHelper.SetupHelper
will always fail as_helperInstanciated
is never reset!WifiNetworkHelper.Disconnect(); should call NetworkHelper.ResetInstance() like in the UnitTests. This will allow after failure to retry to connect once the Disconnect function called.
Similar to Wifi.NetworkHelper, the normal NetworkHelper should have a Disconnect() method or expose the ResetInstance()
How to reproduce
This will result in an invalid operation exception:
Expected behaviour
This should not throw an exception but rather work fine.
Screenshots
No response
Sample project or code
No response
Aditional information
No response
The text was updated successfully, but these errors were encountered: