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.
This is not allowed. The package must be published to pypi.
Sorry didn't see it was a draft.
pkrolkgp
left a comment
There was a problem hiding this comment.
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 |
|
|
||
| # Air Humidifier CA | ||
| ATTR_MOTOR_SPEED = "motor_speed" | ||
| # ATTR_MOTOR_SPEED = "motor_speed" |
There was a problem hiding this comment.
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
| 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.
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.
I've changed this to get rid of runtime instance checking
| "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.
We need to find a better solution for this, too.
|
Do you need help with this @foxel ? Would be great to finally have it supported. I have the 3H btw. |
|
@pawelkw this PR is locked with work on rytilahti/python-miio#634. One that merged, this PR is ready to merge |
|
@foxel rytilahti/python-miio#634 is merged! :) |
|
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.
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.
rytilahti
left a comment
There was a problem hiding this comment.
The CI checks need to be fixed before this can be merged, check out also my single comment wrt. naming.
| 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.
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.
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.
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.
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.
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! 🥇
MartinHjelmare
left a comment
There was a problem hiding this comment.
This platform should be refactored to follow our design guidelines before any further changes are done.
| 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.
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
We should not continue to extend this platform with architecture design breaking changes.
There was a problem hiding this comment.
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.
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.
@MartinHjelmare what if a device does not fall into such a specification?
There was a problem hiding this comment.
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.
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.
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.
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.
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: