Как отправить уведомление Bluetooth с низким энергопотреблением GATT с Bluez?

Question

Я расширяю плагин/gatt_example.c в источниках Bluez, чтобы попробовать функцию уведомления BLE без успеха. Я использую прилагаемый образец Battery Service в источнике Bluez. Он имеет 1 с характеристиками READ и NOTIFY. Я добавляю метод dbus, чтобы вызвать функцию attrib_db_update(), чтобы обновить значение признака за пределами демона bluetooth.

Теперь я могу подключить к этому клиенту (Nexus4 с Android 4.3 и iPhone (бесплатные приложения LightBlue)) и начать уведомление (дескриптор установки CCC уведомляет флаги). (примечание: char cc descriptor имеет разрешение по умолчанию для разрешения, поэтому от iPhone, модифицирующего CCC (начало уведомления), будет выведено bluez, чтобы вернуть ошибку: не разрешать разрешение. Поскольку позже я планирую разрешить авторизацию, я временно изменяю разрешение по умолчанию никому, и iPhone может устанавливать флаги уведомлений CCC).

Проблема заключается даже в том, что клиент (как Android, так и iOS) начал уведомлять, вызывающий атрибут attrib_db_update() не делает bluez для отправки любого уведомления клиенту (монитор с hcidump, без отправки пакета клиенту).

Вопрос: Есть ли какой-либо шаг, который требуется для атрибута attrib_db_update(), чтобы заставить bluez отправлять уведомление клиенту? Я ценю любую ссылку на образец источника. PS. Я использую bluez как конфигурацию периферийного + gatt-сервера (так же, как и обслуживание батареи в plugin/gatt_example.c), а не наоборот.

Спасибо.

=== Update (я не знаю, как комментировать форматирование работы ... так что я добавить обновления здесь.)
О профиле/оповещении образца:
Да я уже проверить профиль/оповещение перед задать вопрос , Другая проблема заключается в том, что я не мог запустить этот образец (это одна из причин, по которой я задаю вопрос в первую очередь).
profile/alert/server.c: attio_connected_cb() - это функция обратного вызова, зарегистрированная filter_devices_notify() в server.c. Он использует btd_device_add_attio_callback() (из src/device.c). Дополнительная проверка src/device.c, похоже, что он проверяет device-> атрибут, если он существует для exec (сначала вставить в очередь, затем обратный вызов exec), callback или просто вставить в очередь, пока устройство не подключится ?.
Отладка, он выглядит как device-> attrib пуст, даже если я уже подключил устройство.

Для тех, кто заинтересован, чтобы запустить/отладку образец оповещения профиля (Поскольку нет дока :().
Закомментируйте следующее, если (около линии 564), мы не заинтересованы в этом чеке ...

 

    /* 
     if (!g_str_equal(alert->srv, sender)) { 
      DBG("Sender %s is not registered in category %s", sender, 
            category); 
      return btd_error_invalid_args(msg); 
     } 
    */ 

Run bluetoothd: бывший bluetoothd -n -d -p предупреждения
не Подключите устройство до startNotify

Регистрация предупреждение из другой консоли:.

 

    dbus-send --system --dest=org.bluez --type=method_call "/org/bluez" "org.bluez.Alert1.RegisterAlert" string:"simple" objpath:"/org/bluez/AlertAgent1" 

Создать новое предупреждение:

 

    dbus-send --system --dest=org.bluez --type=method_call "/org/bluez" "org.bluez.Alert1.NewAlert" string:"simple" uint16:"1" string:"test" 

Я получил журнал на следующий bluetoothd в:

 

    bluetoothd[1928]: src/attrib-server.c:attrib_db_update() handle=0x001c 
    bluetoothd[1928]: src/attrib-server.c:attrib_db_update() handle=0x0021 
    bluetoothd[1928]: profiles/alert/server.c:register_alert() RegisterAlert("simple", "/org/bluez/AlertAgent1") 
    bluetoothd[1928]: src/attrib-server.c:attrib_db_update() handle=0x001e 
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() 0x1b6e718 registered ATT connection callback 
    bluetoothd[1928]: src/device.c:device_set_auto_connect() 10:68:3F:E1:4E:F2 auto connect: 1 
    bluetoothd[1928]: src/adapter.c:adapter_connect_list_add() /org/bluez/hci0/dev_10_68_3F_E1_4E_F2 added to BlueZ 5.14's connect_list 
    bluetoothd[1928]: src/adapter.c:trigger_passive_scanning() 
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() device->attrib = false 
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() cfunc = true 
    bluetoothd[1928]: src/device.c:btd_device_add_attio_callback() no idle 
    bluetoothd[1928]: profiles/alert/server.c:new_alert() NewAlert("simple", 1, "simple") 
    bluetoothd[1928]: src/adapter.c:passive_scanning_complete() status 0x03 
    bluetoothd[1928]: Wrong size of start scanning return parameters 

Memo: добавление некоторого вывода отладки в device.c. Похоже, что device-> attrib пуст.И autoconnect (почему сервер gatt/периферийное устройство должен подключиться к центральному?) Не удалось по неизвестной причине.

Answer 1

Редактировать: У меня есть успешное выполнение примера проверки с использованием скрипта python test-alert в коде.

Я связался с разработчиком напрямую и спросил. Оказалось, что при запуске bluez была ошибка, так как он создал несколько патчей в списке рассылки.

http://marc.info/?l=linux-bluetooth&m=139092431515560&w=2

После применения патча запустить сервер и попробуйте использовать тест-предупреждение:

1. Connect и писать правую КТС ручки для уведомления на стороне клиента
2. На стороне сервера, (-w - поддерживать постоянное тестовое оповещение, -r для регистрации оповещения по электронной почте, -u для непрочитанного сообщения, 30 - количество непрочитанных сообщений электронной почты):

   test-alert -w -r email -u email 30