Hello Johan, On 6 February 2016 at 20:34, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi, > > On Sat, Feb 06, 2016, Johan Hedberg wrote: >> On Sat, Feb 06, 2016, Barry Byford wrote: >> > I'm still having problems with getting information from beacons using >> > the DBus API. Using the DBus API is generally working well. But if >> > there are devices that are advertising in 'broadcast' mode then I >> > can't seem to get the service data being broadcast by the beacon. >> > >> > Following on from discussions had before >> > (http://thread.gmane.org/gmane.linux.bluez.kernel/65201/focus=65263) >> > I've experimented with Bluez 5.36 and 5.37. >> > I've compiled the above versions with --enable-experimental and >> > --enable-maintainer-mode and have the bluetoothd running with -E >> > >> > Linux kernel: >> > $ uname -a >> > Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 >> > armv6l GNU/Linux >> > >> > I have various beacons around and also have got another Raspberry Pi >> > broadcasting an Eddystone URL using the Bluez DBus API. All of these >> > beacons can be seen fine by various apps on my phone. >> > The code for the advertiser using DBus API can be found at: >> > https://github.com/ukBaz/python-bluezero/blob/master/examples/eddystone-url-beacon.py >> > which can be run with: >> > python eddystone-url-beacon.py http://www.bluez.org/ >> > >> > To do the scanning for the beacons I'm using either bluetoothctl or >> > using the test/test-discovery script in the Bluez download. >> > >> > Any help or suggestions as to what I'm doing wrong would be appreciated. >> >> According to doc/device-api.txt the corresponding device objects should >> exhibit a ServiceData property on their Device1 interface. Greping for >> "ServiceData" in the sources seems to indicate that at least the "info" >> command in bluetoothctl should be able to show this. > > Or is the problem that device objects do not get created at all for the > broadcasting devices? Right now bluetoothd requires the advertising data > to have the discoverable flag set in order for new device objects to be > created. It also looks like the Advertising D-Bus interface doesn't add > that to the advertising data unless the "peripheral" type is used. This > doesn't seem right to me since "broadcaster" should also be allowed to > set the flag (imo). So some change to the Advertising D-Bus API might be > needed. There's a lot of speculation in the above though, so it'd be > good if you could confirm if any of it is correct. > > Johan Thanks for the follow up post. I was in the middle of writing back to your previous one. Your speculation seems to be consistent with what I'm observing. e.g. 'peripheral' is creating devices but 'broadcaster' is not creating a device so I can't query it with info. Regards, Barry -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
