How to deal with sleep/wake issues -- wifi timeout errors, handler errors, timeout errors

[leeprevost]

I'm using mostly the video.py code to build a "take_video" function which takes 5 seconds of video and returns a file name.

This works most of the time ....

But, I've found several edge cases that seem to be related to when the gopro goes to sleep or when the gopro is turned off where I encounter errors or warnings. Example 3 maybe related to manually changing back to local wifi rather than camera wifi and then re-running script.

OS: Windows10

(Much thanks to the authors for the incredible video.log capability)

Example 1 (unhadled notification):

     data:   bleak.backends.dotnet.client:  437 11:29:37.031 DEBUG    | Get Services...
     data:   bleak.backends.dotnet.client:  437 11:29:37.031 DEBUG    | Get Services...
     data:   bleak.backends.dotnet.client:  554 11:29:37.486 INFO     | Services resolved for BleakClientDotNet (F5:A2:15:A9:A4:F7)
     data:   bleak.backends.dotnet.client:  554 11:29:37.486 INFO     | Services resolved for BleakClientDotNet (F5:A2:15:A9:A4:F7)
     data:      open_gopro.ble_controller:  157 11:29:37.486 DEBUG    | Attempting to pair...
     data:      open_gopro.ble_controller:  163 11:29:37.486 DEBUG    | Pairing complete!
     data:      open_gopro.ble_controller:  164 11:29:37.486 INFO     | BLE Connected!
     data:      open_gopro.ble_controller:  175 11:29:37.486 INFO     | Enabling notifications...
     data:      open_gopro.ble_controller:  179 11:29:37.486 DEBUG    | Enabling notification on char 00002a19-0000-1000-8000-00805f9b34fb
     **data:               open_gopro.gopro:  424 11:29:37.670 WARNING  | Unhandled notification from handle 15**

Example 2 (Bluetooth timeout error):

     data:      open_gopro.ble_controller:  163 11:25:02.008 DEBUG    | Pairing complete!
     data:      open_gopro.ble_controller:  164 11:25:02.008 INFO     | BLE Connected!
     data:      open_gopro.ble_controller:  175 11:25:02.008 INFO     | Enabling notifications...
     data:      open_gopro.ble_controller:  179 11:25:02.008 DEBUG    | Enabling notification on char 00002a19-0000-1000-8000-00805f9b34fb
 Dummy-65:   bleak.backends.dotnet.client:  215 11:25:16.023 DEBUG    | _ConnectionStatusChanged_Handler: 0
 Dummy-65:   bleak.backends.dotnet.client:  215 11:25:16.023 DEBUG    | _ConnectionStatusChanged_Handler: 0
     data:      open_gopro.ble_controller:   33 11:25:16.023 DEBUG    | On device BleakClientDotNet (F5:A2:15:A9:A4:F7), Disconnected callback called!
 MainThread:               open_gopro.gopro:  408 11:25:16.041 WARNING  | BleakError('Could not start notify on 00002a19-0000-1000-8000-00805f9b34fb: Unreachable'). Retrying #1
      data:      open_gopro.ble_controller:  144 11:25:16.046 INFO     | Establishing BLE connection to F5:A2:15:A9:A4:F7: GoPro 2659...
      data:   bleak.backends.dotnet.client:  164 11:25:16.046 DEBUG    | Connecting to BLE device @ F5:A2:15:A9:A4:F7
      data:   bleak.backends.dotnet.client:  164 11:25:16.046 DEBUG    | Connecting to BLE device @ F5:A2:15:A9:A4:F7
  Dummy-66:   bleak.backends.dotnet.client:  215 11:25:17.057 DEBUG    | _ConnectionStatusChanged_Handler: 1
  Dummy-66:   bleak.backends.dotnet.client:  215 11:25:17.057 DEBUG    | _ConnectionStatusChanged_Handler: 1
      data:   bleak.backends.dotnet.client:  437 11:25:17.057 DEBUG    | Get Services...
      data:   bleak.backends.dotnet.client:  437 11:25:17.057 DEBUG    | Get Services...
  MainThread:               open_gopro.gopro:  408 11:25:17.226 WARNING  | BleakDotNetTaskError('Could not get GATT characteristics for Windows.Devices.Bluetooth.GenericAttributeProfile.GattDeviceService: AccessDenied'). Retrying #2
      data:      open_gopro.ble_controller:  144 11:25:17.242 INFO     | Establishing BLE connection to F5:A2:15:A9:A4:F7: GoPro 2659...
      data:   bleak.backends.dotnet.client:  164 11:25:17.242 DEBUG    | Connecting to BLE device @ F5:A2:15:A9:A4:F7
      data:   bleak.backends.dotnet.client:  164 11:25:17.242 DEBUG    | Connecting to BLE device @ F5:A2:15:A9:A4:F7
    MainThread:               open_gopro.gopro:  408 11:25:32.392 WARNING  | TimeoutError(). Retrying #3
      data:      open_gopro.ble_controller:  144 11:25:32.392 INFO     | Establishing BLE connection to F5:A2:15:A9:A4:F7: GoPro 2659...
      data:   bleak.backends.dotnet.client:  164 11:25:32.392 DEBUG    | Connecting to BLE device @ F5:A2:15:A9:A4:F7
      data:   bleak.backends.dotnet.client:  164 11:25:32.392 DEBUG    | Connecting to BLE device @ F5:A2:15:A9:A4:F7
   MainThread:               open_gopro.gopro:  408 11:25:47.544 WARNING  | TimeoutError(). Retrying #4

