使用cordova-plugin-ble-central读取BLE-9909数据时出现status=133错误

针对你使用cordova-plugin-ble-central读取YINMIK BLE-9909仪表FF01服务下FF02特征时出现的status=133错误，结合设备文档、代码和日志，给出以下排查方向：

• 严格遵循设备协议的操作顺序
  设备文档明确要求：连接成功后需先订阅FF02特征，再执行读取操作。你的代码目前直接调用ble.read，跳过了订阅步骤。BLE浏览器可能自动完成了订阅流程，因此能正常读取。建议修改代码：先调用ble.startNotification订阅FF02特征，之后再执行读取，或者直接通过通知回调接收数据（多数BLE设备会通过主动推送通知返回数据，而非被动读取）。

• 替换短UUID为完整格式
  代码中使用的短UUID（FF01/FF02）可能在部分Android设备上存在解析问题。尝试替换为完整UUID：

  • 服务UUID：0000ff01-0000-1000-8000-00805f9b34fb
  • 特征UUID：0000ff02-0000-1000-8000-00805f9b34fb

• 避免频繁触发GATT操作
  你当前用505ms定时器循环发起ble.isConnected+ble.read，会导致GATT命令队列堆积。Android BLE的GATT操作是串行执行的，未完成的操作会阻塞后续请求，进而引发status=133错误。建议优化逻辑：

  1. 连接成功后仅初始化一次订阅/读取流程；
  2. 依赖ble.startNotification的回调接收数据，而非定时轮询读取；
  3. 若必须轮询，需确保上一次ble.read的回调执行完成后，再发起下一次请求。

• 验证FF02特征的属性支持
  调用ble.discover接口获取FF02特征的详细属性，确认其是否包含PROPERTY_READ。若特征仅支持通知（PROPERTY_NOTIFY），直接调用ble.read必然失败，此时应通过ble.startNotification接收数据。

• 排查插件与系统兼容性

  1. 确认cordova-plugin-ble-central为最新版本，旧版本可能存在自定义UUID处理的bug；
  2. 在不同Android版本的设备上测试，部分系统版本对BLE自定义服务/特征的处理存在差异。

• 对比BLE浏览器的操作流程
  开启Android的Bluetooth HCI snoop log，捕获BLE浏览器成功读取FF02特征的完整流程，与你的应用操作流程对比，重点关注：是否存在订阅步骤、UUID格式、操作间隔、GATT命令顺序等差异。

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