Device Initiated Protocomm Messages?

[p-rimes]

Protocomm is awesome!

I wonder if it is possible to have the device begin a message transmission to the smartphone? For example, say a GPIO input was pressed, to send a message to the phone (ideally, encrypted with the same session).

[ESP_Anurag]

Thanks for showing interest!

Presently protocomm provides out of the box support for transport over BLE and HTTP Server/SoftAP, though each of these implementations assume simple server-client type scenario with the device(ESP32) hosting the server. Since your requirement is that of a mixed approach where the device can also send out requests, these are the various alternatives that I can think of:

• In case of SoftAP use esp_http_client for sending requests to a server running on the user side. Register an endpoint which will generate some message (eg. new state of the GPIO). Now when the trigger event occurs (eg. when GPIO input changes state) call protocomm_req_handle() with the correct endpoint name and session ID. This will generate the encrypted message in an output buffer which can be sent as body of an HTTP request using esp_http_client
• In case of BLE use notification (though that support is not yet present in protocomm_ble)
• Use a workaround, in which the client keeps polling the device on some endpoint about the GPIO state. Though that is slow and inefficient

[p-rimes]

Thanks for your advice ESP_Anurag! I really like the protocomm design and working with that portion of the codebase.

For my case, I was thinking about BLE transport and re-using the established session encryption. But I think that your suggestion of just calling `protocomm_req_handle` directly to generate an encrypted payload should work for BLE as well.

For the BLE notification case, it should be a matter of adding a new endpoint (characteristic) and just doing the subscription/notification with payloads from calling `protocomm_req_handle`?

[ESP_Anurag]

For the BLE notification case, it should be a matter of adding a new endpoint (characteristic) and just doing the subscription/notification with payloads from calling `protocomm_req_handle`?

For this to work the notify bit will have to be enabled for the characteristic corresponding to your endpoint, that means changing the source code for protocomm_ble which currently enables only read and write properties of all characteristics.

The second hurdle is to access the GATT interface handle, internal to protocomm_ble, from inside the endpoint handler. Without this it's not possible to send the notification as the corresponding API esp_ble_gatts_send_indicate() requires the handle.