Re: d-bus or management api for beacon stuff

Hello Don,


On 28 November 2016 at 20:55, Don Zickus [off-list ref] wrote:

On Thu, Nov 24, 2016 at 03:07:21PM +0200, Luiz Augusto von Dentz wrote:

quoted

Hi Don,

On Wed, Nov 23, 2016 at 11:40 PM, Don Zickus [off-list ref] wrote:

quoted

Hi,

I was trying to write some code to continuously scan the bluetooth field
for bluetooth devices sending advertising packets (ie beacon-mode).

That is tricky, if you have anyone else trying to use the adapter in
this situation it will probably be blocked, we may add support for
setting intervals but that will probably be a best effort in case
there is no connection or other usage of the adapter by the system.

quoted

These devices would come and go so I wanted to avoid the cache.

Beacon are not normally not connectable, connections and continuous
advertisement don't go well together so we will probably have to
reduce the intervals in order to maintain any traffic on the
connections.

Hi Luiz,

Thanks for the response.  I am wondering if I explained it wrong.  I wasn't
looking to do advertisements but instead scan for advertisements.  I also
don't plan to connect to any of the advertising device, just read the
advertised data.

quoted

quoted

I noticed the D-Bus interface doesn't quite allow me to do this (as it
caches the devices and I can't monitor the RSSI field).  But I think the
bluetooth management interface does. Is that the correct approach?

Yep you could in theory use the MGMT interface and manually add you
beacon management on top, but I guess you don't want applications to
do that since it would require root permissions to connect to the
management socket, so making bluetoothd, via kernel?, to adjust the
intervals is probably a better idea in the long run. We would probably
have to maintain the biggest advertising window possible, and the
consider:

1.  Is it connectable/there any advertising instance that is
connectable? If yes, the it has to adjust the window to allow them
(perhaps using the default connection parameters).
2.  In case of a connection is made the controller may not be able to
advertise anymore, and in case it can still advertise we need to make
sure it doesn't interrupt the connection (this is not very clear if
the controller is suppose to manage this somehow).
3. Similar to the connection situation we may have application
scanning, again there might be problems if the controller cannot scan
while advertising we would probably have to stop advertising.

Hmm, as I said above, I am wondering if I explained it wrong.

I was wondering how much was already done because in reality, I was just
going to mimic what android does on the phones with apple ibeacons except my
machines stay put and the ibeacons travel.

Currently I was using 'hcitool lescan --duplicates' and 'hcidump' and trying
to script that.  But wanted to be smarter. :-)

I am planning on doing a similar application as you describe and
understood that you should be able to do much of what you want with
the dbus API.
Have you taken a look at adapter/StartDiscovery?
It is documented at
git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/adapter-api.txt#n12
You would then monitor the PropertiesChanged signal on the system dbus.

SetDiscoveryFilter might also be necessary/helpful.

Regards,
Barry

Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html