Come inviare la notifica Bluetooth GATT a basso consumo con Bluez?

Question

Sto estendendo plugin/gatt_example.c nei sorgenti Bluez per provare la funzione di notifica BLE senza successo. Sto usando il servizio batteria di esempio incluso nella fonte Bluez. Ha 1 caratteristica con proprietà READ e NOTIFY. Aggiungo il metodo dbus per chiamare attrib_db_update() per aggiornare il valore caratteristico al di fuori del demone bluetooth.

Ora, posso connettere quale client (Nexus4 con Android 4.3 e iPhone (app gratuite LightBlue)) e avviare la notifica (impostazione descrittore CCC notifica flag). (nota: il char del descrittore ccc ha un'autorizzazione di autenticazione predefinita, quindi da iPhone che modifica CCC (avvia notifica) farà bluez per restituire l'errore: non autorizzare il permesso. Poiché ho intenzione di gestire l'autorizzazione in un secondo momento, cambio temporaneamente l'autorizzazione predefinita a none e iPhone è in grado di impostare i flag di notifica CCC).

Il problema è che anche il client (sia Android che iOS) ha avviato la notifica, la chiamata a attrib_db_update() non sta facendo bluez per inviare alcuna notifica al client (monitor con hcidump, nessun pacchetto inviato al client).

Domanda: Accanto a attrib_db_update() è necessario eseguire un passaggio per rendere Bluez l'invio di notifica al client? Apprezzo qualsiasi link alla fonte di esempio. PS. Io uso bluez come periferica + configurazione del server gatt (proprio come il servizio di batteria in plugin/gatt_example.c) non viceversa.

Grazie.

Aggiornamento

=== (non so come commentare la formattazione lavoro ... quindi aggiungo aggiornamento qui.)
Chi profilo del campione/avviso:
Sì ho già controllare sul profilo/allerta preventiva facendo la domanda . Un altro problema è che non ho potuto eseguire quei campioni (che una ragione per cui pongo la domanda in primo luogo).
profilo/alert/server.c: attio_connected_cb() è una funzione di callback, registrata da filter_devices_notify() in server.c. Usa btd_device_add_attio_callback() (da src/device.c). Controllando ulteriormente src/device.c, sembra che controlli device-> attrib, se esiste per exec (inserire prima la coda quindi eseguire callback) il callback o semplicemente inserire in coda fino al dispositivo connesso ?.
Il debugging, sembra dispositivo-> attrib è vuoto anche se ho già collegato il dispositivo.

Per chi fosse interessato a correre/debug campione profilo di avviso (Dal momento che non c'è doc :().
commento la seguente if (intorno alla linea 564), noi non interessa coloro controllo ...

 

    /* 
     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: ex bluetoothd -n -d -p avviso
Collegare il dispositivo fino a quando startNotify

avviso Registrazione da altre console:.

 

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

Crea un nuovo avviso:

 

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

ho avuto registro del seguente 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: l'aggiunta di un po 'di output di debug in device.c. Sembra che device-> attrib sia vuoto.E il collegamento automatico (perché gatt server/periferica deve connettersi al centrale?) Non è riuscito per ragioni sconosciute.

Answer 1

Modifica: sono riuscito a eseguire l'esempio di avviso utilizzando lo script python test-alert nel codice.

Ho contattato direttamente lo sviluppatore e ho chiesto. Si è scoperto che c'era un bug durante l'esecuzione di bluez come periferica, quindi ha creato diverse patch sulla mailing list.

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

Dopo l'applicazione della patch, eseguire il server e provare a utilizzare test-allarme:

1. Collegare e scrivere al manico ccc giusto per notifica sul lato client
2. Sul lato server, eseguire test-alert come (-w è mantenere l'avviso di test persistente, -r per la registrazione di e-mail, -u per e-mail non lette, 30 è il numero di e-mail non letti):

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