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

Add support for Mi AirPurifier 3 #31729

Merged
merged 11 commits into from
Apr 3, 2020
Merged

Conversation

foxel
Copy link
Contributor

@foxel foxel commented Feb 11, 2020

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

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

Example entry for configuration.yaml:

fan:
  - platform: xiaomi_miio
    name: mi_purifier_1
    host: !secret purifier3_ip
    token: !secret purifier3_token
    model: zhimi.airpurifier.ma4

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

example

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.
  • Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

  • No score or internal
  • 🥈 Silver
  • 🥇 Gold
  • 🏆 Platinum

@probot-home-assistant
Copy link

Hey there @rytilahti, @syssi, mind taking a look at this pull request as its been labeled with a integration (xiaomi_miio) you are listed as a codeowner for? Thanks!

@MartinHjelmare MartinHjelmare changed the title Adding support for Mi AirPurifier 3 (DRAFT) Add support for Mi AirPurifier 3 (DRAFT) Feb 13, 2020
"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"
Copy link
Member

@Kane610 Kane610 Feb 13, 2020

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.

Copy link
Contributor

@pkrolkgp pkrolkgp left a 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

homeassistant/components/xiaomi_miio/fan.py Show resolved Hide resolved
homeassistant/components/xiaomi_miio/fan.py Outdated Show resolved Hide resolved
homeassistant/components/xiaomi_miio/fan.py Show resolved Hide resolved
@foxel
Copy link
Contributor Author

foxel commented Feb 19, 2020

@pkrolkgp thanks for suggestions. I don't have 3H but believe it's the same as 3...

@PawelKwiecinski
Copy link

@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.

@homeassistant
Copy link
Contributor

Hi @pkrolkgp,

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

@Flagun
Copy link

Flagun commented Mar 4, 2020

hi guys can you please add model "zhimi.airpurifier.mb3" as well?

@pkrolkgp
Copy link
Contributor

pkrolkgp commented Mar 4, 2020

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"
Copy link
Member

Choose a reason for hiding this comment

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

Why change this?

Copy link
Contributor Author

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
Copy link
Member

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.

Copy link
Contributor Author

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()]
Copy link
Member

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.

@rytilahti
Copy link
Member

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 🎉

@CLARENNE-Q
Copy link

Any news about this beautiful integration ?

@rytilahti
Copy link
Member

rytilahti/python-miio#658 release PR is now there, so I hope we'll have python-miio 0.5.0 released very soon!

@bbiegun
Copy link

bbiegun commented Mar 29, 2020

@rytilahti , you've just released 050! :)
drums...

@rytilahti
Copy link
Member

rytilahti commented Mar 29, 2020

Indeed! 🎉 I adjusted #32850 to bump the requirement, @foxel, this PR can also proceed now :-)

@foxel foxel marked this pull request as ready for review March 29, 2020 17:39
@nhok3296
Copy link

Already able to use this integration yet? Thank you

@foxel
Copy link
Contributor Author

foxel commented Mar 31, 2020

@nhok3296 I'm using this in my installation now. But it's not merged yet.

@foxel foxel changed the title Add support for Mi AirPurifier 3 (DRAFT) Add support for Mi AirPurifier 3 Mar 31, 2020
@nhok3296
Copy link

@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"
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

Copy link
Member

@rytilahti rytilahti left a 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:
Copy link
Member

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?

Copy link
Contributor Author

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...

Copy link
Member

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.

Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made one

Copy link
Member

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! 🥇

@rytilahti rytilahti merged commit 912eb32 into home-assistant:dev Apr 3, 2020
Copy link
Member

@MartinHjelmare MartinHjelmare left a 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"]
Copy link
Member

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.

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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",
Copy link
Member

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

Copy link
Member

@rytilahti rytilahti Apr 3, 2020

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..

Copy link
Member

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.

Copy link
Contributor

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.

@CLARENNE-Q
Copy link

CLARENNE-Q commented Apr 9, 2020

Nothing about in https://www.home-assistant.io/blog/2020/04/08/release-108/ ?

Invalid config for [fan.xiaomi_miio]: value is not allowed for dictionary value @ data['model']. Got 'zhimi.airpurifier.ma4'. (See ?, line ?).

On homeassistant/qemux86-64-homeassistant with version 0.108.0b5

@frenck
Copy link
Member

frenck commented Apr 9, 2020

@CLARENNE-Q This PR is merged after the beta was cut. It is not in 0.108.

@dj4shots
Copy link

is this available now in 0.108.3 ?

@frenck
Copy link
Member

frenck commented Apr 14, 2020

@dj4shots No, new features are only shipped in major releases. This will be shipped with 0.109

@lock lock bot locked and limited conversation to collaborators Apr 15, 2020
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.