-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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 Mi AirPurifier 3 #31729
Conversation
Hey there @rytilahti, @syssi, mind taking a look at this pull request as its been labeled with a integration ( |
"requirements": ["construct==2.9.45", "python-miio==0.4.8"], | ||
"requirements": [ | ||
"construct==2.9.45", | ||
"https://github.com/foxel/python-miio/archive/air-purifier-3h-support.zip#python-miio==0.5.0" |
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.
This is not allowed. The package must be published to pypi.
Sorry didn't see it was a draft.
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.
Please also add support for 3H model
@pkrolkgp thanks for suggestions. I don't have 3H but believe it's the same as 3... |
I do own a 3H and I'm able to test for you if needed. AFAIK the only difference is the filter type that ships with the unit. All behavior and API should be identical. |
Enabled setting fan level for AirPurifier 3/3H
hi guys can you please add model "zhimi.airpurifier.mb3" as well? |
it is added in second commit |
@@ -154,13 +165,15 @@ | |||
ATTR_HARDWARE_VERSION = "hardware_version" | |||
|
|||
# Air Humidifier CA | |||
ATTR_MOTOR_SPEED = "motor_speed" | |||
# ATTR_MOTOR_SPEED = "motor_speed" |
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.
Why change this?
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.
Duplicates ATTR_MOTOR_SPEED on line 139. Didn't drop this entirely just to keep the notion of this attribute in this "Air Humidifier CA" section
@@ -736,7 +797,10 @@ def speed_list(self) -> list: | |||
def speed(self): | |||
"""Return the current speed.""" | |||
if self._state: | |||
return AirpurifierOperationMode(self._state_attrs[ATTR_MODE]).name | |||
if isinstance(self._device, AirPurifierMiot): | |||
return AirpurifierMiotOperationMode(self._state_attrs[ATTR_MODE]).name |
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.
Would it make more sense to save a reference to the mode as given by the library and simply use _speed.name
? Usage of isinstance
is generally speaking not a good thing.
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 changed this to get rid of runtime instance checking
@@ -750,7 +814,9 @@ def speed(self): | |||
await self._try_command( | |||
"Setting operation mode of the miio device failed.", | |||
self._device.set_mode, | |||
AirpurifierOperationMode[speed.title()], | |||
AirpurifierMiotOperationMode[speed.title()] |
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.
We need to find a better solution for this, too.
I'm waiting to get some feedback on rytilahti/python-miio#643 – if all goes well, I'll prepare a new release soon and we can finally get this merged 🎉 |
Any news about this beautiful integration ? |
rytilahti/python-miio#658 release PR is now there, so I hope we'll have python-miio 0.5.0 released very soon! |
@rytilahti , you've just released 050! :) |
Already able to use this integration yet? Thank you |
@nhok3296 I'm using this in my installation now. But it's not merged yet. |
@foxel I tried xiaomi_miio but it didn't work |
"requirements": ["construct==2.9.45", "python-miio==0.4.8"], | ||
"requirements": [ | ||
"construct==2.9.45", | ||
"python-miio==0.5.0" |
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.
Please bump this to 0.5.0.1, as that bump will be needed soon enough due to a problem with packaging of 0.5.0.
Otherwise this seems to be good to go from my side.
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.
Updated
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 CI checks need to be fixed before this can be merged, check out also my single comment wrt. naming.
@@ -690,6 +747,10 @@ def __init__(self, name, device, model, unique_id): | |||
self._device_features = FEATURE_FLAGS_AIRPURIFIER_2S | |||
self._available_attributes = AVAILABLE_ATTRIBUTES_AIRPURIFIER_2S | |||
self._speed_list = OPERATION_MODES_AIRPURIFIER_2S | |||
elif self._model == MODEL_AIRPURIFIER_3 or self._model == MODEL_AIRPURIFIER_3H: |
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 was rechecking this PR and saw these and wondered why the one below is not merged here, before I realized that one is _3
and one _V3
. Do you think it would make sense to add MIOT
somewhere in there to make it easier to differentiate?
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 didn't ever see V3 version but it's something older and different from 3/3h from 2019...
I don't think adding MIOT would be the best solution. I think in not so distant future we'll need to have 2/2s/Pro support with MiOT protocol...
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.
Or simply use some part of the real model number? It's mildly confusing to differentiate between those constants. Anyway, this is not a blocking issue.
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.
One last thing to do before merging, please update the documentation (for the model listing & the new service): https://github.com/home-assistant/home-assistant.io/blob/current/source/_integrations/fan.xiaomi_miio.markdown
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.
Made one
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, let's get this merged, the docs will follow as soon as someone reviews it! Thanks for your hard work and patience on this! 🥇
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.
This platform should be refactored to follow our design guidelines before any further changes are done.
@@ -302,6 +337,7 @@ | |||
OPERATION_MODES_AIRPURIFIER_PRO = ["Auto", "Silent", "Favorite"] | |||
OPERATION_MODES_AIRPURIFIER_PRO_V7 = OPERATION_MODES_AIRPURIFIER_PRO | |||
OPERATION_MODES_AIRPURIFIER_2S = ["Auto", "Silent", "Favorite"] | |||
OPERATION_MODES_AIRPURIFIER_3 = ["Auto", "Silent", "Favorite", "Fan"] |
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 only allowed speed modes for fans are off, low, medium and high.
core/homeassistant/components/fan/__init__.py
Lines 35 to 38 in dc7127a
SPEED_OFF = "off" | |
SPEED_LOW = "low" | |
SPEED_MEDIUM = "medium" | |
SPEED_HIGH = "high" |
We should not continue to extend this platform with architecture design breaking changes.
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.
Sorry, I didn't notice that... How can we make the situation better? Should the tests be improved to capture such misuses?
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 not sure how we can test this generally. Some platforms are already breaking the rules which might also complicate any general tests.
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.
@MartinHjelmare what if a device does not fall into such a specification?
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 platform can try to translate between home assistant mode and device mode. The platform can also register custom services.
The current design does not cater well to all fans but until we have a better design we have to follow it. We have an open architecture issue on fan speeds. You're welcome to contribute to that and try to bring it forward. We need to figure out a design that can cater for a majority of fans but is still compatible with our frontend and voice assistants.
ATTR_HUMIDITY: "humidity", | ||
ATTR_AIR_QUALITY_INDEX: "aqi", | ||
ATTR_MODE: "mode", | ||
ATTR_FILTER_HOURS_USED: "filter_hours_used", |
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.
Relative times are not allowed in the state machine. We only allow absolute utc timestamps.
Times should preferably be represented as sensors with device class timestamp.
https://developers.home-assistant.io/docs/entity_sensor#available-device-classes
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.
So, should this be completely removed then? The problem with this value is, I presume, that there is no specific timestamp as it depends on the usage. ping @foxel - do you have an idea on this?
P.S. I think we need to have a checklist for reviewers, much like what we have for PR creators, to list things to check. It is sometimes hard to spot all mistakes, and I'm very sorry for not catching this one..
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.
We should update this dev docs page with the allowed fan speeds:
https://developers.home-assistant.io/docs/entity_fan
I'll put it on my todo.
In general we need to make sure that we follow our architecture docs and ADRs. But those are not complete yet, so that's a problem.
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.
It's interesting that relative timestamps are not allowed in state attributes. Didn't know that. Where can I find more docs about it?
I have MQTT devices, Esphome which are breaking this rule. This cannot be found in HA code as HA just puts received json in state_attrs
.
my vacuum state attributes:
cleanTime: 202.8
cleanArea: 12530.2
cleanCount: 1349
last_run_stats:
startTime: 1585934330000
endTime: 1585935335000
duration: 1005
@rytilahti solution for it is to move attributes to independent sensors.
Nothing about in https://www.home-assistant.io/blog/2020/04/08/release-108/ ?
On homeassistant/qemux86-64-homeassistant with version 0.108.0b5 |
@CLARENNE-Q This PR is merged after the beta was cut. It is not in 0.108. |
is this available now in 0.108.3 ? |
@dj4shots No, new features are only shipped in major releases. This will be shipped with 0.109 |
Proposed change
Adding support for Mi AirPurifier 3
Type of change
Adding support for Mi AirPurifier 3 using miot. For now this PR uses a fork of xiaomi-miio which implements miot devices support
Should help with #26957
Example entry for
configuration.yaml
:Additional information
need to be continued after rytilahti/python-miio#634 (or rytilahti/python-miio#585) is merged. I've tested with this change ant that code of miio - works fine for now
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: