wifi_prov_mgr: Add support for continuous (always on) BLE provisionning (IDFGH-4111)

[bbinet]

Is your feature request related to a problem? Please describe.

I'm successfully using wifi_prov_mgr component to provision esp devices, but some esp devices need to update their wifi settings from time to time, for example if they are regularly moved to a new location.
Then we could erase our device to factory defaults and start again the provisioning manager but I'd rather like the provisioning manager to be always on, so that we can update wifi settings easily at any time through BLE transport.

Describe the solution you'd like

So I'd like wifi_prov_mgr component to add support for a "continuous" mode for BLE transport, which means it is always on, even when esp device is actually already connected to wifi, so that we can update the wifi settings easily.

If we configure custom endpoints, the provisioning manager would also allow to be used as the normal communication manager similarly to the esp_local_ctrl component.

I would also be interested to see a example using both wifi_prov_mgr and esp_local_ctrl components at the same time so that they share the same protocomm instance.

[bbinet]

So would the provisioning manager work correctly if we don't call esp_wifi_disconnect() while the esp is already connected to wifi AP?
See: https://github.com/espressif/esp-idf/blob/master/components/wifi_provisioning/src/manager.c#L1449

[Alvin1Zhang]

Thanks for raising this feature request.

[jhnlmn]

I have a similar suggestion -make it easier to extend provision manager and allow it to be integrated with a permanent BLE peripheral, such as bleprph. I was able to do that: completely delete protocomm_nimble.c and replace it by my own code based on bleprph - add provision endpoints to "static const struct ble_gatt_svc_def gatt_svr_svcs", route characteristic read/writes to protocomm_req_handle, call protocomm_handle->sec->open_transport_session on BLE connection and protocomm_handle->sec->close_transport_session on BLE disconnection, etc.
It took me more that a week to make it work - I had to study source code and access some private data structures to do that. It would have been better if provision manager will offer an API that would make such integration easier.
Another big problem is Android library in com.espressif.provisioning. It is written in a way to make extension impossible - all data members and most of constructors are private, which prevents subclassing. I had to use reflection to customize its behaviour, the result works, but extremely ugly. Again, that library should be designed to be extensible.
If I knew how inflexible and clunky provision manager is, I should have implemented my own provisioning protocol - it would have taken no more than 3 days - I may still do that.
I would argue that in the current form provision manager is no more than a demo and is totally useless for real world device because if a company pays the price of enabling BLE in a device, then it would make no sense to use BLE only for such infrequent operation as WiFi provisioning. Company always wants to add some other permanent BLE functionality and the current black box provision manager cannot be integrated well with any other BLE code.

[bbinet]

Hey @jhnlmn, the work you did to integrate the provision manager and a permanent BLE peripheral sounds very interesting and useful.
Would you mind sharing your implementation?

[deviousprophet]

I think the "continuous (always on) BLE provisionning" feature is similar to BLUFI
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/blufi.html

[karunt]

Completely agree - wifi provisioning example with its provisioning manager and protocomm_nimble is completely useless from a real world perspective. And the lack of support from ESP to help implement a solution for continues provisioning is almost non-existent. Anyhow, the way I've achieved this continuous provision is as follows:

1. Execute ESP_ERROR_CHECK(wifi_prov_mgr_disable_auto_stop(0)) before ESP_ERROR_CHECK(wifi_prov_mgr_start_provisioning(security, pop, service_name, service_key)) in app_main.c (from the wifi provisioning example)
2. In custom_prov_data_handler, if inbuf (what the client side app sends over to the ESP32) is equal to a certain string (for example, "restart") , then re-execute ESP_ERROR_CHECK(wifi_prov_mgr_start_provisioning(security, pop, service_name, service_key)). This causes ESP32 to force restart and then you can re-provision the chip. Of course, you have to make sure that upon restarting, NVS flash must be erased, or at least the wifi credentials in NVS flash should be replaced with empty values. While I don't like to force restart the chip in order to re-provision the wifi credentials, this is the only way I've been able to re-provision the chip because I'm unable to access prov_ctx->prov_state (wifi provisioning state in manager.c) and it's the status of prov_state which causes the chip to reboot upon calling wifi_prov_mgr_start_provisioning. If anybody else has a more elegant solution, please share. I'm in desperate need of something more savvy than a force reboot.