Chrome Web Bluetooth连接Wahoo Kickr Core自定义蓝牙服务失败求助

问题场景 #

正在开发用于控制Kickr Core智能骑行台目标输出功率的网页应用，过程中碰到两类连接故障：

• 前期尝试对接标准fitness_machine蓝牙配置时失败，确认该型号骑行台不支持这个标准配置，改用Wahoo自定义Kickr私有配置时仍无法正常连接
• 已交叉核对Wahoo自定义服务的UUID值：文档记载的A026EE07-0A7D-4AB3-97FAF1500F9FEB8B，与通过chrome://bluetooth-internals工具格式化后得到的a026ee07-0a7d-4ab3-97fa-f1500f9feb8b完全匹配，仍出现两类报错：
  1. 用该UUID作为过滤条件调用requestDevice({filters: [uuid]})时，蓝牙连接弹窗内无任何设备可列出
  2. 改用acceptAllDevices: true模式调用requestDevice({ acceptAllDevices: true, optionalServices: [uuid] })时，弹窗可正常显示骑行台，但选中设备后无法检索到对应服务，系统提示服务不存在

可尝试的排查方向 #

• 调整设备搜索的过滤逻辑
  • Web蓝牙API的设备过滤仅会匹配设备初始广播包中主动通告的服务UUID，很多Wahoo设备的私有服务并不会在广播阶段对外披露，这是单UUID过滤时搜不到设备的核心诱因
  • 放弃纯UUID过滤，改用设备名称前缀作为筛选条件，比如Kickr系列的广播名通常以KICKR、KICKR CORE开头，构造过滤条件[{ namePrefix: "KICKR" }]即可跳过广播UUID匹配的限制，正常搜索到设备
• 校验Web蓝牙的服务授权流程
  • Chromium内核浏览器对非标准自定义蓝牙服务有严格的权限校验：自定义UUID必须全量传入optionalServices参数，仅匹配设备的连接请求而不提前声明服务权限时，浏览器会自动隐藏所有未声明的服务，直接返回服务不存在的报错
  • 逐字符核对传入的UUID格式，确认没有字符串截断、大小写转换错误、格式简写的问题——哪怕UUID的一位字符输入错误，都会导致权限校验不通过，服务被浏览器拦截
• 确认骑行台的服务开放前置条件
  • Wahoo Kickr系列的私有服务不会在上电后立刻开放，需要满足两个前提才会解锁：
    • 骑行台没有被其他蓝牙设备（官方App、骑行软件、码表等）占用连接，已有设备连接时，其他主机无法访问私有控制服务
    • 骑行台完成上电自检进入就绪状态，部分固件版本会在上电后的前30秒关闭私有服务，避免和初始的配对流程冲突
• 排查固件版本带来的UUID变更
  • 公开文档记载的UUID可能对应早期固件版本，新版Kickr Core的固件可能对私有服务UUID做过调整。可以在chrome://bluetooth-internals中直接连接骑行台，枚举所有可访问的GATT服务列表，优先匹配具备功率控制特征的服务，不要完全硬套旧文档的UUID值
• 清除浏览器的蓝牙权限缓存
  • 多次失败的连接请求会让浏览器缓存旧的权限配置，把自定义服务从允许访问列表中移除。可以清除当前站点的所有蓝牙权限，完全重启浏览器后再重新发起连接请求，排除缓存导致的权限拦截

内容的提问来源于stack exchange，提问作者Roaders