Skip to content

fix(ios): trigger BLE scan when entering ScanningEquipment view#25

Open
Flo5k5 wants to merge 1 commit intom5stack:mainfrom
Flo5k5:fix/ios-ble-scan-trigger
Open

fix(ios): trigger BLE scan when entering ScanningEquipment view#25
Flo5k5 wants to merge 1 commit intom5stack:mainfrom
Flo5k5:fix/ios-ble-scan-trigger

Conversation

@Flo5k5
Copy link
Copy Markdown

@Flo5k5 Flo5k5 commented Apr 22, 2026

The upstream .task{} block was empty, which meant BlufiUtil.startScan()
was never called after the user reached the QR scan page. Consequence:
after scanning the QR, readCodeString() calls openBlufi() to set the
discovery callback, but there's no live scan feeding it - the iPhone
never sees the ESP32 in advertising mode and the app stays stuck on
the main view.

Call getPermission() in .task (which in turn calls getBlueAndWifiInfo()
and startScan() once the user grants location permission, as iOS
requires for BLE scans).

This is a real bug in the open-source app that should also land
upstream as PR #9. For now it lives on self-host to unblock our
provisioning immediately.

The upstream .task{} block was empty, which meant BlufiUtil.startScan()
was never called after the user reached the QR scan page. Consequence:
after scanning the QR, readCodeString() calls openBlufi() to set the
discovery callback, but there's no live scan feeding it - the iPhone
never sees the ESP32 in advertising mode and the app stays stuck on
the main view.

Call getPermission() in .task (which in turn calls getBlueAndWifiInfo()
and startScan() once the user grants location permission, as iOS
requires for BLE scans).

This is a real bug in the open-source app that should also land
upstream as PR m5stack#9. For now it lives on self-host to unblock our
provisioning immediately.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant