Re: How BLE services could be remembered?

["José Bollo" <jose.bollo@iot.bzh>]

Hi all,

Using the commit c64b4d9e8dc3e36672061f39a9dba19ad0fb1ef1, the issue
is sloved. Great! Thank you.

But my issue was also related to the fact that 'connected' was
received before availability of the attributes/services. The code was
disconnecting with the effect that not attributes/services coulded be
discovered.

Should I that the variable "ServicesResolved" is intended to reflect
the service resolution state? How long should I wait after being
connected for the ServiceResolved Status? Is there a way to know that
service resolution is in progress?

Best regards
Jos=C3=A9 Bollo
Jos=C3=A9 Bollo - Senior Software Engineer
www.iot.bzh



2016-12-09 14:15 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
> Hi Jose,
>
> On Fri, Dec 9, 2016 at 1:14 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wrot=
e:
>> Hi Luiz,
>>
>> 2016-12-09 10:43 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>=
:
>>> Hi Jose,
>>>
>>> On Thu, Dec 8, 2016 at 4:40 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wr=
ote:
>>>> Hello,
>>>>
>>>> I observe a strange behaviour of bluez dbus interface.
>>>>
>>>> I'm using Cinolink BT 4.0 USB Adapter (CSR BC8510 chipset), Bluez 5.43
>>>> on debian and/or on fedora.
>>>>
>>>> When I first pair a BLE device, the services are correctly discovered
>>>> and the GATT endpoints are created (a lot).
>>>>
>>>> Then I can use it as expected and it is nice. But when I turn off the
>>>> computer and restart it, things become different.
>>>>
>>>> Because the devices are paired with LT key, they are still paired but
>>>> the GATT services are not availables. I can connect to the device but
>>>> it doesn't declares the GATT properties/attributes that I need. Also,
>>>> the service advertises itself without effect.
>>>
>>> The attributes should be saved in cache but they are only reloaded on
>>> demand once a connection happens. Also if the database changes the
>>> cache can be invalidated removing its attributes, this has been
>>> changed so premature disconnections don't cause that anymore but in
>>> case the database do actually change their attributes will be
>>> invalidated. So if your device is known to cause premature disconnects
>>> please try with upstream version.
>>
>> That is probably the case, the device disconnects itself after a
>> transaction. Its designer made it to improve battery life.
>>
>> The attribute stay available by DBUS until next restart.
>>
>> I'll try the upstream version and check whether attribute are
>> available after a restart.
>>
>> (snip)
>>
>>> ConnectService? You mean Connect/ConnectProfile, those can be used in
>>> case you want to force an active scanning + connect procedure,
>>> otherwise the device shall be reconnected using passive scanning.
>>
>> Yes I meant ConnectProfile.
>>
>> Is it preferable to use ConnectProfile instead of Connect when only
>> one profile is expected?
>> The device is always advertising. I think that I have to connect
>> explicitly because the connection is not automatic.
>
> Actually in this case it should just reconnect if the device is
> advertising, so you should need to use either ConnectProfile or
> Connect, actually ConnectProfile doesn't work for LE since the
> profiles need GATT to be connected first and anyway the way the LE
> works is that the peripheral would advertise so perhaps what is
> missing is that you register an application implementing GattProfile1
> interface that way bluetoothd can tell there is an application trying
> to use the profile see:
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt
>
> --
> Luiz Augusto von Dentz