Proposal for GATT Client Dbus API.

Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

Hi,

This post contains a proposal for the DBUS GATT API(Gatt CLIENT) that enhances the existing GATT
functionality provided by DBUS APIs interface. Which include Methods,Signals and Properties. 
Could you please provide your comments and feedback for the same? Or we need more APIs to cover all GATT Client functionality?

. RegisterCharacteristicsWatcher can be used to monitor specific Characteristic change. 
. PropertyChanged Signal for the SetProperty().
. ServiceChanged and CharacteristicChanged Signal for Service or Characteristic changes on the server. 
. New Properties for Permissions and remaining Characteristic Descriptors. 

PFA the updated document "new-attribute-api.txt".

Proposed New API:

Device Characteristic hierarchy
===============================
Service                 org.bluez
Interface             org.bluez.Characteristic
Object path        [prefix]/{hci0}/{device0}/{service0}/{characteristic0,...}

Methods:
      			RegisterCharacteristicsWatcher(object agent)
                                    Register a watcher to monitor characteristic changes.
                                    A watcher will be registered for the specific characteristic and will
                                    notify about any changed characteristics.
Signals:
                        PropertyChanged(string name, variant value)
                                    This signal indicates a changed value of the given
                                    property.

                        ServiceChanged (dict values)
                                    This signal indicates service added on server.

                        CharacteristicChanged (dict values)
                                    This signal indicates characteristic added on server.

Properties:
                        uint8 Property [readonly]
                                    The characteristic property, format defined by GATT spec. 

                        uint16 Configuration [readonly]
                                    Optional field containing the configuration value on the server.

                        uint16 Extended [readonly]
                                    The characteristic descriptor describing
                                    the additional Characteristic Properties. 

                        uint16 Aggregate [readonly]
                                    Optional Characteristic descriptor which defines the 
					      format of an aggregated Characteristic Value.

                        uint16 Custom [readonly]
						Optional Characteristic descriptor which defines profile defined descriptor UUID's.


Thanks,
Vijay


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

