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<mailto:alexander.blas...@theqtcompany.com>> wrote: -- Alex ________________________________ Hi, From: Mario Ribeiro <mario.ri...@gmail.com<mailto: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
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
