labapart / gattlib

Library to access GATT information from BLE (Bluetooth Low Energy) devices
http://labapart.com/
436 stars 157 forks source link

Notifications are not received #192

Open cnhyades opened 3 years ago

cnhyades commented 3 years ago

Hi,

Thanks for creating very useful library. So far everything is good except that I'm not able to receive notifications from our device.

  1. The function gattlib_notification_start() doesn't return any error, but no notifications are received.
  2. But the function gattlib_write_char_by_handle() return an error GATTLIB_NOT_FOUND(-2).

I'm not sure whether your library reading the client configuration descriptor correctly or not. However our device works well with Android, iOS, ESP32 etc.

glhrmfrts commented 3 years ago

I've had similar issues using the DBUS API as the backend, I've had to switch to the BlueZ backend in order to be able to receive notifications, which one are you using?

cnhyades commented 3 years ago

Hi, it was using DBUS API by default. Now I changed to Bluez, looks like enable notification succeeded with writting by handle. However I get some other weird issue with Write Request. If I switch back to DBUS works! so very strange thing.

glhrmfrts commented 3 years ago

Let me guess, using BlueZ some of your write requests freeze and never return?

If that's the case, I'm still stuck in this very problem as well.

cnhyades commented 3 years ago

I see write operation is successful, status is zero inside gattlib_write_result_cb inside gattlib_read_write.c. Unfortunately I don't have logs from the peer device. However I did verify the write operation using gatttool, no issues there.

firehills commented 3 years ago

Same here, building on the nordic_uart example, I setup the notification (Note the example itself of a bit out of date)

gattlib_register_notification(m_connection, notification_cb, NULL);
ret = gattlib_notification_start(m_connection, &nus_characteristic_rx_uuid);

and ntf is never called from gattlib.

However Its being received at BlueZ level, My BLE device sends a character every second, and looking directly at the DBUS messages with dbus-monitor I see its being received OK

pi@raspberrypi:~ $ sudo dbus-monitor --system
signal time=1606922308.338984 sender=org.freedesktop.DBus -> destination=:1.53 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.53"
signal time=1606922308.339108 sender=org.freedesktop.DBus -> destination=:1.53 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.53"
signal time=1606922308.809978 sender=:1.13 -> destination=(null destination) serial=2066 path=/org/bluez/hci0/dev_F8_BB_45_65_69_05/service000e/char0011; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.GattCharacteristic1"
   array [
      dict entry(
         string "Value"
         variant             array of bytes [
               51 0a 00
            ]
      )
   ]
   array [
   ]
signal time=1606922309.784356 sender=:1.13 -> destination=(null destination) serial=2067 path=/org/bluez/hci0/dev_F8_BB_45_65_69_05/service000e/char0011; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.GattCharacteristic1"
   array [
      dict entry(
         string "Value"
         variant             array of bytes [
               52 0a 00
            ]
      )
   ]
   array [
   ]
^C
pi@raspberrypi:~ $

This on a RPI4, BlueZ 5.50, Gattlib @ head

Cheprod commented 3 years ago

Hi,

Did you find a solution or a workaround ?

I'm fighting to activate notification on Nordic UART service but without success.

DBus monitor traces look good :

signal time=1609879646.758084 sender=:1.143 -> destination=(null destination) serial=16065 path=/org/bluez/hci0/dev_EC_9A_78_32_DC_09/service000b/char000e; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged string "org.bluez.GattCharacteristic1" array [ dict entry( string "Value" variant array of bytes [ 01 ] ) ] array [ ] method return time=1609879646.758324 sender=:1.143 -> destination=:1.329 serial=16066 reply_serial=4888 array of bytes [ 01 ]

Don't really understand what happens...

Same platform and version as firehills.


Edit :

Playing with GDB seems to indicate some error with DBus : image

Don't really know how it impacts the library because the notification on the device is activated.

However, I'm sure that the callback on_handle_characteristic_property_change is never called.

glhrmfrts commented 3 years ago

Hey, I still don't understand what's going on with the DBus API, I suggest you disable DBus and use BlueZ directly, at least you'll be able to receive the notifications.

gattlib seems to force DBus in a certain BlueZ version, here's what I did to disable it for all BlueZ versions: https://github.com/glhrmfrts/gattlib/commit/ddbf8f8a880844e2931cd87a54eb98b21c0f909c

Cheprod commented 3 years ago

Hi @glhrmfrts

Thanks a lot! You save my day! The notification callback works perfectly now without DBus.

If someone have an explanation why the connection with DBus doesn't work ;)

pierrep commented 3 years ago

I've had exactly the same experience. Couldn't get notifications to work with DBus. Disabled Dbus via the CMakefile, and all works well, except now in neither version can I send data to the device correctly (works with Gattool though)

keentux commented 2 years ago

Hi,

I am facing some problems with the notification despite the fixes that have been made.

I use the CISS-BOSH sensor and I try to recover data on an embedded card with only one core. And, Legacy support has some difficulty working on a card that does not have at least 2 cores. So I have planned to use the dBus support.

Nevertheless, the sensor seems to not understand properly the notification command. After some investigations here what I have found:

In Legacy support, we use a write command with an opcode 0x12 and a Value=0x0001. In dBus support, we use the same command but with a Value=0x0003

I think the problem come from this difference in Value. Someone know how to change this with dBus support ?