[Accessories] 5 - Drive brake-light states

[KacperKozak]

Parent

#475

What to build

Open brake-light configuration and parked preview from its accessory row in the Board selector's Accessories section. Preserve automatic saving and current-Board scope; do not introduce a Settings-only entry or nest the light under a Board.

Deliver speed-derived native braking through acknowledged state messages into the separate firmware light capability, plus sensitivity, parked preference, and actual protocol preview in the app. Use a fake output driver in automated tests until LED hardware is chosen. Firmware rendering stays replaceable behind the state receiver.

Type: AFK. Complexity: high. Blocked by: #477 and #483. Stories: 20–24, 26.

Likely files

• modules/vescape-core/android/src/main/java/expo/modules/vescapecore/protocol/VescTelemetryModels.kt — available speed and Board state.
• modules/vescape-core/android/src/main/java/expo/modules/vescapecore/connection/BoardSessionController.kt — native telemetry consumer wiring.
• modules/vescape-core/ios/connection/BoardSessionController.swift — peer wiring.
• modules/vescape-core/src/index.ts — settings/status bridge contract.
• src/modules/accessories/ and src/app/accessories/ — existing accessory detail, settings and route composition.
• vescape-accessories: lib/ and src/ — capability handlers, hardware drivers and explicit device composition extracted by [Accessories] 7 - Separate firmware device profiles #483.
• vescape-accessories: platformio.ini — separate rear-light build profile and scoped dependencies.
• docs/accessory-protocol.md — semantic output and preview rules.

Firmware scope

Build on #483's shared runtime and rear-light development profile. Implement a brake-light capability with a replaceable output driver. Keep BLE transport, session validation, duplicate handling and lease expiry shared with the sensor firmware. Do not copy the sensor project or put capability-specific behavior back in the main entrypoint.

The renderer maps riding to dim red, braking to brighter red, hard braking to blinking red, and not riding to the selected off/glow preference. Firmware owns disconnected, expired-command and unavailable-telemetry appearance. Keep unavailable telemetry distinct from an expired app lease. State renewals must preserve an unchanged animation's phase. Preview uses the same command and lease path.

Until physical LED hardware is selected, use a fake output driver that exposes observable render output and timing in deterministic tests. Keep the development build clearly identified; completing this task does not establish real LED behavior. Physical driver selection, wiring and validation belong to #481.

Implementation hints

• The parent PRD includes the complete protocol and product-design snapshots. Local docs may not yet exist on the implementation branch; materialize them from the parent when needed.
• PR Vescape Sensors: BLE link to the ESP32 sensor module #441 is prior art at commit 91ebeaf0fdf3daa8a8151314048de9e663b9149c; paths marked PR Vescape Sensors: BLE link to the ESP32 sensor module #441 are absent from the planning checkout.
• Paths prefixed vescape-accessories: belong to vescape-app/vescape-accessories. Coordinate both repositories for firmware/app protocol changes.
• Keep native Android/iOS contracts aligned with parity links. Reuse native lifecycle and storage contracts; JS renders state and sends intents.

Acceptance criteria

• Open brake-light configuration and parked preview from its accessory row in the Board selector's Accessories section. Preserve automatic saving and current-Board scope; do not introduce a Settings-only entry or nest the light under a Board.

• forward/reverse deceleration traces produce normal/braking/hard-braking states.

• constant speed does not indicate braking.

• gaps clear detector history and send unavailable.

• sensitivity and parked preference persist automatically.

• preview restores automatic state.

• renewals do not restart animation.

• expired app commands trigger firmware fallback. Document initial filtering and thresholds as PoC defaults.

• The rear-light profile builds independently without the VL53L0X dependency and advertises only its implemented light capability.

• Fake-driver tests cover output intensity/blink transitions, unchanged-state renewal, preview, unavailable telemetry, expiry, disconnect and fresh-session recovery.

• Firmware protocol tests and both XIAO profile builds pass after integration.

Blocked by

• [Accessories] 2 - Save and reconnect accessories #477
• [Accessories] 7 - Separate firmware device profiles #483

Related

• [Accessories] 1 - Discover compatible accessories #476
• [Accessories] 2 - Save and reconnect accessories #477
• [Accessories] 3 - Calibrate live ground clearance #478
• [Accessories] 4 - Apply ground-clearance tilt #479
• [Accessories] 6 - Validate connected riding #481

[KacperKozak]

Implemented in 1d0cf67 on accessories; firmware fcbd435 on vescape-accessories/main. Physical LED output, device UI and locked-screen BLE validation remain in #481.