-
-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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
Initial xiaomi_ble integration #75618
Conversation
(Will work on brand/doc updates next; have child care duty so it might be this evening). |
Co-authored-by: Ernst Klamer <e.klamer@gmail.com>
Co-authored-by: Ernst Klamer <e.klamer@gmail.com>
Co-authored-by: Ernst Klamer <e.klamer@gmail.com>
|
||
from .const import DOMAIN | ||
|
||
SENSOR_DESCRIPTIONS = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the integration now picks up all sensors that send temperature, humidity, pressure and battery. This might add all sensors, as almost all of them have battery messages. Does this mean that these sensors are added with only a battery entity? Not a problem, I guess, but we can also decide to comment out the sensors that aren't fully supported yet in the pypi package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pressure isnt used yet, but yes. I've left all the parsers active and able to capture fields that aren't turned into entities so we can do a second pass and capture them.
The can ignore any devices they don't want to add in the UI, so i'd slightly prefer to leave as is I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m just a bit afraid of all the issues that are going to be created, when people notice that their device only shows a battery entity. There is also one device that has added a counter in the battery data. Like every tenth advertisement, it will send a counter (as battery data) that is increased with one. I had some filter in BLE monitor for that (not in the parser, but in sensor.py. It will look it up, which one it was…)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh, I'm less worried about that. It's been that way with homekit_controller for a few years.
We can add some boilerplate to the docs about what device classes are support and/or a whitelist of devices we expect to work.
(I actually have a dashboard just for batteries, so I'm totally up for battery only sensors).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CGPR1 is the device with the odd battery sensor. I made a workaround in BLE monitor by storing the last 5 readings in a list, and only process the battery reading if it is in the list (only for the CGPR1, the others work fine without the workaround)
The counter is actually counting downwards, this is what you get without the workaround.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved this into Bluetooth-Devices/xiaomi-ble#3 and will handle it seperately to this PR.
Co-authored-by: Ernst Klamer <e.klamer@gmail.com>
Co-authored-by: Ernst Klamer <e.klamer@gmail.com>
Co-authored-by: Ernst Klamer <e.klamer@gmail.com>
Could this integration also replace the |
I noticed that one and I think it could - but haven't checked yet. |
@MartinHjelmare Yes it can (and will). MiTemp integration is for the LYWSDCGQ, which is just one of supported temperature and humidity sensors (Xiaomi MiBeacon sensors). We can remove that integration as well. |
This will break when I merge #75600 because its going to need a test fixture to enable bluetooth. I'll copy it in and push it here if I merge that one first |
I pushed the fix to mock enable bluetooth that is now needed after #75600 and the test |
Cheers for helping with that! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Proposed change
Based on @bdraco's work on bluetooth and HA, this adds support for the Xiaomi BLE devices as found in (ble_monitor)[https://github.com/custom-components/ble_monitor].
This uses sensorpush as a template - see #75531 for the discussion around the design.
Note that the migration for python 3.10 has broken integrations that rely on bluepy. This includes MiFlora (#74585). This integration has basic support for MiFlora, so my hope is to deprecate/remove that integration too.
@Ernst79 interest.
Type 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
.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: