Feature request: BleakClient.write_gatt_char response default should be dynamic #909
Labels
enhancement
New feature or request
Comments
|
I was thinking about this recently too. I was going to suggest to default to write with response in the case where both are supported since that is the more reliable write, but I suppose that could be a breaking change in some cases. |
dlech
added a commit
that referenced
this issue
Feb 19, 2023
Previously, some backends would select the "best" response type based on the reported characteristics while some did not. For the ones that didn't, it was a commonly reported issue for the write to not work. This adds a recommendation to the docs to always be explicit about the requested response type and moves the common logic for picking the "best" type in the default case to the BleakClient class to avoid duplicated code. The logic is simplified to prefer a write with response if available and no longer reports a warning for devices that don't properly specify properties (since it would create much noise with many writes). Fixes: #909
dlech
added a commit
that referenced
this issue
Feb 19, 2023
Previously, some backends would select the "best" response type based on the reported characteristics while some did not. For the ones that didn't, it was a commonly reported issue for the write to not work. This adds a recommendation to the docs to always be explicit about the requested response type and moves the common logic for picking the "best" type in the default case to the BleakClient class to avoid duplicated code. The logic is simplified to prefer a write with response if available and no longer reports a warning for devices that don't properly specify properties (since it would create much noise with many writes). Fixes: #909
dlech
added a commit
that referenced
this issue
Feb 19, 2023
Previously, some backends would select the "best" response type based on the reported characteristics while some did not. For the ones that didn't, it was a commonly reported issue for the write to not work. This adds a recommendation to the docs to always be explicit about the requested response type and moves the common logic for picking the "best" type in the default case to the BleakClient class to avoid duplicated code. The logic is simplified to prefer a write with response if available and no longer reports a warning for devices that don't properly specify properties (since it would create much noise with many writes). Fixes: #909
dlech
added a commit
that referenced
this issue
Feb 19, 2023
Previously, some backends would select the "best" response type based on the reported characteristics while some did not. For the ones that didn't, it was a commonly reported issue for the write to not work. This adds a recommendation to the docs to always be explicit about the requested response type and moves the common logic for picking the "best" type in the default case to the BleakClient class to avoid duplicated code. The logic is simplified to prefer a write with response if available and no longer reports a warning for devices that don't properly specify properties (since it would create much noise with many writes). Fixes: #909
dlech
added a commit
that referenced
this issue
Jul 20, 2023
Previously, some backends would select the "best" response type based on the reported characteristics while some did not. For the ones that didn't, it was a commonly reported issue for the write to not work. This adds a recommendation to the docs to always be explicit about the requested response type and moves the common logic for picking the "best" type in the default case to the BleakClient class to avoid duplicated code. The logic is simplified to prefer a write with response if available and no longer reports a warning for devices that don't properly specify properties (since it would create much noise with many writes). Fixes: #909
dlech
added a commit
that referenced
this issue
Jul 20, 2023
Previously, some backends would select the "best" response type based on the reported characteristics while some did not. For the ones that didn't, it was a commonly reported issue for the write to not work. This adds a recommendation to the docs to always be explicit about the requested response type and moves the common logic for picking the "best" type in the default case to the BleakClient class to avoid duplicated code. The logic is simplified to prefer a write with response if available and no longer reports a warning for devices that don't properly specify properties (since it would create much noise with many writes). Fixes: #909
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The default value for the
BleakClient.write_gatt_charargumentresponseisFalse.This is a nuisance for BLE devices that support
write, but notwrite-without-response. And we could know this: the properties on the characteristics have this information.Suggestion: we make
responseanOptional[bool]defaulting toNone. And in the default case we examine the properties, use write-without-reponse if it is supported, otherwise we use write.If this is a good idea I'll create a pull request.
The text was updated successfully, but these errors were encountered: