Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bluetooth device connection failure when device is seen by dbus but not bleak #83281

Merged
merged 2 commits into from
Dec 6, 2022

Conversation

bdraco
Copy link
Member

@bdraco bdraco commented Dec 5, 2022

Proposed change

Fix devices missing from the bluetooth scanner's discovered_devices after restarting scanner by restoring them from the bus after starting the scanner. This ensures the scanner is always in sync with the bus properties and we aren't missing any devices or marking devices unavailable unexpectedly because they were missing as they were seen by the bus before the scanner started.

changelog: Bluetooth-Devices/bluetooth-adapters@v0.11.0...v0.12.0
changelog: Bluetooth-Devices/bleak-retry-connector@v2.9.0...v2.10.1

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Black (black --fast homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
  • Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

@bdraco bdraco added this to the 2022.12.0 milestone Dec 5, 2022
@bdraco bdraco changed the title Try fetching bluetooth devices from the bus if they are missing Fix bluetooth device connection failure when device is seen by dbus but not bleak Dec 5, 2022
@bdraco
Copy link
Member Author

bdraco commented Dec 5, 2022

So this has been a problem since day 1

self.seen_devices = {} is set at scan start so everything already on the bus is missing when we do the unavailable checks we will think the device has disappeared because we don't see it.

We need a way to restore self.seen_devices from the global bluez manager when the scanner starts.

Probably need to add a utility in bluetooth_adapters or bleak_retry_connector that does that and than we can skip the logic I just added here

This is going to solve a lot of unexplained issues

Something for tomorrow.

@bdraco bdraco marked this pull request as ready for review December 5, 2022 18:00
@bdraco bdraco marked this pull request as draft December 5, 2022 18:06
@bdraco
Copy link
Member Author

bdraco commented Dec 5, 2022

Still need to test this with switchbots

HomeKit devices are working great

Copy link

@Rudd-O Rudd-O left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are oyu sure the logic here is correct?

https://github.com/Bluetooth-Devices/bleak-retry-connector/blob/5596cfe6b8b59a311e93c2a9945b99f324f1787b/src/bleak_retry_connector/__init__.py#L745

You log if it is LINUX but you return either way (potentially just silencing the error on other platforms).

If this is expected to run in non-Linux envs, why eat the exception in these other cases?


In general you want to restore discoveries after you have connected to the D-Bus signal that will feed you state updates in question, and buffer those updates until after restore discoveries is done. Otherwise code will not be in sync with the latest known states of the devices.

@bdraco
Copy link
Member Author

bdraco commented Dec 5, 2022

There is no restore on non Linux platforms. It would be slightly more efficient to but the Linux guard first

@bdraco
Copy link
Member Author

bdraco commented Dec 5, 2022


In general you want to restore discoveries after you have connected to the D-Bus signal that will feed you state updates in question, and buffer those updates until after restore discoveries is done. Otherwise code will not be in sync with the latest known states of the devices.

We aren't restoring from the bus directly. We are restoring from bleaks latest updated dbus data which than bleak keeps up to date from the stream

@bdraco
Copy link
Member Author

bdraco commented Dec 5, 2022

There is no restore on non Linux platforms. It would be slightly more efficient to but the Linux guard first

Optimized in 2.10.1

@bdraco bdraco marked this pull request as ready for review December 5, 2022 19:31
@bdraco
Copy link
Member Author

bdraco commented Dec 5, 2022

Switchbot looks good as well

@balloob balloob merged commit 1ee9c0c into home-assistant:dev Dec 6, 2022
balloob pushed a commit that referenced this pull request Dec 6, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Dec 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants