Question: recommended way to detect re-pairing completion over D-Bus

From: Tomoka Kimura <hidden>
Date: 2026-05-12 02:00:37

Hi,

I'm developing an embedded device using BlueZ and need to update the
UI when pairing has fully completed.

For initial pairing, I can use the `PropertiesChanged` signal for
`org.bluez.Device1.Paired`, which works well.

However, during re-pairing, if the remote device deletes its pairing
information while my device keeps the existing bond, I cannot detect
when the new pairing has actually completed. In this case, the
`org.bluez.Device1` object already exists, and `Paired`/`Bonded` are
already `true`, so no `PropertiesChanged` signal is emitted.

Environment:
- BlueZ 5.72
- BR/EDR peripheral + BLE peripheral
- Agent capability: NoInputNoOutput
- `JustWorksRepairing=confirm`

What I observed:
- `RequestAuthorization` is called before LTK storage completes, so it
appears too early to treat as pairing completion
- `Connected` also becomes true too early
- `ServicesResolved` does not seem suitable because it is tied to
service discovery rather than pairing/bond persistence, and its timing
can vary depending on the device. In some cases it may be emitted
noticeably after pairing has already completed

What I need is a reliable indication that pairing/bonding has fully
completed and all keys have been stored, including during re-pairing.

My questions are:

1. Is there an official D-Bus API/signal/property for detecting this
completion point?
2. If not, what is the recommended approach for applications that need
to update UI at the correct timing?

I also checked the source up to 5.86 and it looks like
`device_set_paired()` / `device_set_bonded()` still do not emit
`PropertiesChanged` if both bearers are already paired/bonded.

Any guidance would be appreciated.

Best regards,
Tomoka Kimura
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help