NimBLE-Arduino: `NimBLEClient::getService(ServiceUUID)` does not succeed with 16-bit ServiceUUID
The BLE-HID device I’m using in my test appears to own 0x1812 when I view the ServiceUUID list after doing getSerices(true).
However, if I do not do getServices(true) first and do getService(NimBLEUUID((uint16_t)0x1812) it fails.
Successful Code:
NimBLEUUID uuid_service((uint16_t)0x1812);
pClient->getServices(true);
auto pService = pClient->getService(uuid_service);
Failing code:
NimBLEUUID uuid_service((uint16_t)0x1812);
// pClient->getServices(true);
auto pService = pClient->getService(uuid_service); // nullptr is returned
The ServiceUUID on this device I needed was appearing as 00001812-0000-1000-8000-00805f9b34fb instead of 0x1812 in previous BLE libraries. However, specifying 0001812-0000-1000-8000-00805f9b34fb still fails.
Failing code, too:
NimBLEUUID uuid_service("0001812-0000-1000-8000-00805f9b34fb");
// pClient->getServices(true);
auto pService = pClient->getService(uuid_service); // nullptr is returned
pClient->getServices(true);
pService = pClient->getService(uuid_service); // nullptr is returned, too
What do you think ?
If it’s a problem on the ble_gattc_disc_svc_by_uuid() side, solving it can be tricky…
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 68 (39 by maintainers)
Waaaay better than BLEClient at fast responses to disconnects and able to reconnect consistantly (so far) and without lockups. I’m pushing the color switching at 100ms but it can definately go faster, just cleaning up the code bloat first 😃 (This is without the FreeRTOS.cpp mod people do for the timeout lockup on BLEClient (which doesn’t effectively work after several disconnects!)).
https://www.youtube.com/watch?v=p4Ms35I--jI&feature=youtu.be
Also to fix the array warnings, I just casted:
XBT_characteristic[controller]->writeValue((const uint8_t*)XBT_colors[controller], sizeof(XBT_colors[controller]));The array is global, 20 bytes, and I use CANbus later on to control the colors in the array. Also when the ESP restarts it checks for a XBT power cycle, if it’s already set with colors, the ESP dumps the array locally and writes it back with 1 byte configured to 0, to prevent color change while writing back. Writing back at least once prevents a ~20 second kick from the XBT, and will remain connected until a disconnection occurs. If it sees the unit was repowered, it just turns off all the light ports on it until a color is set. This prevents the power on default white output to turn off if it is repowered and not being written to. So color retention is built in without ESP32 reboots messing with em 😃
EDIT: constant delayless loop writeValue changing colors seems working fine so far as well
I was the first person to publish this issue.
When
pClient-> getServices (true);was not called in advance, finally,ble_gattc_disc_svc_uuid_txis called. https://github.com/h2zero/NimBLE-Arduino/blob/5cb454bfce3bf753e26d00817b7bf66cc0de447a/src/nimble/host/src/ble_gattc.c#L1609-L1613Here, since it is limited to
BLE_ATT_UUID_PRIMARY_SERVICE, I guessed thatBLE_ATT_UUID_SECONDARY_SERVICEmight have been omitted from the search target, and I thought that this was unavoidable behavior, but I gave up, but my guess.Is it a difference?
Looks like the 128 bit one went in!
0000ffd0-0000-1000-8000-00805f9b34fbnow it’s asking for the char… So i guess 16bit is broken
characteristic i used (changed ffd0 to ffd1):
0000ffd1-0000-1000-8000-00805f9b34fbSeems to connect fine now, so far, didnt test the writes yet 😛
I am guessing the 16bit doesn’t work because it’s not matching on the report list, I do know they might have conversions to go to and from 128 to 16, but maybe you should accept a 16bit based on the first 16bits of the first block and use that as a quick match
example, 0xFFD0 would match to the 4th service’s first block, and the 4th service pointer would be returned to the caller on exit it wouldn’t require code bloat and conversions, but probably a 1-3 line of code matchup process in getService()