Thanks for your explanation.
However for me it remains a riddle (and probably a bug), why the BlueZ implementation selects the random address as HCI adapter address when the public address is set to zero?
When setting the public address different from zero, the DBus topogoly still keeps the address type as random for Adapter1 despite the hcitool cmd 0x3f 0x006 BD_ADDRESS sets the public address.
Nevertheless this solves the QT issue when the hciForAddress function is called in the HciManager object.
The low level function ioctl(hciSocket, HCIGETDEVINFO, &devInfo) will have a match for the address value in the devInfo when compared to this
new random but still public address (IMHO)