Re: [BlueZ PATCH v1 1/3] doc: Add Advertisement Monitor Device Tracking event

Hi Manish,

can we please stop top-posting and follow the general rules of this mailing list.

The controller sends advertising reports in addition to this event. This event is reported only when there are active and matched advertisement monitors. 

Whenever an advertisement matches a Monitor, the controller sends this event with Monitor_state set to 1, indicating that it has started monitoring that particular device. After that it may send one or more advertising reports based on the configured Sampling_period for that Monitor. Once the controller stops monitoring that device, it sends the same event again with Monitor_state set to 0 to notify the host that it has stopped monitoring that particular device.

Since this event is sent only twice (at start and end of monitoring) per monitoring period [1], combining this with the Sampling_period - 0xFF (send only one advertisement report per monitoring period) [2], we can drastically reduce the number of events generated by the controller during background scanning but still have the DeviceFound/DeviceLost functionality in bluetoothd.

So, it will be better to keep this event separate than the Device Found event as it is triggered only during monitoring. Please let me know what you think about this.
[1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_device_event
[2]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_advertisement

This is what I was thinking:

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 97d33e30a15d..fa9121c3bc87 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt

@@ -4263,6 +4263,7 @@ Device Found Event
                1       Legacy Pairing
                2       Not Connectable
                3       Reserved (not in use)
+               4       Device Tracked
 
        For the RSSI field a value of 127 indicates that the RSSI is
        not available. That can happen with Bluetooth 1.1 and earlier

@@ -4910,3 +4911,19 @@ Controller Resume Event
        Address_Type. Otherwise, Address and Address_Type will both be zero.
 
        This event will be sent to all management sockets.
+
+Device Lost Event
+=================
+
+       Event Code:             0x002f
+       Controller Index:       <controller id>
+       Event Parameters:       Address (6 Octets)
+                               Address_Type (1 Octet)
+
+       This event indicates that a tracked device was no longer found
+       during monitoring.
+
+       Possible values for the Address_Type parameter:
+               0       BR/EDR
+               1       LE Public
+               2       LE Random

I really don’t get why we would make it more complicated for mgmt-api and thus bluetoothd.

Regards

Marcel