Qt Bluetooth Low Energy Notification Bug / Downgrade Qt

chrizbee

@SGaist
I've read some of the Connectivity: Bluetooth bugreports which do not yield any solutions...
Before building I've tested my code on windows with Qt 5.15.2 which results in the exact same "error".

So here's my problem:
My BLE device has the address: FF:FF:20:05:B3:E9 (hcitool lescan)
With gatttool I am able to subscribe to handle: 0x000e, uuid: 0000ffe1-0000-1000-8000-00805f9b34fb with this command:

gatttool -b FF:FF:55:03:9F:52 --char-write-req --handle=0x000e --value=0100 --listen

In my application I'm doing the following (pseudocode):

agent->start(QBluetoothDeviceDiscoveryAgent::LowEnergyMethod);
// wait for QBluetoothDeviceDiscoveryAgent::deviceDiscovered(info)
control = QLowEnergyController::createCentral(info, this);
control->connectToDevice();
// wait for QLowEnergyController::connected
control->discoverServices();
// wait for QLowEnergyController::serviceDiscovered(uuid)
if (uuid == myUuid) {
    service = control->createServiceObject(uuid, this);
    // connect characteristicChanged, stateChanged, error, ...
    service->discoverDetails();
}
// wait for QLowEnergyService::stateChanged(state)
if (state == QLowEnergyService::ServiceDiscovered) {
    auto chs = service->characteristics();
    for (QLowEnergyCharacteristic &c : chs) {
        auto des = c.descriptors();
        for (QLowEnergyDescriptor &d : des) {
            qDebug() << d.name() << d.type() << d.handle() << d.uuid() << d.value();
        }
    }

Unfortunately I'm not able to write to the descriptor QBluetoothUuid::ClientCharacteristicConfiguration because service->characteristic(myUuid).descriptors().size() is 0 (characteristic has no descriptors).

So why can I subscribe to the given uuid / handle with gatttool but not with Qt?

chrizbee

@SGaist Or should I create a new post that isn't related to downgrading Qt?

KH-219Design

Given both of these:

(1) The older post: https://forum.qt.io/topic/98115/low-energy-bluetooth-notifications-not-working

And (2) the current issue described here of being unable to convince Qt to attach to notifications because descriptors().size() is zero.

... in my mind this definitely qualifies as a reportable bug at https://bugreports.qt.io

I'm half inclined to report it myself, but I don't have the requisite hardware for reproducing and testing this.

If I am reading this post (and the other one) correctly, then it looks like there is a valid BLE usage scenario that the Qt BLE code simply fails to account for. And this scenario is roughly described as "my BLE peripheral always sends notifications, despite not providing a 0x2902 descriptor with which to enable them."

Do any of these cover it?

https://bugreports.qt.io/browse/QTBUG-83363
https://bugreports.qt.io/browse/QTBUG-54806
https://bugreports.qt.io/browse/QTBUG-89723

If not, then please report it. BLE seems to continue to grow in popularity, so getting this working for future users (not to mention your own use case!) would be a great service.

chrizbee

@KH-219Design Your last link is my bugreport :D
I'm currently testing other Qt versions to see for which version bump it'll stop working.

chrizbee

Update: The application does not receive any notifications without configuration for Qt versions >= 5.11.0.

Qt 5.10.1: Working
Qt 5.11.0: Not working

It's most probably due to this change:
[QTBUG-46819] Ported QLowEnergyController central mode to BlueZ's DBus API. The new implementation is used when BlueZ 5.42+ is detected.

KH-219Design

Excellent investigation. I am now following that bug ticket. Eager to see where it leads...

chrizbee

@KH-219Design Do you think there is a workaround for the time being?
I don't want to build Qt 5.9.9 for my Raspberry Pi...

KH-219Design

I don't want to rule out the possibility of a workaround, but if I had to make a wager, I would say it is a long shot.

I have never cross-compiled Qt, so I'm not sure if it is tricky to cross-compile for rpi using a linux host. If you don't want to cross-compile, then I would imagine that the main issue with building for rpi is that you would be building on the rpi, and this will take hours.

But hey... if you start now, then in a few hours this can all be over ;)

Other than the idea of it taking a long time, are there other concerns with building from source? I actually do it often (once a month or so) on Linux, and it isn't that bad.

I've posted about the steps before (but this is all for Ubuntu):

https://forum.qt.io/topic/119026/how-much-time-will-it-take-to-build-qt-5-15-x-source-package/10

https://forum.qt.io/topic/114784/definitive-guide-to-building-source-from-downloaded-run-file/33

Whenever I build any large open source project, it seems that the trickiest part is often just getting all the other '*dev' library dependencies installed first, so that the build can find everything and succeed.

If something like this exists on raspbian, then you should be most of the way there:

sudo apt-get build-dep qt5-default

Another option would be to find someone who maintains rpi binaries for qt. Does no one maintain such a collection?

chrizbee

@KH-219Design I've actually built Qt directly on a Raspberry Pi 4 a couple of times. But I don't want to stick to the older version of Qt 5.9.9 if there's a workaround for more recent versions.

[QTBUG-46819] Ported QLowEnergyController central mode to BlueZ's DBus API. The new implementation is used when BlueZ 5.42+ is detected. Earlier versions will continue to use the the previous custom GATT stack. The benefit of this change is improved co-existence with BlueZ which avoids interference between BlueZ and Qt and permits multiple Qt and platform apps being able to share BTLE connections. The custom GATT peripheral role implementation is still used on all BlueZ platforms.

I thought of something like downgrading BlueZ to < 5.42 (see bold text). Might give that a try if possible.

chrizbee

I've found a workaround for it:
If you set the environment variable BLUETOOTH_FORCE_DBUS_LE_VERSION to anything below 5.42, Qt will use the old GATT stack implementation instead of BlueZ DBUS implementation. What I've tested:

BLUETOOTH_FORCE_DBUS_LE_VERSION=5.41 ./BleTest

I'll close this and keep the bugreport open since it's a missing feature / bug of the new implementation.

Source: qlowenergycontroller.cpp and bluez5_helper.cpp

Nishantdawn

Hi I am facing the same issue on Qt 5.15.3 and Qt 6.5.3. I am cross compiling BLE code for Android arm64-v8a device.
How can I force BLUETOOTH_FORCE_DBUS_LE_VERSION on the Android device?

chrizbee

This post is deleted!