Skip to content
  • 0 Votes
    7 Posts
    1k Views
    D

    @ivk16 Yes, take a look here: https://bugreports.qt.io/browse/QTBUG-76565

  • 0 Votes
    3 Posts
    2k Views
    P

    @raven-worx Yes, your are right that it is a little unclear in the term that I had used, I think the term that actually used for BLE pairing is PASSKEY rather than PIN-CODE, but essentially the question stays the same. I have updated original question accordingly.

    Sorry for not answering on that for too long, but at the end of the day I have finished with using Bluez-Qt library. I had to update it with Low Energy functionality by myself, but it was rather easier for me since I am familiar with Bluez DBus Api.

    So, AFAIK, the Qt Bluetooth module does not provide any functionality similar to what Bluez's agent provides, i.e. it is not possible to perform general pairing/bonding procedure with different IO (Input-Output) capabilities. Please correct me, if I am wrong.

  • 0 Votes
    3 Posts
    1k Views
    C

    No, because they were neved emitted. I just found this: https://bugreports.qt.io/browse/QTBUG-38401, it seems that they are not implemented yet for Bluez 5. However, I would like to set the pin in only one-way, the raspberry shouldn't accept any pairing if the pin code (probably hardcoded in the raspberry) is different from the one entered by the user. Anyway, I'm not sure if this is possible.

  • 0 Votes
    6 Posts
    3k Views
    M

    @raven-worx no, sorry, as said in the last post it doens't listen for incoming pairing request. Is the application which has to issue a pairing request! It's quite different.

    Of course the final result is pretty the same, but I didn't understand how it works from the documentation.