> On Sep 7, 2016, at 12:37 AM, Tobias Svehagen <tobias.svehagen@xxxxxxxxx> wrote: > > The property is not on the Adapter1 interface but it is found on the > Device1 interface. Also note that you have to check for every object > under /org/bluez/hci0 if that one is connected. I don't think there is > a way to see if an adapter is connected or not. Here is an example of > getting the Connected property of all the devices. <snip> Thank you very much, your code example worked nicely. Now I have additional questions of course. :) What is the difference between and adapter and device in the lingo here? I’m using a usb bluetooth dongle. Can I assume that that is an adapter? That if I had two dongles, I would have 2 adapters? But what then does the “device” represent? And why would I have more than one of them? Or is it just that they are arbitrarily named? The values shown don’t seem to correspond to the addr numbers I see when I run hciconfig. Running the code you graciously shared, I saw some interesting results. <reboot linux device> # ./connected (no output) <ble connect from iphone> # ./connected /org/bluez/hci0/dev_49_7C_73_51_21_1E Connected: 1 <terminate iOS app, should disconnect> # ./connected /org/bluez/hci0/dev_49_7C_73_51_21_1E Connected: 0 <wait a minute or so> # ./connected /org/bluez/hci0/dev_49_7C_73_51_21_1E Connected: 0 <reconnect iOs app> ./connected /org/bluez/hci0/dev_49_7C_73_51_21_1E Connected: 0 /org/bluez/hci0/dev_41_7B_77_4F_E4_AA Connected: 1 <disconnect> ./connected /org/bluez/hci0/dev_49_7C_73_51_21_1E Connected: 0 /org/bluez/hci0/dev_41_7B_77_4F_E4_AA Connected: 0 <reconnect> ./connected /org/bluez/hci0/dev_49_7C_73_51_21_1E Connected: 0 /org/bluez/hci0/dev_41_7B_77_4F_E4_AA Connected: 1 <reboot linux device> # ./connected (no output) <ble connect from iphone> ./connected /org/bluez/hci0/dev_41_7B_77_4F_E4_AA Connected: 1 <disconnect, pretty soon after connection, 5s maybe> ./connected /org/bluez/hci0/dev_41_7B_77_4F_E4_AA Connected: 1 <wait 30s or so> ./connected /org/bluez/hci0/dev_41_7B_77_4F_E4_AA Connected: 1 <after a minute or so> ./connected (no response) If I continued, I think I’d say more variations on the theme. The basic patterns I see are that a disconnected/reconnect cycle behaves in a couple of different ways 1) the device shows up immediately as not connected, and stays listed as not connected, on reconnect is reused and again shows as connected 2) the device shows up immediately as not connected, stays listed as not connected, on reconnect a NEW device shows up 3) no device is listed any more (connected or not connected), on reconnect the same device again shows up as connected 4) no device is listed any more (connected or not connected), on reconnect a NEW device shows up I would love to understand this. Running the sample you shared takes 1200-800 ms on my paltry ARM board. I don’t know if that is all python/dbus setup or, or query time. That’s a long time. Is there a way to register something more event based so I could be notified when it changes? Seems like a catch 22 since I don’t know what the device name will be before hand. -- 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
