Additional Inherited Members

Detailed Description

The QLowEnergyService class represents an individual service on a Bluetooth Low Energy Device.

QLowEnergyService provides access to the details of Bluetooth Low Energy services. The class facilitates the discovery and publification of service details, permits reading and writing of the contained data and notifies about data changes.

Service Structure

A Bluetooth Low Energy peripheral device can contain multiple services. In turn each service may include further services. This class represents a single service of the peripheral device and is created via QLowEnergyController::createServiceObject(). The type() indicates whether this service is a primary (top-level) service or whether the service is part of another service. Each service may contain one or more characteristics and each characteristic may contain descriptors. The resulting structure may look like the following diagram:

A characteristic is the principle information carrier. It has a value() and properties() describing the access permissions for the value. The general purpose of the contained descriptor is to further define the nature of the characteristic. For example, it might specify how the value is meant to be interpreted or whether it can notify the value consumer about value changes.

Service Interaction

Once a service object was created for the first time, its details are yet to be discovered. This is indicated by its current state() being DiscoveryRequired. It is only possible to retrieve the serviceUuid() and serviceName().

The discovery of its included services, characteristics and descriptors is triggered when calling discoverDetails(). During the discovery the state() transitions from DiscoveryRequired via DiscoveringServices to its final ServiceDiscovered state. This transition is advertised via the stateChanged() signal. Once the details are known, all of the contained characteristics, descriptors and included services are known and can be read or written.

The values of characteristics and descriptors can be retrieved via QLowEnergyCharacteristic and QLowEnergyDescriptor, respectively. However, direct reading or writing of these attributes requires the service object. The readCharacteristic() function attempts to re-read the value of a characteristic. Although the initial service discovery may have obtained a value already this call may be required in cases where the characteristic value constantly changes without any notifications being provided. An example might be a time characteristic that provides a continuous value. If the read attempt is successful, the characteristicRead() signal is emitted. A failure to read the value triggers the CharacteristicReadError. The writeCharacteristic() function attempts to write a new value to the given characteristic. If the write attempt is successful, the characteristicWritten() signal is emitted. A failure to write triggers the CharacteristicWriteError. Reading and writing of descriptors follows the same pattern.

Every attempt is made to read or write the value of a descriptor or characteristic on the hardware. This means that meta information such as QLowEnergyCharacteristic::properties() is generally ignored when reading and writing. As an example, it is possible to call writeCharacteristic() despite the characteristic being read-only based on its meta data description. The resulting write request is forwarded to the connected device and it is up to the device to respond to the potentially invalid request. In this case the result is the emission of the CharacteristicWriteError in response to the returned device error. This behavior simplifies interaction with devices which report wrong meta information. If it was not possible to forward the request to the remote device the OperationError is set. A potential reason could be that the to-be-written characteristic object does not even belong the current service. In summary, the two types of errors permit a quick distinction of local and remote error cases.

All requests are serialised based on First-In First-Out principle. For example, issuing a second write request, before the previous write request has finished, is delayed until the first write request has finished.

Note: Currently, it is not possible to send signed write or reliable write requests.

The example shows a battery level characteristic which updates the central on every value change. The notifications are provided via the characteristicChanged() signal. More details about this mechanism are provided by the Bluetooth Specification.

Service Data Sharing

Each QLowEnergyService instance shares its internal states and information with other QLowEnergyService instance of the same service. If one instance initiates the discovery of the service details, all remaining instances automatically follow. Therefore the following snippet always works:

Member Type Documentation

enum QLowEnergyService::ServiceError

This enum describes all possible error conditions during the service's existence. The error() function returns the last occurred error.

Constant

Value

Description

QLowEnergyService::NoError

0

No error has occurred.

QLowEnergyService::OperationError

1

An operation was attempted while the service was not ready. An example might be the attempt to write to the service while it was not yet in the ServiceDiscoveredstate() or the service is invalid due to a loss of connection to the peripheral device.

QLowEnergyService::CharacteristicReadError

5

An attempt to read a characteristic value failed. For example, it might be triggered in response to a call to readCharacteristic(). This value was introduced by Qt 5.5.

QLowEnergyService::CharacteristicWriteError

2

An attempt to write a new value to a characteristic failed. For example, it might be triggered when attempting to write to a read-only characteristic.

QLowEnergyService::DescriptorReadError

6

An attempt to read a descriptor value failed. For example, it might be triggered in response to a call to readDescriptor(). This value was introduced by Qt 5.5.

QLowEnergyService::DescriptorWriteError

3

An attempt to write a new value to a descriptor failed. For example, it might be triggered when attempting to write to a read-only descriptor.

QLowEnergyService::UnknownError

4

An unknown error occurred when interacting with the service. This value was introduced by Qt 5.5.

enum QLowEnergyService::ServiceState

A service can become invalid when it looses the connection to the underlying device. Even though the connection may be lost it retains its last information. An invalid service cannot become valid anymore even if the connection to the device is re-established.

The service is a top-level/primary service. If this type flag is not set, the service is considered to be a secondary service. Each service may be included by another service which is indicated by IncludedService.

QLowEnergyService::IncludedService

0x0002

The service is included by another service. On some platforms, this flag cannot be determined until the service that includes the current service was discovered.

The ServiceTypes type is a typedef for QFlags<ServiceType>. It stores an OR combination of ServiceType values.

