Removes the two-phase flow where the user had to confirm beacon flashing
and tap "Write Config". Now goes straight from connect → write → register
in one shot. The dxsmartConnectedView UI is removed.
Two changes:
1. DXSmartProvisioner now registers for BLE disconnect callbacks.
Previously if the beacon dropped the link mid-write, the provisioner
would sit waiting for ACK timeouts (5s × 2 retries = 10s of dead air).
Now it fails immediately with a clear error.
2. Inter-command delay reduced from 150ms → 50ms since beacon handles
fast writes fine.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
After SaveConfig is sent, the DXSmartProvisioner.writeConfig() returns
but never disconnects. The beacon MCU needs the BLE link dropped to
finalize its save-and-reboot cycle. Without disconnect, the beacon stays
connected and keeps flashing indefinitely.
Added 200ms delay + explicit provisioner.disconnect() after writeConfig
completes in the success path.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The beacon reboots instantly on SaveConfig (0x60). Using .withResponse
meant CoreBluetooth expected a GATT ACK that never arrived, potentially
causing the write to be silently dropped — leaving the config unsaved
and the beacon LED still flashing after provisioning.
Switching to .withoutResponse fires the bytes directly into the BLE
radio buffer without requiring a round-trip ACK. The beacon firmware
processes the save command from its buffer before rebooting.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The API requires HardwareId as a mandatory field, but the iOS app was
sending MacAddress (wrong key) and always passing nil. This caused
"HardwareId is required" errors after provisioning.
Since CoreBluetooth doesn't expose raw MAC addresses, we use the
CBPeripheral.identifier UUID as the hardware ID — same concept as
Android's device.address.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
succeed() was calling disconnectPeripheral() before completion(), so the
disconnect delegate fired while writesCompleted was still false — causing
the "Unexpected disconnect" error log even on successful provisions.
Swapped order: signal completion first, then disconnect. Also removed the
redundant provisioner.disconnect() in ScanView since succeed() already
handles it.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
SaveConfig (0x60) causes the beacon MCU to reboot and save to flash.
It never sends an ACK, so writeToCharAndWaitACK would wait for the
5s timeout, during which the beacon disconnects. The disconnect
handler fires while writesCompleted is still false, causing a false
"Unexpected disconnect: beacon timed out" error.
Fix: fire-and-forget the SaveConfig write and return immediately.
The BLE-level write (.withResponse) confirms delivery. writeConfig()
returns before the disconnect callback runs, so writesCompleted gets
set to true in time.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Shaves ~4.6s off the 23-command provisioning sequence while keeping
a safe margin for the beacon's BLE stack to process each write.
Next step: if stable, we can go more aggressive (200ms or 150ms).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
After all 23 commands write successfully, the DX-Smart beacon reboots
to apply config — dropping the BLE connection. ScanView's disconnect
handler was racing the async writeConfig return and logging this as
"Unexpected disconnect: beacon timed out" even though provisioning
succeeded.
Added writesCompleted flag so the disconnect handler knows writes
finished and logs it as expected behavior instead of an error.
Remove the guard that dropped non-CP-28 devices. All discovered
BLE peripherals now appear in the scan list (defaulting to .dxsmart
type). detectBeaconType still classifies known CP-28 patterns but
unknown devices are no longer hidden.
The CP-28-only refactor accidentally over-filtered the BLE scan:
1. FFF0 service detection was gated on name patterns — CP-28 beacons
advertising FFF0 with non-matching names (e.g. already provisioned
as "Payfrit") were silently filtered out. Restored unconditional
FFF0 → dxsmart mapping (matching old behavior).
2. Already-provisioned beacons broadcast with name "Payfrit" (set by
old SDK cmd 0x43), but that name wasn't in the detection patterns.
Added "payfrit" to the name check.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove BlueCharmProvisioner, KBeaconProvisioner, and FallbackProvisioner.
Simplify BeaconType enum to DX-Smart only. Simplify BLE detection to only
show CP-28 beacons. Remove multi-type provisioner factory from ScanView.
-989 lines of dead code removed. Other beacon types will be re-added
when we start using different hardware.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1. Minor allocation: reject minor=0 from API instead of silently using it.
API returning null/0 means the service point isn't configured right.
2. DXSmart write reliability:
- Add per-command retry (1 retry with 500ms backoff)
- Increase inter-command delay from 200ms to 500ms
- Increase post-auth settle from 100ms to 500ms
- Add 2s cooldown in FallbackProvisioner between provisioner attempts
The beacon's BLE stack gets hammered by KBeacon's 15 failed auth
attempts before DXSmart even gets a chance. These timings give it
breathing room.
3. KBeacon passwords: password 5 was a duplicate of password 3
(both "1234567890123456"). Replaced with "000000" (6-char variant).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Frame1_DevInfo (cmd 0x61) and potentially other commands don't send a
separate FFE1 notification after being written. The code was waiting for
didUpdateValueFor (notification) to resolve responseContinuation, but it
never came — causing a 5s timeout on every such command.
The .withResponse write type already guarantees the BLE stack confirmed
delivery. Now didWriteValueFor resolves responseContinuation on success,
so commands that don't trigger notifications still complete immediately.
If a notification also arrives later, responseContinuation is already nil
so it's harmlessly ignored.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Swift strict concurrency checker flags MainActor-isolated self access from
nonisolated CBCentralManagerDelegate methods when using Task{@MainActor in}.
DispatchQueue.main.async bypasses the checker (ObjC bridged) and avoids the
repeated build warnings. Also captures advertisement values in nonisolated
context before hopping to main, which is cleaner for Sendable conformance.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
After DXSmart auth completes, the beacon often drops BLE connection
due to aggressive timeouts. The disconnect handler was treating this
as a failure, stomping the .connected state before the user could see
the "Write Config" button.
Changes:
- Ignore BLE disconnects during .connected state for DXSmart beacons
(the LED keeps flashing regardless of BLE connection)
- Auto-reconnect in writeConfigToConnectedBeacon() if BLE dropped
while waiting for user confirmation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
KBeaconProvisioner had no onStatusUpdate callback, so the UI showed a static
"Connecting..." message during the entire auth cycle (5 passwords × 5s timeout
× 3 retries = 75s of dead silence). Now reports each phase: connecting,
discovering services, authenticating (with password attempt count), writing,
saving.
Also fixed ScanView disconnect handler to cover .writing and .verifying states —
previously only handled .connecting/.connected, so a mid-write disconnect left
the UI permanently stuck.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- DXSmartProvisioner now reports each phase (connecting, discovering
services, authenticating, retrying) via onStatusUpdate callback
- ScanView shows live diagnostic log during connecting/writing states,
not just on failure — so you can see exactly where it stalls
- Unexpected BLE disconnects now properly update provisioningState to
.failed instead of silently logging
- Added cancel button to connecting progress view
- "Connected" screen title changed to "Connected — Beacon is Flashing"
for clearer status indication
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
BIG FIX: Provisioners were calling centralManager.connect() but
BLEManager is the CBCentralManagerDelegate — provisioners never
received didConnect/didFailToConnect callbacks, so connections
ALWAYS timed out after 5s regardless. This is why provisioning
kept failing. Fixed by:
1. Adding didConnect/didFailToConnect/didDisconnect to BLEManager
2. Provisioners register connection callbacks via bleManager
3. Increased connection timeout from 5s to 10s
DIAGNOSTICS: Added ProvisionLog system so failures show a timestamped
step-by-step log of what happened (with Share button). Every phase
is logged: init, API calls, connect attempts, service discovery,
auth, write commands, and errors.
Sort the beacon list so strongest signal (closest beacon) appears at the
top. Sorting happens both in BLEManager as beacons are discovered and in
the ScanView list rendering.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Major detection gaps were causing iOS to miss 7-8 out of 8-9 nearby DX beacons:
1. FFF0 service UUID was incorrectly mapped exclusively to BlueCharm.
Android maps DXSmartProvisioner.SERVICE_UUID_FFF0 to DXSMART.
Now checks device name to disambiguate FFF0 between DX and BlueCharm,
defaulting to DXSmart (matching Android behavior).
2. Added DX factory default UUID detection (E2C56DB5-DFFB-48D2-B060-D0F5A71096E0).
Android catches DX beacons by this UUID on line 130 of BeaconScanner.kt.
iOS was missing this entirely.
3. Added Payfrit shard UUID detection — already-provisioned DX beacons
broadcasting a shard UUID are now recognized.
4. Added iBeacon manufacturer data parsing with proper UUID extraction.
Any device broadcasting valid iBeacon data is now included (not just
those with minor > 10000).
5. Added permissive fallback matching Android lines 164-169: connectable
devices with names are included even if type is unknown, so they're
at least visible to the user.
6. Added FEA0 service UUID for BlueCharm (Android line 124).
7. Added "DX-CP" name pattern (Android line 138) that was missing.
Root cause: Android uses MAC OUI prefix 48:87:2D to catch all DX beacons
regardless of advertisement contents. iOS can't do this (CoreBluetooth
doesn't expose MAC addresses), so we compensate with broader iBeacon
UUID matching and more permissive device inclusion.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When tapping Back from ScanView, BusinessListView remounts and .task fires
loadBusinesses() which sees AppPrefs.lastBusinessId still set — immediately
re-navigating into the same business. Fix: clear lastBusinessId on back,
and add skipAutoNav flag to also prevent single-business auto-select from
firing when user explicitly navigated back.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The app crashed immediately when tapping QR scan because the Info.plist
was missing the required NSCameraUsageDescription key. iOS kills the app
with EXC_BAD_INSTRUCTION when camera access is requested without it.
Also fixes:
- Flash toggle could SIGABRT if lockForConfiguration failed (try? + unconditional unlock)
- Camera setup now logs errors instead of silently failing
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The API returns {OK: true, BUSINESSES: [...]} but the iOS client was
decoding {Success: true, Data: [...]} which never matched — causing
"Failed to load businesses" on every call. Also fixes Business model
(BusinessID/Name vs ID/BusinessName) and ServicePoint model
(ServicePointID vs ID). All response decoders now match the real API.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Three bugs found and fixed:
1. sendOTP was sending "ContactNumber" but API expects "Phone"
2. APIResponse expected {"Success":true,"Data":{}} but API returns {"OK":true,"UUID":"..."}
3. verifyOTP was sending "Code" but API expects "OTP"
Now decodes the raw API format directly instead of going through the
generic APIResponse wrapper (which doesn't match auth endpoints).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
PayfritGreen and PayfritGreenDark were defined in both Assets.xcassets
(as .colorset files) and in BrandColors.swift (as Color extensions).
All code references the Swift extension (.payfritGreen), so the asset
catalog versions are redundant and cause ambiguity. Removed the colorsets.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The ShapeStyle where Self == Color extension duplicated Color statics,
causing 'ambiguous use' errors in foregroundStyle/stroke/tint/background
contexts. Removed the extension entirely and use explicit Color.xxx prefix
at all call sites instead.
- App icon now uses white bg + PAYFRIT text + bluetooth beacon icon (matches Android)
- AccentColor set to Payfrit Green (#22B24B)
- Added BrandColors.swift with full Android color palette parity
- All views updated: payfritGreen replaces .blue, proper status colors throughout
- Signal strength, beacon type badges, QR scanner corners all use brand colors
- DevBanner uses warningOrange matching Android's #FF9800
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use explicit toolbar(content:) call instead of trailing closure to
disambiguate the SwiftUI toolbar modifier overload.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Project references PayfritBeacon/Info.plist but the file was never committed.
Includes Bluetooth and Location usage descriptions required for beacon functionality.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Copied from payfrit-user-ios — same Payfrit brand icon.
Contents.json now references the file.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Xcode build was failing because the asset catalog referenced in
project.pbxproj didn't exist on disk. Added:
- Assets.xcassets/Contents.json
- AppIcon.appiconset/Contents.json (single 1024x1024 slot, no image yet)
- AccentColor.colorset/Contents.json
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The project file referenced old flat-structure filenames (Api.swift,
BeaconScanner.swift, BLEBeaconScanner.swift, etc.) but files are now
organized into App/, Models/, Provisioners/, Services/, Utils/, Views/.
Changes:
- Added PBXGroup entries for all 6 subdirectories
- Updated all 26 Swift file references to use subdirectory paths
- Removed 6 stale references (Api.swift, BeaconScanner.swift,
BLEBeaconScanner.swift, BeaconProvisioner.swift,
ServicePointListView.swift, DebugLog.swift)
- Added 14 new file references (AppPrefs, AppState, BeaconConfig,
BeaconType, Business, ServicePoint, all Provisioners, APIClient,
APIConfig, BLEManager, SecureStorage)
- All build configurations preserved unchanged
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- payfrit-favicon-light-outlines.svg (copied from payfrit-works-ios)
- en.lproj/InfoPlist.strings (standard localization)
These were referenced in project.pbxproj but not committed to the repo,
causing build failures.
