Fix Zwift Click V2: keepalive + adaptive unlock detection (no 24h Zwift requirement) - #4743
Open
cagnulein wants to merge 1 commit into
Open
Fix Zwift Click V2: keepalive + adaptive unlock detection (no 24h Zwift requirement)#4743cagnulein wants to merge 1 commit into
cagnulein wants to merge 1 commit into
Conversation
…quirement
The Click V2 RIGHT controller alone drops after ~56s idle (HCI 0x08 supervision
timeout) because it deep-sleeps. The LEFT is the anchor: connecting it too keeps
the RIGHT solid. Both are already connected by our bluetooth.cpp scan; the
missing piece was the RideOn keepalive that prevents deep-sleep.
Changes:
- Keepalive: re-send RideOn every 3s (LEFT and RIGHT types; NONE = old Click
is unchanged). Prevents the 0x08 HCI supervision timeout that caused the drop.
- ff0400 unlock-ack to LEFT on initial handshake: OpenBikeControl (commit
2cb079fc) discovered that a device previously unlocked by Zwift recognises
this short ack and stays in unlocked mode. No-op on a locked device.
- Unlock detection via SYNC_TX echo: when unlocked the device echoes back the
RideOn handshake starting with 0x52 ('R') on SYNC_TX; a locked device sends
a crypto challenge (0xFF). Sets deviceUnlocked flag and shows toast when the
LEFT controller is confirmed unlocked, so the user gets feedback. When locked
the LEFT implicit fallback is right-only (our 0x23 parser already ignores
LEFT frames that carry no decodable button data).
Result: RIGHT buttons work indefinitely without ever opening Zwift. LEFT buttons
work too when the device was unlocked by Zwift within the last ~24h (ff0400 ack
maintains the hardware-persistent unlock state across reconnects).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Zwift Click V2 required opening Zwift every ~24h to re-unlock the device. Two root causes:
0x08supervision timeout and a dropped BLE link. Without keepalive the user would lose the connection regularly.Solution
Analysis of MaximumTrainer/MaximumTrainer_Redux#307 and OpenBikeControl/bikecontrol commit 2cb079fc revealed the following:
0x23button frames decode without any crypto.bluetooth.cppalready connects both; the missing piece was the keepalive.2cb079fc) discovered that an already-unlocked device recognises a shortff 04 00ack on SYNC_RX and stays in unlocked mode across reconnects.0x52('R') on SYNC_TX; a locked device sends a crypto challenge (0xFF).Changes (
zwiftclickremote.cpp/.h)ff0400to LEFT on initial handshakedeviceUnlockedflag + SYNC_TX echo detectionBehaviour after this fix
ff0400ack keeps it unlocked across reconnects; user sees "Left controller unlocked!" toast ✓0x23parser already ignores LEFT frames when the device is locked ✓Test plan
🤖 Generated with Claude Code