Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Analyzing QBluetoothServiceDiscoveryAgent signals
Forum Update on Monday, May 27th 2025

Analyzing QBluetoothServiceDiscoveryAgent signals

Scheduled Pinned Locked Moved Unsolved General and Desktop
4 Posts 2 Posters 224 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Anonymous_Banned275
    wrote on last edited by
    #1

    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.

    Pl45m4P 1 Reply Last reply
    0
    • A Anonymous_Banned275

      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.

      Pl45m4P Offline
      Pl45m4P Offline
      Pl45m4
      wrote on last edited by Pl45m4
      #2

      @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 a QString, always.
      There is no need to check whether it's a QString or not. Even when there is no data, it's an empty QString.


      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 use QList<QBluetoothServiceInfo> QBluetoothServiceDiscoveryAgent::discoveredServices() after you are done with discovery. It will return a list with all services found.

      • https://doc.qt.io/qt-5/qbluetoothservicediscoveryagent.html#discoveredServices

      If debugging is the process of removing software bugs, then programming must be the process of putting them in.

      ~E. W. Dijkstra

      A 1 Reply Last reply
      2
      • Pl45m4P Pl45m4

        @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 a QString, always.
        There is no need to check whether it's a QString or not. Even when there is no data, it's an empty QString.


        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 use QList<QBluetoothServiceInfo> QBluetoothServiceDiscoveryAgent::discoveredServices() after you are done with discovery. It will return a list with all services found.

        • https://doc.qt.io/qt-5/qbluetoothservicediscoveryagent.html#discoveredServices
        A Offline
        A Offline
        Anonymous_Banned275
        wrote on last edited by
        #3

        @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

        1. info.device().name() - no name
        2. 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: 0

        from 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 ServiceDiscoveryDialog

        So 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 .

        Pl45m4P 1 Reply Last reply
        0
        • A Anonymous_Banned275

          @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

          1. info.device().name() - no name
          2. 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: 0

          from 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 ServiceDiscoveryDialog

          So 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 .

          Pl45m4P Offline
          Pl45m4P Offline
          Pl45m4
          wrote on last edited by Pl45m4
          #4

          @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.

          • https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
          • https://en.wikipedia.org/wiki/Bluetooth_Low_Energy

          If debugging is the process of removing software bugs, then programming must be the process of putting them in.

          ~E. W. Dijkstra

          1 Reply Last reply
          1

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved