# Future request: fixed 10-second discovery delays connections to known peripherals

**URL:** <https://community.homey.app/t/future-request-fixed-10-second-discovery-delays-connections-to-known-peripherals/160272>\
**Category:** Developers\
**Tags:** bluetooth-le-ble\
**Created:** [October 2, 2026, 12:52pm UTC](https://community.homey.app/t/future-request-fixed-10-second-discovery-delays-connections-to-known-peripherals/160272 "2026-10-02T12:52:42Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![makleso6](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/makleso6/32/78907_2.png) [@makleso6](https://community.homey.app/u/makleso6)\
**Post date:** [October 2, 2026, 12:52pm UTC](https://community.homey.app/t/future-request-fixed-10-second-discovery-delays-connections-to-known-peripherals/160272/1 "2026-10-02T12:52:42Z")

</div>

I am developing a Homey Pro app for the Aqara A100 Pro lock using local HomeKit over BLE. A fixed discovery delay significantly affects the responsiveness of lock commands.  
Observed behaviour  
When the peripheral is already cached, this.homey.ble.find(peripheralUuid) returns in a few milliseconds. When discovery is required, the caller waits for the full scan window of approximately 10 seconds before it can proceed.  
This adds latency before GATT discovery and HomeKit authentication even begin. Keeping the lock permanently connected through periodic reads is undesirable because it increases battery consumption.  
Requested improvement  
Could you provide a supported way to find and connect to a known peripheral as soon as it is discovered, without waiting for the remaining scan window?  
Ideally:

1. A targeted find(peripheralUuid) resolves as soon as a matching advertisement arrives.
2. Connection scheduling allows that result to be used immediately, without remaining blocked behind the full scan.
3. Scanning remains coordinated safely between apps.  
A configurable timeout or advertisement subscription API would also help. The current documented ManagerBLE API exposes neither option.  
The existing full-window discover() behaviour could remain available for applications that need a complete device list.  
Is there already a supported approach for this, or could this be considered for a firmware/SDK improvement? I can provide a minimal reproduction and timing logs.  
Thank you!