Dreame F9 Vacuum (dreame.vacuum.p2008) support

[peleccom]

This PR adds support for Dreame F9 Vacuum (dreame.vacuum.p2008)
https://home.miot-spec.com/spec?type=urn%3Amiot-spec-v2%3Adevice%3Avacuum%3A0000A006%3Adreame-p2008%3A1

[rytilahti]

Hi and thanks for the PR! Have you tried to check how much does this differ from the current dreame implementation? If it's just about different mappings (and some other extra features), it would be better to extend that instead of having a separate implementation for this.

[peleccom]

@rytilahti Hi. It has different mapping and some different statuses. Do you mean we should create subclass for Dreame F9 in that case?

[rytilahti]

@peleccom hi! Okay, so it would be better to modify the existing implementation to have a dictionary of mappings (e.g., https://github.com/rytilahti/python-miio/blob/master/miio/fan_miot.py#L17) and using the same keys wherever possible.

I see that the current dreame implementation is not using call_action for the actions, likely because the wasn't available when the integration was created.. So, the way I see this should be done is to adjust the existing mc1808 mapping to include the necessary actions (as yours does) and consolidate the code to use call_action for everything.

If there are some functions that are available only on p2008, you can check for the model (self.model) and raise an exception to inform that the functionality is not available. The plan is to have some common interfaces to make it easier to add homeassistant integration notwithstanding that devices are produced by different vendors.

Now for the status container, we can extend that to cover new features of p2008, and it's fine to return None if the data is not available due to a different mapping.
About the status codes themselves, the best approach depends on whether we can re-use the existing mapping at all or not. Are the common codes (or statuses) being shared by both models, or do the differ so much that this would require a separate status code class?

[peleccom]

Ok. Now it share the same implementation as Dreame 1C.

#1254 as a rewrite of Dreame 1C implementation looks good and simplify code much. But it is very different from other implementation. Also current state doesn't allow to use commands from cli tool as I can see.

Also I want to ask if it is some progress with universal interface for all vacuum implementations? Can I help with something?

[rytilahti]

A brief review round:

• Please avoid separate container & implementation classes, as this makes it just harder to prepare to move using common interfaces.
• DreameVacuumMiot would be the main class, which supports both models, you can adjust the behavior inside the class by leveraging the model information (self.model).

[rytilahti]

Ok. Now it share the same implementation as Dreame 1C.

Looks already much better! 👍

#1254 as a rewrite of Dreame 1C implementation looks good and simplify code much. But it is very different from other implementation. Also current state doesn't allow to use commands from cli tool as I can see.

Ah, you are right. It's better to get your PR done first, and then consider adding support for other dreame devices to the integration.

Also I want to ask if it is some progress with universal interface for all vacuum implementations? Can I help with something?

Alas, there hasn't been much going on on that front, I simply don't have time to work on it currently. The first step to make that happen would likely involve creating those interfaces (for Vacuum and VacuumStatus) and start porting all integrations over, starting from small with only very basic functionality and extending that over time.

[rytilahti]

Hi @peleccom, I realized that there is no facilities to handle mappings dictionaries without fuss.. I created #1302 to improve the situation, that should make it simpler to implement the required changes, please let me know if that helps :-)

[peleccom]

@rytilahti Please check

[codecov-commenter]

Codecov Report

Merging #1290 (7ddd689) into master (2af2d67) will decrease coverage by 0.09%.
The diff coverage is 76.92%.

@@            Coverage Diff             @@
##           master    #1290      +/-   ##
==========================================
- Coverage   82.43%   82.34%   -0.10%     
==========================================
  Files         109      109              
  Lines       11614    11831     +217     
  Branches     1376     1397      +21     
==========================================
+ Hits         9574     9742     +168     
- Misses       1838     1880      +42     
- Partials      202      209       +7     

Impacted Files	Coverage Δ
miio/discovery.py	49.33% <ø> (ø)
miio/miot_device.py	81.53% <0.00%> (-1.28%)	⬇️
...io/integrations/vacuum/dreame/dreamevacuum_miot.py	75.08% <65.07%> (-8.57%)	⬇️
miio/__init__.py	100.00% <100.00%> (ø)
...ions/vacuum/dreame/tests/test_dreamevacuum_miot.py	100.00% <100.00%> (ø)
miio/integrations/vacuum/roborock/vacuum.py	63.38% <0.00%> (+0.07%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2af2d67...7ddd689. Read the comment docs.

[rytilahti]

Btw, looks like another model (dreame.vacuum.p2028) is also using the same command set: #1217 (comment)

[peleccom]

@rytilahti Fine. I've added Dreame Z10 Pro (dreame.vacuum.p2028) to the list of supported models.
Can we merge PR now?

[rytilahti]

@peleccom this is just pending on the status container docstring as I mentioned earlier: #1290 (comment) - would you please handle that? :-)

[rytilahti]

Looks great, thanks for the PR @peleccom! Please rebase on top of the current master and I'll merge it.