Qt Bluetooth Low Energy Notification Bug / Downgrade Qt
-
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-89723If 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.
www.219design.com
Software | Electrical | Mechanical | Product Design -
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-89723If 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.
@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. -
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. -
Excellent investigation. I am now following that bug ticket. Eager to see where it leads...
www.219design.com
Software | Electrical | Mechanical | Product Design -
Excellent investigation. I am now following that bug ticket. Eager to see where it leads...
@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... -
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-defaultAnother option would be to find someone who maintains rpi binaries for qt. Does no one maintain such a collection?
www.219design.com
Software | Electrical | Mechanical | Product Design -
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-defaultAnother option would be to find someone who maintains rpi binaries for qt. Does no one maintain such a collection?
@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.
-
I've found a workaround for it:
If you set the environment variableBLUETOOTH_FORCE_DBUS_LE_VERSIONto 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 ./BleTestI'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
-
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? -
N Nishantdawn referenced this topic on
-
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?
