Chapter 2. API Reference
Device Discovery
The advertisement and device discovery is left to the application and depending on the protocol chosen, the phone
apps and device firmware application can choose appropriate method to advertise and discovery.
For the SoftAP+HTTP transport, typically the SSID (network name) of the AP hosted by the device can be used for
discovery.
For the BLE transport device name or primary service included in the advertisement or combination of both can be
used for discovery.
Architecture
The below diagram shows architecture of unified provisioning.
Fig. 28: Unified Provisioning Architecture
It relies on the base layer called Protocol Communication (Protocol Communication) which provides a framework
for security schemes and transport mechanisms. Wi-Fi Provisioning layer uses Protocomm to provide simple call-
backs to the application for setting the configuration and getting the Wi-Fi status. The application has control over
implementation of these callbacks. In addition application can directly use protocomm to register custom handlers.
Application creates a protocomm instance which is mapped to a specific transport and specific security scheme. Each
transport in the protocomm has a concept of an“end-point”which corresponds to logical channel for communication
for specific type of information. For example security handshake happens on a different endpoint than the Wi-Fi
configuration endpoint. Each end-point is identified using a string and depending on the transport internal represen-
tation of the end-point changes. In case of SoftAP+HTTP transport the end-point corresponds to URI whereas in
case of BLE the end-point corresponds to GATT characteristic with specific UUID. Developers can create custom
end-points and implement handler for the data that is received or sent over the same end-point.
Espressif Systems 677
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General