esp-idf/examples/provisioning
Rahul Tank 6040bba236 Wifi Prov: Disabled the default support for BLE Encrpytion on characteristics read /write
By default, disabled the BLE Encrpyption requirement for provisioning characteristic.
With this flag enabled, when remote attempts to read and if the ACL link is not encrypted,
ESP device will return Insufficient Authentication. It is remote device responsibility to go
for link encryption which may result in pairing.

Some devices do not proceed for any pairing and just show failure pop-up. Also, user needs
to remove bonding on remote phone manually and then try again. This is causing bad user experience.

End user can enable it as per their use case.
2022-11-25 14:21:13 +05:30
..
legacy ESP32C3: Fix for provisioning failure with ble transport mode and bluedriod stack for v4.3 2021-09-21 19:34:13 +05:30
wifi_prov_mgr Wifi Prov: Disabled the default support for BLE Encrpytion on characteristics read /write 2022-11-25 14:21:13 +05:30
README.md provisioning: update README.md 2021-03-19 13:58:08 +08:00

Provisioning Application Examples

This primarily consists of a single unified example wifi_prov_mgr

  • wifi_prov_mgr Abstracts out most of the complexity of Wi-Fi provisioning and allows easy switching between the SoftAP (using HTTP) and BLE transports. It also demonstrates how applications can register and use additional custom data endpoints.

Provisioning applications are available for various platforms:

The Android and iOS provisioning applications allow the user to configure the device manually or by scanning a QR code. QR codes can be generated by any online QR code generator. QR code payload is encoded with a JSON string containing the device name, proof-of-possession key (if used) and transport type (BLE or softAP), for example:

{"ver":"v1","name":"PROV_000318","pop":"a1000318","transport":"softap"}

The more details about QR code format, you can refer to QR Code Scan.

Legacy Examples

The legacy examples require own implementation of provisioning functions and handlers. The Wi-Fi provisioning component abstracts out most of this complexity and provides a simpler interface and so, that is recommended for use. However, if you want to use lower level provisioning and protocomm APIs, you can check the these examples under legacy/ folder:

  • softap_prov Provisioning involves Wi-Fi station configuration via an HTTP server running on the device, which is initially configured to be in SoftAP mode. After provisioning, device runs in Wi-Fi station mode only and connects to the AP whose credentials were provided during provisioning.

  • ble_prov Provisioning involves Wi-Fi station configuration via BLE service endpoints running on the device initially. After provisioning, BLE is turned off and device runs in Wi-Fi station mode, connecting to the AP whose credentials were provided during provisioning.

  • console_prov Provisioning involves Wi-Fi station configuration via UART console. This is intended for debugging protocomm and provisioning related features.

  • custom_config Similar to softap_prov examples, but allows for configuration of custom (device-local) information during provisioning. This is intended as an example for implementing custom provisioning schemes.

Refer to the README.md files in each example directory for more information.