[Accessories] 6 - Validate connected riding

[KacperKozak]

Parent

#475

What to build

Choose and connect the physical light driver when hardware exists, then verify the complete sensor + Board + light flow in current Android/iOS development builds. Start with controlled stationary checks, then rider-assisted measurements. Tune documented PoC timings/thresholds from evidence. This is the hardware-completion boundary; fake output tests do not satisfy it.

Type: HITL. Complexity: high. Blocked by: #479, #480 and #483. Stories: 4, 11–17, 20–25.

Likely files

• vescape-accessories: lib/ and src/ — real LED driver and rear-light device composition from [Accessories] 7 - Separate firmware device profiles #483/[Accessories] 5 - Drive brake-light states #480.
• vescape-accessories: platformio.ini — chosen driver's build configuration if needed.
• vescape-accessories: docs/accessories.md — actual wiring and measured configuration.
• vescape-accessories: docs/flashing.md — established upload procedure.
• docs/accessory-protocol.md — validated timings and failure evidence.
• docs/accessories.md — final PoC behavior and limitations.
• docs/connectionState.md — existing lifecycle expectations.

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.

Device and build validation

Use two separate ESP32 devices: one clearance profile and one rear-light profile. Select the actual LED hardware with the user and implement its driver behind #480's output interface. Record the selected board, pins, power requirements and wiring in the hardware repository. Keep fake output explicitly limited to development/tests.

Compile both profiles and flash the intended firmware to each device using the documented automatic upload path. Record firmware revisions/profiles and app revisions/platforms. Verify that the clearance manifest advertises its sensor and the light manifest advertises its light, and that ordinary reboot/update retains accessory identity and saved enrollment.

Verify measurement standby while parked, preview-only sampling, riding sampling and smooth release on sensor loss. Verify actual dim/bright/blinking light output, parked off/glow, preview restoration and firmware-owned unavailable behavior. Exercise both devices concurrently with the Board while the app is locked/backgrounded on Android and iOS. Distinguish accessory power loss, app termination or stopped renewals, and Board telemetry loss. Confirm fresh-session recovery without old commands or samples being replayed.

Record measured sampling cadence, latency, missing readings and light response under concurrent BLE traffic. Tune documented defaults only from recorded results. Desktop tests and firmware compilation alone cannot close this task.

Acceptance criteria

• confirm current workspace firmware and app builds, recording revisions and selected profiles.
• both firmware profiles compile; separate physical sensor and light devices run their intended profiles.
• real LED driver/wiring are documented; the sensor firmware does not advertise a dummy light.
• reboot/update preserves identity; reconnect starts a fresh session and restores settings.
• parked standby and preview demand behave correctly on the real sensor.
• observe real light states and preview.
• locked-screen concurrent BLE operation is measured.
• sensor and app power-loss cases produce expected fallback.
• Board Move handoff behaves correctly.
• record measured sampling/latency and remaining limits.
• no claims based on stale installed bundles.

Blocked by

• [Accessories] 4 - Apply ground-clearance tilt #479
• [Accessories] 5 - Drive brake-light states #480
• [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] 5 - Drive brake-light states #480