ukBaz / BLE_GATT

Python package for using BlueZ D-Bus API to create a Client
MIT License
29 stars 5 forks source link

BLE_GATT.Central KeyError #8

Closed DsapPH closed 2 years ago

DsapPH commented 2 years ago

The code is being run on a raspberry pi and connecting to a ble peripheral that follow GATT protocol.

ISSUE:

pi@raspberrypi:~ $ python3 bluez_test.py 
Traceback (most recent call last):
  File "/home/pi/bluez_test.py", line 4, in <module>
    ubit = BLE_GATT.Central(ubit_address)
  File "/home/pi/.local/lib/python3.9/site-packages/BLE_GATT/central.py", line 24, in __init__
    raise KeyError(f'Device address [{address}] is not found.'
KeyError: 'Device address [E8:6A:A4:0A:71:1E] is not found.Use bluetoothctl to find what devices are nearby'

CODE:

import BLE_GATT

ubit_address = 'E8:6A:A4:0A:71:1E'
ubit = BLE_GATT.Central(ubit_address)
ubit.connect()

The code is fairly short but I debugged using bluetoothctl.

using bluetoothctl and scan on I can see the device.

[bluetooth]# scan on
Discovery started
[CHG] Controller E4:5F:01:6E:17:1B Discovering: yes
[NEW] Device E8:6A:A4:0A:71:1E NAME ble

I can also connect to the device through bluetoothctl using pair address

[bluetooth]# pair E8:6A:A4:0A:71:1E
Attempting to pair with E8:6A:A4:0A:71:1E
[CHG] Device E8:6A:A4:0A:71:1E Connected: yes

Are there other steps to take towards debugging this. The error also happens instantly when running the code. As if it takes no time to spend scanning.

ukBaz commented 2 years ago

There is a couple of bits of information that will be helpful.

On the command line can you do the following busctl command to see what the D-Bus paths are:

pi@SensePi:~ $ busctl tree org.bluez
└─/org
  └─/org/bluez
    └─/org/bluez/hci0
...

Inside bluetoothctl can you do devices to see if the address you are trying to connect to is in the list. If it is not, can you do a scan and a connect (rather than pair).

DsapPH commented 2 years ago

Using busctl shows this.

pi@raspberrypi:~ $ busctl tree org.bluez
└─/org
  └─/org/bluez
    └─/org/bluez/hci0
      └─/org/bluez/hci0/dev_E8_6A_A4_0A_71_1E

Using devices in bluetoothctl shows this.

pi@raspberrypi:~ $ bluetoothctl
Agent registered
AdvertisementMonitor path registered
[bluetooth]# devices
Device E8:6A:A4:0A:71:1E NAME ble

What does it mean to have it listed within the D-Bus like this?

I reran the previous code and got a successful connection. I haven't touched anything myself to fix that. The raspberrypi was just idling. Was using pair what could have caused this? Using disconnect in bluetoothctl and rerunning the code again still showed it passing. I have plenty of other BLE peripherals in my BLE centrals range. Was BLE_GATT.Central what added it to the D-bus? Is there some reason it would have worked now versus against previous? Earlier I had rerun the script on a loop to see if maybe it was just missing the advertising packets being sent out and let it run for 5+ minutes but that never worked.

ukBaz commented 2 years ago

It is difficult to know exactly what was the issue. If I was to speculate, the most likely thing is that BlueZ had removed the device from the list. BlueZ only keeps the device in the list after a successful connection (or a correct pairing key is entered). The script can't connect if the BLE device is not in the list.

Can I go ahead and close this now?

DsapPH commented 2 years ago

Understood. Yeah I don't understand it much myself as to why that may have happened. Is there a way to successfully add it back to that list of BlueZ removed it? I.e would using connect in bluetoothctl manually fix that, and allow the code to work again?

Yes feel free to close it. I appreciate all the responses and time you took for these even though it fixed itself and was probably a very beginner scenario.

ukBaz commented 2 years ago

One the device is in the list BlueZ will not remove it. If you do find it is not there then using bluetoothctl to scan and connect should do the job.

Good luck with it all...