So senden Sie Bluetooth Low Energy GATT Benachrichtigung mit Bluez?

Question

Ich erweitere Plugin/gatt_example.c in Bluez-Quellen, um die BLE-Benachrichtigungsfunktion ohne Erfolg zu versuchen. Ich verwende den mitgelieferten Batterieservice in der Bluez-Quelle. Es hat 1 Merkmal mit READ und NOTIFY Eigenschaften. Ich füge dbus-Methode hinzu, um attrib_db_update() aufzurufen, um den Merkmalswert von außerhalb des Bluetooth-Dämons zu aktualisieren.

Jetzt kann ich den Client verbinden (Nexus4 mit Android 4.3 und iPhone (LightBlue kostenlose Anwendungen)) und starten Sie die Benachrichtigung (Einstellung deskriptor CCC Benachrichtigung Flags). (Anmerkung: ccc Deskriptor char hat die Erlaubnis Standard Auth, so von iPhone modifizieren CCC (Start benachrichtigen) wird bluez machen Fehler zurück. Nicht Erlaubnis autorisieren Da ich plane, später mit Genehmigung umgehen, ich vorübergehend die Standardberechtigungsänderung zu keiner, und iPhone ist in der Lage, CCC-Benachrichtigungsflag zu setzen).

Das Problem ist, sogar der Client (sowohl Android oder iOS) hat zu benachrichtigen, Aufruf von attrib_db_update() macht Bluez keine Benachrichtigung an den Client senden (Monitor mit hcidump, kein Paket an den Client senden).

Frage: Gibt es einen Schritt neben attrib_db_update erforderlich() bluez Senden einer Benachrichtigung an den Client zu machen? Ich schätze jeden Link zur Beispielquelle. PS. Ich benutze Bluez als Peripherie + Gatt-Server-Konfiguration (genauso wie Batterie-Service in plugin/gatt_example.c) nicht umgekehrt.

Danke.

=== Update (ich weiß nicht, wie Kommentar Arbeit Formatierung ... so füge ich Update hier.)
über Profil/alert Beispiel:
Ja ich überprüfe, bereits im Profil/alert vor der Frage stellen . Ein weiteres Problem ist, dass ich diese Probe nicht ausführen konnte (Der eine Grund, warum ich die Frage an erster Stelle stelle).
Profil/alert/server.c: attio_connected_cb() ist eine Callback-Funktion, durch filter_devices_notify registriert() in server.c. Es verwendet btd_device_add_attio_callback() (aus src/device.c). Weitere Überprüfung von src/device.c, es sieht so aus, dass es überprüfen Gerät-> attrib, wenn es exec existiert (Einfügen in die Warteschlange zuerst dann Exec Callback) den Rückruf oder einfach in die Warteschlange einfügen, bis das Gerät verbunden?.
Debuggen, es sieht aus wie Gerät-> Attrib ist leer, auch wenn ich das Gerät bereits angeschlossen.

Für Interessenten laufen/Debug-Alert-Profil Probe (Da kein doc es :().
Kommentieren Sie die folgende if (um die Linie 564), wir in diesem Check nicht interessiert tun ...

 

    /* 
     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 Alarm
Ihr Gerät bis startNotify Schließen

Register Alarm aus anderen Konsole.

 

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

Erstellen neuer Alarm:

 

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

ich die folgende bluetoothd Logbuch bekam:

 

    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: Hinzufügen einiger Debug-Ausgabe in device.c. Es scheint, dass Gerät-> Attrib ist leer.Und autoconnect (warum gatt server/periphery muss sich mit central verbinden?) Ist aus unbekannten Gründen fehlgeschlagen.

Answer 1

Bearbeiten: Ich habe erfolgreich ausgeführt, Beispiel mit dem Test-Alert-Python-Skript im Code ausführen.

Ich kontaktierte den Entwickler direkt und fragte. Es stellte sich heraus, dass es einen Fehler gab, wenn Bluez als Peripheriegerät ausgeführt wurde, also erstellte er mehrere Patches auf der Mailing-Liste.

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

Nach Patch anwenden, um den Server ausführen und versuchen, mit Hilfe von Test-Alarm: nach rechts ccc Griff für die Benachrichtigung auf Client-Seite

Auf Server-Seite

1. Connect und schreiben, test-alert ausführen wie (-w soll die Test-Warnung persistent halten, -r für die Registrierung der E-Mail-Warnung, -u für die ungelesene E-Mail, 30 ist die Anzahl der ungelesenen E-Mails):

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