How can I call BLE StartDiscovery consistently?

[parsley72]

I started with this blog post Me and the Devil BlueZ: Reading BLE Sensors From C++ which uses this code to call StartDiscovery:

void BleSensor::enableScanning(bool enable)
{
    const std::string METHOD_START_DISCOVERY { "StartDiscovery" };
    const std::string METHOD_STOP_DISCOVERY { "StopDiscovery" };
    std::cout << (enable?"Start":"Stop") << " scanning\n";
    bluezProxy->callMethod(enable?METHOD_START_DISCOVERY:METHOD_STOP_DISCOVERY)
        .onInterface(INTERFACE_ADAPTER)
        .dontExpectReply();
}

This works fine on Ubuntu but when I try the same code on my embedded device I get:

"org.freedesktop.DBus.Error.UnknownObject" failed, error: Method "StartDiscovery" with signature "" on interface "org.bluez.Adapter1" doesn't exist

But if I try this on the command line it seems to work:

dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/hci0 org.bluez.Adapter1.StartDiscovery
method return time=1732476480.402514 sender=:1.5 -> destination=:1.412130 serial=194 reply_serial=2

How can I do this in using sdbus-c++ so it works consistently on different devices?

(also asked here and I added a tag for sdbus-cpp)

[parsley72]

Oops, after reading what causes the error "Unknown object" ? I realised I'd tried debugging the code so changed it to:

_bluezProxy->callMethod(enable ? METHOD_START_DISCOVERY : METHOD_STOP_DISCOVERY)
    .onInterface(INTERFACE_ADAPTER)
    .storeResultsTo(variant);
lgr_notice("Victron::%s(enable = %d): variant = %s", __func__, enable, variant.peekValueType().c_str());

Changing it back fixed the error. But my original problem is that discovery on Ubuntu finds all the BLE devices around me whereas on my embedded device I only see:

interfaceAddedCallback(path = /org/bluez/hci0) *** UNEXPECTED SIGNAL ***
interfaceAddedCallback(path = /org/bluez/hci0) *** UNEXPECTED SIGNAL ***

If I run bluetooth ctl then scan le I see all the devices I'd expect so this isn't a BLE problem.

[sangelovic]

What version of sdbus-c++ are you using? Since v2, the proxy created the way you mentioned connects to the bus depending on the context -- it may be a system bus or a session bus. If your proxy connects to the session bus and the remote object is on system bus, it will fail.

[sangelovic]

Third, you want your proxy to listen to signals from the remote object, then you have to subscribe to those signals. See the Using sdbus-c++ tutorial on how to do that.

[parsley72]

I think you missed my second message.

[sangelovic]

I did not miss your second message. What I'm missing, however, is a detailed, complete, understandable description of your situation so that I don't have to guess and lose my time. If you want me to help you, and it's my own free will that I'm giving my time to you, then, please provide me with full contextual information, because from the fragments of information you've provided here I'm unable to do that. You've not shared with me how you create bluezProxy, for example. You've not shared with me what interfaceAddedCallback(path = /org/bluez/hci0) *** UNEXPECTED SIGNAL *** means. How shall I know that? I do not know about Bluetooth D-Bus interfaces, but still I did my own investigation to learn a bit about that just to help you -- and what I've got -- is your short statement.

So, perhaps something like "thanks for your reply" or "please can you help me" or "can I help you with some more info?: in your messages would surely make me happier to help you.

[sangelovic]

For inspiration, see #471 for an example of how a good discussion, with a lot of explanation of client's situation and the efforts he took to solve that, can be started like.

[parsley72]

I'm sorry, I understand the nature of open-source support and I appreciate your help. Your comment about StartDiscovery was correct but I'd already said that in my second message so I thought you'd missed it.

To make things clear, I used the blog post Me and the Devil BlueZ: Reading BLE Sensors From C++ and the source code from that. The repo's been archived so I forked it, added a CI build and fixed a few minor issues here https://github.com/parsley72/NoiseCollectorBLE.

Like I said, this code works fine on Ubuntu but not on my embedded Linux device. They're using almost the same version of BlueZ (5.64 versus 5.65). Since I'm still on Ubuntu 22 I can't use sdbus-C++ v2 (it requires a newer compiler) so I have:

Package: libsdbus-c++-dev
Version: 1.1.0-3

[parsley72]

Small update - I saw somewhere else that you can use dbus-monitor --system "destination='org.bluez'" "sender='org.bluez'" to see what DBus is doing. I tried this on the device and saw:

method call time=1732571029.400255 sender=:1.492603 -> destination=org.bluez serial=2 path=/org/bluez/hci0; interface=org.bluez.Adapter1; member=StartDiscovery
error time=1732571029.402757 sender=:1.5 -> destination=:1.492603 error_name=org.freedesktop.DBus.Error.UnknownObject reply_serial=2
   string "Method "StartDiscovery" with signature "" on interface "org.bluez.Adapter1" doesn't exist
"

The strange thing is there's a try catch around the StartDiscovery command but it's not triggering:

    try {
        const std::string METHOD_START_DISCOVERY{"StartDiscovery"};
        const std::string METHOD_STOP_DISCOVERY{"StopDiscovery"};
        std::cout << (enable ? "Start" : "Stop") << " scanning\n";
        _bluezProxy->callMethod(enable ? METHOD_START_DISCOVERY : METHOD_STOP_DISCOVERY)
            .onInterface(INTERFACE_ADAPTER)
            .dontExpectReply();
    }
    catch (sdbus::Error &error)
    {
        std::cerr << "ERR: on enableScanning(): " << error.getName() << " with message " << error.getMessage() << std::endl;
    }

[parsley72]

When I run the same command on Ubuntu I get:

method call time=1732580504.199691 sender=:1.51093 -> destination=org.bluez serial=4 path=/org/bluez/hci0; interface=org.bluez.Adapter1; member=StartDiscovery
method call time=1732580504.199902 sender=:1.13 -> destination=org.freedesktop.DBus serial=1083094 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.51093'"
method return time=1732580504.199920 sender=org.freedesktop.DBus -> destination=:1.13 serial=349 reply_serial=1083094
signal time=1732580504.303922 sender=:1.13 -> destination=(null destination) serial=1083095 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.Adapter1"
   array [
      dict entry(
         string "Discovering"
         variant             boolean true
      )
   ]
   array [
   ]

[parsley72]

Ah dammit, looks to be a timing problem. The app enables Bluetooth then starts discovery. If I enable Bluetooth first then run the app it works - I guess there's a delay between enabling it and BlueZ accepting messages. I'll see if there's a way of polling for it.

Weird that sdbus-c++ doesn't throw an exception though. Is there any point me investigating this further or should I just wait until I can use v2?