You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There are new features that are not being used in stable projects because there is not an official release of python-miio library for more than a year.
I personally would love to have a new release including already merged elements like: #1521, but I know there are a tons of other equally useful new features that cannot be used until a new proper release is out.
Describe the solution you'd like
A new release version.
Additional context
My selfish reason comes from this feature I would love to have in home-assistant: home-assistant/core#64726 (comment), but I think the impact would be way broader than that.
Reacted by Som83, Tomáš Lipovský, starkillerOG, Maximilian Geberl, saxel, Vincent Långström, dsimop, Tomek Król, Ryan Sonshine, Gleb Petrakov and 7 more
Thanks for the reminder, I definitely agree with you! I thought I could manage to rewire the homeassistant integration to use the new features, but life happened... Anyway, it's better to get a new release out and figure rest of the todos listed in #1114 in minor releases as none of the missing pieces should not cause any breaking changes.
I did some necessary work that have to go in (#1813#1816), and hopefully #1814 is the last piece before cutting a new release. I am working on it right now, but I have no access to any devices to test anything and I'm preoccupied with other things, so I'm going to need some help, especially with testing. As the upcoming release will contain a lot of breaking changes, I'm planning to release alphas/betas to get some feedback and to fix any blockers.
Reacted by sesame_madness, Maximilian Geberl, Akshaya Annavajhala and Vincent Långström
I am also available to test, if my hardware is of use to you (I have a viomi.vacuum.v10 which is unsupported in the home assistant integration but works through python-miio itself)
@rytilahti If you need any support with this, let me know. I'm currently owning the following devices:
Tower Fan (dmaker.fan.p39)
Smart Heater 1S (zhimi.heater.mc2a)
Dreame L10s Pro (dreame.vacuum.r2228o)
Roborock 1st gen vacuum (rockrobo.vacuum.v1)
It's a real pitty seeing all the device support added since v0.5.12 without being able to leverage them in Home Assistant because the most recent release is a year and a half old.
So again: If I can help in any way, just let me know :-)!
Here with the zhimi.airp.rmb1. The change needed was merged in Aug 2022 on #1486 , currently using a local relative path to install in my project but it would be nice to get a new package release if possible.
Hi everyone, and thanks for the interest and patience :-)
I have just released 0.6.0.dev0 (available also on pypi) to make it easier to install, to test and to port code over to use the new APIs. Please see the release notes for more information about the changes, and note particularly that this is not ready for end user consumption and cannot be used with current homeassistant integration as-is.
If you want to help with testing, the first steps would be to install the release and try out that everything is working as expected with the miiocli tool.
Install from pypi: pip install python-miio==0.6.0.dev0
You can use miiocli cloud to fetch and display the information like tokens.
miiocli device --ip <ip> --token <token> info should be able to show the command to use for further commands.
If the device supports miot, the info will show you that. In those cases, you can use miiocli genericmiot --ip <ip> --token <token> status to get the status information. actions command will list the available actions which can be called by using call. The settings (shown in the status and available also using miiocli genericmiot settings) can be changed using set, for example: miiocli genericmiot --ip <ip> --token <token> set light:on False
If you want to use this programmatically, you can use DeviceFactory.create() to create device instances, status(), actions(), settings(), and sensors() are part of the common API you want to try out. Most of the existing device integrations have not been ported over to define the necessary metadata, so if you have one of those devices and want to help, take a look at https://python-miio.readthedocs.io/en/latest/contributing.html#status-containers and for example viomivacuum or yeelight on how to do just that. #1617 shows the current coverage.
That's pretty much it, if something doesn't seem to be working, please open an issue or a discussion topic, and we can figure it hopefully out!
As mentioned in the release notes, this requires a major refactoring (well, basically a rewrite...) of the xiaomi_miio integration to leverage the introspectable APIs (and genericmiot for miot devices) and is not ready for end users. I will clean up the existing code I have as a custom component, and release it later this week for those who want to test and contribute. Again, this will not be something ready for production use, but more a call for contributors to make it usable.
Reacted by Manuel Rüger, Daneish, Ryan Sonshine and Andrzej Pomirski
The current state of the rewrite based on 0.6+ is now available at https://github.com/rytilahti/homeassistant-xiaomi-ng . It is nowhere near production ready and there are bugs, both known and unknown, so simply reporting issues alone is not that useful if they are not combined with the intention to help to improve the situation with PRs.
That being said, if someone wants to give it a try, the repository is also open for issue reports that to make it easier to track the process of what really needs to be done. #1618 is probably one of the largest TODO that I would like to see done before even starting to think about getting this merged back to the homeassistant core, but there are plenty of other places that require polishing before this is ready to be released to the public.
This uses the same DOMAIN as the current core one and will probably break downgrading, so please don't test in production without backups if you don't want to help writing the code to migrate between the versions :-) The new config_entry format is not backwards-compatible the unique id is changed from the mac address to the device id to allow updating the IP address based on zeroconf updates.**
Reacted by Daneish, Manuel Rüger, Ryan Sonshine, Andrzej Pomirski, Samuel Knoch and Jakub Sarnowski
@rytilahti
Gerekçeni anlıyorum, özel yaşamındaki sorunlar yüzünden projenin ertelediğini söylüyorsun. Ancak, şunu bilmende yarar var; bu bir sorumluluktur böyle çoğu kişinin ilgisini çeken bir projede böyle çok fazla 'bug' görmek hiç mi hiç kariyerine olumlu yansımaz.
çoğu insan hakkındaki fikirlerini olumsuz düşünmelerine neden olursun.
bir proje yaptın ve popüler oldu ve arkasını getir.
If you want it English, please translate
Reacted by Said Ali
Reacted by Sebastian Muszynski, Ferenc Steyer, Vincent Långström, Giel Janssens, Tomek Król, Krzysztof Hajdamowicz, Abílio Costa, AdeZwart, t-animal, Wojciech Sobczak and 6 more
Another concrete case for a release: #1477 (merged July 2022) fixed set_led_brightness for the reversed-brightness MIoT purifiers, but 0.5.12 still has the old and value check. LedBrightness.Bright has value 0, so the reversal is skipped and the device gets 0, which on these models means off.
Reproduced with 0.5.12 and model="zhimi.airp.mb5":
Bright -> sends led_brightness=0 (should be 2)
Dim -> sends led_brightness=1
Off -> sends led_brightness=0
Home Assistant pins python-miio==0.5.12, so selecting "bright" on an Air Purifier 4 (zhimi.airp.mb5) or 4 Pro (zhimi.airp.vb4) turns the display off (see home-assistant/core#90302, auto-closed as stale). A 0.5.13 patch release with #1477 would be enough to fix it there. I'm proposing a small workaround in Home Assistant in the meantime.
Activity
rytilahti commentedon Aug 28, 2023
Thanks for the reminder, I definitely agree with you! I thought I could manage to rewire the homeassistant integration to use the new features, but life happened... Anyway, it's better to get a new release out and figure rest of the todos listed in #1114 in minor releases as none of the missing pieces should not cause any breaking changes.
I did some necessary work that have to go in (#1813 #1816), and hopefully #1814 is the last piece before cutting a new release. I am working on it right now, but I have no access to any devices to test anything and I'm preoccupied with other things, so I'm going to need some help, especially with testing. As the upcoming release will contain a lot of breaking changes, I'm planning to release alphas/betas to get some feedback and to fix any blockers.
jazomand commentedon Sep 6, 2023
Im happy and ready to help with testing. Please let me know what do you need. @rytilahti
akshay7394 commentedon Nov 14, 2023
I am also available to test, if my hardware is of use to you (I have a viomi.vacuum.v10 which is unsupported in the home assistant integration but works through python-miio itself)
pawelaugustyn commentedon Nov 15, 2023
@rytilahti I volunteer to test in case you need it
paranerd commentedon Dec 4, 2023
@rytilahti If you need any support with this, let me know. I'm currently owning the following devices:
It's a real pitty seeing all the device support added since v0.5.12 without being able to leverage them in Home Assistant because the most recent release is a year and a half old.
So again: If I can help in any way, just let me know :-)!
vinicentus commentedon Dec 10, 2023
@rytilahti I'd be happy to help with testing my
dreame.vacuum.mc1808, if it's still needed!mleppanen commentedon Jan 7, 2024
Also willing to help testing with my dreame.vacuum.p2140p Just drop me a line what to focus on. Eagerly waiting for the HA integration.
KSchmeeds commentedon Jan 21, 2024
I'm also here with the zhimi.airp.cpa4
ryansonshine commentedon Mar 3, 2024
Here with the
zhimi.airp.rmb1. The change needed was merged in Aug 2022 on #1486 , currently using a local relative path to install in my project but it would be nice to get a new package release if possible.Awesome project btw, thanks!
rytilahti commentedon Mar 13, 2024
Hi everyone, and thanks for the interest and patience :-)
I have just released 0.6.0.dev0 (available also on pypi) to make it easier to install, to test and to port code over to use the new APIs. Please see the release notes for more information about the changes, and note particularly that this is not ready for end user consumption and cannot be used with current homeassistant integration as-is.
If you want to help with testing, the first steps would be to install the release and try out that everything is working as expected with the
miioclitool.pip install python-miio==0.6.0.dev0miiocli cloudto fetch and display the information like tokens.miiocli device --ip <ip> --token <token> infoshould be able to show the command to use for further commands.miiocli genericmiot --ip <ip> --token <token> statusto get the status information.actionscommand will list the available actions which can be called by usingcall. The settings (shown in the status and available also usingmiiocli genericmiot settings) can be changed usingset, for example:miiocli genericmiot --ip <ip> --token <token> set light:on FalseIf you want to use this programmatically, you can use
DeviceFactory.create()to create device instances,status(),actions(),settings(), andsensors()are part of the common API you want to try out. Most of the existing device integrations have not been ported over to define the necessary metadata, so if you have one of those devices and want to help, take a look at https://python-miio.readthedocs.io/en/latest/contributing.html#status-containers and for example viomivacuum or yeelight on how to do just that. #1617 shows the current coverage.That's pretty much it, if something doesn't seem to be working, please open an issue or a discussion topic, and we can figure it hopefully out!
As mentioned in the release notes, this requires a major refactoring (well, basically a rewrite...) of the xiaomi_miio integration to leverage the introspectable APIs (and genericmiot for miot devices) and is not ready for end users. I will clean up the existing code I have as a custom component, and release it later this week for those who want to test and contribute. Again, this will not be something ready for production use, but more a call for contributors to make it usable.
rytilahti commentedon Mar 14, 2024
The current state of the rewrite based on 0.6+ is now available at https://github.com/rytilahti/homeassistant-xiaomi-ng . It is nowhere near production ready and there are bugs, both known and unknown, so simply reporting issues alone is not that useful if they are not combined with the intention to help to improve the situation with PRs.
That being said, if someone wants to give it a try, the repository is also open for issue reports that to make it easier to track the process of what really needs to be done. #1618 is probably one of the largest TODO that I would like to see done before even starting to think about getting this merged back to the homeassistant core, but there are plenty of other places that require polishing before this is ready to be released to the public.
This uses the same DOMAIN as the current core one and will probably break downgrading, so please don't test in production without backups if you don't want to help writing the code to migrate between the versions :-) The new config_entry format is not backwards-compatible the unique id is changed from the mac address to the device id to allow updating the IP address based on zeroconf updates.**
hmmbob commentedon Jun 21, 2024
Any stable release in sight already?
Can't help to notice that the 0.6.0 milestone is running for almost 3 years already, and that this issue is also almost a year old by now.
CyberMan571 commentedon May 17, 2025
@rytilahti
Gerekçeni anlıyorum, özel yaşamındaki sorunlar yüzünden projenin ertelediğini söylüyorsun. Ancak, şunu bilmende yarar var; bu bir sorumluluktur böyle çoğu kişinin ilgisini çeken bir projede böyle çok fazla 'bug' görmek hiç mi hiç kariyerine olumlu yansımaz.
çoğu insan hakkındaki fikirlerini olumsuz düşünmelerine neden olursun.
bir proje yaptın ve popüler oldu ve arkasını getir.
If you want it English, please translate
miguelsg29 commentedon Oct 1, 2026
Another concrete case for a release: #1477 (merged July 2022) fixed
set_led_brightnessfor the reversed-brightness MIoT purifiers, but 0.5.12 still has the oldand valuecheck.LedBrightness.Brighthas value 0, so the reversal is skipped and the device gets0, which on these models means off.Reproduced with 0.5.12 and
model="zhimi.airp.mb5":Home Assistant pins
python-miio==0.5.12, so selecting "bright" on an Air Purifier 4 (zhimi.airp.mb5) or 4 Pro (zhimi.airp.vb4) turns the display off (see home-assistant/core#90302, auto-closed as stale). A 0.5.13 patch release with #1477 would be enough to fix it there. I'm proposing a small workaround in Home Assistant in the meantime.