enum QLowEnergyService::WriteMode

This enum describes the mode to be used when writing a characteristic value. The characteristic advertises its supported write modes via its properties.

If a characteristic is written using this mode, the remote peripheral shall not send a write confirmation. The operation's success cannot be determined and the payload must not be longer than 20 bytes. A characteristic must have set the QLowEnergyCharacteristic::WriteNoResponse property to support this write mode. Its adavantage is a quicker write operation as it may happen in between other device interactions.

QLowEnergyService::WriteSigned

2

If a characteristic is written using this mode, the remote peripheral shall not send a write confirmation. The operation's success cannot be determined and the payload must not be longer than 8 bytes. A bond must exist between the two devices and the link must not be encrypted. A characteristic must have set the QLowEnergyCharacteristic::WriteSigned property to support this write mode. This value was introduced in Qt 5.7 and is currently only supported on Android and on Linux with BlueZ 5 and a kernel version 3.7 or newer.

If the associated controller object is in the central role, this signal is emitted when the value of characteristic is changed by an event on the peripheral. In that case, the signal emission implies that change notifications must have been activated via the characteristic's ClientCharacteristicConfiguration descriptor prior to the change event on the peripheral. More details on how this might be done can be found further above.

If the controller is in the peripheral role, that is, the service object was created via QLowEnergyController::addService, the signal is emitted when a GATT client has written the value of the characteristic using a write request or command.

The newValue parameter contains the updated value of the characteristic.

This signal is emitted when the read request for characteristic successfully returned its value. The signal might be triggered by calling characteristicRead(). If the read operation is not successful, the error() signal is emitted using the CharacteristicReadError flag.

This signal is emitted when the value of characteristic is successfully changed to newValue. The change must have been triggered by calling writeCharacteristic(). If the write operation is not successful, the error() signal is emitted using the CharacteristicWriteError flag.

Since this signal is an indication of a successful write operation newValue generally matches the value that was passed to the associated writeCharacteristic() call. However, it may happen that the two values differ from each other. This can occur in cases when the written value is used by the remote device to trigger an operation and it returns some other value via the written and/or change notification. Such cases are very specific to the target device. In any case, the reception of the written signal can still be considered as a sign that the target device received the to-be-written value.

This signal is emitted when the read request for descriptor successfully returned its value. The signal might be triggered by calling descriptorRead(). If the read operation is not successful, the error() signal is emitted using the DescriptorReadError flag.

This signal is emitted when the value of descriptor is successfully changed to newValue. If the associated controller object is in the central role, the change must have been caused by calling writeDescriptor(). Otherwise, the signal is the result of a write request or command from a GATT client to the respective descriptor.

Returns the UUIDs of all services which are included by the current service.

The returned list is empty if this service instance's discoverDetails() was not yet called or there are no known characteristics.

It is possible that an included service contains yet another service. Such second level includes have to be obtained via their relevant first level QLowEnergyService instance. Technically, this could create a circular dependency.

All descriptor and characteristic requests towards the same remote device are serialised. A queue is employed when issuing multiple requests at the same time. The queue does not eliminate duplicated read requests for the same characteristic.

All descriptor and characteristic requests towards the same remote device are serialised. A queue is employed when issuing multiple requests at the same time. The queue does not eliminate duplicated read requests for the same descriptor.

If the device's service was instantiated for the first time, the object's state is DiscoveryRequired. The state of all service objects which point to the same service on the peripheral device are always equal. This is caused by the shared nature of the internal object data. Therefore any service object instance created after the first one has a state equal to already existing instances.

A service becomes invalid if the QLowEnergyController disconnects from the remote device. An invalid service retains its internal state at the time of the disconnect event. This implies that once the service details are discovered they can even be retrieved from an invalid service. This permits scenarios where the device connection is established, the service details are retrieved and the device immediately disconnected to permit the next device to connect to the peripheral device.

However, under normal circumstances the connection should remain to avoid repeated discovery of services and their details. The discovery may take a while and the client can subscribe to ongoing change notifications.

All descriptor and characteristic write requests towards the same remote device are serialised. A queue is employed when issuing multiple write requests at the same time. The queue does not eliminate duplicated write requests for the same characteristic. For example, if the same descriptor is set to the value A and immediately afterwards to B, the two write request are executed in the given order.

Note: Currently, it is not possible to use signed or reliable writes as defined by the Bluetooth specification.

The call results in the value of the characteristic getting updated in the local database.

If a client is currently connected and it has enabled notifications or indications for the characteristic, the respective information will be sent. If a device has enabled notifications or indications for the characteristic and that device is currently not connected, but a bond exists between it and the local device, then the notification or indication will be sent on the next reconnection.

If there is a constraint on the length of the characteristic value and newValue does not adhere to that constraint, the behavior is unspecified.

Writes newValue as value for descriptor. The exact semantics depend on the role that the associated controller object is in.

Central role

A call to this function results in a write request to the remote device. If the operation is successful, the descriptorWritten() signal is emitted; otherwise the DescriptorWriteError is emitted.

All descriptor and characteristic requests towards the same remote device are serialised. A queue is employed when issuing multiple write requests at the same time. The queue does not eliminate duplicated write requests for the same descriptor. For example, if the same descriptor is set to the value A and immediately afterwards to B, the two write request are executed in the given order.