Re: d-bus or management api for beacon stuff

[Barry Byford <31baz66@gmail.com>]

Hello Don,


On 28 November 2016 at 20:55, Don Zickus <dzickus@redhat.com> wrote:
> On Thu, Nov 24, 2016 at 03:07:21PM +0200, Luiz Augusto von Dentz wrote:
>> Hi Don,
>>
>> On Wed, Nov 23, 2016 at 11:40 PM, Don Zickus <dzickus@redhat.com> wrote:
>> > 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.
>>
>> > 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.
>
>
>>
>> > 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