-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
Add support for ESPHome raw bluetooth advertisements #94138
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We now send advertisements in bundles of 16. The raw bytes are parsed by bluetooth_data_tools to take the load of the esp device and reduce the amount of time the wifi radio is on which improves Bluetooth and Wi-Fi co-existance since we significantly reduce the number of packets needed to get the bluetooth data from the ESP to HA
home-assistant
bot
added
cla-signed
integration: esphome
small-pr
PRs with less than 30 lines.
labels
Jun 7, 2023
Hey there @OttoWinter, @jesserockz, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
11 tasks
bdraco
added a commit
to Bluetooth-Devices/ruuvitag-ble
that referenced
this pull request
Jun 7, 2023
unblocks home-assistant/core#94138 bluetooth-data-tools got a major version bump (not breaking for this lib)
This was referenced Jun 7, 2023
bdraco
added a commit
that referenced
this pull request
Jun 7, 2023
no code change, only loosen deps to unblock #94138 Bluetooth-Devices/ruuvitag-ble@v0.1.1...v0.1.2
This reverts commit 28ed815.
bdraco
added a commit
that referenced
this pull request
Jun 7, 2023
needs #94144 changelog: Bluetooth-Devices/bluetooth-data-tools@v0.4.0...v1.0.0 supports #94138
20 tasks
Toothbrush test is much smoother now. The esp has yet to complain about too many packets to process anymore. |
jesserockz
approved these changes
Jun 7, 2023
tested all day. looks good 👍 |
mover85
pushed a commit
to mover85/core
that referenced
this pull request
Jun 8, 2023
…94138) Co-authored-by: Jesse Hills <3060199+jesserockz@users.noreply.github.com>
bdraco
added
the
noteworthy
Marks a PR as noteworthy and should be in the release notes (in case it normally would not appear)
label
Jun 17, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
cla-signed
integration: esphome
noteworthy
Marks a PR as noteworthy and should be in the release notes (in case it normally would not appear)
Quality Scale: No score
small-pr
PRs with less than 30 lines.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Edit: After running this in production for a bit, the results wildly exceed expectations. The overall runtime to process the incoming data on the ha system is down by at least 10%, and esphome incoming data path run time is down by at least 50% when coupled with the new Bluetooth-data-tools.
I know it's a bit counterintuitive to have a remote device be faster than a local one, but I don't even have to profile them to tell that my olimex Poe iso ea proxies are faster than the local adapter now as the time it takes to lock and unlock a Yale lock is a about half the time with the proxy vs the local adapter.
I'll work on a pr to bump the recommended esphome version for Bluetooth proxies to 2023.6.0+
Proposed change
We now send advertisements in bundles of up to 16. The raw bytes are parsed by
bluetooth_data_tools
to take the load of the esp device and reduce the amount of time the wifi radio is being used. In testing the reduced number of packets and the redunction in processing of the packets more than offset the cost of doing the parsing in the library vs the ESP. This improves Bluetooth and Wi-Fi co-existance since we significantly reduce the number of packets (being sent over Wi-Fi) needed to get the bluetooth data from the ESP to HA.Note that packets are only bundled together if the esphome code already bundled them together which means there is no significant change in latency (faster in most cases since the overhead to read and unpack the protobuf packet had to be done between each ble packet before)
esphome/esphome#4924 is required to use the new code path (but is backwards compatible)
library bump:
aioesphomeapi
esphome/aioesphomeapi@v13.9.0...v14.0.0Type of change
Additional information
Checklist
black --fast homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.To help with the load of incoming pull requests: