Closed h2zero closed 1 month ago
That definitely helped some (battery level now updates appropriately in my example) but the HID is still non functional - I think it may have to do with the change to auth you added in this pr? or maybe something else is still messed up somewhere
The logic for the auth code hasn't changed, just cleaned up.
should I expect to see logs of the form adding disc UUID: 0xYYYY, handle: 0x0000
, such as:
[Hid Service Example/I][0.300]: Starting
[BleGattServer/I][0.301]: Initializing GATT server with device name: 'ESP++ HID'
I (318) BLE_INIT: BT controller compile version [c66a703]
I (319) BLE_INIT: Bluetooth MAC: f4:12:fa:5a:85:92
I (321) phy_init: phy_version 680,a6008b2,Jun 4 2024,16:41:10
[BleGattServer/I][0.373]: Creating server
[BleGattServer/I][0.374]: Creating device info service
[BleGattServer/I][0.375]: Creating battery service
[Hid Service Example/I][0.376]: Report Descriptor:
[Hid Service Example/I][0.377]: Size: 170
[Hid Service Example/I][0.378]: Data: [0x5, 0x1, 0x9, 0x5, 0xa1, 0x1, 0x85, 0x1, 0x9, 0x1, 0xa1, 0x0, 0x9, 0x30, 0x9, 0x31, 0x15, 0x0, 0x27, 0xfe, 0xff, 0x0, 0x0, 0x75, 0x10, 0x95, 0x2, 0x81, 0x2, 0xc0, 0x9, 0x1, 0xa1, 0x0, 0x9, 0x32, 0x9, 0x35, 0x15, 0x0, 0x27, 0xfe, 0xff, 0x0, 0x0, 0x75, 0x10, 0x95, 0x2, 0x81, 0x2, 0xc0, 0x5, 0x2, 0x9, 0xc5, 0x15, 0x0, 0x26, 0xff, 0x3, 0x95, 0x1, 0x75, 0xa, 0x81, 0x2, 0x95, 0x1, 0x75, 0x6, 0x81, 0x1, 0x5, 0x2, 0x9, 0xc4, 0x15, 0x0, 0x26, 0xff, 0x3, 0x95, 0x1, 0x75, 0xa, 0x81, 0x2, 0x95, 0x1, 0x75, 0x6, 0x81, 0x1, 0x5, 0x1, 0x9, 0x39, 0x15, 0x1, 0x25, 0x8, 0x35, 0x0, 0x46, 0x3b, 0x1, 0x65, 0x14, 0x55, 0x0, 0x75, 0x4, 0x95, 0x1, 0x81, 0x42, 0x95, 0x1, 0x75, 0x4, 0x81, 0x1, 0x5, 0x9, 0x19, 0x1, 0x29, 0xf, 0x15, 0x0, 0x25, 0x1, 0x75, 0x1, 0x95, 0xf, 0x81, 0x2, 0x95, 0x1, 0x75, 0x1, 0x81, 0x1, 0x85, 0x2, 0x5, 0x8, 0x19, 0x61, 0x29, 0x64, 0x15, 0x0, 0x25, 0x1, 0x75, 0x1, 0x95, 0x4, 0x91, 0x2, 0x95, 0x1, 0x75, 0x4, 0x91, 0x1, 0xc0]
adding disc UUID: 0x2908, handle: 0x0000
adding disc UUID: 0x2908, handle: 0x0000
adding disc UUID: 0x2904, handle: 0x0000
[BleGattServer/I][0.383]: Setting legacy advertising data
[BleGattServer/I][0.385]: Starting legacy advertising for 0 ms
[Hid Service Example/I][4.405]: Device connected
[Hid Service Example/I][5.387]: Connected devices: 1
[Hid Service Example/I][5.733]: Names: ["Pixel 6"]
[BleGattServer/I][5.735]: RSSI for connected device 62:df:3b:41:be:6f: -62
[Hid Service Example/I][5.736]: RSSIs: [-62]
[Hid Service Example/I][6.645]: Device authenticated
[Hid Service Example/I][21.573]: Device disconnected: REMOTE_USER_TERMINATED
emphasis being that the handle for the descriptor is 0x0000.
Hmm, looks like some debugging got left behind. That message can be ignored, i'll clean it up after.
As for the onConfirmPIN issue, it's working fine on my end, check your function signature:
void onConfirmPIN(NimBLEConnInfo& connInfo, uint32_t pass_key) override {
printf("The passkey YES/NO number: %" PRIu32 "\n", pass_key);
/** Inject false if passkeys don't match. */
NimBLEDevice::injectConfirmPIN(connInfo, true);
};
Oh there's no issue pairing (this is just the HID example, not the GFPS code) - I'm pairing properly and the device stays connected just fine. I'm just seeing that the HID service is not able to be read properly (likely since it's the service that supports encryption, and this device is paired).
Confirmed, GFPS pairing (which doesn't require encryption) works fine, but HID still fails (the test I have for that has both GFPS and HID).
Edit:
The HID input report is configured with the properties READ | NOTIFY | READ_ENC
, which I believe is the part causing the failure. I'll test the example by commenting out the READ_ENC
and see if that fixes it.
Edit 2: As expected, Android and iOS don't like that.
I'm not able to repro this behavior, can you make a minimal example for me to debug this?
For now I will merge this, please open an issue to track the HID problem.
Sure I'll try to make a basic example. In the meantime, if you're able and willing to run the espp hid_service example that shows the behavior
@h2zero I've created a (relatively) simple example which exhibits the error using just NimBLE classes for BLE. The error is related to the broken support for NimBLEAttValue::setValue(std::vector<uint8_t>)
.
https://github.com/h2zero/esp-nimble-cpp/issues/200
Edit: example can be found here: https://github.com/finger563/nimble-cpp-hid-issue-example/blob/main/main/main.cpp#L91
The connection handle was not initialized correctly when recording the subscribe status causing the call to send notification/indications to fail with BLE_HS_ENOTCONN.
@finger563 please test, works for me.