fix(dbus): re-surface cached BlueZ devices at scan start

[cryptomilk]

Matter device commissioning via matterjs-server consistently failed for the IKEA sensors (e.g. TIMMERFLOTTE) because noble never fired a discover event for it. bluetoothd had already cached the device from background scanning, so BlueZ never emitted an InterfacesAdded signal when noble started its own scan. The device was invisible to noble.

After StartDiscovery, re-read GetManagedObjects and replay _handleDeviceProps for every cached device under the adapter so they appear as discover events.

I'm not really a Javascript developer. So this works for me, not sure everything is 100% correct. I can remove the debug but I needed it to understand why devices vanished after they where detected first.

Feel free to modify the commit and push to the repo to update it. I'm currently moving to a new location so I'm mostly unavailable till next week.

[Apollon77]

@cryptomilk My comment would basically if these number of debug logs are missing for the final code PR ... but sure for testing they help. Could you maybe post a log with these

[stoprocent]

Thanks for digging into this — the underlying problem is real (BlueZ doesn't re-emit InterfacesAdded for devices already in its cache when a scan starts) and the core cache-replay fix is the right idea. A few requests to keep the change tight and avoid touching things it doesn't need to:

1. Please drop the lib/hci-socket/gap.js changes entirely. That file is the HCI-socket path and is unrelated to this D-Bus/BlueZ fix. The if (cond) → const willEmit = cond refactor plus the debug() lines in onLeScanEnableSetCmd and the advertising-report handlers touch a hot, well-tested code path for no functional benefit here. Reverting this file keeps the PR scoped to the actual fix.

2. Remove the debug logging added in bindings.js (you already offered to — appreciated). When they go, the locals that only exist to feed them can go too: surfacedCount, and the per-device addr / name / uuids / serviceData temporaries in the new block, in _onInterfacesAdded, and in _handleDeviceProps. That leaves just the functional replay loop. If you want a trace hook, a single concise debug() consistent with the few already in the file is plenty — not one per device / per advertisement.

3. One behavior question before merge. The new block calls _handleDeviceProps (which unconditionally emit('discover', ...)) for every cached device on every startScanning(). Since there's already a cache replay at init time (around L218–223), the first scan re-emits those, and every stop/start cycle re-fires discover for all cached devices — with rssi: 0 when RSSI is absent. Is that intended? If not, could we guard it so we don't double-emit or surface phantom rssi-0 rediscoveries?

After 1 and 2 this is essentially a ~15-line fix, which is exactly where I'd like it. Thanks again for the contribution!

---

Generated by Claude Code

[cryptomilk]

Done and added the suggested guard.