app_prov_get_wifi_state() returns "connecting" even after wifi is connected?

[RMandR]

I'm working on BLE provisioning based on IDF 3.2 and the samples ios app (the version before the latest change to v1.2)

Even after the esp32 is connected to the AP, the status is not updated and the IOS app gets stuck in polling.

I've added an additional endpoint to the BLE to send some custom device info BEFORE the Wifi credential is sent.

What am I doing incorrectly?

Thanks in advance.

Code: Select all

I (135674) app_prov_handler: WiFi Credentials Received :
        ssid MySSID
        password 123456
I (135834) app_prov_handler: WiFi Credentials Applied
I (101424) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (102424) wifi: state: init -> auth (b0)
I (102434) wifi: state: auth -> assoc (0)
I (102434) app_prov_handler: Connecting state: 0
I (102434) wifi: state: assoc -> run (10)
I (102454) wifi: connected with MySSID, channel 1
I (102504) wifi: pm start, type: 1

I (135964) app_prov_handler: Connecting state: 0
I (141144) app_prov_handler: Connecting state: 0

[RMandR]

Update:

it looks like the only way the status will change is when esp32 gets and IP address.

Code: Select all

//app_prov.c
 case SYSTEM_EVENT_STA_GOT_IP:
        ESP_LOGI(TAG, "STA Got IP");
        /* Station got IP. That means configuration is successful.
         * Schedule timer to stop provisioning app after 30 seconds. */
        g_prov->wifi_state = WIFI_PROV_STA_CONNECTED;

The issue is that if esp32 is already connected to an SSID, and you'd like to switch it to a new network, the ios app will not get a provisioning successful message.

Not only that, if you plan on changing the same SSID's password or name on the AP, and you preemptively change the wifi provisioning info from the IOS app, you don't get the "networkNotFound" error.

to get back on the happy path, one needs to apply the wrong the SSID info, reboot esp32, then go through the BLE provisioning process with proper terminating responses. Otherwise, the provisioning does not seem to stop.

Thank you for your help.

-a

[ESP_Piyush]

Hello,

Re-provisioning an ESP32 already connected to a network is not an intended use case for the Unified Wi-Fi provisioning component. You must explicitly reset the ESP32's saved Wi-Fi credentials and reboot it to restart provisioning.

Hope this helps. If you specify your exact use case, I can check what can be done.

[RMandR]

@ESP_Piyush Thanks for clarifying.

In the case of a mobile app provisioning over BLE, the app will not receive a final confirmation if the user tries to provision an already provisioned device.

Since the users can't be relied on performing WiFi wipe and reboot, the workaround on provision initiation would be: 1) wipe the wifi creds, 2) reboot esp32, 3) somehow note that post reboot, it esp32 should go into provisioning mode.

Not sure if there is a better way.

-a