Python SDK 0.22.0 (PyPI): WirelessGoPro.open() never completes on HERO10 (works on main; please publish a release)

[69k9zb628r-sys]

First ensure you are using a camera that is currently supported by Open GoPro. Any other tickets will be rejected.

HERO10 Black is supported (minimum firmware v01.10.00). Tested on v01.62.00.

Component

• SDKs (Python)

Describe the bug
With open-gopro 0.22.0, the latest release on PyPI, WirelessGoPro.open() never completes against a HERO10 Black. This happens even with interfaces={WirelessGoPro.Interface.BLE}.

The same script on main (0f96357, version 0.23.0) opens in about 4 seconds. The fix exists but has not been released, so anyone installing from PyPI hits this. It looks like a remaining case of #756.

Same camera, same Mac, run back to back:

SDK	Result
0.22.0 (PyPI), bleak 0.22.3	open() never returns. Stopped by a 100 s budget after two Error while opening: TimeoutError() retries. An earlier run with no budget logged nothing for more than 3 minutes on its third attempt.
main @ 0f96357 (0.23.0), bleak 2.1.1	open() completes in 4.0 s. gopro.cohn.is_supported is False. Hardware info and API version queries succeed.

Cause in 0.22.0

1. HERO10 replies to the COHN status registration right away, on Query Response, with 02:f5:02. The SDK parses this as FeatureId.QUERY / ErrorCode.INVALID_PARAM.
2. _send_ble_message then raises RuntimeError("[FeatureId.QUERY::ActionId.RESPONSE_GET_COHN_STATUS] received incorrect response: [FeatureId.QUERY]") (gopro_wireless.py line 804).
3. CohnFeature._track_status catches only GoProError, so nothing sets _ready_event.
4. wait_until_ready() times out after 30 s, and open() disconnects and retries.

On main, the same camera reply comes back as GoProError("Failed to start receiving updates ==> FeatureId.QUERY::ActionId.RESPONSE_GET_COHN_STATUS") from GoProObservable. _track_status handles that by marking COHN unsupported. The log shows Failed to start COHN feature: ... Camera may not support COHN.

To Reproduce

1. HERO10 Black on firmware v01.62.00, already paired.
2. Python 3.13.15 on macOS 27.0: pip install open-gopro==0.22.0
3. Run:

import asyncio
from open_gopro import WirelessGoPro

async def main() -> None:
    # "XXXX" = last 4 digits of the camera serial (its BLE name suffix)
    async with WirelessGoPro("XXXX", interfaces={WirelessGoPro.Interface.BLE}) as gopro:
        print((await gopro.ble_command.get_hardware_info()).data)

asyncio.run(main())

4. open() never returns. Each attempt logs Error while opening: TimeoutError() 30 s after Waiting for COHN to be ready.

Expected behavior
open() completes over BLE on a camera that does not support COHN, and COHN is marked unsupported. This is what main already does.

Workaround for 0.22.0
Make CohnFeature.wait_until_ready return immediately (monkeypatch it before calling open()). After that, every BLE query I tried works: statuses, settings, setting capabilities, presets, hardware info, and date/time.

Logs
DEBUG log from 0.22.0, excerpted. Multi-line message dumps are condensed to one line, and device identifiers are removed.

