Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

BLE: send the current state when the app subscribes

Open
  • Is something wrong?
#58 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Tichael is already working on this.

Since Oct 23, 2026.

  • #65 by @Tichael — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
rust
Domain
embedded-iot

Research direction

Read the CCCD write handling for the device→app characteristic and trouble-host's attribute.rs, especially should_notify, to understand why notifications are dropped before subscription. Trace how the current basic and advanced state is sent, then check the WiCAN virtual-car pairing and reconnect flows described in the issue. Done means both flows receive the full state immediately after notifications are enabled; linked pull request #65 is already open.

Written by the indexing model from the issue text.

Description

Problem

The first state update after a BLE connection is usually lost:

  • The firmware holds state updates until the link is encrypted, then sends the held one right away.
  • The app subscribes to the device→app characteristic only after that (the pairing wizard subscribes once its bond-probe write succeeds; the dashboard transport subscribes after connecting).
  • trouble-host's notify sends nothing to a peer that hasn't subscribed and returns Ok (attribute.rs, should_notify), so the update is dropped silently.

The app then waits for the next periodic update (every 5 s on the virtual car; on E-GMP it depends on CAN traffic). The pairing wizard waits only a limited time for that first message, so pairing could time out even though the bond was made. That happened while testing #52 and OpenCarControls/mobile-app#41. The 500 ms sleep after encryption, which #52 removes (#28), used to hide this race most of the time.

OpenCarControls/mobile-app#41 makes the wizard wait 15 s as a safety margin; this issue is the actual fix.

Proposal

When the app writes the CCCD of the device→app characteristic to enable notifications, send the current full state (basic + advanced) to that connection. Pairing then gets its first message straight away, and the dashboard shows data at once on every reconnect.

Testing

On the WiCAN with the virtual car: pair from the app and check the wizard finishes within a second of the bond; reconnect and check the dashboard fills straight away.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
10h 56m
Merged PRs (30d)
15

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenCarControls/firmware

All issues in OpenCarControls/firmware

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.