Example 3 (wifi connection timeout -- several tries but never connects to wifi, ends with this in log):

MainThread:     open_gopro.wifi_controller:  897 11:38:14.536 DEBUG    | Waiting 1 second for Wi-Fi connection to establish...
keep_alive:        open_gopro.ble_commands:  350 11:38:58.733 INFO     | <----------- set : LED.BLE_KEEP_ALIVE
keep_alive:               open_gopro.gopro:  540 11:38:58.733 DEBUG    | SettingId.LED acquiring semaphore
keep_alive:               open_gopro.gopro:  542 11:38:58.733 DEBUG    | SettingId.LED has semaphore
      data:      open_gopro.ble_controller:   72 11:38:58.733 DEBUG    | Writing to b5f90074-aa8d-11e3-9046-0002a5d5c51b: 03:5b:01:3d
      data:   bleak.backends.dotnet.client:  716 11:38:58.737 DEBUG    | Write Characteristic b5f90074-aa8d-11e3-9046-0002a5d5c51b : bytearray(b'\x03[\x01=')
      data:   bleak.backends.dotnet.client:  716 11:38:58.737 DEBUG    | Write Characteristic b5f90074-aa8d-11e3-9046-0002a5d5c51b : bytearray(b'\x03[\x01=')
      data:               open_gopro.gopro:  427 11:38:58.962 DEBUG    | Received response on UUID.CQ_SETTINGS_RESP: b'02:5b:00'
keep_alive:               open_gopro.gopro:  574 11:38:58.962 DEBUG    | SettingId.LED released the semaphore
keep_alive:        open_gopro.ble_commands:  362 11:38:58.962 INFO     | -----------> 
{
 "status": "SUCCESS",
 "id": "UUID.CQ_SETTINGS_RESP::SettingId.LED"
}

Question: is there a guide to properly wake up? Could this be related to how windows handles a device that is already paired and then atempting to re-pair to the device upon waking it? I noticed in source, there are some references to a todo "make robust" -- I wonder if this is what I'm running into?

[KonradIT]

I've found the Hero9 to hang up and respond less to wake-up command via BLE connect than my other GoPros (MAX, Hero5, Hero7), both using gopro-ble-py and the python programs on here.

What I've ended up doing is just using a while tries < X statement, where I attempt to connect/pair/do an operation more than once. But some times all that's needed is pulling out the battery.

[leeprevost]

Thanks @KonradIT. I've spent some time also with your awesome gopro-ble-py and in many ways, I find it more straightforward. I have advanced in my learning curve on the problems encoutereed above by simply staying connected via BLE. I was trying to find a way to do this in a more power efficient way (ie. connect, disable wap, reconnect when I need to record, etc.).

As I've advanced, I've moved from the relatively low level asynch tutorials concept to using the GoPro class handler in the demos. I"m learning to appreciate what all it does for us and abstracsts for us. And when I use it in a keep alive context statement, many of the problems reported above seem to go away if I just connect once using the GoPro class and allow it to keep-alive.

Also, I've noted for GoPro Hero9, I can't get battery information back either on your gpro-ble-py or via the GoPro class handler in the Python OpenGopro SDK. I'm going to create another issue with my findings.

[tcamise-gpsw]

Regarding the "unhandled notification"...this is the battery level notification using the Bluetooth spec-defined characteristics. This warning is currently "expected" just in that I haven't yet added handling of non GoPro-characteristics.

Regarding example 2, I see this sometimes also and believe it to be bleak / OS bug because whenever it is in this state, I can connect to the GoPro from other devices such as my phone. Konrad's idea for retries should certainly help. I think maybe what we need is a way to do some type of OS bluetooth-driver reset.

Regarding example 3, it looks we're handling this in #19

If it's ok with you, I'd like to close this and follow up in #19 with WiFi problems.

[leeprevost]

Yes, please do. Shall I close?