The Bike page provides six-digit PIN setup, change, removal, local screen locking, bike locking where supported, and a locked-screen timeout of 15/30/60/120 seconds (30 by default). New PINs require confirmation; changing or removing one requires the existing code. There is no default PIN. Keep the chosen code available: no PIN recovery or bypass UI is implemented.
The security NVS namespace holds a versioned record containing a random 16-byte salt, SHA-256 PIN digest, lock intent, timeout and failed-attempt count. Plaintext PINs are not stored or logged. The numeric BLE proxy passkey is held in RAM after PIN setup or a successful local unlock; boot with a configured code requires local unlock before the secured proxy is available. Five incorrect entries impose a 30-second cooldown; reboot preserves the failure threshold and starts a fresh cooldown. Read errors or malformed records fail closed. Storage operations must succeed before PIN changes or an explicit bike-lock request can proceed.
Once a PIN exists, boot requires that code to access the display. This local screen lock does not itself send a bike command. An explicit bike lock persists intent before queuing LOCK. Bike lock/unlock requests require fresh stationary telemetry, a supported stopped state, zero controller fault, low motor current, a ready connection and exclusive access without a phone proxy lease. The bridge pauses while the local screen is locked. An observed disabled bike also locks the display when a PIN is configured.
LOCK (12) sends an explicit boolean state, not a toggle. wheel-e uses package 101. WFB uses package 102 based on its documented command enum and Float-family handler semantics; this WFB behavior has not been verified against the vendor firmware. The UI waits for telemetry from the same connection after the command, including a settling interval. Only DISABLED confirms locking; a stopped non-disabled sample confirms unlocking. Disconnection, stale samples or a five-second timeout leave bike status unconfirmed and the PIN screen in place. The user can retry locking; unlock requires another PIN entry. No automatic command replay occurs across reconnects.
After the locked-screen idle timeout, brightness is set to zero. A valid contact wakes the display to the user's saved brightness and is swallowed until release. Partial PIN input is cleared on sleep/wake. Failed touch reads do not manufacture a release. Both PIN and sleep overlays consume input above the underlying UI, and active gestures are cancelled when the PIN overlay opens.
The same code controls authenticated pairing to this display's BLE proxy. A change/removal revokes old phone bonds and disconnects old security sessions; it does not alter the upstream device's independent PIN/bond.
This PIN protects this display's controls and proxy. It is not a native bike PIN or a hardware immobilizer: another client talking directly to the bike can issue its own commands, and physical flash access is outside this local access-control mechanism. Validate actual propulsion-disable behavior on each supported firmware before relying on the bike lock.