[-- Attachment #2: new-attribute-api.txt --]
[-- Type: text/plain, Size: 6122 bytes --]

BlueZ D-Bus Attribute API description
*************************************

Copyright (C) 2004-2010  Marcel Holtmann <marcel@holtmann.org>

Service details
---------------

One service object path for every remote SDP record or service in the
attribute database. One service object path for every local SDP record
or service from attribute database.

Local services are children of the adapter object path. Remote services
are children of the remote device object path. This doesn't solve the
problem where local attributes can have different instances based on
the remote device.

In general the idea is to also represent SDP records as services so that
new style application can just use the service interfaces to retrieve the
needed information. That way the usage of SDP and GATT would be mostly
fully transparent and a differentiation becomes unimportant in the future.

A service consists of some generic service information and a set of
characteristics. All characteristic are presented as object path as well.


Local Service hierarchy
=======================

Service		org.bluez
Interface	org.bluez.Service
		org.bluez.Characteristic
Object path	[prefix]/{hci0}/{service0, service1, ...}

Methods

Properties


Device Service hierarchy
========================

Service		org.bluez
Interface	org.bluez.Characteristic
Object path	[prefix]/{hci0}/{device0}/{service0, service1, ...}
		[prefix]/{hci0}/{device1}/{service0, service1, ...}

Methods 	dict GetProperties()

			Returns all properties for the interface. See the
			Properties section for the available properties.

		array{object} DiscoverCharacteristics()

			Discover all characteristics that belongs in this service.
			When it returns all the characteristics paths will be
			already registered. It will return the characteristics paths
			as soon as they are discovered. After that it will try to
			read all values.

		RegisterCharacteristicsWatcher(object agent)

			Register a watcher to monitor characteristic changes.
			A watcher will be registered for this service and will
			notify about any changed characteristics in the service.
			This also notifies about any included characteristics.

		UnregisterCharacteristicsWatcher(object agent)

			Unregister a watcher.

Properties	string Name (mandatory) [readonly]

			General name of service

		string Description (optional) [readonly]

			Description of service

		string UUID (mandatory) [readonly]

			UUID of service. Service class value for SDP and GATT
			UUID for attribute based services.

		array{object} Characteristics [readonly]

			This list contains the characteristics owned by this
			specific service and other characteristics from service
			includes. That way no complicated service includes array
			is needed.


Device Characteristic hierarchy
===============================

Service		org.bluez
Interface	org.bluez.Characteristic
Object path	[prefix]/{hci0}/{device0}/{service0}/{characteristic0,...}
		[prefix]/{hci0}/{device0}/{service1}/{characteristic0,...}

Methods	dict GetProperties()

			Returns all properties for the characteristic. See the
			properties section for available properties.

		void SetProperty(string name, variant value)

			Changes the value of the specified property. Only
			read-write properties can be changed. On success
			this will emit a PropertyChanged signal.

    RegisterCharacteristicsWatcher(object agent)

			Register a watcher to monitor characteristic changes.
			A watcher will be registered for the characteristic and will
			notify about any changed characteristics.

			Possible Errors: org.bluez.Error.InvalidArguments

Signals		PropertyChanged(string name, variant value)
			This signal indicates a changed value of the given
			property.
			
			ServiceChanged (dict values)
			This signal indicates service added on server.

  		CharacteristicChanged (dict values)
			This signal indicates characteristic added on server.


Properties 	string UUID [readonly]
			UUID128 of this characteristic.

		string Name [readonly]
			Optional field containing a friendly name for the
			Characteristic UUID.

		uint8 Property [readonly]
			The characteristic property, format defined by GATT spec. 

		uint16 Configuration [readonly]
			Optional field containing the configuration value on the server.

		uint16 Extended [readonly]
			The characteristic descriptor describing
			the additional Characteristic Properties. 

		uint16 Aggregate [readonly]
			Optional Characteristic descriptor which defines the 
      			format of an aggregated Characteristic Value.
      			
    uint16 Custom [readonly]
			Optional Characteristic descriptor which defines profile defined descriptor UUID’s.
      
		string Description [readonly]
			Textual optional characteristic descriptor describing
			the Characteristic Value.

		struct Format [readonly]

			Optional Characteristic descriptor which defines the
			format of the Characteristic Value. For numeric
			values, the actual value can be value * 10^Exponent.
			NameSpace and Description are defined on the Assigned
			Number Specification.

			  uint8  | Format: format of the value
			  uint8  | Exponent: Field to determine how the value is
			         | further formatted.
			  uint16 | Unit: unit of the characteristic
			  uint8  | NameSpace: Name space of description.
			  uint16 | Description: Description of the characteristic defined
			         | in a high layer profile.

		array{byte} Value [readwrite]

			Raw value of the Characteristic Value attribute.

		string Representation (of the binary Value) [readonly]

			Friendly representation of the Characteristic Value
			based on the format attribute.


Characteristic Watcher hierarchy
===============================

Service		unique name
Interface	org.bluez.Watcher
Object path	freely definable

Methods		void ValueChanged(object characteristic, array{byte})

			New raw value of the Characteristic Value attribute.

Re: Proposal for GATT Client Dbus API.

[Claudio Takahasi]

SGkgVmlqYXksCgpPbiBUdWUsIE9jdCA0LCAyMDExIGF0IDEwOjU5IEFNLCBWaWpheWt1bWFyIERh
ZG1vZGUKPFZpamF5a3VtYXIuRGFkbW9kZUBjc3IuY29tPiB3cm90ZToKPiBIaSwKPgo+IFRoaXMg
cG9zdCBjb250YWlucyBhIHByb3Bvc2FsIGZvciB0aGUgREJVUyBHQVRUIEFQSShHYXR0IENMSUVO
VCkgdGhhdCBlbmhhbmNlcyB0aGUgZXhpc3RpbmcgR0FUVAo+IGZ1bmN0aW9uYWxpdHkgcHJvdmlk
ZWQgYnkgREJVUyBBUElzIGludGVyZmFjZS4gV2hpY2ggaW5jbHVkZSBNZXRob2RzLFNpZ25hbHMg
YW5kIFByb3BlcnRpZXMuCj4gQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIHlvdXIgY29tbWVudHMg
YW5kIGZlZWRiYWNrIGZvciB0aGUgc2FtZT8gT3Igd2UgbmVlZCBtb3JlIEFQSXMgdG8gY292ZXIg
YWxsIEdBVFQgQ2xpZW50IGZ1bmN0aW9uYWxpdHk/Cj4KPiAuIFJlZ2lzdGVyQ2hhcmFjdGVyaXN0
aWNzV2F0Y2hlciBjYW4gYmUgdXNlZCB0byBtb25pdG9yIHNwZWNpZmljIENoYXJhY3RlcmlzdGlj
IGNoYW5nZS4KPiAuIFByb3BlcnR5Q2hhbmdlZCBTaWduYWwgZm9yIHRoZSBTZXRQcm9wZXJ0eSgp
Lgo+IC4gU2VydmljZUNoYW5nZWQgYW5kIENoYXJhY3RlcmlzdGljQ2hhbmdlZCBTaWduYWwgZm9y
IFNlcnZpY2Ugb3IgQ2hhcmFjdGVyaXN0aWMgY2hhbmdlcyBvbiB0aGUgc2VydmVyLgo+IC4gTmV3
IFByb3BlcnRpZXMgZm9yIFBlcm1pc3Npb25zIGFuZCByZW1haW5pbmcgQ2hhcmFjdGVyaXN0aWMg
RGVzY3JpcHRvcnMuCj4KPiBQRkEgdGhlIHVwZGF0ZWQgZG9jdW1lbnQgIm5ldy1hdHRyaWJ1dGUt
YXBpLnR4dCIuCj4KPiBQcm9wb3NlZCBOZXcgQVBJOgo+Cj4gRGV2aWNlIENoYXJhY3RlcmlzdGlj
IGhpZXJhcmNoeQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPiBTZXJ2aWNlwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgb3JnLmJsdWV6Cj4gSW50ZXJmYWNlwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIG9yZy5ibHVlei5DaGFyYWN0ZXJpc3RpYwo+IE9iamVjdCBwYXRo
wqDCoMKgwqDCoMKgwqAgW3ByZWZpeF0ve2hjaTB9L3tkZXZpY2UwfS97c2VydmljZTB9L3tjaGFy
YWN0ZXJpc3RpYzAsLi4ufQo+Cj4gTWV0aG9kczoKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoFJlZ2lzdGVyQ2hhcmFjdGVyaXN0aWNzV2F0Y2hlcihvYmplY3QgYWdlbnQpCj4g
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBSZWdpc3RlciBhIHdhdGNoZXIgdG8gbW9uaXRvciBjaGFyYWN0ZXJpc3Rp
YyBjaGFuZ2VzLgo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQSB3YXRjaGVyIHdpbGwgYmUgcmVnaXN0ZXJlZCBm
b3IgdGhlIHNwZWNpZmljIGNoYXJhY3RlcmlzdGljIGFuZCB3aWxsCj4gwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBu
b3RpZnkgYWJvdXQgYW55IGNoYW5nZWQgY2hhcmFjdGVyaXN0aWNzLgoKSXMgaXQgcmVhbGx5IG5l
Y2Vzc2FyeT8gSSB0aG91Z2h0IHJlZ2lzdGVyaW5nIGEgd2F0Y2hlciBhdCBzZXJ2aWNlCiJsZXZl
bCIgd2FzIGVub3VnaC4KCj4gU2lnbmFsczoKPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgUHJvcGVydHlDaGFuZ2VkKHN0cmluZyBuYW1lLCB2YXJpYW50IHZh
bHVlKQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgVGhpcyBzaWduYWwgaW5kaWNhdGVzIGEgY2hhbmdlZCB2YWx1
ZSBvZiB0aGUgZ2l2ZW4KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHByb3BlcnR5Lgo+Cj4gwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBTZXJ2aWNlQ2hhbmdlZCAoZGljdCB2
YWx1ZXMpCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBUaGlzIHNpZ25hbCBpbmRpY2F0ZXMgc2VydmljZSBhZGRl
ZCBvbiBzZXJ2ZXIuCgpDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gdGhlIHJlbGF0aW9uIGJldHdl
ZW4gdGhpcyBwcm9wZXJ0eSBhbmQKU2VydmljZSBDaGFuZ2VkIGNoYXJhY3RlcmlzdGljKEdlbmVy
aWMgQXR0cmlidXRlIFByb2ZpbGUgU2VydmljZSk/CkluIG15IG9waW5pb24sIGl0IGlzIGEgc2Vy
dmljZSBwcm9wZXJ0eSBpbnN0ZWFkIG9mIGNoYXJhY3RlcmlzdGljIHByb3BlcnR5LgoKPgo+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQ2hhcmFjdGVyaXN0
aWNDaGFuZ2VkIChkaWN0IHZhbHVlcykKPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFRoaXMgc2lnbmFsIGluZGlj
YXRlcyBjaGFyYWN0ZXJpc3RpYyBhZGRlZCBvbiBzZXJ2ZXIuCj4KPiBQcm9wZXJ0aWVzOgo+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdWludDggUHJvcGVy
dHkgW3JlYWRvbmx5XQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVGhlIGNoYXJhY3RlcmlzdGljIHByb3BlcnR5
LCBmb3JtYXQgZGVmaW5lZCBieSBHQVRUIHNwZWMuCj4KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB1aW50MTYgQ29uZmlndXJhdGlvbiBbcmVhZG9ubHld
Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCBPcHRpb25hbCBmaWVsZCBjb250YWluaW5nIHRoZSBjb25maWd1cmF0
aW9uIHZhbHVlIG9uIHRoZSBzZXJ2ZXIuCgpSZWFkIG9ubHk/IENDQyBjYW4gYmUgd3JpdGVhYmxl
IHJpZ2h0PwoKQlIsCkNsYXVkaW8uCgo+Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgdWludDE2IEV4dGVuZGVkIFtyZWFkb25seV0KPiDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIFRoZSBjaGFyYWN0ZXJpc3RpYyBkZXNjcmlwdG9yIGRlc2NyaWJpbmcKPiDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHRoZSBhZGRpdGlvbmFsIENoYXJhY3RlcmlzdGljIFByb3BlcnRpZXMuCj4KPiDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB1aW50MTYgQWdncmVnYXRl
IFtyZWFkb25seV0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE9wdGlvbmFsIENoYXJhY3RlcmlzdGljIGRlc2Ny
aXB0b3Igd2hpY2ggZGVmaW5lcyB0aGUKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGZvcm1hdCBvZiBhbiBhZ2dyZWdh
dGVkIENoYXJhY3RlcmlzdGljIFZhbHVlLgo+Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCB1aW50MTYgQ3VzdG9tIFtyZWFkb25seV0KPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoE9wdGlvbmFsIENoYXJhY3RlcmlzdGljIGRlc2NyaXB0b3Igd2hpY2ggZGVmaW5lcyBwcm9m
aWxlIGRlZmluZWQgZGVzY3JpcHRvciBVVUlEJ3MuCj4KPgo+IFRoYW5rcywKPiBWaWpheQo+Cj4K
PiBNZW1iZXIgb2YgdGhlIENTUiBwbGMgZ3JvdXAgb2YgY29tcGFuaWVzLiBDU1IgcGxjIHJlZ2lz
dGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMsIHJlZ2lzdGVyZWQgbnVtYmVyIDQxODczNDYsIHJl
Z2lzdGVyZWQgb2ZmaWNlIENodXJjaGlsbCBIb3VzZSwgQ2FtYnJpZGdlIEJ1c2luZXNzIFBhcmss
IENvd2xleSBSb2FkLCBDYW1icmlkZ2UsIENCNCAwV1osIFVuaXRlZCBLaW5nZG9tCj4gTW9yZSBp
bmZvcm1hdGlvbiBjYW4gYmUgZm91bmQgYXQgd3d3LmNzci5jb20uIEZvbGxvdyBDU1Igb24gVHdp
dHRlciBhdCBodHRwOi8vdHdpdHRlci5jb20vQ1NSX1BMQyBhbmQgcmVhZCBvdXIgYmxvZyBhdCB3
d3cuY3NyLmNvbS9ibG9nCj4K

RE: Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

SGkgQ2xhdWRpbywNClRoYW5rcyBmb3IgeW91ciBpbnB1dHMuIFBsZWFzZSBm
aW5kIG15IGNvbW1lbnRzIGlubGluZS4NCg0KPiBJcyBpdCByZWFsbHkgbmVj
ZXNzYXJ5PyBJIHRob3VnaHQgcmVnaXN0ZXJpbmcgYSB3YXRjaGVyIGF0IHNl
cnZpY2UNCj4gImxldmVsIiB3YXMgZW5vdWdoLg0KDQpZZXMuIEkgdGhpbmsg
aWYgd2UgaWYgd2UgaGF2ZSB3YXRjaGVyIGF0IHNlcnZpY2UgbGV2ZWwgaXMg
ZW5vdWdoIGNhdXNlIGhhdmluZyBhIHNwZWNpZmljIGNoYXJhY3RlcmlzdGlj
IHdhdGNoZXIgd291bGQgbm90IGhlbHAgbXVjaC4NCg0KPiBDb3VsZCB5b3Ug
cGxlYXNlIGV4cGxhaW4gdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhpcyBwcm9w
ZXJ0eSBhbmQNCj4gU2VydmljZSBDaGFuZ2VkIGNoYXJhY3RlcmlzdGljKEdl
bmVyaWMgQXR0cmlidXRlIFByb2ZpbGUgU2VydmljZSk/DQo+IEluIG15IG9w
aW5pb24sIGl0IGlzIGEgc2VydmljZSBwcm9wZXJ0eSBpbnN0ZWFkIG9mIGNo
YXJhY3RlcmlzdGljIHByb3BlcnR5Lg0KDQpZZXMgeW91IGFyZSBjb3JyZWN0
LiBTZXJ2aWNlQ2hhbmdlZCgpIHdpbGwgZG8uIA0KDQo+IFJlYWQgb25seT8g
Q0NDIGNhbiBiZSB3cml0ZWFibGUgcmlnaHQ/DQogSXQncyBhY3R1YWxseSAi
My4zLjEuMSBDaGFyYWN0ZXJpc3RpYyBQcm9wZXJ0aWVzIiBmcm9tIHNwZWMu
IA0KDQoNClRoYW5rcywNClZpamF5DQoKCk1lbWJlciBvZiB0aGUgQ1NSIHBs
YyBncm91cCBvZiBjb21wYW5pZXMuIENTUiBwbGMgcmVnaXN0ZXJlZCBpbiBF
bmdsYW5kIGFuZCBXYWxlcywgcmVnaXN0ZXJlZCBudW1iZXIgNDE4NzM0Niwg
cmVnaXN0ZXJlZCBvZmZpY2UgQ2h1cmNoaWxsIEhvdXNlLCBDYW1icmlkZ2Ug
QnVzaW5lc3MgUGFyaywgQ293bGV5IFJvYWQsIENhbWJyaWRnZSwgQ0I0IDBX
WiwgVW5pdGVkIEtpbmdkb20KTW9yZSBpbmZvcm1hdGlvbiBjYW4gYmUgZm91
bmQgYXQgd3d3LmNzci5jb20uIEZvbGxvdyBDU1Igb24gVHdpdHRlciBhdCBo
dHRwOi8vdHdpdHRlci5jb20vQ1NSX1BMQyBhbmQgcmVhZCBvdXIgYmxvZyBh
dCB3d3cuY3NyLmNvbS9ibG9nCg==

Re: Proposal for GATT Client Dbus API.

[Anderson Lizardo]

Hi Vijay,

On Fri, Oct 14, 2011 at 7:51 AM, Vijaykumar Dadmode
<Vijaykumar.Dadmode@csr.com> wrote:
>> Read only? CCC can be writeable right?
>  It's actually "3.3.1.1 Characteristic Properties" from spec.

I think Claudio was actually referring to this part:

                        uint16 Configuration [readonly]
                                    Optional field containing the
configuration value on the server.

Looks like this is related to "Client Characteristic Configuration"
descriptor (section 3.3.3.3), which is:

* Readable with no authentication or authorization.
* Writable with authentication and authorization defined by a higher
layer specification or is implementation specific.

If you do not plan to have this property writable, it is not useful to
have it accessible for external D-Bus clients IMHO.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: Proposal for GATT Client Dbus API.

[Anderson Lizardo]

Hi Vijay,

First of all: can you provide your changes as a diff against the
current doc/attribute-api.txt ? It is not clear you are proposing a
whole new API, or extending the current one in that document.

Note you are also free to change doc/attribute-api.txt, as that API is
not stable yet.

On Tue, Oct 4, 2011 at 9:59 AM, Vijaykumar Dadmode
<Vijaykumar.Dadmode@csr.com> wrote:
> This post contains a proposal for the DBUS GATT API(Gatt CLIENT) that enhances the existing GATT
> functionality provided by DBUS APIs interface. Which include Methods,Signals and Properties.
> Could you please provide your comments and feedback for the same? Or we need more APIs to cover all GATT Client functionality?

You are free to propose a "full" API, but implement it by pieces (as
need arises). These API docs can evolve as long as we keep them
"unstable".

> . RegisterCharacteristicsWatcher can be used to monitor specific Characteristic change.

AFAIK, only the Characteristic Value is allowed to change, and we can
monitor its changes by enabling Notification or Indication. As Claudio
mentioned, we currently have a RegisterCharacteristicsWatcher() method
which is useful for monitoring:

* Characteristic Value changes
* New characteristics (actually not implemented, as we would need
client side support for Service Changed).

All other Characteristic components (properties and descriptors) are
not supposed to change on server side (as far as I know), given they
are part of each profile definition.

> . PropertyChanged Signal for the SetProperty().

If any property is supposed to change, will this PropertyChanged
signal be emitted at all?

> . ServiceChanged and CharacteristicChanged Signal for Service or Characteristic changes on the server.

I think a "ServiceChanged" signal does not make sense under the
characteristic object path. Why not abstract it and instead emit
signals for each characteristic which is mentioned on the "Service
Changed" characteristic of GATT service?

CharacteristicChanged is redundant if you have a
"RegisterCharacteristicsWatcher" which registers a callback when some
characteristic value changes.

> Properties:
>                         uint8 Property [readonly]
>                                     The characteristic property, format defined by GATT spec.

what about "Properties" (plural)?

>
>                         uint16 Configuration [readonly]
>                                     Optional field containing the configuration value on the server.

what about "ClientConfiguration" ? (remember there is Server
Characteristic Configuration as well)

>
>                         uint16 Extended [readonly]
>                                     The characteristic descriptor describing
>                                     the additional Characteristic Properties.

What about "ExtendedProperties"?

One idea (but I want feedback from other BlueZ developers) is to merge
"Properties" and "ExtendedProperties" and instead have an array of
strings representing each bit field, e.g.:

{ "Read", "Write", "Notify", "Reliable Write" }

>
>                         uint16 Aggregate [readonly]
>                                     Optional Characteristic descriptor which defines the
>                                              format of an aggregated Characteristic Value.

Actually the "Aggregate Format" descriptor is a list of handles. But
how can this be useful for a D-Bus client if it does not know about
handles at all?

My suggestion is to modify the current Format property defined in
doc/attribute-api.txt and have it as an array of struct, where each
struct is a Format. If there is no aggregate descriptor and only a
single presentation format descriptor, it will contain only a single
entry (i.e. array with size one). If there is no Presentation format
at all, it will be an empty array.

>
>                         uint16 Custom [readonly]
>                                                Optional Characteristic descriptor which defines profile defined descriptor UUID's.

I see a couple of issues with this property:

* There can be more than one "custom" descriptor.
* The descriptor value can have any size.
* And more important:

"Characteristic descriptor declaration permissions are defined by a higher layer
profile or are implementation specific. A client shall not assume all
characteris-
tic descriptor declarations are readable."

In summary, for custom/unknown descriptors, It makes more sense to
have a Method to read/write to them when needed by the client.

My suggestion is something like:

void           WriteDescriptor(uint16 handle, array{byte} value)
array{byte}  ReadDescriptor(uint16 handle)

And then a property which contains a dict (mapping handle -> uuid) for
*all* descriptors (of course the properties for known descriptors
would still exist, but this generic read/write API would be used for
them as well):

dict Descriptors [readonly]

It should then be noted by the docs that the attribute handle is only
valid during the session, and should not be stored/cached by the
client.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

RE: Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

Hi Anderson,
Thanks for your inputs. I am extending the current doc/attribute-api.txt. Will work towards your proposed changes and update the same. 

Thanks,
Vijay


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

RE: Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

Hi All,
Here's my proposal for modification to existing attribute-api.doc.
The addition include:
1)Comments provided on this post.
2)Comments taken from the discussion part of " GATT Dbus API on BlueZ - attirbute-api.txt modifications" post.
3) Doesn't address ServiceChanged(), will discuss as part of another post. 

