结论：设备设置页、配对/订阅状态页与 Firehose 统计页都是观察窗口，不是授权与执行本身。配对二维码每 300 秒刷新、订阅状态约每 5 秒轮询、Firehose 统计约每 30 秒拉取；但页面上显示「已配对」「ACTIVE」并不证明服务端已授权、也不证明数据正在上传。源码快照里，Firehose 页面甚至没有任何「启用上传」参数或上传控制调用，它只是按网络条件给出提示。
设备页能做什么，不能证明什么
设备页提供的是有限的本地操作：查看设备标识（来自设备 ID 与硬件序列号）、预览座舱摄像头、复位标定、重启或关机，以及查看培训与监管信息。这些入口都有前置条件——座舱摄像头预览在两种布局上都要求处于停车（offroad）状态才使能，而且预览并不校验摄像头标定精度。
「复位标定」尤其容易被误解。它在请求时与确认时都会检查是否处于驾驶接管（engaged）状态，然后删除四个学习缓存键，并写入一次行车周期请求；被删除的四个键分别由四个后台学习进程读取并重建。关键是：这不是把传感器硬件恢复出厂，而且四个删除操作与周期请求不是事务——断电或进程并发时的一致性并未被验证。
重启与关机同样是「请求」而非「执行」：界面做二次确认并检查非 engaged，然后写入对应的电源请求消息，最终执行由系统管理进程与平台决定。大屏在停车时才显示关机按钮，mici 布局在未点火时显示。
配对与订阅：三套显示门不等于授权
配对二维码由设备 ID 调用接口获取令牌后组装，指向配对地址，并每 300 秒刷新一次；订阅状态则在 UI 初始化后由后台线程在「非行车且屏幕唤醒」时查询设备与账户接口，约每 5 秒检查一次。这里有两个必须说清的边界：其一，二维码本身包含可用于配对的令牌，应按敏感凭据处理，避免日志、截图或远程投屏无意泄露；其二，接口失败时会保留旧状态并记录错误，因此离线页面可能显示的是缓存值，不能当作实时云端授权结果。
首页还有一处容易看错的细节：订阅宣传组件用的是「是否订阅」判断，而设置入口组件用的是另一个「是否已配对」判断。两个门不同，所以一台已配对但没有订阅的设备，可能同时看到升级宣传和 Firehose 入口。此外，配对按钮的显示门只检查系统时间是否有效——失败时提示连接 Wi-Fi，成功就弹出配对界面，它并不检查 Wi-Fi 或互联网是否真的可达，也不检查设备标识或服务端令牌签发结果。
| 界面元素 | 看起来代表 | 源码里的实际含义 |
|---|---|---|
| 配对二维码 | 配对完成 | 仅生成含令牌的配对链接，每 300 秒刷新；是否授权由服务端决定 |
| 订阅摘要 / 升级宣传 | 订阅有效 | 读取缓存的订阅类型；接口失败时保留旧状态，可为离线缓存 |
| 首页 Firehose 入口 | 正在上传数据 | 由「是否已配对」门控制，与订阅、上传状态均无关 |
| Firehose 页面 ACTIVE | 上传任务运行中 | 仅表示网络类型非空且非计费网络，是网络条件提示 |
Firehose 页面只是网络条件提示
Firehose 统计页在构造时读取本地缓存并启动后台线程，线程在非行车且屏幕唤醒时约每 30 秒从设备接口拉取统计。注意：这个线程由组件构造启动，不是用户进入页面才启动。
页面状态的判定非常克制：只有当设备状态里的网络类型非空、且网络非计费（networkMetered=False）时显示 ACTIVE，否则显示 INACTIVE。更重要的是，源码中没有 Firehose 页面专属的「启用上传」参数，也没有上传控制调用。因此页面上写着 ACTIVE，只能说明当前网络条件符合提示规则，不能证明上传任务正在运行、远端已接收，或数据被用于训练。
| 刷新对象 | 周期 | 触发条件 |
|---|---|---|
| 配对二维码 | 约 300 秒 | 配对界面打开且尚未完成配对 |
| 订阅 / 配对状态 | 约 5 秒 | 非行车且屏幕唤醒的后台线程 |
| Firehose 统计 | 约 30 秒 | 非行车且屏幕唤醒的后台线程 |
真正的上传器在页面之外
选择与发送上传文件的是后台上传器，它按已上传标记、锁文件、文件优先级与计费网络限制挑候选文件，再从设备状态读取网络条件执行上传。这里也有一个反直觉的边界：计费网络并非一概不上传，部分小文件或被请求的路段仍可能被选中。换句话说，上传策略由上传器与日志保留策略决定，Firehose 页面既不替代也不覆盖这套策略。
插件化与台架验证要覆盖什么
如果要做插件化，边界应这样划：设备能力插件声明屏幕、座舱相机、监管文件、系统电源与校准缓存的可用性，实际的复位/重启/关机要经独立服务验证驻车、驾驶状态与用户确认，而不是只读界面上那个 engaged 布尔值；配对/订阅插件只负责短期令牌展示与状态观察，服务端仍是授权源；上传插件以明确的队列、网络预算、隐私许可与服务端确认结果为契约，说明/统计页只能消费状态，不能越过日志保留或计费网络策略直接读取或上传车内数据。台架验证至少覆盖：确认弹窗期间由驻车变成 engaged、四个缓存删除中途断电、二维码令牌过期、订阅接口离线与重试、计费网络上的文件选择，以及重启/关机的执行与失效恢复。
常见问题
Firehose 页面显示 ACTIVE，是不是就在上传数据？
不是。该状态只依据设备状态里的网络类型非空且网络非计费来判定，是网络条件提示；源码中没有 Firehose 页面专属的启用上传参数或上传控制调用，真正的上传由后台上传器按文件优先级与计费网络限制自行选择执行。
点「复位标定」会把传感器恢复到出厂状态吗？
不会。复位只是删除四个学习缓存键并写入一次行车周期请求，这些键由对应的后台学习进程读取并重建，属于软件层面的重新学习，不是把传感器硬件恢复出厂设置。
配对二维码可以截图或投屏吗？
不建议。二维码包含可用于配对的令牌，应按敏感凭据处理，避免在日志、截图或远程投屏中无意泄露；令牌的实际有效期与服务器授权规则需要由后端验证。
设备显示「已配对」，就说明订阅有效吗？
不能这样推断。首页的订阅宣传与设置入口使用两个不同的判断门，已配对但未订阅的设备可能同时看到升级宣传与 Firehose 入口；订阅摘要读取的是缓存状态，接口失败时会保留旧值，不能当作实时云端授权结果。
延伸阅读
- 设备身份注册：从序列号到云端账户的绑定链 —— 补全设备标识与账户绑定的完整链路。
- 上传队列的持久化与重试：断网时数据去哪了 —— 讲上传器在断网与重试下的真实行为。
- 二维码配对与 eSIM 管线：一次扫码背后的分支 —— 从扫码入口看配对流程的分支与失败态。
- OBD AI 插件化平台：端侧解析为什么必须插件化 —— 插件边界与本文「能力插件 / 上传插件」的划分呼应。
参考资料
- 项目 02 ——
openpilot-research/DEVICE_PAIRING_FIREHOSE_DEEP_DIVE.md（设备页、配对与订阅状态、Firehose 页面与上传器、插件边界）
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有周期、阈值与配置均出自源文档，标注为未验证的结论保留其原有边界；页面显示状态与外部服务/硬件是否已执行，本文严格区分。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复