MainThread:01:01:15.726 gopro_wireless.py  789 INFO  | <<<<--  "id": "ActionId.REQUEST_GET_COHN_STATUS", "feature_id": "FeatureId.QUERY", "uuid": "Query", "register_cohn_status": "1"
MainThread:01:01:15.726 gopro_wireless.py  793 DEBUG | Writing to [Query] UUID: 20:04:f5:6f:08:01
MainThread:01:01:15.778 gopro_wireless.py  409 INFO  | Using Open GoPro API version 2.0
MainThread:01:01:15.778 cohn_feature.py     75 DEBUG | Waiting for COHN to be ready
MainThread:01:01:15.837 gopro_wireless.py  742 DEBUG | Received response on BleUUID [Query Response]: 02:f5:02
MainThread:01:01:15.837 response.py        348 DEBUG | BleRespBuilder identified response: FeatureId.QUERY
MainThread:01:01:15.837 gopro_wireless.py  711 INFO  | -->>>>  "id": "FeatureId.QUERY", "status": "ErrorCode.INVALID_PARAM", "protocol": "Protocol.BLE"
MainThread:01:01:15.839 gopro_wireless.py  803 ERROR | [FeatureId.QUERY::ActionId.RESPONSE_GET_COHN_STATUS] received incorrect response: [FeatureId.QUERY]
MainThread:01:01:45.779 gopro_wireless.py  438 ERROR | Error while opening: TimeoutError()
MainThread:01:01:45.792 gopro_wireless.py  394 INFO  | Opening BLE connection...
MainThread:01:01:51.419 cohn_feature.py     75 DEBUG | Waiting for COHN to be ready
MainThread:01:02:21.420 gopro_wireless.py  438 ERROR | Error while opening: TimeoutError()
MainThread:01:02:21.426 gopro_wireless.py  394 INFO  | Opening BLE connection...
MainThread:01:02:25.081 gopro_wireless.py  626 INFO  | Waiting for camera to be ready for communication
(no further output for >3 minutes)

Same step on main @ 0f96357:

WARNING  Received non-success status: ErrorCode.INVALID_PARAM                      gopro_wireless.py:837
WARNING  Failed to start COHN feature: Failed to start receiving updates ==>
         FeatureId.QUERY::ActionId.RESPONSE_GET_COHN_STATUS. Camera may not support COHN.   cohn_feature.py:103
INFO     Camera configured.                                                        gopro_wireless.py:422

Hardware

• Camera: HERO10 Black, firmware H21.01.01.62.00, Open GoPro API 2.0
• Desktop: MacBook Pro, macOS 27.0 (26A428), Python 3.13.15

Additional context
Could main (0.23.0) be published to PyPI? Until it is, pip install open-gopro gives HERO10 users an SDK that cannot connect.

[69k9zb628r-sys]

Follow-up: I found a second, intermittent failure mode caused by the same COHN status request on 0.22.0. The setup is unchanged (HERO10 Black v01.62.00, macOS 27.0, Python 3.13.15, bleak 0.22.3).

In this run the SDK sent the status-update registration and the COHN status request back to back on the Query characteristic, before either response arrived. Each response was then delivered to the wrong waiter, one request behind (DEBUG log, excerpted):

15:52:21.095 Writing to [Query] UUID: 20:02:53:0a                       (QueryCmdId.REG_STATUS_VAL_UPDATE)
15:52:21.114 Writing to [Query] UUID: 20:04:f5:6f:08:01                 (ActionId.REQUEST_GET_COHN_STATUS)
15:52:21.147 Received response on BleUUID [Query Response]: 05:53:00:0a:01:00
15:52:21.150 ERROR [FeatureId.QUERY::ActionId.RESPONSE_GET_COHN_STATUS] received incorrect response: [QueryCmdId.REG_STATUS_VAL_UPDATE]
15:52:21.208 Received response on BleUUID [Query Response]: 02:f5:02  (FeatureId.QUERY, INVALID_PARAM)
15:52:23.108 Writing to [Settings] UUID: 20:03:5b:01:42                 (SettingId.LED = keep-alive, value 66)
15:52:23.156 ERROR [SettingId.LED] received incorrect response: [FeatureId.QUERY]
15:52:23.157 Received response on BleUUID [Settings Response]: 02:5b:00

After that, the log stayed silent and open() made no progress for more than 90 s, so I stopped it. The keep-alive going through ble_setting.led may explain the SettingId.LED timeout in #756's original report.

The workaround in this issue's description (making wait_until_ready return immediately) does not prevent this, because the COHN request is still sent. What avoided both failure modes on 0.22.0 was not sending the COHN request at all: I patched CohnFeature.open to mark COHN unsupported and set the ready event, without registering for COHN status. That gave 4 consecutive clean connections, with 0 COHN requests and 0 mismatched responses in the logs.

I haven't checked whether main can still hit this ordering race. It also sends the COHN request while connecting, but my single main run connected cleanly.