Queries:
1) As the "Signals" are a broadcast, how do we direct it to the application which requests for it?
2) Does bluez support SetConnectionParameters & UpdateConnectionParameters, if not do we need to add the APIs for the same ? 


diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index 98d7f30..34d77bc 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -110,8 +110,56 @@ Methods		dict GetProperties()
 			read-write properties can be changed. On success
 			this will emit a PropertyChanged signal.
 
+		void GetCharacteristicValue( )
+
+			Read the value of the characteristic.
+			This will emit a ReadResponse signal with status code.
+
+		void SetCharacteristicValue(variant value, string method, uint16 offset)
+
+			Changes the value of the specified characteristic as per the offset and method. Only
+			read-write characteristic value can be changed.
+			This will emit a WriteResponse signal with status code.
+			
+			Write the value of the characreristic, with any of these specified method:
+			"WriteWithResponse", "SignedWriteWithoutResponse", 
+			"WriteLongCharacteristicValue", "PrepareWrite", "ExecuteWrite".
+			 
+		void  ReadDescriptor(uint16 handle)
+                        
+			Read the value of the specified characteristic descriptor matching the handle.
+			This will emit a ReadDescriptorResponse signal with status code.
+                        
+		void  WriteDescriptor(uint16 handle, array{byte} value)
+
+			Changes the value of the specified characteristic descriptor matching the handle. Only
+			read-write descriptors can be changed.
+			This will emit a WriteDescriptorResponse signal with status code.
+
 			Possible Errors: org.bluez.Error.InvalidArguments
 
+Signals		PropertyChanged(string name, variant value)
+
+			This signal indicates a changed value of the given
+			property.
+		
+		ReadResponse(uint8 status, variant value)
+
+			Parameter is the read value and status code for GetCharacteristicValue operation. 
+
+		WriteResponse(uint8 status)
+
+			Parameter is the status code for SetCharacteristicValue operation. 
+			
+
+		ReadDescriptorResponse(uint8 status, variant value)
+
+			Parameter is the read value and status code for ReadDescriptor operation. 
+
+		WriteDescriptorResponse(uint8 status)
+
+			Parameter is the status code for WriteDescriptor operation. 
+
 Properties 	string UUID [readonly]
 
 			UUID128 of this characteristic.
@@ -121,12 +169,22 @@ Properties 	string UUID [readonly]
 			Optional field containing a friendly name for the
 			Characteristic UUID.
 
+		array{string} Properties [readonly]
+
+			The characteristic properties includes extended properties if defined, format defined by GATT spec. 
+			Possible values representing each bit field: 
+			{ "Broadcast", "Read", "WriteWithoutResponse", "Write", "Notify", "Indicate", "AuthenticatedSignedWrite", 					"ExtentedProperties", "ReliableWrite", "WritableAuxiliaries"}
+
+		uint16 ClientConfiguration [readwrite]
+
+			Optional field containing the client configuration value on the server.
+
 		string Description [readonly]
 
 			Textual optional characteristic descriptor describing
 			the Characteristic Value.
 
-		struct Format [readonly]
+		array{struct} Format [readonly]
 
 			Optional Characteristic descriptor which defines the
 			format of the Characteristic Value. For numeric
@@ -151,6 +209,11 @@ Properties 	string UUID [readonly]
 			Friendly representation of the Characteristic Value
 			based on the format attribute.
 
+		dict Descriptors [readonly]
+
+			The value is a dictionary for all Characteristic descriptor with the handle as keys and the UUID as values.The key is 			uint16 and the value a string for this dictionary. Can be used with WriteDescriptor and ReadDescriptor.  
+		      These attribute handle is only valid during the session, and should not be stored/cached by the client.
+


> Hi,
> Thanks for your inputs. I am extending the current doc/attribute-api.txt. Will work towards your proposed changes and > > update the same. 

> Thanks,
> Vijay

Thanks,
Vijay


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

RE: Proposal for GATT Client Dbus API.

[Ganir, Chen]

Vijay,

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Vijaykumar Dadmode
> Sent: Thursday, November 03, 2011 12:32 PM
> To: 'Anderson Lizardo'; 'claudio.takahasi@openbossa.org'
> Cc: linux-bluetooth@vger.kernel.org
> Subject: RE: Proposal for GATT Client Dbus API.
> 
> Hi All,
> Here's my proposal for modification to existing attribute-api.doc.
> The addition include:
> 1)Comments provided on this post.
> 2)Comments taken from the discussion part of " GATT Dbus API on BlueZ -
> attirbute-api.txt modifications" post.
> 3) Doesn't address ServiceChanged(), will discuss as part of another
> post.
> 
> Queries:
> 1) As the "Signals" are a broadcast, how do we direct it to the
> application which requests for it?
We can use the existing watchers. At the moment, watchers are registered to be called when indication/notification arrives from the sever. This means that a watcher will receive ValueChanged message with characteristic path and new value. We could use this interface and add the ReadRespnse and WriteResponse to it.

> 2) Does bluez support SetConnectionParameters &
> UpdateConnectionParameters, if not do we need to add the APIs for the
> same ?
> 
> 
> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
> index 98d7f30..34d77bc 100644
> --- a/doc/attribute-api.txt
> +++ b/doc/attribute-api.txt
> @@ -110,8 +110,56 @@ Methods		dict GetProperties()
>  			read-write properties can be changed. On success
>  			this will emit a PropertyChanged signal.
> 
> +		void GetCharacteristicValue( )
> +
> +			Read the value of the characteristic.
> +			This will emit a ReadResponse signal with status
> code.
When will this signal/message be sent ? Do we implement a timeout for connection timeout ? Can we set it as a parameter to this message?

> +
> +		void SetCharacteristicValue(variant value, string method,
> uint16 offset)
> +
> +			Changes the value of the specified characteristic as
> per the offset and method. Only
> +			read-write characteristic value can be changed.
What is this read-write char value you are referring to here ?

> +			This will emit a WriteResponse signal with status
> code.
Again, we need some timeout, to allow clean upper level implementation.

> +
> +			Write the value of the characreristic, with any of
> these specified method:
> +			"WriteWithResponse", "SignedWriteWithoutResponse",
> +			"WriteLongCharacteristicValue", "PrepareWrite",
> "ExecuteWrite".
> +
> +		void  ReadDescriptor(uint16 handle)
> +
> +			Read the value of the specified characteristic
> descriptor matching the handle.
> +			This will emit a ReadDescriptorResponse signal with
> status code.
This will not go through. Handles should not be used by the users. In fact, all descriptors can be turned into D-BUS dictionaries, and be available as characteristic properties. This is already done today for some descriptors. However, not all of them should be exposed directly to user (client characteristic config descriptor for example can be exposed as properties Notify and Indicate, server char config descriptor can be exposed as property Broadcast, and so on. Format is already discovered and partially used in the existing code.

> +
> +		void  WriteDescriptor(uint16 handle, array{byte} value)
> +
> +			Changes the value of the specified characteristic
> descriptor matching the handle. Only
> +			read-write descriptors can be changed.
> +			This will emit a WriteDescriptorResponse signal with
> status code.
> +
>  			Possible Errors: org.bluez.Error.InvalidArguments
> 
No use for this one - see above my previous comment.

> +Signals		PropertyChanged(string name, variant value)
> +
> +			This signal indicates a changed value of the given
> +			property.
> +
When will this be used? We already have readresponse, writeresponse. Other properties are fixed, and read on connection automatically. We will not need this. We can use this if we expose Notify, Indicate, Broadcast properties. Writing to these properties will cause the propertychanged event to be called, once the write has completed, if that's possible.

> +		ReadResponse(uint8 status, variant value)
> +
> +			Parameter is the read value and status code for
> GetCharacteristicValue operation.
We need to add the characteristic path as well. We may issue multiple read requests, and receive them all after a while - we need to be able to understand which characteristic value we received.

> +
> +		WriteResponse(uint8 status)
> +
> +			Parameter is the status code for
> SetCharacteristicValue operation.
Same as above - we need the characteristic path.

> +
> +
> +		ReadDescriptorResponse(uint8 status, variant value)
> +
> +			Parameter is the read value and status code for
> ReadDescriptor operation.
> +
> +		WriteDescriptorResponse(uint8 status)
> +
> +			Parameter is the status code for WriteDescriptor
> operation.
> +
No need for this.

>  Properties 	string UUID [readonly]
> 
>  			UUID128 of this characteristic.
> @@ -121,12 +169,22 @@ Properties 	string UUID [readonly]
>  			Optional field containing a friendly name for the
>  			Characteristic UUID.
> 
> +		array{string} Properties [readonly]
> +
> +			The characteristic properties includes extended
> properties if defined, format defined by GATT spec.
> +			Possible values representing each bit field:
> +			{ "Broadcast", "Read", "WriteWithoutResponse",
> "Write", "Notify", "Indicate", "AuthenticatedSignedWrite",
> 			"ExtentedProperties", "ReliableWrite",
> "WritableAuxiliaries"}
> +
Properties which can be changed, such as Broadcast, Indicate, Notify should be standalong, Boolean read/write properties. See above for more information on why we need these.

> +		uint16 ClientConfiguration [readwrite]
> +
> +			Optional field containing the client configuration
> value on the server.
> +
We should not expose bit fields to the users. We can abstract this to Notify/Indicate Boolean properties.

>  		string Description [readonly]
> 
>  			Textual optional characteristic descriptor describing
>  			the Characteristic Value.
> 
> -		struct Format [readonly]
> +		array{struct} Format [readonly]
> 
>  			Optional Characteristic descriptor which defines the
>  			format of the Characteristic Value. For numeric
> @@ -151,6 +209,11 @@ Properties 	string UUID [readonly]
>  			Friendly representation of the Characteristic Value
>  			based on the format attribute.
> 
This also needs to be simplified. We need to take the format strings from the spec, and apply the correct properties according to the format descriptor. Again, we should not expose raw bit fields here.

> +		dict Descriptors [readonly]
> +
> +			The value is a dictionary for all Characteristic
> descriptor with the handle as keys and the UUID as values.The key is
> 			uint16 and the value a string for this dictionary.
> Can be used with WriteDescriptor and ReadDescriptor.
> +		      These attribute handle is only valid during the
> session, and should not be stored/cached by the client.
> +
See above. Not needed.

> 
> 
> > Hi,
> > Thanks for your inputs. I am extending the current doc/attribute-
> api.txt. Will work towards your proposed changes and > > update the
> same.
> 
> > Thanks,
> > Vijay
> 
> Thanks,
> Vijay
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill
> House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United
> Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at
> http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks,
Chen Ganir.

RE: Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

Hi Chen,
Thanks for your inputs. Please find my comments inline. 
 
> > Queries:
> > 1) As the "Signals" are a broadcast, how do we direct it to the
> > application which requests for it?
> We can use the existing watchers. At the moment, watchers are registered to be called when indication/notification arrives from the > > sever. This means that a watcher will receive ValueChanged message with characteristic path and new value. We could use this > >interface >and add the ReadRespnse and WriteResponse to it.

