Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
We have a device that needs to be configured in the field to establish what SSID and passphrase it should connect to by default. The default AP that a client connects to in the SDK (3.2.2) is hard coded, and there does not seem to be a mechanism to set the default SSD as the connection logic uses the hard coded values or looks in the stored_app_list information in the wifi config dct to select the AP to autoconnect with.
So to do what we need to do, the plan is to do a wifi scan and look for the SSID of interest so we can collect the access point details.
We could then save this information and when the device resets, do a manual wiced_wifi_join call to establish our connection.
It would seem structurally better to populate the stored_app_list in the dct with the information we get from the scan, and let the default behavior of bringing up the services do its job, so that in future releases of the SDK if there are additional requirements to establish the connection, we don't have to re-code our app to deal with it if the change is not completely encapsulated in the wiced_wifi_join call.
But I don't like hacking on SDK internal data structures that are also subject to change that would percolate upstream and cause us rework.
Is there a better way to implement this feature that gives us better isolation from SDK changes?