Yeah instead of the QVariant I am expecting a QVariantMap (but the connection doesn't work with a slot with that kind of prototype). Here is an example of the data that would be received array [ dict entry( string "Address" variant string "FF:FF:FF:FF:FF:FF" ) dict entry( string "AddressType" variant string "random" ) dict entry( string "Name" variant string "device name" ) dict entry( string "Alias" variant string "device alias" ) dict entry( string "Paired" variant boolean false ) dict entry( string "Trusted" variant boolean false ) dict entry( string "Blocked" variant boolean false ) dict entry( string "LegacyPairing" variant boolean false ) dict entry( string "RSSI" variant int16 -69 ) dict entry( string "Connected" variant boolean false ) dict entry( string "UUIDs" variant array [ string "0000fea0-0000-1000-8000-00805f9b34fb" ] ) dict entry( string "Adapter" variant object path "/org/bluez/hci0" ) dict entry( string "ServiceData" variant array [ dict entry( string "00000000-0000-0000-0000-000000000000" variant array of bytes [ ff ff ff ff ff ff ff ff ff ff ff ff ff ] ) ] ) dict entry( string "ServicesResolved" variant boolean false ) ] where array is essentially the Map.

I don't believe the message protocol contains that information unless your sender manually inserts an ID into the message being sent. A web search indicates there are some out of band mechanisms to determin the PID of a program using a specific bus endpoint, but not directly within the dbus messages. If I'm wrong then I'd love to see the solution myself.

I've solved it. To handle long I did not have to send immediately reply (even though tutorial said that we have to). And delayed reply will be send. Also in extension, QDBusPendingReply<QString, QByteArray> reply = *call; setting expecting signature to \"say\" and not looking to xml interface.

@SGaist You're right,I did not think about it! I have to remove the systemBus, I'm not using it in reality, it's part of the project that I found on Github. Ok then I can try to make it an instance variable of the class or similer. Thank you!

I have found solution for this, using QDbusConnectionInterface instead QDbusServiceWatcher: connect(QDBusConnection::sessionBus().interface(), &QDBusConnectionInterface::serviceRegistered, this, [=](QString a) { qDebug() <<"service R: " << a; });

@micland WOOW!!! Thank you sooo much micland!! It works!!! I tried a code similar to yours but some data were missing. Just needed to do a very tiny modification on your code: qDebug() << key << value.variant().toString(); or directly qDebug() << value.variant().toString(); Except it, it is perfect! Thank you again. @micland said: I have no clue why the qdbusviewer of Qt 5.6 is unable to call the DBus method but the code snippet above is working fine. I hope it is going to change as I intend to use it or the 5.7 version very soon. Cheers again.

@Mark81 I'm certainly not a D-Bus guru, my experience with it is somewhat limited. That said, I think QDBusReply::value can be used, provided you have registered your types. Kind regards.

I confirm that adding the pthread library did the trick. But the question "why" is still there :)

@SGaist Okay, thanks :)