Chapter 2. API Reference
The provisioning service will automatically finish only if it receives valid Wi-Fi AP credentials followed by success-
fully connection of device to the AP (IP obtained). Regardless of that, the provisioning service can be stopped at any
moment by making a call to wifi_prov_mgr_stop_provisioning().
Note: If the device fails to connect with the provided credentials, it won’t accept new credentials anymore, but
the provisioning service will keep on running (only to convey failure to the client), until the device is restarted. Upon
restart the provisioning state will turn out to be true this time (as credentials will be found in NVS), but device will
again fail to connect with those same credentials (unless an AP with the matching credentials somehow does become
available). This situation can be fixed by resetting the credentials in NVS or force starting the provisioning service.
This has been explained above in Check Provisioning State.
Waiting For Completion Typically, the main application will wait for the provisioning to finish, then de-initialize
the manager to free up resources and finally start executing its own logic.
There are two ways for making this possible. The simpler way is to use a blocking call to
wifi_prov_mgr_wait().
// Start provisioning service
ESP_ERROR_CHECK( wifi_prov_mgr_start_provisioning(security, pop, service_
,→name, service_key) );
// Wait for service to complete
wifi_prov_mgr_wait();
// Finally de-initialize the manager
wifi_prov_mgr_deinit();
The other way is to use the default event loop handler to catch WIFI_PROV_EVENT``s and call
:cpp:func:`wifi_prov_mgr_deinit()` when event ID is ``WIFI_PROV_END:
static void event_handler(void* arg, esp_event_base_t event_base,
int event_id, void* event_data)
{
if (event_base == WIFI_PROV_EVENT && event_id == WIFI_PROV_END) {
/* De-initialize manager once provisioning is finished */
wifi_prov_mgr_deinit();
}
}
User Side Implementation When the service is started, the device to be provisioned is identified by the advertised
service name which, depending upon the selected transport, is either the BLE device name or the SoftAP SSID.
When using SoftAP transport, for allowing service discovery, mDNS must be initialized before starting provisioning.
In this case the hostname set by the main application is used, and the service type is internally set to _esp_wifi_prov.
When using BLE transport, a custom 128 bit UUID should be set using
wifi_prov_scheme_ble_set_service_uuid(). This UUID will be included in the BLE advertisement
and will correspond to the primary GATT service that provides provisioning endpoints as GATT characteristics.
Each GATT characteristic will be formed using the primary service UUID as base, with different auto assigned 12th
and 13th bytes (assume counting starts from 0th byte). Since, an endpoint characteristic UUID is auto assigned, it
shouldn’t be used to identify the endpoint. Instead, client side applications should identify the endpoints by reading
the User Characteristic Description (0x2901) descriptor for each characteristic, which contains the endpoint name
of the characteristic. For example, if the service UUID is set to 55cc035e-fb27-4f80-be02-3c60828b7451, each
endpoint characteristic will be assigned a UUID like 55cc____-fb27-4f80-be02-3c60828b7451, with unique values
at the 12th and 13th bytes.
Once connected to the device, the provisioning related protocomm endpoints can be identified as follows :
Espressif Systems 682
Submit Document Feedback
Release v4.4
To Next Page
Loading...