Is there a way to always save credentials ?

[dumarjo]

Hi,
In some circumtance, the configuration of the WIFI can be done without WIFI access. So in this case, I would like to save the credentials event if no connexion happen. Is it possible to achieve this with AutoConnect ?

From the documentation https://hieromon.github.io/AutoConnect/apiconfig.html#autosave, It's look like a new enum item can be added , like AC_SAVECREDENTIAL_ALWAYS ?

What do you thing about this ?

[Hieromon]

@dumarjo What is the difference between AC_SAVECREDENTIAL_ALWAYS and using AutoConnectCredential API?

the configuration of the WIFI

If it indicates what is included in the AutoConnectCredential data structure, it is also possible to pre-store WiFi configuration data by using the AutoConnectCredential API with the sketch.
Refs: https://hieromon.github.io/AutoConnect/credit.html

Or is your intended use case limited to applying static IP addresses?

[dumarjo]

Hi @Hieromon,

I think I haven't explain the problem correctly.

What happen if I enter manually the SSID and password in the AP web page and the SSID is not reachable at that moment ? Is the creds are stored or will be ignored ?

AC_SAVECREDENTIAL_ALWAYS must force the creds to be saved even is the SSID cannot be connected. This is why I propose this new enum.

Is it clearer ?

[Hieromon]

@dumarjo It became clear. Thank you.
In other words, it provides the utility of interactively pre-registering APs that allow connections. isn't it?
OK. Let's do it!

Are there any additional restrictions in determining the specifications? In my experience, this kind of functionality can cause inconsistencies with other specifications... Is there a possibility of a spec conflict between AC_SAVECREDENTIAL_ALWAYS and AutoConnectConfig::autoReconnect via the background? When AC_SAVECREDENTIAL_ALWAYS is implemented, it should be possible to set a new AP while executing the loop() with the autoReconnect enabled. Is that okay?

[dumarjo]

I think the only difference is the saving of a inexistent SSID/password. The rest of the specs should be the same.

[Hieromon]

@dumarjo We have one problem in implementing this support.
This is a simple implementation, but it affects the current specifications as I thought.
Pre-registering an AP's credentials means that AutoConnect does not yet know the BSSID of that AP. Normally, when AutoConnect attempts to connect to an AP using registered credentials, it executes WiFi SCAN in advance to match the BSSID of the saved credentials with the BSSID of the AP to connect to. Then AutoConnect will not invoke WiFi::begin if they are in disagreement. There is an option to use SSID instead of BSSID to match APs, but this option is enabled at build time. It does not dynamically switch to SSID matching at your convenience at runtime.
In other words, even if you pre-register your credentials, you will not be able to connect to the target AP because the BSSID is undefined. I realized that was the reason I felt uncomfortable.
Refs: Match with known access points by SSID

To avoid this inconvenience, you need to change the specifications of AutoConnect::begin. Maybe we have two options:

1. Change AP matching key default to SSID
2. Perform SSID matching only with pre-registered credentials

I think option # 1 is not desirable. In an environment where different APs with the same SSID exist, it is not always possible to connect to the same AP as last time. It should be the user's choice.

Option # 2 interprets the stored credentials as pre-registered if the BBSSID is NULL and uses the SSID for AP matching even if AUTOCONNECT_APKEY_SSID is not defined. At first glance this seems to fit the occasion where you need it. But once the connection is successful, AutoConnect will overwrite the BSSID with the actual value (which is provided by the AP). And the next connection will use BSSID. This is distinction of connectability condition and can be confusing to the user.
Do you have any solutions for the inconsistent connection behavior to the AP?

[dumarjo]

You are right, I forget that behavior.. We have changed the AUTOCONNECT_APKEY_SSID in our code because we are in an environment where we have multiple AP with the same SSID. The BSSID can improve the connection time. I Think your option 2 is the solution for an easy solution. If the device is installed in a multi-AP environment, the AUTOCONNECT_APKEY_SSID will be set anyways. In a environment that only one AP, the option 2 will fit.

It took us some time before knowing that the BSSID was saved by default instead of the SSID. But we where happy to see that a compile time switch can be use to change this behavior.

[Hieromon]

@dumarjo Thank you for your suggestion.
I tried to implement it experimentally based on the above specifications. After evaluating this, I noticed that there are other things to consider apart from AUTOCONNECT_APKEY_SSID. It always reproduces in the following scenarios and also affects the AutoConnectConfig settings in the user sketch.

In the simplest sketch sequence case:

1. Declare AutoConnect object
2. Declare AutoConnectConfig object
3. Set AC_SAVECREDENTIAL_ALWAYS to AutoConnectConfig::autoSave
4. Configre AutoConnectConfig via AutoConnect::config()
5. Start AutoConnect::begin(), it doesn't matter if you can connect to any AP at this point. The connection may be successful and the AutoConnect::handleClient() in the loop() may be repeated, but the problematic event will occur regardless of it.
6. In the client browser, register a new AP credential that cannot be reached using Config NEW in the AutoConnect menu.
7. Proceed to APPLY, of course, the connection attempt will fail. But the SSID and password you entered and the IP configuration has been saved as a new one of credentials.

So far that's what we expected, aimed. From here to follow, it is the behavior that doesn't feel right to me.

8. Reset ESP module via RESET menu.
9. Start AutoConnect::begin(), the 1st-WiFi.begin in AutoConnecrt::begin() will always fail. Because the SDK does not store the credential of the new AP you registered. ConfigNEW menu disconnects from WiFi and then runs WiFi.begin based on a new credential. At this point, the credentials stored by the SDK will be lost. That is, the 1st-WiFi.begin with no arguments does not have the required credentials.
10. Launch WIFI_AP, start DNS, the captive portal will open.

This behavior is correct under the current AutoConnect specifications. However, the user only registered a new credential on the assumption that he could not connect. Will they even allow the current WiFi connection to be abandoned?
Obviously, this is a detrimental effect of diverting the Config NEW feature.

Having said that, we have the option to avoid this inconvenience. It is autoReconnect. If autoReconnect is enabled, it will even connect to the unconnected SSID you have just registered.
After all, AC_SAVECREDENTIAL_ALWAYS is a strange parameter whose utility changes depending on how autoReconnect is set.

Can you accept this specification? Is it the same for other users?
Also, the experimental implementation is in my local repository and I haven't pushed it to the remote yet. Do you need it?
I have staged a version for evaluation of this support into the enhance/v130 branch. You can evaluate the behavior of AC_SAVECREDENTIAL_ALWAYS. If you have any questions, please post.
After finalizing the above specifications, I plan to release it as AutoConnect v1.3.0.

[dumarjo]

Hi @Hieromon ,
This is probably a special case for you project. So to have a different behavior when AC_SAVECREDENTIAL_ALWAYS is used, i don't think this will be problematic. Since nobody have used it in the past.

I will take a look at it and let you know my impression.

[Hieromon]

This feature has been supported in v1.3.0.