Schwifty b88dded928 fix: resolve write ACK on didWriteValueFor instead of waiting for notification ... 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>		2026-03-23 02:16:24 +00:00
..
BlueCharmProvisioner.swift	fix: connection callback bug + add provisioning diagnostics	2026-03-22 23:12:06 +00:00
DXSmartProvisioner.swift	fix: resolve write ACK on didWriteValueFor instead of waiting for notification	2026-03-23 02:16:24 +00:00
FallbackProvisioner.swift	fix: connection callback bug + add provisioning diagnostics	2026-03-22 23:12:06 +00:00
KBeaconProvisioner.swift	fix: add real-time status updates to KBeacon provisioner + fix disconnect handler	2026-03-23 00:40:43 +00:00
ProvisionerProtocol.swift	fix: connection callback bug + add provisioning diagnostics	2026-03-22 23:12:06 +00:00
ProvisionError.swift	feat: complete rebuild of PayfritBeacon iOS from scratch	2026-03-22 17:13:36 +00:00