[PATCH 1/2] device: LastSeen property for D-Bus interface

[PATCH 1/2] device: LastSeen property for D-Bus interface

[andrey.zheregelya]

From: Andrey Zheregelya <andrey.zheregelya@dsr-company.com>

It returns le_seen or bredr_seen to caller. Marked as experimental.
Can be used to detect if device is still reachable.
---
 src/device.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/src/device.c b/src/device.c
index 264d599..7fe4d32 100644
--- a/src/device.c
+++ b/src/device.c
@@ -937,6 +937,17 @@ static gboolean dev_property_get_tx_power(const GDBusPropertyTable *property,
 	return TRUE;
 }
 
+static gboolean dev_property_get_last_seen(const GDBusPropertyTable *property,
+					DBusMessageIter *iter, void *data)
+{
+	struct btd_device *dev = data;
+	dbus_int64_t val = (dev->bredr_seen > dev->le_seen) ? dev->bredr_seen : dev->le_seen;
+
+	dbus_message_iter_append_basic(iter, DBUS_TYPE_INT64, &val);
+
+	return TRUE;
+}
+
 static gboolean dev_property_exists_tx_power(const GDBusPropertyTable *property,
 								void *data)
 {
@@ -2529,6 +2540,8 @@ static const GDBusPropertyTable device_properties[] = {
 	{ "TxPower", "n", dev_property_get_tx_power, NULL,
 					dev_property_exists_tx_power },
 	{ "ServicesResolved", "b", dev_property_get_svc_resolved, NULL, NULL },
+	{ "LastSeen", "x", dev_property_get_last_seen, NULL, NULL,
+					G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
 
 	{ }
 };
-- 
2.9.2

[PATCH 2/2] doc/device-api.txt Information about D-Bus LastSeen property

[andrey.zheregelya]

From: Andrey Zheregelya <andrey.zheregelya@dsr-company.com>

---
 doc/device-api.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/doc/device-api.txt b/doc/device-api.txt
index 087efb9..6387a0c 100644
--- a/doc/device-api.txt
+++ b/doc/device-api.txt
@@ -216,3 +216,11 @@ Properties	string Address [readonly]
 
 			Indicate whether or not service discovery has been
 			resolved.
+
+    bool LastSeen [readonly, experimantal]
+
+      Unix time of last found device update. 
+      Indicates if device is alive and reachable.
+      Adapter should be in discovery mode.
+      Information about device's reachability is based
+      on advertisement packets.
-- 
2.9.2

Re: [PATCH 2/2] doc/device-api.txt Information about D-Bus LastSeen property

[Bastien Nocera]

On Tue, 2016-08-02 at 18:40 +0300, andrey.zheregelya@dsr-company.com
wrote:
> From: Andrey Zheregelya <andrey.zheregelya@dsr-company.com>
> 
> ---
>  doc/device-api.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/device-api.txt b/doc/device-api.txt
> index 087efb9..6387a0c 100644
> --- a/doc/device-api.txt
> +++ b/doc/device-api.txt
> @@ -216,3 +216,11 @@ Properties	string Address [readonly]
>  
>  			Indicate whether or not service discovery
> has been
>  			resolved.
> +
> +    bool LastSeen [readonly, experimantal]
> +
> +      Unix time of last found device update. 
> +      Indicates if device is alive and reachable.

It's doesn't, really, until you apply heuristics to it. How do you plan
to use this?

> +      Adapter should be in discovery mode.
> +      Information about device's reachability is based
> +      on advertisement packets.

Re: [PATCH 2/2] doc/device-api.txt Information about D-Bus LastSeen property

[Andrey Zheregelya]

On 02.08.2016 18:57, Bastien Nocera wrote:

> It's doesn't, really, until you apply heuristics to it. How do you plan
> to use this?

Initially, there is a requirement for application to detect if a list of 
device are available for connection or not. Before connection and after.

As far as I understood, d-bus interface doesn't provide any way to 
detect if device is advertising or not.

le_seen and bredr_seen provides the last time when device's 
advertisement packet was detected (Of course if my understanding is correct)

Application can read LastSeen time, read current time and compare with 
application-defined timeout to make a decision if device is alive.

Yes, this property doesn't answer to direct question "Alive or not". But 
in this way user can apply any heuristic algorithm he wants.

And this approach doesn't require any BLE connections to device.

-- 
Best regards,
Andrey Zheregelya

Re: [PATCH 2/2] doc/device-api.txt Information about D-Bus LastSeen property

[Luiz Augusto von Dentz]

Hi Andrey,

On Tue, Aug 2, 2016 at 7:55 PM, Andrey Zheregelya
<andrey.zheregelya@dsr-company.com> wrote:
>
>
> On 02.08.2016 18:57, Bastien Nocera wrote:
>
>> It's doesn't, really, until you apply heuristics to it. How do you plan
>> to use this?
>
>
> Initially, there is a requirement for application to detect if a list of
> device are available for connection or not. Before connection and after.
>
> As far as I understood, d-bus interface doesn't provide any way to detect if
> device is advertising or not.
>
> le_seen and bredr_seen provides the last time when device's advertisement
> packet was detected (Of course if my understanding is correct)
>
> Application can read LastSeen time, read current time and compare with
> application-defined timeout to make a decision if device is alive.
>
> Yes, this property doesn't answer to direct question "Alive or not". But in
> this way user can apply any heuristic algorithm he wants.
>
> And this approach doesn't require any BLE connections to device.

But can't you use the last time you received a RSSI from the device?
Just timestamp it in the application side, in the other hand if
duplicate filtering is active this won't update in every packet
received since the controller can omit them.

-- 
Luiz Augusto von Dentz

Re: [PATCH 2/2] doc/device-api.txt Information about D-Bus LastSeen property

[Andrey Zheregelya]

Hi Luiz,

On 03.08.2016 12:48, Luiz Augusto von Dentz wrote:
> Hi Andrey,
>
> On Tue, Aug 2, 2016 at 7:55 PM, Andrey Zheregelya
> <andrey.zheregelya@dsr-company.com> wrote:
>>
>>
>> On 02.08.2016 18:57, Bastien Nocera wrote:
>>
>>> It's doesn't, really, until you apply heuristics to it. How do you plan
>>> to use this?
>>
>>
>> Initially, there is a requirement for application to detect if a list of
>> device are available for connection or not. Before connection and after.
>>
>> As far as I understood, d-bus interface doesn't provide any way to detect if
>> device is advertising or not.
>>
>> le_seen and bredr_seen provides the last time when device's advertisement
>> packet was detected (Of course if my understanding is correct)
>>
>> Application can read LastSeen time, read current time and compare with
>> application-defined timeout to make a decision if device is alive.
>>
>> Yes, this property doesn't answer to direct question "Alive or not". But in
>> this way user can apply any heuristic algorithm he wants.
>>
>> And this approach doesn't require any BLE connections to device.
>
> But can't you use the last time you received a RSSI from the device?
> Just timestamp it in the application side, in the other hand if
> duplicate filtering is active this won't update in every packet
> received since the controller can omit them.
>

Do you mean processing of PropertyChanged event for RSSI property?
If so, this means that GLib main loop should be used to process events. 
Correct me if I'm wrong.
But application may has its own scheduler with a requirement not to use 
Glib related schedule logic.

Offtopic:
Luiz, do you mean device_merge_duplicate function when mentioned about 
duplicate filtering? How does it affect to RSSI updates?

-- 
Best regards, Andrey Zheregelya

Re: [PATCH 2/2] doc/device-api.txt Information about D-Bus LastSeen property

[Luiz Augusto von Dentz]

Hi Andrey,

On Wed, Aug 3, 2016 at 3:32 PM, Andrey Zheregelya
<andrey.zheregelya@dsr-company.com> wrote:
> Hi Luiz,
>
> On 03.08.2016 12:48, Luiz Augusto von Dentz wrote:
>>
>> Hi Andrey,
>>
>> On Tue, Aug 2, 2016 at 7:55 PM, Andrey Zheregelya
>> <andrey.zheregelya@dsr-company.com> wrote:
>>>
>>>
>>>
>>> On 02.08.2016 18:57, Bastien Nocera wrote:
>>>
>>>> It's doesn't, really, until you apply heuristics to it. How do you plan
>>>> to use this?
>>>
>>>
>>>
>>> Initially, there is a requirement for application to detect if a list of
>>> device are available for connection or not. Before connection and after.
>>>
>>> As far as I understood, d-bus interface doesn't provide any way to detect
>>> if
>>> device is advertising or not.
>>>
>>> le_seen and bredr_seen provides the last time when device's advertisement
>>> packet was detected (Of course if my understanding is correct)
>>>
>>> Application can read LastSeen time, read current time and compare with
>>> application-defined timeout to make a decision if device is alive.
>>>
>>> Yes, this property doesn't answer to direct question "Alive or not". But
>>> in
>>> this way user can apply any heuristic algorithm he wants.
>>>
>>> And this approach doesn't require any BLE connections to device.
>>
>>
>> But can't you use the last time you received a RSSI from the device?
>> Just timestamp it in the application side, in the other hand if
>> duplicate filtering is active this won't update in every packet
>> received since the controller can omit them.
>>
>
> Do you mean processing of PropertyChanged event for RSSI property?
> If so, this means that GLib main loop should be used to process events.
> Correct me if I'm wrong.
> But application may has its own scheduler with a requirement not to use Glib
> related schedule logic.

It doesn't matter what binding the application will be using as soon
as it got PropertiesChanged with RSSI just generate a timestamp.

>
> Offtopic:
> Luiz, do you mean device_merge_duplicate function when mentioned about
> duplicate filtering? How does it affect to RSSI updates?

This is done in the controller, see the Bluetooth spec:

7.8.11 LE Set Scan Enable Command

The Filter_Duplicates parameter controls whether the Link Layer should filter
out duplicate advertising reports (Filtering_Enabled) to the Host, or
if the Link
Layer should generate advertising reports for each packet received
(Filtering_Disabled).

Filtering is enabled by default when doing StartDiscovery but you can
disable it with SetDiscoveryFilter, but be aware that this is very
spammy.

-- 
Luiz Augusto von Dentz