python-miio
python-miio copied to clipboard
New release is needed
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: https://github.com/rytilahti/python-miio/pull/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: https://github.com/home-assistant/core/pull/64726#issuecomment-1682081996, but I think the impact would be way broader than that.
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.
Im happy and ready to help with testing. Please let me know what do you need. @rytilahti
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 I volunteer to test in case you need it
- roborock.vacuum.a62 (not supported in 0.5.12, but support present in the current codebase)
- zhimi.airpurifier.m1 (control only via cloud)
- zhimi.airpurifier.mb3
@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 :-)!
@rytilahti I'd be happy to help with testing my dreame.vacuum.mc1808
, if it's still needed!
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.
I'm also here with the zhimi.airp.cpa4
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!
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 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 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.
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. https://github.com/rytilahti/python-miio/pull/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.**
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.