Analyzing QBluetoothServiceDiscoveryAgent signals
-
Per Qt doc there in no guarantee QBluetoothServiceDiscoveryAgent emits ALL signals.
it is recommended to actually check for error after "finished" is emitted.When it is working it emits several "serviceDiscovered" signals.
In my case four and they all are QStrings.I am having small issues collecting , validating and displaying only one received "service".
The question is
if QBluetoothServiceDiscoveryAgent emits multiple "serviceDiscovered " signals, one per "service" and they are not really known beforehand would it make sense to "collect " them and display them AFTER "finished" is received ?On more silly question - would it be feasible to "analyze" returned signal value just for
"is it a string ?" The actual value is not important , for now. -
Per Qt doc there in no guarantee QBluetoothServiceDiscoveryAgent emits ALL signals.
it is recommended to actually check for error after "finished" is emitted.When it is working it emits several "serviceDiscovered" signals.
In my case four and they all are QStrings.I am having small issues collecting , validating and displaying only one received "service".
The question is
if QBluetoothServiceDiscoveryAgent emits multiple "serviceDiscovered " signals, one per "service" and they are not really known beforehand would it make sense to "collect " them and display them AFTER "finished" is received ?On more silly question - would it be feasible to "analyze" returned signal value just for
"is it a string ?" The actual value is not important , for now.@AnneRanch said in Analyzing QBluetoothServiceDiscoveryAgent signals:
On more silly question - would it be feasible to "analyze" returned signal value just for
"is it a string ?" The actual value is not important , for now.If a signal sends a
QString
, it is aQString
, always.
There is no need to check whether it's aQString
or not. Even when there is no data, it's an emptyQString
.
if QBluetoothServiceDiscoveryAgent emits multiple "serviceDiscovered " signals, one per "service" and they are not really known beforehand would it make sense to "collect " them and display them AFTER "finished" is received ?
The Qt classes send out multiple default signals when you use them. You dont have to react to all of them. What signals you need, depends on what you want to do.
How it could look like, is explained here:
(but still depends on you, if you want to display all services found or whatever you want to do)https://doc.qt.io/qt-5/qbluetoothservicediscoveryagent.html#details
Edit:
The signal is emitted as soon as a new service is detected... If you dont need the service info there, you can useQList<QBluetoothServiceInfo> QBluetoothServiceDiscoveryAgent::discoveredServices()
after you are done with discovery. It will return a list with all services found. -
@AnneRanch said in Analyzing QBluetoothServiceDiscoveryAgent signals:
On more silly question - would it be feasible to "analyze" returned signal value just for
"is it a string ?" The actual value is not important , for now.If a signal sends a
QString
, it is aQString
, always.
There is no need to check whether it's aQString
or not. Even when there is no data, it's an emptyQString
.
if QBluetoothServiceDiscoveryAgent emits multiple "serviceDiscovered " signals, one per "service" and they are not really known beforehand would it make sense to "collect " them and display them AFTER "finished" is received ?
The Qt classes send out multiple default signals when you use them. You dont have to react to all of them. What signals you need, depends on what you want to do.
How it could look like, is explained here:
(but still depends on you, if you want to display all services found or whatever you want to do)https://doc.qt.io/qt-5/qbluetoothservicediscoveryagent.html#details
Edit:
The signal is emitted as soon as a new service is detected... If you dont need the service info there, you can useQList<QBluetoothServiceInfo> QBluetoothServiceDiscoveryAgent::discoveredServices()
after you are done with discovery. It will return a list with all services found.@Pl45m4 Thanks, appreciate the reply.
I got little mixed up expecting that I will receive non- humanly readable SIGNALS.
At present, when not receiving the error, I get reliably "serviceName" as QString.Since some of the methods are simplified (?) / duplicated I have changed to read "attribute".
The attached fails in
- info.device().name() - no name
- no description nor provider
void ServiceDiscoveryDialog::addService(const QBluetoothServiceInfo& info) { qDebug() << "Discovered service on" << info.device().name() << info.device().address().toString(); qDebug() << "\tService name:" << info.serviceName(); qDebug() << "\tDescription:" << info.attribute(QBluetoothServiceInfo::ServiceDescription).toString(); qDebug() << "\tProvider:" << info.attribute(QBluetoothServiceInfo::ServiceProvider).toString(); qDebug() << "\tL2CAP protocol service multiplexer:" << info.protocolServiceMultiplexer(); qDebug() << "\tRFCOMM server channel:" << info.serverChannel();
The above gets processed four times from "boom boxes" - but no name or description or provider
It receives ONE signal - identify Service name: "Serial Port Profile"
Discovered service on "" "98:D3:31:F8:39:33"
Service name: "Serial Port Profile"
Description: ""
Provider: ""
L2CAP protocol service multiplexer: 0from dongle attached to radio - that is what I really need.
BUT AFTER I changed to read "attribute" !And totally fails to identify Raspberry Pi "embedded" Bluetooth device and another bluetooth dongle attached to Rpi USB bus.
Here is part of my debug output when no RPi is "discovered" at all
connect discoveryAgent SIGNAL finished slot serviceDiscoveryFinished()
expecting two signals ../../../bluetooth/btscanner/service.cpp
Function ServiceDiscoveryDialog
@ line 241
qt.bluetooth.bluez: No uuids found for "B8:27:EB:11:3F:82"
serviceDiscoveryFinished
discoveryAgent->start()
expecting two signals ../../../bluetooth/btscanner/service.cpp
Function ServiceDiscoveryDialogSo there are few inconsistencies / bugs , however, only "Serial Port Profile" is needed at this point.
What is most frustrating - one does not know if ones code is faulty or Qt is not doing the expected job.
The BT terminology is also challenge- what the hell is "profile" ?
PS
If I cannot make more progress getting "service " from RPi I'll change my code to display "stuff" AFTER "finished " - seems safer that way . -
@Pl45m4 Thanks, appreciate the reply.
I got little mixed up expecting that I will receive non- humanly readable SIGNALS.
At present, when not receiving the error, I get reliably "serviceName" as QString.Since some of the methods are simplified (?) / duplicated I have changed to read "attribute".
The attached fails in
- info.device().name() - no name
- no description nor provider
void ServiceDiscoveryDialog::addService(const QBluetoothServiceInfo& info) { qDebug() << "Discovered service on" << info.device().name() << info.device().address().toString(); qDebug() << "\tService name:" << info.serviceName(); qDebug() << "\tDescription:" << info.attribute(QBluetoothServiceInfo::ServiceDescription).toString(); qDebug() << "\tProvider:" << info.attribute(QBluetoothServiceInfo::ServiceProvider).toString(); qDebug() << "\tL2CAP protocol service multiplexer:" << info.protocolServiceMultiplexer(); qDebug() << "\tRFCOMM server channel:" << info.serverChannel();
The above gets processed four times from "boom boxes" - but no name or description or provider
It receives ONE signal - identify Service name: "Serial Port Profile"
Discovered service on "" "98:D3:31:F8:39:33"
Service name: "Serial Port Profile"
Description: ""
Provider: ""
L2CAP protocol service multiplexer: 0from dongle attached to radio - that is what I really need.
BUT AFTER I changed to read "attribute" !And totally fails to identify Raspberry Pi "embedded" Bluetooth device and another bluetooth dongle attached to Rpi USB bus.
Here is part of my debug output when no RPi is "discovered" at all
connect discoveryAgent SIGNAL finished slot serviceDiscoveryFinished()
expecting two signals ../../../bluetooth/btscanner/service.cpp
Function ServiceDiscoveryDialog
@ line 241
qt.bluetooth.bluez: No uuids found for "B8:27:EB:11:3F:82"
serviceDiscoveryFinished
discoveryAgent->start()
expecting two signals ../../../bluetooth/btscanner/service.cpp
Function ServiceDiscoveryDialogSo there are few inconsistencies / bugs , however, only "Serial Port Profile" is needed at this point.
What is most frustrating - one does not know if ones code is faulty or Qt is not doing the expected job.
The BT terminology is also challenge- what the hell is "profile" ?
PS
If I cannot make more progress getting "service " from RPi I'll change my code to display "stuff" AFTER "finished " - seems safer that way .@AnneRanch said in Analyzing QBluetoothServiceDiscoveryAgent signals:
The BT terminology is also challenge- what the hell is "profile" ?
A BT profile is a set of specifications / settings in order to communicate with or use a BT Service.
For example, GATT is a BT profile which specifies how to send or receive small amounts of data by using BlueTooth Low Energy (or other low energy links)
The device(s) has/have to support the profile to use the BT Service.