[Windows 11] Protocol Error 0x05: Insufficient Authentication when writing to Polar H10 PMD Control

[Miguelhg8]

Environment details:

OS: Windows 11

Python version: 3.10.11

Bleak version: 0.20.1

Hardware: Polar H10 (Latest firmware)

PC Specs: MSI Katana A15 (AMD Ryzen 9 8945HS, MediaTek RZ616 Bluetooth Adapter) - Laptop. I suspect there might be a conflict between this specific hardware's driver and how WinRT handles GATT service caching when a device requires bonding, but im not entirely sure...

Description:
I am developing a real-time physiological monitoring system using a Polar H10 and Bleak. I am currently facing a Protocol Error 0x05 (Insufficient Authentication) when trying to enable the PMD (Polar Measurement Data) streams for both ECG and Accelerometer (ACC) data.

The Issue:
The connection is established successfully and I can read the battery level without issues. However, the moment I try to write the start commands to the PMD Control characteristic, the execution crashes.

Error Log:

Plaintext

  File "...\bleak\backends\winrt\client.py", line 115, in _ensure_success
    raise BleakError(
bleak.exc.BleakError: Could not write value bytearray(b'\x02\x00\x00\x01\x82\x00\x01\x01\x0e\x00') to characteristic 002E: Protocol Error 0x05: Insufficient Authentication
Configuration File (config_Polar.py):

Python

POLAR_MAC = "24:AC:AC:10:51:04"

# GATT UUIDs
PMD_UUID_CONTROL = "fb005c81-02e7-f387-1cad-8acd2d8df0c8"
PMD_UUID_DATA = "fb005c82-02e7-f387-1cad-8acd2d8df0c8"

# HEX Commands for PMD Handshake
# ECG: 130Hz
ECG_START_CMD = bytearray([0x02, 0x00, 0x00, 0x01, 0x82, 0x00, 0x01, 0x01, 0x0E, 0x00])
# ACC: 200Hz, 2G, 16-bit
ACC_START_CMD = bytearray([0x02, 0x02, 0x00, 0x01, 0xC8, 0x00, 0x01, 0x01, 0x10, 0x00, 0x02, 0x01, 0x08, 0x00])
Simplified Connector Logic:

Python

class PolarH10Connector:
    def __init__(self, address):
        self.address = address
        self.client = BleakClient(address, timeout=30.0)

    async def connect(self):
        await self.client.connect()
        # Adding await self.client.pair() here bypasses 0x05 but leads to a timeout loop
        return self.client.is_connected

    async def start_streams(self):
        # Subscribe to PMD Data channel
        await self.client.start_notify(config.PMD_UUID_DATA, self.pmd_data_callback)
        
        # 1. Start ECG - Fails here with Error 0x05 (Insufficient Authentication)
        await self.client.write_gatt_char(config.PMD_UUID_CONTROL, config.ECG_START_CMD, response=True)
        
        await asyncio.sleep(0.5)
        
        # 2. Start ACC - Also requires authentication
        await self.client.write_gatt_char(config.PMD_UUID_CONTROL, config.ACC_START_CMD, response=True)

Observed Context:

Unpaired: Reading Battery level works, but writing to PMD Control triggers the 0x05 error.

Manually paired via OS Bluetooth settings: The connection or service discovery process hangs for a significant period before eventually failing with a TimeoutError. When the device is paired, the hang happens specifically during the service discovery phase. Even with use_cached_services=True, the backend seems to struggle to retrieve the service list, leading to the TimeoutError.

Using client.pair(): If I add await self.client.pair() in the code, the script moves past the 0x05 error initially, but then it triggers a different error.

The "Timeout Loop": Once the Windows pairing prompt is accepted, the device shows as "Connected" in the OS, but all subsequent attempts to run the script result in a permanent TimeoutError during connection or service discovery.

Once Windows marks the device as 'Connected', it seems to establish an exclusive lock. Even after killing the Python process, the sensor remains 'Connected' in the OS, and subsequent runs of the script cannot re-acquire the GATT session until the device is manually removed and re-paired.

Questions:

Does the Polar H10 require an explicit await client.pair() call within the script to authorize writes to the PMD Control point? I noticed that while it bypasses the 0x05 error once, I then fall into a TimeoutError loop.

Why would pairing the device cause BleakClient.connect() to timeout or hang in subsequent runs?

Is there any specific winrt backend flag to handle the bonding process more gracefully for sensors requiring authenticated writes?

Is there any alternative way to authorize these specific characteristics without relying on a persistent OS-level connection? In Windows 11, once the device is paired, the OS automatically establishes a connection. I haven't found a way to keep the device "Paired" but "Disconnected" to allow Bleak to manage the session exclusively without the system's interference, which seems to be the root of the TimeoutError.

Personal Note:
I'm sorry if I'm not expressing myself clearly—I'm just a biomedical engineer with little work experience, currently pursuing a master's degree in robotics and automation, and I don't know much about pure hardware... I apologize, and thank you to anyone who can help. I need to fix this so I can turn in my master’s thesis on time :(. My plan is to read data from the Polar H10 as close to real-time as possible to analyze it and derive a stress indicator based on HRV metrics, and using Bleak along with NeuroKit2 and pylsl is the best and fastest option I’ve found. I just hope I don't have to completely overhaul my architecture at this point, given how little time I have left to defend my thesis... :(

[dlech]

Once Windows marks the device as 'Connected', it seems to establish an exclusive lock. Even after killing the Python process, the sensor remains 'Connected' in the OS, and subsequent runs of the script cannot re-acquire the GATT session until the device is manually removed and re-paired.

Is it not possible to disconnect the device without unpairing/removing?

Why would pairing the device cause BleakClient.connect() to timeout or hang in subsequent runs?

Because the device is already connected, so it is not advertising.

Is there any specific winrt backend flag to handle the bonding process more gracefully for sensors requiring authenticated writes?

There are some unfinished attempts to do this in the open pull requests here.

once the device is paired, the OS automatically establishes a connection.

Interesting... we have a long-standing request to allow connecting to already connected devices, but no one has attempted to implement it yet. #367

---

This will pair before connecting instead of after. Not sure if it would work for your case or not.

async with BleakClient(address, timeout=30.0, pair=True) as client:
   # do stuff with client here.
   ...

[Miguelhg8]

Thank you for your follow-up! Regarding your question:

Is it not possible to disconnect the device without unpairing/removing?

In Windows 11 (Standard Bluetooth Settings UI), for BLE devices like the Polar H10, the "Disconnect" option seems to be non-existent. When I click the three dots, the only available action I see is "Remove device" (Unpairing).

From my limited experience, it looks like once the device is bonded, Windows attempts to maintain a background connection to poll standard services (like Heart Rate), and I am not aware of any native toggle to just "kill" that active GATT session without removing the pairing altogether.

I am currently testing if this "OS-level persistent connection" is what might be causing the TimeoutError when Bleak tries to initiate its own session. I'll keep investigating and I will keep you posted on any progress. Thanks again for the support!

Just to clarify one technical point: regarding the 'Protocol Error 0x05: Insufficient Authentication', am I correct in assuming that the Polar H10 PMD service requires a formal Bonding process to satisfy the security requirements of the Control Point characteristic? Or is there an alternative way to handle the security elevation or key exchange programmatically within Bleak without relying on the OS-level bonding UI?

[dlech]

Since it sounds like you need a quick solution, I would suggest to use the WinRT APIs to find the already connected device after it has been paired.

The main function will be DeviceInformation.find_all_async().

AI tools can probably help figure out the the parameters for the AQS filter and additional properties.

Then you should be able to take the found DeviceInformation and pass it as the details of a new BLEDevice(). then pass that object to BleakClient().

am I correct in assuming that the Polar H10 PMD service requires a formal Bonding process to satisfy the security requirements of the Control Point characteristic?

Yes, it is common for characteristics with sensitive information to require encryption and encryption is only available after pairing/bonding.

[Miguelhg8]

Since it sounds like you need a quick solution, I would suggest to use the WinRT APIs to find the already connected device after it has been paired.

The main function will be DeviceInformation.find_all_async().

Hi! Thanks for the tip about using DeviceInformation.find_all_async(). I successfully located the Polar H10 using the AQS filter, but I've hit a couple of roadblocks:

IsEnabled is False: The returned DeviceInformation object shows is_enabled = False even though the device is paired in Windows settings. Does Bleak require is_enabled to be True to establish the GATT session?

BLEDevice details structure: When I pass the DeviceInformation object as details to a new BLEDevice and try to connect, I get AttributeError. It seems the Windows backend expects details to have specific attributes like .bluetooth_address or .adv (which aren't present in the native WinRT object).

My script:

import asyncio
from bleak_winrt.windows.devices.enumeration import DeviceInformation, DeviceInformationKind

async def debug_for_dev():
    # Buscamos por la dirección MAC del Polar H10
    mac = "24:AC:AC:10:51:04"
    aqs = f"System.Devices.Aep.DeviceAddress:=\"{mac}\""
    
    # Pedimos las propiedades que Bleak suele inspeccionar
    props = ["System.Devices.Aep.IsPaired", "System.Devices.Aep.IsConnected"]
    
    devices = await DeviceInformation.find_all_async(
        aqs, props, DeviceInformationKind.ASSOCIATION_ENDPOINT
    )

    if not devices:
        print("Device not found in PnP records.")
        return

    dev = devices[0]
    print(f"DEBUG DATA FOR {dev.name}:")
    print(f"- ID: {dev.id}")
    print(f"- IsEnabled: {dev.is_enabled}")
    print(f"- IsDefault: {dev.is_default}")
    print(f"- Kind: {dev.kind}")
    
    # Listamos qué hay en el saco de propiedades
    print("- Available Properties:")
    for p in dev.properties:
        print(f"  [+] {p}")

if __name__ == "__main__":
    asyncio.run(debug_for_dev())

Here is the output from my debug script:

DEBUG DATA FOR Polar H10 10510430:
- ID: BluetoothLE#BluetoothLE78:46:5c:11:fe:6c-24:ac:ac:10:51:04
- IsEnabled: False
- IsDefault: False
- Kind: 5
- Available Properties:
  [+] System.ItemNameDisplay
  [+] {A35996AB-11CF-4935-8B61-A6761081ECDF} 19
  [+] System.Devices.Aep.CanPair
  [+] System.Devices.Aep.IsPaired
  [+] {A35996AB-11CF-4935-8B61-A6761081ECDF} 18
  [+] {A35996AB-11CF-4935-8B61-A6761081ECDF} 13
  [+] System.Devices.Aep.ContainerId
  [+] System.Devices.Icon
  [+] System.Devices.GlyphIcon
  [+] System.Devices.Aep.IsConnected

Could you clarify what is the exact expected structure for the details object on Windows to satisfy the BleakClient requirements without performing a full scan?

[dlech]

Does Bleak require is_enabled to be True to establish the GATT session?

I'm not sure what is_enabled means for BLE device. Windows uses this same DeviceInfo for all kinds of devices, so it might not be relevant at all.

Could you clarify what is the exact expected structure for the details object on Windows to satisfy the BleakClient requirements without performing a full scan?

Technically, it is expecting details to be a bleak.backends.winrt.scanner.RawAdvData object.

BleakClient doesn't check this explicitly though, so you just need a object that is compatible with details.adv.bluetooth_address where bluetooth_address is the integer form of the Bluetooth address.

So actually, it looks like you could skip the find_all_async() if you only care about one device and already know the address.

[Miguelhg8]

Hi dlech,

I’ve finally found a consistent (though not ideal) way to make it work with my current setup.

The Workaround:
The only way to successfully receive notifications from the Heart Rate Service (0x180D) is to force a full security cycle within the script:

Connect using BleakClient(device, pair=True).

Perform the GATT operations (Battery read and HR notifications work perfectly this way).

Crucially, call await client.unpair() right before disconnecting.

If I don't call unpair(), Windows 11 keeps the device bonded in the background and "hijacks" the service handle, causing any subsequent script execution to fail with a CancelledError or simply time out during start_notify. By forcing Windows to "forget" the device at the end of every session, I ensure a clean GATT table for the next run.

Next steps:
While this works, the constant re-pairing is slow and not optimal for a real-time application. I have just ordered a TP-Link UB500 (Realtek chip) dongle to see if a different radio stack allows for a persistent bond without the OS locking the service exclusively.

I'll post a final update once I test the new hardware to see if it eliminates the need for this pair/unpair "hack".

Thanks for the support!