Race condition or timeouts on establishing BTLE connection?

[reinhard-brandstaedter]

First and most important:
fantastic work and great demos/videos!
I love your explanations and humor you put into this project! (just saying: I have a fire extinguisher in my house!)

I really want to get this to work and do some cool projects like you!
Currently testing this on my Raspberry box with the different bluetooth options, but I'm seeing strange behaviors. The most stable one seems to be gatt, but even there I can only connect with the demo application maybe once out of 30 tries.
I'm wondering if this has to do somethinhg with the Hub itself, some timeout or maybe some race condition.

Examples

A semi-working connection with gatt, once in a while I do get the led_demo working until the end.

~/pylgbst $ python3 examples/demo.py -d led_colors -c gatt://00:16:53:b8:90:8b
210	INFO	comms-gatt	Discovering devices...
225	INFO	comms	Found LEGO Move Hub at 00:16:53:b8:90:8b
7301	INFO	comms-gatt	Waiting for device connection...
8423	INFO	hub	Attached peripheral: EncodedMotor on port 0x0
18323	WARNING	hub	Got only these devices: (EncodedMotor on port 0x0, None, None, None, None, None, None)

After that the demo just hangs, the MoveHub seems to have turned off.
Sometimes I do get this:

~/pylgbst $ python3 examples/demo.py -d led_colors -c gatt://00:16:53:b8:90:8b
792	INFO	comms-gatt	Discovering devices...
Traceback (most recent call last):
  File "examples/demo.py", line 254, in <module>
    connection = connection_from_url(options.connection)  # get_connection_bleak(hub_name=MoveHub.DEFAULT_NAME)
  File "examples/demo.py", line 244, in connection_from_url
    **params
  File "/usr/local/lib/python3.7/dist-packages/pylgbst/__init__.py", line 25, in get_connection_gatt
    return GattConnection(controller).connect(hub_mac, hub_name)
  File "/usr/local/lib/python3.7/dist-packages/pylgbst/comms/cgatt.py", line 100, in connect
    for dev in devices:
RuntimeError: dictionary changed size during iteration

This seems to be a race condition that maybe the list of nearby bluetooth devices changes during iteration?

With gattlib

~/pylgbst $ sudo python3 examples/demo.py -d led_colors -c gattlib://00:16:53:b8:90:8b
53	INFO	comms-gattlib	Discovering devices using hci0...
102	INFO	comms-gattlib	Discovering devices using hci0...
1225	INFO	comms-gattlib	Discovering devices using hci0...
2350	INFO	comms-gattlib	Discovering devices using hci0...
3137	INFO	comms-gattlib	Discovering devices using hci0...
4334	INFO	comms-gattlib	Discovering devices using hci0...
5366	INFO	comms-gattlib	Discovering devices using hci0...
6159	INFO	comms	Found LEGO Move Hub at 00:16:53:B8:90:8B
16750	WARNING	hub	Got only these devices: (None, None, None, None, None, None, None)

With bluepy
I get tens of thousands ERRORs within a very short time after the Hub has been detected

10852	ERROR	comms-bluepy	Exception in call dispatcher thread
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/pylgbst/comms/cbluepy.py", line 64, in _dispatch_calls
    self._peripheral.waitForNotifications(1.)
  File "/usr/local/lib/python3.7/dist-packages/bluepy/btle.py", line 560, in waitForNotifications
    resp = self._getResp(['ntfy','ind'], timeout)
  File "/usr/local/lib/python3.7/dist-packages/bluepy/btle.py", line 407, in _getResp
    resp = self._waitResp(wantType + ['ntfy', 'ind'], timeout)
  File "/usr/local/lib/python3.7/dist-packages/bluepy/btle.py", line 338, in _waitResp
    if self._helper.poll() is not None:
AttributeError: 'NoneType' object has no attribute 'poll'

With ```bleak`` usually no devices are discovered

~/pylgbst $ sudo python3 examples/demo.py -d led_colors -c bleak://00:16:53:b8:90:8b
659	INFO	comms-bleak	Discovering devices... Press green button on Hub
10679	WARNING	hub	Got only these devices: (None, None, None, None, None, None, None)

Versions

python 3.7.3
gatt                           0.2.7      
gattlib                        0.20200122 
pygatt                         4.0.5      
pylgbst                        1.2.0      
bluebrick-Adafruit-BluefruitLE 0.9.13     
bluepy                         1.3.0

Any idea or pointers would be much appreciated!

[reinhard-brandstaedter]

Investigating this a bit further it seems that the MoveHub goes into standby/off rather quit if it doesn't get initialized (via special commands?) within a rather short time after the initial connection.
It looks like ~8seconds after I press the green button it turns off again. When connecting via the Lego App it seems to receive some "stay-awake" heartbeat command.

[reinhard-brandstaedter]

Using the debug server option, with forcing gatt as the connection option and hardcoding the mac address of my MoveHub:

~/pylgbst $ python3 -c "import logging; logging.basicConfig(level=logging.DEBUG);import pylgbst; pylgbst.start_debug_server()"
DEBUG:comms-gatt:Starting DeviceManager...
INFO:comms-gatt:Discovering devices...
DEBUG:comms-gatt:Devices: dict_values([<gatt.gatt_linux.Device object at 0xb56675d0>])
DEBUG:comms:Checking device: LEGO Move Hub, MAC: 00:16:53:b8:90:8b
INFO:comms:Found LEGO Move Hub at 00:16:53:b8:90:8b
INFO:comms-gatt:Waiting for device connection...
DEBUG:comms-gatt:Sleeping...
DEBUG:comms-gatt:Getting MoveHub services and characteristics...
DEBUG:comms-gatt:[00:16:53:b8:90:8b] Resolved services
DEBUG:comms-gatt:[00:16:53:b8:90:8b]  Service [00001623-1212-efde-1623-785feabcd123]
DEBUG:comms-gatt:[00:16:53:b8:90:8b]    Characteristic [00001624-1212-efde-1623-785feabcd123]
DEBUG:comms-gatt:MoveHub characteristic found
DEBUG:comms-gatt:[00:16:53:b8:90:8b]  Service [00001801-0000-1000-8000-00805f9b34fb]
DEBUG:comms-gatt:[00:16:53:b8:90:8b]    Characteristic [00002a05-0000-1000-8000-00805f9b34fb]
INFO:comms:Accepting MoveHub debug connections at 9090

The debugserver connects, but then the MoveHub turns off right afterwards. That is not normal, the LED of the hub should stay on, right?

[undera]

This is not normal for hub to disconnect in this situation. In BLE, there is distinct connect action that marks connection as active, so Hub stays on. I guess there may be some specifics in behaviors with different BLE libraries...

[sranck]

I was running into a similar issue after installing a more current version of Raspbian on my Pi 3 B+. Downgrading the Bluetooth firmware resolved the issue:

$ wget https://github.com/RPi-Distro/bluez-firmware/raw/ade2bae1aaaebede09abb8fb546f767a0e4c7804/broadcom/BCM4345C0.hcd
$ sudo cp BCM4345C0.hcd /lib/firmware/brcm/

This thread pointed me in the right direction: https://www.raspberrypi.org/forums/viewtopic.php?t=254523

Hope this helps!