BLE: send the current state when the app subscribes
维护者通常 1 天内回复
已经有一个关联 PR 被合并了。
- #65 来自 @Tichael —— 已合并
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 停滞
- 技术栈
- rust
- 领域
- embedded-iot
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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
notifysends nothing to a peer that hasn't subscribed and returnsOk(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.
- 主要语言
- Rust
- 星标
- 1
- 派生
- 0
- 平均合并
- 11 小时 26 分钟
- 30 天内合并 PR
- 18
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
OpenCarControls/firmware 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 51/100
OpenCarControls/firmware#68 ·
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
OpenCarControls/firmware#55 ·
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
OpenCarControls/firmware#54 ·
维护者通常 1 天内回复
-
First-setup pairing window is too short and stays open after the first bond可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭enhancement
难度 4/5 3-5 天 新手友好度 55/100
OpenCarControls/firmware#53 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
OpenCarControls/firmware#51 ·
维护者通常 1 天内回复
查看 OpenCarControls/firmware 的全部 Issue
相似的 Issue
-
checkpoint/verify/rebuild_indexes on a thread holding a WriteTransaction deadlock instead of INT-001未关闭bug known-issue
难度 2/5 1-3 小时 新手友好度 74/100
project-minigraf/minigraf#734 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 1/5 1 小时以内 新手友好度 88/100
维护者通常 4 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 64/100
Nimblesite/lspkit#26 ·
维护者通常 1 天内回复