[Interest] BLE: reading a characteristic

[Mario Ribeiro]

Awesome, thanks for reporting. Looking forward to see this available on
Qt5.5 :)

On 6 March 2015 at 12:18, Blasche Alexander <
alexander.blasche at theqtcompany.com> wrote:

>  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> wrote:
>
>>
>>
>>   --
>>
>> Alex
>>   ------------------------------
>> Hi,
>>
>> *From:* Mario Ribeiro <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
>



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