Follow-up from #1986.
While adding BleakAdapter.get() in #1986, we chose to raise BleakBluetoothNotAvailableError with reason POWERED_OFF whenever the adapter isn't on, without distinguishing a hardware/rfkill block from a software toggle. Worth revisiting whether to expose that distinction with a dedicated reason.
Per-platform state:
- Windows: exposed reliably —
RadioState.Disabled is the hardware/firmware switch (not programmatically changeable), RadioState.Off is the software toggle.
- Linux/BlueZ: only via the experimental
PowerState property, where off-blocked (rfkill) looks equivalent to Windows' Disabled. The stable Powered flag carries no cause.
- macOS: no hardware switch exists and
CBManagerState.poweredOff carries no cause, so there's nothing to distinguish.
Since BlueZ PowerState is still experimental, leaving this for the future. Once it's stable, the direction would be to map WinRT Disabled and BlueZ off-blocked to a shared "hardware/rfkill blocked" reason.
Follow-up from #1986.
While adding
BleakAdapter.get()in #1986, we chose to raiseBleakBluetoothNotAvailableErrorwith reasonPOWERED_OFFwhenever the adapter isn't on, without distinguishing a hardware/rfkill block from a software toggle. Worth revisiting whether to expose that distinction with a dedicated reason.Per-platform state:
RadioState.Disabledis the hardware/firmware switch (not programmatically changeable),RadioState.Offis the software toggle.PowerStateproperty, whereoff-blocked(rfkill) looks equivalent to Windows'Disabled. The stablePoweredflag carries no cause.CBManagerState.poweredOffcarries no cause, so there's nothing to distinguish.Since BlueZ
PowerStateis still experimental, leaving this for the future. Once it's stable, the direction would be to map WinRTDisabledand BlueZoff-blockedto a shared "hardware/rfkill blocked" reason.