Awesome, thanks for reporting. Looking forward to see this available on Qt5.5 :)
On 6 March 2015 at 12:18, Blasche Alexander < alexander.blas...@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.ri...@gmail.com> > *Sent:* Friday, March 6, 2015 12:33 > *To:* Blasche Alexander > *Cc:* interest@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.blas...@theqtcompany.com> wrote: > >> >> >> -- >> >> Alex >> ------------------------------ >> Hi, >> >> *From:* Mario Ribeiro <mario.ri...@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
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
