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>
- 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.
- QRScannerView: AVFoundation camera + barcode/QR detection with
flashlight toggle, viewfinder overlay, MAC/UUID pattern recognition
- New API endpoints: deleteServicePoint, updateServicePoint,
listBeacons, decommissionBeacon, lookupByMac, getBeaconStatus, getProfile
- Wire QR scanner into ScanView with BLE Scan + QR Scan side-by-side
- MAC address lookup on scan to check if beacon already registered
- Updated Xcode project file with new source
Replaces the v2 refactor with a clean v3 rewrite built from the working
pre-refactor code (d123d25). Preserves all battle-tested BLE fixes while
removing dead code and simplifying state management. See schwifty/v3-clean-refactor
branch for full details.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Starting fresh from the working pre-refactor code (d123d25), this is a clean
rewrite that preserves all the hard-won BLE reliability fixes while simplifying
the architecture. Key changes:
What's preserved (battle-tested, working):
- Exact same 16-step write sequence (DeviceName, Frame1, Frame2 iBeacon, Save)
- Same DX-Smart packet format (4E 4F CMD LEN DATA XOR)
- Response gating between writes (1s timeout, matches Android)
- Adaptive delays (1s for frame select/type, 0.8s for UUID, 0.5s base)
- FFE2 missing → full disconnect/reconnect (CoreBluetooth stale GATT cache)
- SaveConfig write-error = success (beacon reboots immediately)
- Disconnect recovery with write position resume
- Multi-password auth (555555, dx1234, 000000)
- Skip device info read (0x30 causes disconnects, MAC is optional)
- Skip extra frame disables (frames 3-6 untouched, fewer writes = fewer disconnects)
What's cleaned up:
- Removed dead device info provisioning code (was already skipped)
- Removed processDeviceInfoForProvisioning (dead code)
- Removed awaitingDeviceInfoForProvisioning flag
- Removed skipDeviceInfoRead flag
- Removed deviceInfoRetryCount (no longer needed)
- Consolidated charRediscovery into handleFFE2Missing()
- Renamed state vars for clarity (dxSmartWriteIndex → writeIndex, etc.)
- Extracted scheduleGlobalTimeout (was inline closure)
- Added cancelAllTimers() helper
- Reduced mutable state from ~30 vars to ~22
1652 lines → 1441 lines (-211 lines, -13%)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When CoreBluetooth renegotiates connection parameters (common at edge-of-range),
it can invalidate cached CBCharacteristic references, causing the characteristics
dictionary to return nil mid-write. This resulted in "FFE2 characteristic lost
during write" failures.
Changes:
- Add resolveCharacteristic() with live service fallback when cache misses
- Implement peripheral(_:didModifyServices:) to handle service invalidation
- Replace all direct characteristics[] lookups with resolveCharacteristic()
- Eliminates force-unwrap on FFE1 notification subscribe
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- PRE_AUTH_DELAY bumped from 0.8s to 2.0s — beacons need more stabilization
time after characteristic discovery before password write
- If disconnect happens during authenticating state, retry connection once
with full re-discovery instead of immediate failure
- Reset authDisconnectRetried flag on new provision and cleanup
DX-Smart beacons drop the BLE connection when a password write (FFE3) arrives
too quickly after service/characteristic discovery. The v2 refactor had a
POST_AUTH_DELAY (1.5s) before writes, but nothing before the auth attempt itself.
Adds PRE_AUTH_DELAY (0.8s) after characteristic discovery + FFE1 subscription
before the first password write. This gives the beacon MCU time to stabilize
after the discovery handshake.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Major cleanup of the BLE provisioning flow:
- Remove frames 3-6 disable steps (no longer overwriting "extra frames")
Only Frame 1 (device info) and Frame 2 (iBeacon) are configured now.
Command count drops from 24 to 16.
- Eliminate 5 layers of retry/reconnect/resume logic:
No more disconnect retry counter (was 5 retries)
No more resume-from-position after reconnect
No more characteristic re-discovery attempts
No more device info read/skip dance
If connection drops mid-write, fail cleanly — let user retry.
- Prevention approach: verify all 3 required characteristics (FFE1/FFE2/FFE3)
are confirmed before starting any writes. No mid-write discovery.
- Add POST_AUTH_DELAY (1.5s) to let beacon stabilize after auth before writes.
- Keep response gating (wait for FFE1 after each write) — this is the key
mechanism that prevents blasting commands faster than the MCU can handle.
- 191 insertions, 476 deletions — nearly half the code removed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Two key changes:
1. Remove frames 3-6 disable commands (was steps 16-23, 8 extra BLE writes).
We only configure Frame 1 (device info) and Frame 2 (iBeacon), then save.
Fewer writes = fewer chances for supervision timeout disconnects.
2. When FFE2 characteristic goes missing after a disconnect, do a full
disconnect → reconnect → re-discover services → re-auth → resume cycle
instead of trying to rediscover characteristics on the same (stale GATT)
connection. CoreBluetooth returns cached results on the same connection,
so FFE2 stays missing. Full reconnect forces a fresh GATT discovery.
Write sequence is now 16 steps (down from 24).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When FFE2 goes missing during writes, the rediscovery path had no
timeout — if CoreBluetooth never called back didDiscoverCharacteristics,
the app would hang at "Re-discovering characteristics..." indefinitely.
Adds a 5-second timeout per rediscovery attempt. If it fires, it either
retries (up to MAX_CHAR_REDISCOVERY) or fails with .timeout instead of
hanging forever.
Root cause: iOS was firing the next GATT command as soon as the BLE write
ACK arrived, without waiting for the beacon's FFE1 notification response.
Android explicitly waits up to 1s for the beacon to respond (via
responseChannel.receive) before sending the next command. This gives the
beacon MCU time to process each command before the next one arrives.
Without this gate, the beacon gets overwhelmed and drops the BLE connection
(supervision timeout), causing the "DX Smart command characteristic" error
John reported after repeated disconnects.
Changes:
- Add awaitingCommandResponse flag + 1s response gate timer
- After each FFE2 write success, wait for FFE1 notification before advancing
- If no response within 1s, advance anyway (some commands don't respond)
- Check for 4E 4F 00 rejection pattern (matches Android)
- Clean up gate timer on disconnect, cleanup, and state resets
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
After 2+ disconnects during provisioning, the beacon's BLE stack can
return incomplete characteristic discovery results. Instead of hard-
failing with "DX-Smart command characteristic (FFE2) not found", we
now re-trigger characteristic discovery (up to 2 attempts) and resume
writing from the saved position once FFE2 is found.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause: DX-Smart CP28 beacons were disconnecting during provisioning
because the 0.3s inter-command delay was too fast for the beacon's MCU.
Frame selection (0x11-0x16) and type commands (0x61, 0x62) trigger internal
state changes that need processing time. Rapid writes caused the beacon to
miss BLE connection events, triggering link-layer supervision timeouts.
Changes:
- Base delay: 0.3s → 0.5s for all commands
- Heavy delay: 1.0s after frame select/type commands (MCU state change)
- Large payload delay: 0.8s after UUID writes (21 bytes)
- Resume delay: 0.5s → 1.5s after reconnect (let BLE stack stabilize)
- Non-fatal skip delay: 0.15s → 0.5s
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Previously, when the beacon disconnected mid-write, the reconnect handler
cleared the entire command queue and reset writeIndex to 0, causing all 24
commands to be re-sent from scratch on every reconnect. This could confuse
the beacon firmware with duplicate config writes and wasted reconnect cycles.
Changes:
- On disconnect during writing, PRESERVE command queue and write index
- After reconnect + re-auth, resume from the last command instead of rebuilding
- Increase MAX_DISCONNECT_RETRIES from 3 to 5 (resume is lightweight)
- Increase inter-command delay from 150ms to 300ms for firmware breathing room
- Increase global timeout from 45s to 90s to accommodate more retries
- Add resumeWriteAfterDisconnect flag to control post-auth flow
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Wire provisioner.progress into assignment sheet UI (was showing static
"Provisioning beacon..." instead of live updates like "Connecting...",
"Authenticating...", "Writing config 1/24...")
- Increase disconnect retries from 2 to 3 with longer backoff (3s/4s/5s)
- Cancel write timeout timer on disconnect to prevent double-failure
- Bump global timeout from 30s to 45s for extra retry headroom
- Improve error message with actionable guidance ("move closer and retry")
The iOS provisioner had no per-write timeout — if a BLE write callback
never came back, the operation hung until the 30s global timeout, by
which point the connection was likely dead. Android uses a 5-second
per-write timeout with withTimeoutOrNull(5000L).
Changes:
- Add 5-second per-write timeout with retry (1 retry per command)
- On timeout: retry once, skip if non-fatal (steps 1-6), or fail
- SaveConfig timeout treated as success (beacon reboots = no callback)
- Reduce inter-write delay from 200ms to 150ms (Android uses 100ms)
- Log negotiated MTU on connect to diagnose packet size issues
- Cancel write timeout on cleanup/succeed/fail to prevent stale timers
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Previously retry logic only caught disconnects during .authenticating
and .writing states. Beacons can also drop during .discoveringServices
(characteristic discovery) and .verifying (broadcast check), which
would bypass retry and immediately hard-fail.
Now all active provisioning phases get the same reconnect retry
treatment with backoff delays.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Instead of immediately failing on disconnect during authenticating or
writing states, retry up to 2 times with backoff. Resets passwordIndex
on reconnect so re-auth starts fresh (fixes issue where burned password
attempts caused retry failures). Also fixes passwordIndex reset in the
device-info safety-net reconnect path.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The DX-Smart 0x30 device info query consistently causes beacon BLE disconnects,
which exhausted the retry counter and failed provisioning. The MAC address is
optional — API falls back to iBeacon UUID as hardware ID. Device info read is
still available in readConfig/check mode where it doesn't block provisioning.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The device info disconnect handler was sharing connectionRetryCount with
the initial connection retry logic. If earlier connection attempts burned
through retries, the device info handler had zero retries left and
immediately hit "retries exhausted" — causing the "Disconnected while
reading device information" error John reported.
Now uses a separate deviceInfoRetryCount (max 2) so device info retries
are independent of connection retries.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The beacon sometimes drops BLE connection during the optional MAC address
query (0x30) after auth. Previously this failed with "Disconnected after
auth during device info read". Now we reconnect and skip the MAC read on
retry, going straight to config write. MAC is nice-to-have, not required.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The comment said "treat as non-fatal" but the code calls fail() — which
is correct behavior since we can't write config without a connection.
Updated comment to accurately describe the fail-with-retry-prompt flow.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add isTerminating flag to guard succeed()/fail() against double invocation
from racing didWriteValueFor + didDisconnectPeripheral callbacks
- Only call cancelPeripheralConnection when peripheral.state == .connected
(avoids triggering spurious didDisconnectPeripheral on already-disconnected peripheral)
- Handle disconnect during device info read (post-auth) with specific error message
- Include state info in unexpected disconnect errors for easier debugging
- Early-return structure in disconnect handler for clearer control flow
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The previous fix only caught the disconnect callback path. But CoreBluetooth
can also fire didWriteValueFor with an error when the beacon reboots mid-ATT
response. This was hitting fail() at the isNonFatalCommand check instead of
being treated as success.
Now handles both paths:
1. didDisconnectPeripheral with state=.writing at last command → succeed()
2. didWriteValueFor error for SaveConfig (last command) → succeed()
Also added detailed state/index logging to disconnect handler for diagnostics.
The DX-Smart CP28 beacon reboots after receiving SaveConfig (0x60) to
persist config to flash. This drops the BLE connection before the write
callback fires, causing the app to report "Unexpected disconnect" even
though the config was successfully saved.
Now we check if we're on the last command (SaveConfig) when disconnect
occurs — if so, treat it as success instead of failure.
Co-Authored-By: Luna <luna@payfrit.com>
Without this reset, if provision() was called first and incremented
passwordIndex, a subsequent readConfig() call would start at the wrong
password index and potentially skip the correct password entirely.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- DX-Smart auth now tries multiple passwords in sequence (555555, dx1234, 000000)
instead of hardcoding a single password. Matches Android behavior for better
compatibility across firmware versions.
- Added ProvisioningError enum with structured error codes (CONNECTION_FAILED,
AUTH_FAILED, SERVICE_NOT_FOUND, WRITE_FAILED, etc.) matching Android's
BeaconConfig error codes. All fail() calls now tagged with codes for better
debugging and error reporting.
- Added ProvisioningResult.failureWithCode case and handling in ScanView.
- Added missing API endpoints that Android has:
- getBusiness() - single business fetch
- getBusinessName() - cached business name lookup
- allocateServicePointMinor() - minor value allocation
- Fixed stray print() in Api.swift to use DebugLog.shared.log() for consistency.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Created UUIDFormatting.swift with .normalizedUUID and .uuidWithDashes
String extensions, replacing 4 duplicate formatUuidWithDashes() methods
and 6+ inline .replacingOccurrences(of: "-", with: "").uppercased() calls
across Api.swift, BeaconScanner.swift, ScanView.swift,
ServicePointListView.swift, BeaconBanList.swift, and BeaconProvisioner.swift.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Modified BeaconProvisioner to read device info (0x30) before writing config
- Extract MAC address from beacon and return in ProvisioningResult
- Use MAC address as hardware_id field (snake_case for backend)
- Reorder scan view: Configurable Devices section now appears first
- Add debug logging for beacon registration
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Fix critical packet format bugs matching SDK: frame select/type/trigger/disable
commands now send empty data, RSSI@1m corrected to -59 dBm. Add DebugLog,
read-config mode, service point list, and dev scheme.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
