[Edited Message Follows]

Hi Carles,

Humm... not quite, I have recently created a QT bug report (See : https://bugreports.qt.io/browse/QTBUG-71727)  although I think different parties are to blame, I'm still not sure who is doing really wrong, or miss interprets the data.

Thus to summarize again:
If no public address is set for the Nordic BT controller, the HCI adapter has by default address 00:00:00:00:00:00.

When Qt creates a QLowEnergyController object it uses the BT random address to find the HCI adapter (hciForAddress member function in the HciManager class), but as the random address is different from the default public address it is not able to create a QT BT socket, and thus all BLE actions will fail (E.g. advertising).

As QT uses the Bluez DBus function for retrieving the address info you could say it is the Bluez stack to blame, as the address is referring to the HCI adapter is the random address and not the public device address (00:00:00:00:00:00) (See attach pic of QDbusViewer).

Thus only after setting the public address different from the zero address (by means of the hcitool cmd) , Qt is able to create a correct LowEnergyController object for starting to advertise. But also in this case you could wonder why is in the DBus topology ("Property: AddressType") the public set address still typed as "random". 

I'm wondering how Qt will reply to the issue. Honestly I love to work with QT as a C++ developer.

Also the Zephyr HCI_UART running on the Nordic HW offers a different solution than using the plain C solution (serialize concept when separating connectivity board from application board) offered by Nordic or the C++ solution based on the Nordic PC BLE driver. Altough the latter also gives a nice solution for integrating BT in our products. 

Best regards,
Frank