[Interest] BLE: reading a characteristic

[Blasche Alexander]

Indeed the RTC use case is convincing. Notifications don't make sense and its read-only anyway.

This requires a small API addition:


https://bugreports.qt.io/browse/QTBUG-44841


--

Alex

________________________________
From: Mario Ribeiro <mario.ribas at gmail.com>
Sent: Friday, March 6, 2015 12:33
To: Blasche Alexander
Cc: interest at qt-project.org
Subject: Re: [Interest] BLE: reading a characteristic

?Hi again,

Thanks for the prompt reply!?


On 6 March 2015 at 08:24, Blasche Alexander <alexander.blasche at theqtcompany.com<mailto:alexander.blasche at theqtcompany.com>> wrote:



--

Alex

________________________________
Hi,

From: Mario Ribeiro <mario.ribas at gmail.com<mailto:mario.ribas at gmail.com>>
>However, the thing with readings, and according to documentation, is that the value is cached and is only >updated after service's details discovery, a successful write operation or change notification.


>I'm discovering all services as the app starts so all of them will be on state ServiceDiscovered

> after a while. But then, how can I update the cached value of characteristics?


There is no way to trigger such a reread at this point in time. It could be added for 5.5 but the question really is why this would be necessary. Maybe you can provide the use case for it.

?Several BLE services require the READ operation to be available (at the peripheral's level). Some examples:?
?
?Alert Notification Service - https://developer.bluetooth.org/TechnologyOverview/Pages/ANS.aspx
Battery Service - https://developer.bluetooth.org/TechnologyOverview/Pages/BAS.aspx?

In addition to that, and in our case, we have a Real-Time Clock (RTC) embedded in our device that we need to read at specific circumstances.


In general I would assume that if you have a characteristic with changing value (such as a sensor value)

that it would advertise those changes via a change notification. Subsequently you would have to ensure that your device attaches the Notify or Indicate property to the characteristic in question and provide the

required ClientCharacteristicConfiguration.


After all a select() statement is usually much better than busy polling.


?Indeed we have some characteristics that use the notify or indicate properties. But considering the RTC or battery level again, we just need to read their values very sporadically upon central device's request. A workaround would be to write to a characteristic and receive a notification as a response, but after all thats the READ operation purpose.

What you think?




>I attempted to re-discover the service's details before trying to read a characteristic belonging to it but I >don't get an updated value (and my BLE peripheral - which I'm developing so I have access do debugging >utilities - receives nothing).

>Any suggestion?


Indeed this won't work at this point in time. QLowEnergyService::discoverDetails() has the following code


if (d->state != QLowEnergyService::DiscoveryRequired)
   return;


This means the rediscover doesn't even start.


--
Mário Ribeiro



--
Mário Ribeiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150306/ae4efcd0/attachment.html>