Support for the Xiaomi Induction Cooker

[basveeling]

This is a first attempt at supporting the Xiaomi Induction Cooker models (#491), which include models
chunmi.ihcooker.eg1 chunmi.ihcooker.exp1 chunmi.ihcooker.chefnic chunmi.ihcooker.hk1 chunmi.ihcooker.korea1 chunmi.ihcooker.tw1 chunmi.ihcooker.v1

Turns out the device is a bit more advanced than the app makes it appear. It supports 16-step recipes with each step having specific power, temperature, timer and next-phase settings. This enables building 'smart' recipes for e.g. automated rice cooking, kettle, pressure cooking, etc.

Supported features:

• Stopping device
• Starting a profile with and without confirmation
• Status of cooker including temperature, power/fire output, recipe phase.
• Saving a recipe to the menu.
• Making custom recipes with CookProfile.
• Update recipe settings while running.
• Factory reset.
• Interpreting existing recipes.

To do:

• Build successfully; currently stuck on an issue with poetry/tox AttributeError: type object 'Callable' has no attribute '_abc_registry' <- I could use some advice here :-).
• Run some more real-world tests.
• Verify with beta testers.
• Verify that other models are correctly supported.
• Figure out some of the remaining mystery bits & bytes in the recipe and status fields.
• Write more tests on integration.
• Figure out how to make recipe building accessible (default yaml file that can be passed to CLI?)

Shout-out to @aquarat, @EUA and @hossF for initial analysis and @esgie for the plugin APK 👍

Here's a read-out of a rice-cooker program.

[coolibry]

Hi basveeling,

thanks for this works.

for Build successfully; currently stuck on an issue with poetry/tox AttributeError: type object 'Callable' has no attribute '_abc_registry' <- I could use some advice here :-) :
maybe it's on line 621 of ihcooker.py, change menu to recip_name :
"Menu: {result.recipe_name}\n"

in my side build works.

[didjeru]

Any news on this issue?

[guancio]

I'm willing to test it. It is working on my induction cooker.

[rytilahti]

Hi and thanks for the PR! Looks like I forgot to submit this review looooong time ago for some reason, apologies for that... I hope that the inlined comments should help restructuring the code a bit, but it's currently just way too much to review piece-by-piece.

The biggest issue I have in its current form is that the code is too hard to read: there are too many magic numbers and direct index accesses (also outside the checksum calculation) that should be easier to define as contruct.Structs for maintainability.

Considering that at least part of the contents of those hex-encoded payloads are already known based on the code, it should not be too hard to convert them to use construct for parsing.

[rytilahti]

There is also #1018 (which aims to support only one model listed in your description). I think it would be great if you @basveeling and @sschirr could combine your efforts & knowledge on this topic :-)

[basveeling]

There is also #1018 (which aims to support only one model listed in your description). I think it would be great if you @basveeling and @sschirr could combine your efforts & knowledge on this topic :-)

It seems this is a different device class (chunmi.cooker, whereas this PR concerns chunmi.ihcooker) and the multicooker seems closer to the rice cookers in operation.

[basveeling]

@rytilahti Thank you for the review! With a bit of delay on my side, I believe I have made most of the changes requested, outside of moving the bytestring building to Construct. I can take a look at that at a later point, I leave it up to you to decide if that is a blocking issue for this PR. In the mean time I'm happy to address any other issues, looking forward to hearing your thoughts!

[rytilahti]

Thanks @basveeling, no worries about delays, we are are volunteers here! :-) I added some more comments inline, my opinion is that it'd be better to convert to use construct for the payloads, as that will greatly simplify the code by avoiding plenty of conditionals & direct offset accesses.

Now, I'm not sure if there should be separate V1 and V2 structs (or a parameterized, shared one) defining the data structure, but as long as the access keys are shared among those, it should be easy to have a common interface for both.

[basveeling]

@rytilahti Thank you for the feedback! A couple of changes in this new version.

• moved the recipe building to Construct (I needed to add two custom Subconstructs for this, perhaps you know a good place to place these in the directory structure?)
• I went for a parametrised construct for the two versions, I could not get a single construct to work for both versions.
• Added a JSON recipe conversion option and example recipe.
• Some extra commands for making simple recipes based on single power and temperature settings.

[rytilahti]

Hi @basveeling and thanks for the update!

• moved the recipe building to Construct (I needed to add two custom Subconstructs for this, perhaps you know a good place to place these in the directory structure?)

Great! Since #1160 we started to move integrations to their own packages, the idea being that contents of that directory do not spill over to other integrations.

This will allow storing all code, auxiliary files and tests inside a single package. So I would suggest creating miio/integrations/ihcooker/ and move everything contained in this PR there, the directory structure could be something like:

• ihcooker/data/ for the profile files
• ihcooker/tests/ for the test file(s)
• ihcooker/ihcooker.py for the main entry point (the Device-derived class)
• Additional files, so maybe it makes sense to separate the structures into separate file(s) to make the main module cleaner

• I went for a parametrised construct for the two versions, I could not get a single construct to work for both versions.

Without reading the code yet, that sounds like a good approach 👍 If you don't mind reshuffling the parts prior I do a full review, that would be great!

[basveeling]

Hi @rytilahti, thanks for the suggestion. I've refactored the code to use the new dir structure. It's a large PR so I'd understand if it takes some time :-). Looking forward to your review!

[basveeling]

Hi Teemu / @rytilahti,

I hope all is well. I see there's still a change requested status on this PR, but I think I've addressed all the comments. Just wanted to make sure it's clear this is ready for your review whenever you find the time :-).

Enjoy the holiday period!

[rytilahti]

Hey Bas, sorry, I completely forgot to submit some commentary I had written earlier... Thanks for the reminder! So there are just a couple of minor changes I'd like to see prior merging this, after those are done this is good to go 👍

edit: oh, also, do not forget to update README.md accordingly :-)

[rytilahti]

I don't think these are correct for mdns? Either remove these completely for now, or check what format is being used in mdns on your device and just add them here as regular strings.

This information should be moved inside the integration itself at some point, but it'll require some more work. Having these here as strings makes it easy to copy them over if/when that time comes.

[basveeling]

Removed.

[rytilahti]

They seem to be still there in the diff 👀

[dangenendt]

Hi! Following this issue since the start.
Want to build my brew master with this cooker.
Any news on this? 😁

[rytilahti]

Could you move the directroy to be under cooker/chunmi/ (just in case some other "cooker" devices come around), and rebase on top of the current master? Otherwise this is good to go and should be a part of the next release.

[rytilahti]

They seem to be still there in the diff 👀

[dmatora]

I have chunmi.ihcooker.v2
tried running miiocli cooker --ip blablabla --token blablabla status and got

WARNING:miio.device:Found an unsupported model 'chunmi.ihcooker.v2' for class 'Cooker'. If this is working for you, please open an issue at https://github.com/rytilahti/python-miio/
Error: {'code': -9999, 'message': 'user ack timeout'}

[dmatora]

@syssi where can I read about extracting react plugin from android (or jailbroken iPhone) device?

[trackhacs]

what to do to reactivate this?

[thewh1teagle]

@basveeling
Maybe you will be interested, and it will be great if you can take a look
I rewrote this PR in Dart and use it in a cross-platform Flutter app which controls the cooker.
Here is the repository: https://github.com/thewh1teagle/MiCook.

[tuxcrafter]

Any news on this merge for the cookers?