So you mean we add the ReadResponse and WriteResponse to Watcher Hierarchy?  , but what if we don't register the watcher and just want to read/write?  

>> 
>> +		void GetCharacteristicValue( )
>> +
>> +			Read the value of the characteristic.
>> +			This will emit a ReadResponse signal with status
>> code.


>When will this signal/message be sent ? Do we implement a timeout for connection timeout ? Can we set it as a parameter to this message?


Method can be called when applications want to read the value on server(active read).

> > +
> > +		void SetCharacteristicValue(variant value, string method,
> uint16 offset)
> > +
> > +			Changes the value of the specified characteristic as
> > per the offset and method. Only
> > +			read-write characteristic value can be changed.
> What is this read-write char value you are referring to here ?

Updated.

> +			This will emit a WriteResponse signal with status
> code.
> Again, we need some timeout, to allow clean upper level implementation.

> +
> +			Write the value of the characreristic, with any of
> these specified method:
> +			"WriteWithResponse", "SignedWriteWithoutResponse",
> +			"WriteLongCharacteristicValue", "PrepareWrite",
> "ExecuteWrite".
> +
> +		void  ReadDescriptor(uint16 handle)
> +
> +			Read the value of the specified characteristic
> descriptor matching the handle.
> +			This will emit a ReadDescriptorResponse signal with
> status code.
> This will not go through. Handles should not be used by the users. In fact, all descriptors can be turned into D-BUS dictionaries, >and be available as characteristic properties. This is already done today for some descriptors. However, not all of them should be >exposed directly to user (client characteristic config descriptor for example can be exposed as properties Notify and Indicate, server >char config descriptor can be exposed as property Broadcast, and so on. Format is already discovered and partially used in the >existing code.

ReadDescriptor and WriteDescriptor we have added keeping "Custom" descriptors (Optional Characteristic descriptor which
defines profile defined descriptor UUID's.)  in mind.
> +		dict Descriptors [readonly]

So a property which contains a dict (mapping handle -> uuid) for
*all* descriptors (of course the properties for known descriptors
would still exist, but this generic read/write API would be used for
them as well). 



> +
> +		void  WriteDescriptor(uint16 handle, array{byte} value)
> +
> +			Changes the value of the specified characteristic
> descriptor matching the handle. Only
> +			read-write descriptors can be changed.
> +			This will emit a WriteDescriptorResponse signal with
> status code.
> +
>  			Possible Errors: org.bluez.Error.InvalidArguments
> 
> No use for this one - see above my previous comment.

> +Signals		PropertyChanged(string name, variant value)
> +
> +			This signal indicates a changed value of the given
> +			property.
> +
> When will this be used? We already have readresponse, writeresponse. Other properties are fixed, and read on connection > >automatically. We will not need this. We can use this if we expose Notify, Indicate, Broadcast properties. Writing to these properties >will cause the propertychanged event to be called, once the write has completed, if that's possible.

Yes agree with adding Notify, Indicate, Broadcast as properties. 



> +		ReadResponse(uint8 status, variant value)
> +
> +			Parameter is the read value and status code for
> GetCharacteristicValue operation.
>We need to add the characteristic path as well. We may issue multiple read requests, and receive them all after a while - we need to >be able to understand which characteristic value we received.

Agreed.

> +
> +		WriteResponse(uint8 status)
> +
> +			Parameter is the status code for
> SetCharacteristicValue operation.
>Same as above - we need the characteristic path.

Agreed.

> +
> +
> +		ReadDescriptorResponse(uint8 status, variant value)
> +
> +			Parameter is the read value and status code for
> ReadDescriptor operation.
> +
> +		WriteDescriptorResponse(uint8 status)
> +
> +			Parameter is the status code for WriteDescriptor
> operation.
> +
>No need for this.

Added keeping "Custom" descriptors in mind.

>  Properties 	string UUID [readonly]
> 
>  			UUID128 of this characteristic.
> @@ -121,12 +169,22 @@ Properties 	string UUID [readonly]
>  			Optional field containing a friendly name for the
>  			Characteristic UUID.
> 
> +		array{string} Properties [readonly]
> +
> +			The characteristic properties includes extended
> properties if defined, format defined by GATT spec.
> +			Possible values representing each bit field:
> +			{ "Broadcast", "Read", "WriteWithoutResponse",
> "Write", "Notify", "Indicate", "AuthenticatedSignedWrite",
> 			"ExtentedProperties", "ReliableWrite",
> "WritableAuxiliaries"}
> +
>Properties which can be changed, such as Broadcast, Indicate, Notify should be standalong, Boolean read/write properties. See above >for more information on why we need these.

Agreed. I think we can have this array plus for the simpler usage we can add the r/w Broadcast, Indicate, Notify properties.

> +		uint16 ClientConfiguration [readwrite]
> +
> +			Optional field containing the client configuration
> value on the server.
> +
> We should not expose bit fields to the users. We can abstract this to Notify/Indicate Boolean properties.

Agreed

>>  		string Description [readonly]
>> 
>  			Textual optional characteristic descriptor describing
>  			the Characteristic Value.
> 
> -		struct Format [readonly]
> +		array{struct} Format [readonly]
> 
>  			Optional Characteristic descriptor which defines the
>  			format of the Characteristic Value. For numeric
> @@ -151,6 +209,11 @@ Properties 	string UUID [readonly]
>  			Friendly representation of the Characteristic Value
>  			based on the format attribute.
> 
> This also needs to be simplified. We need to take the format strings from the spec, and apply the correct properties according to the > format descriptor. Again, we should not expose raw bit fields here.

>> +		dict Descriptors [readonly]
>> +
>> +			The value is a dictionary for all Characteristic
>> descriptor with the handle as keys and the UUID as values.The key is
> 			uint16 and the value a string for this dictionary.
> Can be used with WriteDescriptor and ReadDescriptor.
> +		      These attribute handle is only valid during the
>> session, and should not be stored/cached by the client.
>> +
> See above. Not needed.
Explained part of ReadDescriptor. 

Thanks,
Vijay



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

RE: Proposal for GATT Client Dbus API.

[Ganir, Chen]

Vijay,


> -----Original Message-----
> From: Vijaykumar Dadmode [mailto:Vijaykumar.Dadmode@csr.com]
> Sent: Friday, November 04, 2011 2:46 PM
> To: Ganir, Chen
> Cc: linux-bluetooth@vger.kernel.org
> Subject: RE: Proposal for GATT Client Dbus API.
> 
> Hi Chen,
> Thanks for your inputs. Please find my comments inline.
> 
> > > Queries:
> > > 1) As the "Signals" are a broadcast, how do we direct it to the
> > > application which requests for it?
> > We can use the existing watchers. At the moment, watchers are
> registered to be called when indication/notification arrives from the >
> > sever. This means that a watcher will receive ValueChanged message
> with characteristic path and new value. We could use this > >interface
> >and add the ReadRespnse and WriteResponse to it.
> 
> So you mean we add the ReadResponse and WriteResponse to Watcher
> Hierarchy?  , but what if we don't register the watcher and just want
> to read/write?
> 
> >>
> >> +		void GetCharacteristicValue( )
> >> +
> >> +			Read the value of the characteristic.
> >> +			This will emit a ReadResponse signal with status
> >> code.
> 
> 
> >When will this signal/message be sent ? Do we implement a timeout for
> connection timeout ? Can we set it as a parameter to this message?
> 
> 
> Method can be called when applications want to read the value on
> server(active read).
> 
This I understand. 
Since this is an async function, we must have some timeout, or mechanism to notify the user that we're either connected and fetching the value, and he should be expecting a ReadResponse anytime soon, or that we are not currently connected, and we will try a connection procedure to the server, which may take some time, or may even never end. Now that I think of it - maybe we also need CancelGetCharacteristicValue function, to remove a pending read value request - we do not want the ReadResponse event triggered if the connection is established after a few days for example.

> > > +
> > > +		void SetCharacteristicValue(variant value, string method,
> > uint16 offset)
> > > +
> > > +			Changes the value of the specified characteristic as
> > > per the offset and method. Only
> > > +			read-write characteristic value can be changed.
> > What is this read-write char value you are referring to here ?
> 
> Updated.
> 
Same as above - we need to be able to cancel a set request, and we need some timeout to notify the user that the DBUS client has given up and will not try to set the value any more.

> > +			This will emit a WriteResponse signal with status
> > code.
> > Again, we need some timeout, to allow clean upper level
> implementation.
> 
> > +
> > +			Write the value of the characreristic, with any of
> > these specified method:
> > +			"WriteWithResponse", "SignedWriteWithoutResponse",
> > +			"WriteLongCharacteristicValue", "PrepareWrite",
> > "ExecuteWrite".
> > +
> > +		void  ReadDescriptor(uint16 handle)
> > +
> > +			Read the value of the specified characteristic
> > descriptor matching the handle.
> > +			This will emit a ReadDescriptorResponse signal with
> > status code.
> > This will not go through. Handles should not be used by the users. In
> fact, all descriptors can be turned into D-BUS dictionaries, >and be
> available as characteristic properties. This is already done today for
> some descriptors. However, not all of them should be >exposed directly
> to user (client characteristic config descriptor for example can be
> exposed as properties Notify and Indicate, server >char config
> descriptor can be exposed as property Broadcast, and so on. Format is
> already discovered and partially used in the >existing code.
> 
> ReadDescriptor and WriteDescriptor we have added keeping "Custom"
> descriptors (Optional Characteristic descriptor which
> defines profile defined descriptor UUID's.)  in mind.
> > +		dict Descriptors [readonly]
> 
This custom descriptor is defined as an array of bytes with specific uuid. It can be reflected to the user as a property, which will be available if the server contains such a descriptor for the characteristic. This way, we can use the getproperty and setproperty, and hide all the irrelevant descriptor/handle logic from the user.

> So a property which contains a dict (mapping handle -> uuid) for
> *all* descriptors (of course the properties for known descriptors
> would still exist, but this generic read/write API would be used for
> them as well).
> 
This is wrong. This means that you duplicate the data - once in single flags (notify, indicate, user_defined) and once as a set of raw descriptor data. Again, I believe this should be hidden from the user, who does not need to handle descriptors and handles.

> 
> 
> > +
> > +		void  WriteDescriptor(uint16 handle, array{byte} value)
> > +
> > +			Changes the value of the specified characteristic
> > descriptor matching the handle. Only
> > +			read-write descriptors can be changed.
> > +			This will emit a WriteDescriptorResponse signal with
> > status code.
> > +
> >  			Possible Errors: org.bluez.Error.InvalidArguments
> >
> > No use for this one - see above my previous comment.
> 
> > +Signals		PropertyChanged(string name, variant value)
> > +
> > +			This signal indicates a changed value of the given
> > +			property.
> > +
> > When will this be used? We already have readresponse, writeresponse.
> Other properties are fixed, and read on connection > >automatically. We
> will not need this. We can use this if we expose Notify, Indicate,
> Broadcast properties. Writing to these properties >will cause the
> propertychanged event to be called, once the write has completed, if
> that's possible.
> 
> Yes agree with adding Notify, Indicate, Broadcast as properties.
> 
> 
> 
> > +		ReadResponse(uint8 status, variant value)
> > +
> > +			Parameter is the read value and status code for
> > GetCharacteristicValue operation.
> >We need to add the characteristic path as well. We may issue multiple
> read requests, and receive them all after a while - we need to >be able
> to understand which characteristic value we received.
> 
> Agreed.
> 
> > +
> > +		WriteResponse(uint8 status)
> > +
> > +			Parameter is the status code for
> > SetCharacteristicValue operation.
> >Same as above - we need the characteristic path.
> 
> Agreed.
> 
> > +
> > +
> > +		ReadDescriptorResponse(uint8 status, variant value)
> > +
> > +			Parameter is the read value and status code for
> > ReadDescriptor operation.
> > +
> > +		WriteDescriptorResponse(uint8 status)
> > +
> > +			Parameter is the status code for WriteDescriptor
> > operation.
> > +
> >No need for this.
> 
> Added keeping "Custom" descriptors in mind.
> 
See above about custom descriptors.


> >  Properties 	string UUID [readonly]
> >
> >  			UUID128 of this characteristic.
> > @@ -121,12 +169,22 @@ Properties 	string UUID [readonly]
> >  			Optional field containing a friendly name for the
> >  			Characteristic UUID.
> >
> > +		array{string} Properties [readonly]
> > +
> > +			The characteristic properties includes extended
> > properties if defined, format defined by GATT spec.
> > +			Possible values representing each bit field:
> > +			{ "Broadcast", "Read", "WriteWithoutResponse",
> > "Write", "Notify", "Indicate", "AuthenticatedSignedWrite",
> > 			"ExtentedProperties", "ReliableWrite",
> > "WritableAuxiliaries"}
> > +
> >Properties which can be changed, such as Broadcast, Indicate, Notify
> should be standalong, Boolean read/write properties. See above >for
> more information on why we need these.
> 
> Agreed. I think we can have this array plus for the simpler usage we
> can add the r/w Broadcast, Indicate, Notify properties.
> 
Why duplicate data again ? it is very confusing to have this information in two or more places. Writable properties should have their own representation, without duplication in this list.

> > +		uint16 ClientConfiguration [readwrite]
> > +
> > +			Optional field containing the client configuration
> > value on the server.
> > +
> > We should not expose bit fields to the users. We can abstract this to
> Notify/Indicate Boolean properties.
> 
> Agreed
> 
> >>  		string Description [readonly]
> >>
> >  			Textual optional characteristic descriptor describing
> >  			the Characteristic Value.
> >
> > -		struct Format [readonly]
> > +		array{struct} Format [readonly]
> >
> >  			Optional Characteristic descriptor which defines the
> >  			format of the Characteristic Value. For numeric
> > @@ -151,6 +209,11 @@ Properties 	string UUID [readonly]
> >  			Friendly representation of the Characteristic Value
> >  			based on the format attribute.
> >
> > This also needs to be simplified. We need to take the format strings
> from the spec, and apply the correct properties according to the >
> format descriptor. Again, we should not expose raw bit fields here.
> 
> >> +		dict Descriptors [readonly]
> >> +
> >> +			The value is a dictionary for all Characteristic
> >> descriptor with the handle as keys and the UUID as values.The key is
> > 			uint16 and the value a string for this dictionary.
> > Can be used with WriteDescriptor and ReadDescriptor.
> > +		      These attribute handle is only valid during the
> >> session, and should not be stored/cached by the client.
> >> +
> > See above. Not needed.
> Explained part of ReadDescriptor.
> 
See above why we should not expose raw descriptors to the user. We have the properties mechanism, which is what descriptors are all about. Simply translate the GATT descriptors into DBUS properties.

> Thanks,
> Vijay
> 
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill
> House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United
> Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at
> http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


Vijay, can you send an updated proposal with the changes we've discussed, or should I send it ?

Thanks,
Chen Ganir.
Texas Instruments.

RE: Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

Hi Chen,
Could you please clarify below points:
> > > application which requests for it?
> > We can use the existing watchers. At the moment, watchers are
> registered to be called when indication/notification arrives from the 
> >
> > sever. This means that a watcher will receive ValueChanged message
> with characteristic path and new value. We could use this > >interface
> >and add the ReadRespnse and WriteResponse to it.
> 

So you mean we add the ReadResponse and WriteResponse to Watcher 
Hierarchy?  , but what if we don't register the watcher and just want 
to read/write?


> This custom descriptor is defined as an array of bytes with specific uuid. It can be reflected to the user as a property, which will > be available if the server contains such a descriptor for the characteristic. This way, we can use the getproperty and setproperty,  > and hide all the irrelevant descriptor/handle logic from the user.

The custom desc can be: 
* There can be more than one "custom" descriptor.
* The descriptor value can have any size.
* And more important: "Characteristic descriptor declaration permissions are defined by a higher layer profile or are implementation specific. A client shall not assume all characteristic descriptor declarations are readable."

Proposal 1: We can have custom specific desc calls ReadCustomDescriptor and WriteCustomDescriptor. 
Proposal 2: Have a property Custom, and then access the descriptor as Attributes. 

Thanks,
Vijay

-----Original Message-----
From: Ganir, Chen [mailto:chen.ganir@ti.com] 
Sent: Sunday, November 06, 2011 1:25 PM
To: Vijaykumar Dadmode
Cc: linux-bluetooth@vger.kernel.org
Subject: RE: Proposal for GATT Client Dbus API.

Vijay,


> -----Original Message-----
> From: Vijaykumar Dadmode [mailto:Vijaykumar.Dadmode@csr.com]
> Sent: Friday, November 04, 2011 2:46 PM
> To: Ganir, Chen
> Cc: linux-bluetooth@vger.kernel.org
> Subject: RE: Proposal for GATT Client Dbus API.
> 
> Hi Chen,
> Thanks for your inputs. Please find my comments inline.
> 
> > > Queries:
> > > 1) As the "Signals" are a broadcast, how do we direct it to the
> > > application which requests for it?
> > We can use the existing watchers. At the moment, watchers are
> registered to be called when indication/notification arrives from the >
> > sever. This means that a watcher will receive ValueChanged message
> with characteristic path and new value. We could use this > >interface
> >and add the ReadRespnse and WriteResponse to it.
> 
> So you mean we add the ReadResponse and WriteResponse to Watcher
> Hierarchy?  , but what if we don't register the watcher and just want
> to read/write?
> 
> >>
> >> +		void GetCharacteristicValue( )
> >> +
> >> +			Read the value of the characteristic.
> >> +			This will emit a ReadResponse signal with status
> >> code.
> 
> 
> >When will this signal/message be sent ? Do we implement a timeout for
> connection timeout ? Can we set it as a parameter to this message?
> 
> 
> Method can be called when applications want to read the value on
> server(active read).
> 
This I understand. 
Since this is an async function, we must have some timeout, or mechanism to notify the user that we're either connected and fetching the value, and he should be expecting a ReadResponse anytime soon, or that we are not currently connected, and we will try a connection procedure to the server, which may take some time, or may even never end. Now that I think of it - maybe we also need CancelGetCharacteristicValue function, to remove a pending read value request - we do not want the ReadResponse event triggered if the connection is established after a few days for example.

> > > +
> > > +		void SetCharacteristicValue(variant value, string method,
> > uint16 offset)
> > > +
> > > +			Changes the value of the specified characteristic as
> > > per the offset and method. Only
> > > +			read-write characteristic value can be changed.
> > What is this read-write char value you are referring to here ?
> 
> Updated.
> 
Same as above - we need to be able to cancel a set request, and we need some timeout to notify the user that the DBUS client has given up and will not try to set the value any more.

> > +			This will emit a WriteResponse signal with status
> > code.
> > Again, we need some timeout, to allow clean upper level
> implementation.
> 
> > +
> > +			Write the value of the characreristic, with any of
> > these specified method:
> > +			"WriteWithResponse", "SignedWriteWithoutResponse",
> > +			"WriteLongCharacteristicValue", "PrepareWrite",
> > "ExecuteWrite".
> > +
> > +		void  ReadDescriptor(uint16 handle)
> > +
> > +			Read the value of the specified characteristic
> > descriptor matching the handle.
> > +			This will emit a ReadDescriptorResponse signal with
> > status code.
> > This will not go through. Handles should not be used by the users. In
> fact, all descriptors can be turned into D-BUS dictionaries, >and be
> available as characteristic properties. This is already done today for
> some descriptors. However, not all of them should be >exposed directly
> to user (client characteristic config descriptor for example can be
> exposed as properties Notify and Indicate, server >char config
> descriptor can be exposed as property Broadcast, and so on. Format is
> already discovered and partially used in the >existing code.
> 
> ReadDescriptor and WriteDescriptor we have added keeping "Custom"
> descriptors (Optional Characteristic descriptor which
> defines profile defined descriptor UUID's.)  in mind.
> > +		dict Descriptors [readonly]
> 
This custom descriptor is defined as an array of bytes with specific uuid. It can be reflected to the user as a property, which will be available if the server contains such a descriptor for the characteristic. This way, we can use the getproperty and setproperty, and hide all the irrelevant descriptor/handle logic from the user.

> So a property which contains a dict (mapping handle -> uuid) for
> *all* descriptors (of course the properties for known descriptors
> would still exist, but this generic read/write API would be used for
> them as well).
> 
This is wrong. This means that you duplicate the data - once in single flags (notify, indicate, user_defined) and once as a set of raw descriptor data. Again, I believe this should be hidden from the user, who does not need to handle descriptors and handles.

> 
> 
> > +
> > +		void  WriteDescriptor(uint16 handle, array{byte} value)
> > +
> > +			Changes the value of the specified characteristic
> > descriptor matching the handle. Only
> > +			read-write descriptors can be changed.
> > +			This will emit a WriteDescriptorResponse signal with
> > status code.
> > +
> >  			Possible Errors: org.bluez.Error.InvalidArguments
> >
> > No use for this one - see above my previous comment.
> 
> > +Signals		PropertyChanged(string name, variant value)
> > +
> > +			This signal indicates a changed value of the given
> > +			property.
> > +
> > When will this be used? We already have readresponse, writeresponse.
> Other properties are fixed, and read on connection > >automatically. We
> will not need this. We can use this if we expose Notify, Indicate,
> Broadcast properties. Writing to these properties >will cause the
> propertychanged event to be called, once the write has completed, if
> that's possible.
> 
> Yes agree with adding Notify, Indicate, Broadcast as properties.
> 
> 
> 
> > +		ReadResponse(uint8 status, variant value)
> > +
> > +			Parameter is the read value and status code for
> > GetCharacteristicValue operation.
> >We need to add the characteristic path as well. We may issue multiple
> read requests, and receive them all after a while - we need to >be able
> to understand which characteristic value we received.
> 
> Agreed.
> 
> > +
> > +		WriteResponse(uint8 status)
> > +
> > +			Parameter is the status code for
> > SetCharacteristicValue operation.
> >Same as above - we need the characteristic path.
> 
> Agreed.
> 
> > +
> > +
> > +		ReadDescriptorResponse(uint8 status, variant value)
> > +
> > +			Parameter is the read value and status code for
> > ReadDescriptor operation.
> > +
> > +		WriteDescriptorResponse(uint8 status)
> > +
> > +			Parameter is the status code for WriteDescriptor
> > operation.
> > +
> >No need for this.
> 
> Added keeping "Custom" descriptors in mind.
> 
See above about custom descriptors.


> >  Properties 	string UUID [readonly]
> >
> >  			UUID128 of this characteristic.
> > @@ -121,12 +169,22 @@ Properties 	string UUID [readonly]
> >  			Optional field containing a friendly name for the
> >  			Characteristic UUID.
> >
> > +		array{string} Properties [readonly]
> > +
> > +			The characteristic properties includes extended
> > properties if defined, format defined by GATT spec.
> > +			Possible values representing each bit field:
> > +			{ "Broadcast", "Read", "WriteWithoutResponse",
> > "Write", "Notify", "Indicate", "AuthenticatedSignedWrite",
> > 			"ExtentedProperties", "ReliableWrite",
> > "WritableAuxiliaries"}
> > +
> >Properties which can be changed, such as Broadcast, Indicate, Notify
> should be standalong, Boolean read/write properties. See above >for
> more information on why we need these.
> 
> Agreed. I think we can have this array plus for the simpler usage we
> can add the r/w Broadcast, Indicate, Notify properties.
> 
Why duplicate data again ? it is very confusing to have this information in two or more places. Writable properties should have their own representation, without duplication in this list.

> > +		uint16 ClientConfiguration [readwrite]
> > +
> > +			Optional field containing the client configuration
> > value on the server.
> > +
> > We should not expose bit fields to the users. We can abstract this to
> Notify/Indicate Boolean properties.
> 
> Agreed
> 
> >>  		string Description [readonly]
> >>
> >  			Textual optional characteristic descriptor describing
> >  			the Characteristic Value.
> >
> > -		struct Format [readonly]
> > +		array{struct} Format [readonly]
> >
> >  			Optional Characteristic descriptor which defines the
> >  			format of the Characteristic Value. For numeric
> > @@ -151,6 +209,11 @@ Properties 	string UUID [readonly]
> >  			Friendly representation of the Characteristic Value
> >  			based on the format attribute.
> >
> > This also needs to be simplified. We need to take the format strings
> from the spec, and apply the correct properties according to the >
> format descriptor. Again, we should not expose raw bit fields here.
> 
> >> +		dict Descriptors [readonly]
> >> +
> >> +			The value is a dictionary for all Characteristic
> >> descriptor with the handle as keys and the UUID as values.The key is
> > 			uint16 and the value a string for this dictionary.
> > Can be used with WriteDescriptor and ReadDescriptor.
> > +		      These attribute handle is only valid during the
> >> session, and should not be stored/cached by the client.
> >> +
> > See above. Not needed.
> Explained part of ReadDescriptor.
> 
See above why we should not expose raw descriptors to the user. We have the properties mechanism, which is what descriptors are all about. Simply translate the GATT descriptors into DBUS properties.

> Thanks,
> Vijay
> 
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill
> House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United
> Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at
> http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog


Vijay, can you send an updated proposal with the changes we've discussed, or should I send it ?

Thanks,
Chen Ganir.
Texas Instruments.


 To report this email as spam click https://www.mailcontrol.com/sr/keBbNGaYv7HTndxI!oX7UsdpzMR7Bo2KP2imJfv699sbiy929P9Qs4lEOZpe1nNVJnoe!+NpOToakVWf!6zCig== .

RE: Proposal for GATT Client Dbus API.

[Ganir, Chen]

Vijay,


> -----Original Message-----
> From: Vijaykumar Dadmode [mailto:Vijaykumar.Dadmode@csr.com]
> Sent: Monday, November 07, 2011 11:20 AM
> To: Ganir, Chen
> Cc: linux-bluetooth@vger.kernel.org
> Subject: RE: Proposal for GATT Client Dbus API.
> 
> Hi Chen,
> Could you please clarify below points:
> > > > application which requests for it?
> > > We can use the existing watchers. At the moment, watchers are
> > registered to be called when indication/notification arrives from the
> > >
> > > sever. This means that a watcher will receive ValueChanged message
> > with characteristic path and new value. We could use this >
> >interface
> > >and add the ReadRespnse and WriteResponse to it.
> >
> 
> So you mean we add the ReadResponse and WriteResponse to Watcher
> Hierarchy?  , but what if we don't register the watcher and just want
> to read/write?
> 
If this is the case, you will not get any responses to your write and read commands. I think it is ok to force the user to register a watcher, to get callbacks. I do not feel good with broadcasting such events to everyone. 

> 
> > This custom descriptor is defined as an array of bytes with specific
> uuid. It can be reflected to the user as a property, which will > be
> available if the server contains such a descriptor for the
> characteristic. This way, we can use the getproperty and setproperty,
> > and hide all the irrelevant descriptor/handle logic from the user.
> 
> The custom desc can be:
> * There can be more than one "custom" descriptor.
> * The descriptor value can have any size.
> * And more important: "Characteristic descriptor declaration
> permissions are defined by a higher layer profile or are implementation
> specific. A client shall not assume all characteristic descriptor
> declarations are readable."
> 
> Proposal 1: We can have custom specific desc calls ReadCustomDescriptor
> and WriteCustomDescriptor.
> Proposal 2: Have a property Custom, and then access the descriptor as
> Attributes.
> 
I would go with Custom property. We can even set a numeric or even add the handle, as done for serives and characteristics, something like Custom0002, Custom 001a and so on, for supporting multiple custom characteristic descriptors.




> Thanks,
> Vijay
> 
> -----Original Message-----
> From: Ganir, Chen [mailto:chen.ganir@ti.com]
> Sent: Sunday, November 06, 2011 1:25 PM
> To: Vijaykumar Dadmode
> Cc: linux-bluetooth@vger.kernel.org
> Subject: RE: Proposal for GATT Client Dbus API.
> 
> Vijay,
> 
> 
> > -----Original Message-----
> > From: Vijaykumar Dadmode [mailto:Vijaykumar.Dadmode@csr.com]
> > Sent: Friday, November 04, 2011 2:46 PM
> > To: Ganir, Chen
> > Cc: linux-bluetooth@vger.kernel.org
> > Subject: RE: Proposal for GATT Client Dbus API.
> >
> > Hi Chen,
> > Thanks for your inputs. Please find my comments inline.
> >
> > > > Queries:
> > > > 1) As the "Signals" are a broadcast, how do we direct it to the
> > > > application which requests for it?
> > > We can use the existing watchers. At the moment, watchers are
> > registered to be called when indication/notification arrives from the
> >
> > > sever. This means that a watcher will receive ValueChanged message
> > with characteristic path and new value. We could use this >
> >interface
> > >and add the ReadRespnse and WriteResponse to it.
> >
> > So you mean we add the ReadResponse and WriteResponse to Watcher
> > Hierarchy?  , but what if we don't register the watcher and just want
> > to read/write?
> >
> > >>
> > >> +		void GetCharacteristicValue( )
> > >> +
> > >> +			Read the value of the characteristic.
> > >> +			This will emit a ReadResponse signal with
> status
> > >> code.
> >
> >
> > >When will this signal/message be sent ? Do we implement a timeout
> for
> > connection timeout ? Can we set it as a parameter to this message?
> >
> >
> > Method can be called when applications want to read the value on
> > server(active read).
> >
> This I understand.
> Since this is an async function, we must have some timeout, or
> mechanism to notify the user that we're either connected and fetching
> the value, and he should be expecting a ReadResponse anytime soon, or
> that we are not currently connected, and we will try a connection
> procedure to the server, which may take some time, or may even never
> end. Now that I think of it - maybe we also need
> CancelGetCharacteristicValue function, to remove a pending read value
> request - we do not want the ReadResponse event triggered if the
> connection is established after a few days for example.
> 
> > > > +
> > > > +		void SetCharacteristicValue(variant value, string
> method,
> > > uint16 offset)
> > > > +
> > > > +			Changes the value of the specified
> characteristic as
> > > > per the offset and method. Only
> > > > +			read-write characteristic value can be changed.
> > > What is this read-write char value you are referring to here ?
> >
> > Updated.
> >
> Same as above - we need to be able to cancel a set request, and we need
> some timeout to notify the user that the DBUS client has given up and
> will not try to set the value any more.
> 
> > > +			This will emit a WriteResponse signal with status
> > > code.
> > > Again, we need some timeout, to allow clean upper level
> > implementation.
> >
> > > +
> > > +			Write the value of the characreristic, with any of
> > > these specified method:
> > > +			"WriteWithResponse", "SignedWriteWithoutResponse",
> > > +			"WriteLongCharacteristicValue", "PrepareWrite",
> > > "ExecuteWrite".
> > > +
> > > +		void  ReadDescriptor(uint16 handle)
> > > +
> > > +			Read the value of the specified characteristic
> > > descriptor matching the handle.
> > > +			This will emit a ReadDescriptorResponse signal with
> > > status code.
> > > This will not go through. Handles should not be used by the users.
> In
> > fact, all descriptors can be turned into D-BUS dictionaries, >and be
> > available as characteristic properties. This is already done today
> for
> > some descriptors. However, not all of them should be >exposed
> directly
> > to user (client characteristic config descriptor for example can be
> > exposed as properties Notify and Indicate, server >char config
> > descriptor can be exposed as property Broadcast, and so on. Format is
> > already discovered and partially used in the >existing code.
> >
> > ReadDescriptor and WriteDescriptor we have added keeping "Custom"
> > descriptors (Optional Characteristic descriptor which
> > defines profile defined descriptor UUID's.)  in mind.
> > > +		dict Descriptors [readonly]
> >
> This custom descriptor is defined as an array of bytes with specific
> uuid. It can be reflected to the user as a property, which will be
> available if the server contains such a descriptor for the
> characteristic. This way, we can use the getproperty and setproperty,
> and hide all the irrelevant descriptor/handle logic from the user.
> 
> > So a property which contains a dict (mapping handle -> uuid) for
> > *all* descriptors (of course the properties for known descriptors
> > would still exist, but this generic read/write API would be used for
> > them as well).
> >
> This is wrong. This means that you duplicate the data - once in single
> flags (notify, indicate, user_defined) and once as a set of raw
> descriptor data. Again, I believe this should be hidden from the user,
> who does not need to handle descriptors and handles.
> 
> >
> >
> > > +
> > > +		void  WriteDescriptor(uint16 handle, array{byte} value)
> > > +
> > > +			Changes the value of the specified characteristic
> > > descriptor matching the handle. Only
> > > +			read-write descriptors can be changed.
> > > +			This will emit a WriteDescriptorResponse signal with
> > > status code.
> > > +
> > >  			Possible Errors: org.bluez.Error.InvalidArguments
> > >
> > > No use for this one - see above my previous comment.
> >
> > > +Signals		PropertyChanged(string name, variant value)
> > > +
> > > +			This signal indicates a changed value of the given
> > > +			property.
> > > +
> > > When will this be used? We already have readresponse,
> writeresponse.
> > Other properties are fixed, and read on connection > >automatically.
> We
> > will not need this. We can use this if we expose Notify, Indicate,
> > Broadcast properties. Writing to these properties >will cause the
> > propertychanged event to be called, once the write has completed, if
> > that's possible.
> >
> > Yes agree with adding Notify, Indicate, Broadcast as properties.
> >
> >
> >
> > > +		ReadResponse(uint8 status, variant value)
> > > +
> > > +			Parameter is the read value and status code for
> > > GetCharacteristicValue operation.
> > >We need to add the characteristic path as well. We may issue
> multiple
> > read requests, and receive them all after a while - we need to >be
> able
> > to understand which characteristic value we received.
> >
> > Agreed.
> >
> > > +
> > > +		WriteResponse(uint8 status)
> > > +
> > > +			Parameter is the status code for
> > > SetCharacteristicValue operation.
> > >Same as above - we need the characteristic path.
> >
> > Agreed.
> >
> > > +
> > > +
> > > +		ReadDescriptorResponse(uint8 status, variant value)
> > > +
> > > +			Parameter is the read value and status code for
> > > ReadDescriptor operation.
> > > +
> > > +		WriteDescriptorResponse(uint8 status)
> > > +
> > > +			Parameter is the status code for WriteDescriptor
> > > operation.
> > > +
> > >No need for this.
> >
> > Added keeping "Custom" descriptors in mind.
> >
> See above about custom descriptors.
> 
> 
> > >  Properties 	string UUID [readonly]
> > >
> > >  			UUID128 of this characteristic.
> > > @@ -121,12 +169,22 @@ Properties 	string UUID [readonly]
> > >  			Optional field containing a friendly name for the
> > >  			Characteristic UUID.
> > >
> > > +		array{string} Properties [readonly]
> > > +
> > > +			The characteristic properties includes extended
> > > properties if defined, format defined by GATT spec.
> > > +			Possible values representing each bit field:
> > > +			{ "Broadcast", "Read", "WriteWithoutResponse",
> > > "Write", "Notify", "Indicate", "AuthenticatedSignedWrite",
> > > 			"ExtentedProperties", "ReliableWrite",
> > > "WritableAuxiliaries"}
> > > +
> > >Properties which can be changed, such as Broadcast, Indicate, Notify
> > should be standalong, Boolean read/write properties. See above >for
> > more information on why we need these.
> >
> > Agreed. I think we can have this array plus for the simpler usage we
> > can add the r/w Broadcast, Indicate, Notify properties.
> >
> Why duplicate data again ? it is very confusing to have this
> information in two or more places. Writable properties should have
> their own representation, without duplication in this list.
> 
> > > +		uint16 ClientConfiguration [readwrite]
> > > +
> > > +			Optional field containing the client configuration
> > > value on the server.
> > > +
> > > We should not expose bit fields to the users. We can abstract this
> to
> > Notify/Indicate Boolean properties.
> >
> > Agreed
> >
> > >>  		string Description [readonly]
> > >>
> > >  			Textual optional characteristic descriptor describing
> > >  			the Characteristic Value.
> > >
> > > -		struct Format [readonly]
> > > +		array{struct} Format [readonly]
> > >
> > >  			Optional Characteristic descriptor which defines the
> > >  			format of the Characteristic Value. For numeric
> > > @@ -151,6 +209,11 @@ Properties 	string UUID [readonly]
> > >  			Friendly representation of the Characteristic Value
> > >  			based on the format attribute.
> > >
> > > This also needs to be simplified. We need to take the format
> strings
> > from the spec, and apply the correct properties according to the >
> > format descriptor. Again, we should not expose raw bit fields here.
> >
> > >> +		dict Descriptors [readonly]
> > >> +
> > >> +			The value is a dictionary for all
> Characteristic
> > >> descriptor with the handle as keys and the UUID as values.The key
> is
> > > 			uint16 and the value a string for this dictionary.
> > > Can be used with WriteDescriptor and ReadDescriptor.
> > > +		      These attribute handle is only valid during the
> > >> session, and should not be stored/cached by the client.
> > >> +
> > > See above. Not needed.
> > Explained part of ReadDescriptor.
> >
> See above why we should not expose raw descriptors to the user. We have
> the properties mechanism, which is what descriptors are all about.
> Simply translate the GATT descriptors into DBUS properties.
> 
> > Thanks,
> > Vijay
> >
> >
> >
> > Member of the CSR plc group of companies. CSR plc registered in
> England
> > and Wales, registered number 4187346, registered office Churchill
> > House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ,
> United
> > Kingdom
> > More information can be found at www.csr.com. Follow CSR on Twitter
> at
> > http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
> 
> 
> Vijay, can you send an updated proposal with the changes we've
> discussed, or should I send it ?
> 
> Thanks,
> Chen Ganir.
> Texas Instruments.
> 
> 
>  To report this email as spam click
> https://www.mailcontrol.com/sr/keBbNGaYv7HTndxI!oX7UsdpzMR7Bo2KP2imJfv6
> 99sbiy929P9Qs4lEOZpe1nNVJnoe!+NpOToakVWf!6zCig== .

Thanks,
Chen Ganir

Test Management interface for LE with latest kernel.

[Vijaykumar Dadmode]

Hi,
We were trying to test the BT LE scan/connect, using the MGMT_INTERFACE. I have enabled the enable_le && enable_mgmt in kernel. But I am seeing the below error. Could you please help me with the same? 

Error: " Too small mgmt_device_found event packet. "

Latest code:
Bluez: http://git.kernel.org/?p=bluetooth/bluez.git;a=summary 
Kernel: http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-next.git;a=summary 

Thanks,
Vijay


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

RE: Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

Hi Chen,
Below is the latest diff, with all the changes incorporated. Let me know your view. 

diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index 98d7f30..9dd8222 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -110,6 +110,20 @@ Methods		dict GetProperties()
 			read-write properties can be changed. On success
 			this will emit a PropertyChanged signal.
 
+		void GetCharacteristicValue(uint16 timeout)
+
+			Read the value of the characteristic with timeout value in seconds. 
+			This will emit a ReadResponse signal with status code.
+
+		void SetCharacteristicValue(variant value, string method, uint16 offset, uint16 timeout)
+
+			Changes the value of the specified characteristic as per the offset and method, with timeout value in seconds. 
+			This will emit a WriteResponse signal with status code.
+			
+			Write the value of the characreristic, with any of these specified method:
+			"WriteWithResponse", "SignedWriteWithoutResponse", 
+			"WriteLongCharacteristicValue", "PrepareWrite", "ExecuteWrite".
+
 			Possible Errors: org.bluez.Error.InvalidArguments
 
 Properties 	string UUID [readonly]
@@ -126,7 +140,41 @@ Properties 	string UUID [readonly]
 			Textual optional characteristic descriptor describing
 			the Characteristic Value.
 
+		boolean Broadcast [readwrite]
+
+		    	Indicates whether this characteristic is broadcasted or not.
+		    	If GATT Server Characteristic Configuration descriptor
+		    	is not available for this characteristic, or if the characteristic
+		    	properties do not allow this, writing to this property is not
+		    	allowed.
+
+		boolean Indicate [readwrite]
+
+		    	Indicates whether this characteristic is notified or not.
+		    	If GATT Client Characteristic Configuration descriptor
+		    	is not available for this characteristic, or if the characteristic
+		    	properties do not allow this, writing to this property is not
+		    	allowed.
+
+		boolean Notify [readwrite]
+
+		    	Indicates whether this characteristic is indicated or not.
+		    	If GATT Client Characteristic Configuration descriptor
+		    	is not available for this characteristic, or if the characteristic
+		    	properties do not allow this, writing to this property is not
+		    	allowed.
+
+		boolean Readable [readonly]
+
+		    	Indicates wether this characteristic value can be read.
+
+		array{string} WriteMethods [readonly]
+
+			Write methods supported by the characteristic, includes extended properties if defined, format defined by GATT spec. 
+			Possible values: 
+			{ "WriteWithoutResponse", "Write", "AuthenticatedSignedWrite", "ReliableWrite", "WritableAuxiliaries"}
+

-		struct Format [readonly]
+		array{struct} Format [readonly]
 
 			Optional Characteristic descriptor which defines the
 			format of the Characteristic Value. For numeric
@@ -142,6 +190,11 @@ Properties 	string UUID [readonly]
 			  uint16 | Description: Description of the characteristic defined
 			         | in a high layer profile.
 
+		array{object} CustomCharacteristicsDesc [readonly]
+
+			This list contains the user defined characteristics descriptors owned by this
+			specific characteristics.
+
 		array{byte} Value [readwrite]
 
 			Raw value of the Characteristic Value attribute.
@@ -162,3 +215,11 @@ Object path	freely definable
 Methods		void ValueChanged(object characteristic, array{byte})
 
 			New raw value of the Characteristic Value attribute.
+
+		void ReadResponse(object characteristic, uint8 status, variant value)
+
+			Value read and status code for Read Characteristic Value attribute operation. 
+
+		void WriteResponse(object characteristic, uint8 status)
+
+			Status code for Write Characteristic Value attribute opeartion.


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

RE: Proposal for GATT Client Dbus API.

[Ganir, Chen]

Vijay,

> -----Original Message-----
> From: Vijaykumar Dadmode [mailto:Vijaykumar.Dadmode@csr.com]
> Sent: Monday, November 07, 2011 3:35 PM
> To: Ganir, Chen
> Cc: linux-bluetooth@vger.kernel.org
> Subject: RE: Proposal for GATT Client Dbus API.
> 
> Hi Chen,
> Below is the latest diff, with all the changes incorporated. Let me
> know your view.
> 
> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
> index 98d7f30..9dd8222 100644
> --- a/doc/attribute-api.txt
> +++ b/doc/attribute-api.txt
> @@ -110,6 +110,20 @@ Methods		dict GetProperties()
>  			read-write properties can be changed. On success
>  			this will emit a PropertyChanged signal.
> 
> +		void GetCharacteristicValue(uint16 timeout)
> +
> +			Read the value of the characteristic with timeout
> value in seconds.
> +			This will emit a ReadResponse signal with status
> code.
The ReadResponse will be emitted on timeout as well ? Why do you call this GetCharacteriristicValue instead of ReadCharacteristicValue, as the GATT spec names this operation ?

> +
> +		void SetCharacteristicValue(variant value, string method,
> uint16 offset, uint16 timeout)
Why do you call this SetCharacteristicValue instead of WriteCharacteristic value (Write is defined in the GATT spec) ?

> +
> +			Changes the value of the specified characteristic as
> per the offset and method, with timeout value in seconds.
> +			This will emit a WriteResponse signal with status
> code.
> +
> +			Write the value of the characreristic, with any of
> these specified method:
> +			"WriteWithResponse", "SignedWriteWithoutResponse",
> +			"WriteLongCharacteristicValue", "PrepareWrite",
> "ExecuteWrite".
> +
>  			Possible Errors: org.bluez.Error.InvalidArguments
> 
>  Properties 	string UUID [readonly]
> @@ -126,7 +140,41 @@ Properties 	string UUID [readonly]
>  			Textual optional characteristic descriptor describing
>  			the Characteristic Value.
> 
> +		boolean Broadcast [readwrite]
> +
> +		    	Indicates whether this characteristic is broadcasted
> or not.
> +		    	If GATT Server Characteristic Configuration
> descriptor
> +		    	is not available for this characteristic, or if the
> characteristic
> +		    	properties do not allow this, writing to this
> property is not
> +		    	allowed.
> +
> +		boolean Indicate [readwrite]
> +
> +		    	Indicates whether this characteristic is notified or
> not.
> +		    	If GATT Client Characteristic Configuration
> descriptor
> +		    	is not available for this characteristic, or if the
> characteristic
> +		    	properties do not allow this, writing to this
> property is not
> +		    	allowed.
> +
> +		boolean Notify [readwrite]
> +
> +		    	Indicates whether this characteristic is indicated or
> not.
> +		    	If GATT Client Characteristic Configuration
> descriptor
> +		    	is not available for this characteristic, or if the
> characteristic
> +		    	properties do not allow this, writing to this
> property is not
> +		    	allowed.
> +
> +		boolean Readable [readonly]
> +
> +		    	Indicates wether this characteristic value can be
> read.
> +
> +		array{string} WriteMethods [readonly]
> +
> +			Write methods supported by the characteristic,
> includes extended properties if defined, format defined by GATT spec.
> +			Possible values:
> +			{ "WriteWithoutResponse", "Write",
> "AuthenticatedSignedWrite", "ReliableWrite", "WritableAuxiliaries"}
> +
> 
> -		struct Format [readonly]
> +		array{struct} Format [readonly]
> 
>  			Optional Characteristic descriptor which defines the
>  			format of the Characteristic Value. For numeric
> @@ -142,6 +190,11 @@ Properties 	string UUID [readonly]
>  			  uint16 | Description: Description of the
> characteristic defined
>  			         | in a high layer profile.
> 
> +		array{object} CustomCharacteristicsDesc [readonly]
> +
> +			This list contains the user defined characteristics
> descriptors owned by this
> +			specific characteristics.
> +
>  		array{byte} Value [readwrite]
> 
>  			Raw value of the Characteristic Value attribute.
We should be perfectly clear here, that this is the last known value. It may be wrong, and GetCharacteristicValue should be used to get the latest value. We also should make sure that setting this property will use the Bluez preferred way of writing this characteristic, according to the supported permissions and properties. In addition, ValueChanged will be emitted is the value is actually written and a success was returned from the server. GetProperty on this property will get the current value, and a gatt_read command will be issued, emitting a ValueChanged event if the value is different when the read is complete and the value is different than what was initially returned.


> @@ -162,3 +215,11 @@ Object path	freely definable
>  Methods		void ValueChanged(object characteristic, array{byte})
> 
>  			New raw value of the Characteristic Value attribute.
This will be sent in one of the following scenarios :
1. Value was notified/indicated by the server
2. Value was read using the GetProperty, and the updated value received from the server was different than the one provided as the GetProperty result.


> +
> +		void ReadResponse(object characteristic, uint8 status,
> variant value)
> +
> +			Value read and status code for Read Characteristic
> Value attribute operation.
> +
> +		void WriteResponse(object characteristic, uint8 status)
> +
> +			Status code for Write Characteristic Value attribute
> opeartion.
> 
This one will be used only when using Write operations which have a response. Write command for example will not emit this signal, and it is the responsibility of the client to make sure (by reading the value) that the value was actually set correctly.

> 
> Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill
> House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United
> Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at
> http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

I think this is ok. I don't see any big issues with this one.



Best regards,
Chen Ganir
Texas Instruments.

RE: Proposal for GATT Client Dbus API.

[Vijaykumar Dadmode]

Hi All,
Below is the updated proposal with all your valuable feedback. Could you please let me know your inputs for the same? 

diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index 98d7f30..a6b79c9 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -110,6 +110,20 @@ Methods		dict GetProperties()
 			read-write properties can be changed. On success
 			this will emit a PropertyChanged signal.
 
+		void ReadCharacteristicValue(uint16 timeout)
+
+			Read the value of the characteristic with timeout value. 
+			This will emit a ReadResponse signal with status code.
+
+		void WriteCharacteristicValue(variant value, string method, uint16 offset, uint16 timeout)
+
+			Changes the value of the specified characteristic as per the offset and method, with timeout value. 
+			This will emit a WriteResponse signal with status code.
+			
+			Write the value of the characreristic, with any of these specified method:
+			"WriteWithResponse", "SignedWriteWithoutResponse", 
+			"WriteLongCharacteristicValue", "PrepareWrite", "ExecuteWrite".
+
 			Possible Errors: org.bluez.Error.InvalidArguments
 
 Properties 	string UUID [readonly]
@@ -121,12 +135,46 @@ Properties 	string UUID [readonly]
 			Optional field containing a friendly name for the
 			Characteristic UUID.
 
+		boolean Broadcast [readwrite]
+
+		    	Indicates whether this characteristic is broadcasted or not.
+		    	If GATT Server Characteristic Configuration descriptor
+		    	is not available for this characteristic, or if the characteristic
+		    	properties do not allow this, writing to this property is not
+		    	allowed.
+
+		boolean Indicate [readwrite]
+
+		    	Indicates whether this characteristic is indicated or not.
+		    	If GATT Client Characteristic Configuration descriptor
+		    	is not available for this characteristic, or if the characteristic
+		    	properties do not allow this, writing to this property is not
+		    	allowed.
+
+		boolean Notify [readwrite]
+
+		    	Indicates whether this characteristic is notified or not.
+		    	If GATT Client Characteristic Configuration descriptor
+		    	is not available for this characteristic, or if the characteristic
+		    	properties do not allow this, writing to this property is not
+		    	allowed.
+
+		boolean Readable [readonly]
+
+		    	Indicates wether this characteristic value can be read.
+
+		array{string} WriteMethods [readonly]
+
+			Write methods supported by the characteristic, includes extended properties if defined, format defined by GATT spec. 
+			Possible values: 
+			{ "WriteWithoutResponse", "Write", "AuthenticatedSignedWrite", "ReliableWrite", "WritableAuxiliaries"}
+
 		string Description [readonly]
 
 			Textual optional characteristic descriptor describing
 			the Characteristic Value.
 
-		struct Format [readonly]
+		array{struct} Format [readonly]
 
 			Optional Characteristic descriptor which defines the
 			format of the Characteristic Value. For numeric
@@ -144,13 +192,17 @@ Properties 	string UUID [readonly]
 
 		array{byte} Value [readwrite]
 
-			Raw value of the Characteristic Value attribute.
+			The last known raw value of the Characteristic Value attribute. ReadCharacteristicValue should be used to get the 			latest value from the server.
 
 		string Representation (of the binary Value) [readonly]
 
 			Friendly representation of the Characteristic Value
 			based on the format attribute.
 
+		array{object} CustomCharacteristicsDesc [readonly]
+
+			This list contains the user defined characteristics descriptors owned by this
+			specific characteristics, access the descriptor as attributes.
 
 Characteristic Watcher hierarchy
 ===============================
@@ -161,4 +213,14 @@ Object path	freely definable
 
 Methods		void ValueChanged(object characteristic, array{byte})
 
-			New raw value of the Characteristic Value attribute.
+			New raw value of the Characteristic Value attribute. This will be sent in one of the following scenarios :
+			Value was notified/indicated by the server.
+			Value was read using the GetProperty, and the updated value received from the server was different than the one 				provided as the GetProperty result.
+
+		void ReadResponse(object characteristic, uint8 status, variant value)
+
+			Value read and status code for Read Characteristic Value attribute operation. 
+
+		void WriteResponse(object characteristic, uint8 status)
+
+			Status code for Write Characteristic Value attribute opeartion. Should be used only when using Write operations which +			have a response. Write command will not emit this signal, it is the responsibility of the client to make sure (by 				reading the value) that the value was actually set correctly.


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

Re: Proposal for GATT Client Dbus API.

[Luiz Augusto von Dentz]

Hi,

On Mon, Nov 7, 2011 at 3:35 PM, Vijaykumar Dadmode
<Vijaykumar.Dadmode@csr.com> wrote:
> Hi Chen,
> Below is the latest diff, with all the changes incorporated. Let me know your view.
>
> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
> index 98d7f30..9dd8222 100644
> --- a/doc/attribute-api.txt
> +++ b/doc/attribute-api.txt
> @@ -110,6 +110,20 @@ Methods            dict GetProperties()
>                        read-write properties can be changed. On success
>                        this will emit a PropertyChanged signal.
>
> +               void GetCharacteristicValue(uint16 timeout)

The interface name already is org.bluez.Characteristic so we really
need Characteristic again.

> +                       Read the value of the characteristic with timeout value in seconds.
> +                       This will emit a ReadResponse signal with status code.

Why you don't return an error? Signals are not that great here, you
also want to track the caller so that if it exit you cancel the
operation.

> +               void SetCharacteristicValue(variant value, string method, uint16 offset, uint16 timeout)
> +
> +                       Changes the value of the specified characteristic as per the offset and method, with timeout value in seconds.
> +                       This will emit a WriteResponse signal with status code.
> +
> +                       Write the value of the characreristic, with any of these specified method:
> +                       "WriteWithResponse", "SignedWriteWithoutResponse",
> +                       "WriteLongCharacteristicValue", "PrepareWrite", "ExecuteWrite".
> +

Same here, signals are useful for async events not for response, also
you are mixing terminology of set/get with read/write, either use one
or the other.

>                        Possible Errors: org.bluez.Error.InvalidArguments
>
>  Properties     string UUID [readonly]
> @@ -126,7 +140,41 @@ Properties         string UUID [readonly]
>                        Textual optional characteristic descriptor describing
>                        the Characteristic Value.
>
> +               boolean Broadcast [readwrite]
> +
> +                       Indicates whether this characteristic is broadcasted or not.
> +                       If GATT Server Characteristic Configuration descriptor
> +                       is not available for this characteristic, or if the characteristic
> +                       properties do not allow this, writing to this property is not
> +                       allowed.
> +
> +               boolean Indicate [readwrite]
> +
> +                       Indicates whether this characteristic is notified or not.
> +                       If GATT Client Characteristic Configuration descriptor
> +                       is not available for this characteristic, or if the characteristic
> +                       properties do not allow this, writing to this property is not
> +                       allowed.
> +
> +               boolean Notify [readwrite]
> +
> +                       Indicates whether this characteristic is indicated or not.
> +                       If GATT Client Characteristic Configuration descriptor
> +                       is not available for this characteristic, or if the characteristic
> +                       properties do not allow this, writing to this property is not
> +                       allowed.
> +
> +               boolean Readable [readonly]
> +
> +                       Indicates wether this characteristic value can be read.
> +
> +               array{string} WriteMethods [readonly]
> +
> +                       Write methods supported by the characteristic, includes extended properties if defined, format defined by GATT spec.
> +                       Possible values:
> +                       { "WriteWithoutResponse", "Write", "AuthenticatedSignedWrite", "ReliableWrite", "WritableAuxiliaries"}
> +
>
> -               struct Format [readonly]
> +               array{struct} Format [readonly]
>
>                        Optional Characteristic descriptor which defines the
>                        format of the Characteristic Value. For numeric
> @@ -142,6 +190,11 @@ Properties         string UUID [readonly]
>                          uint16 | Description: Description of the characteristic defined
>                                 | in a high layer profile.
>
> +               array{object} CustomCharacteristicsDesc [readonly]
> +
> +                       This list contains the user defined characteristics descriptors owned by this
> +                       specific characteristics.
> +
>                array{byte} Value [readwrite]
>
>                        Raw value of the Characteristic Value attribute.
> @@ -162,3 +215,11 @@ Object path        freely definable
>  Methods                void ValueChanged(object characteristic, array{byte})
>
>                        New raw value of the Characteristic Value attribute.
> +
> +               void ReadResponse(object characteristic, uint8 status, variant value)
> +
> +                       Value read and status code for Read Characteristic Value attribute operation.
> +
> +               void WriteResponse(object characteristic, uint8 status)
> +
> +                       Status code for Write Characteristic Value attribute opeartion.



-- 
Luiz Augusto von Dentz