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
This meta task will track the progress and tasks to do for the next major release, which aims to simplify the use of the library for downstream users and reorganize the organically grown code base to be more maintainable.
This issue will give an overview of the planned changes, which are discussed more in-depth under their corresponding issues linked below as they get written. This meta issue shall serve as a checklist for the changelog, and is open for discussions.
Repository structure
Motivation: all source files are currently stored in the main miio directory for historical reasons, making it messy.
Goal: by splitting each individual implementation (integration?) and files related to it (e.g., tests and some data files) will clean up the code base.
Motivation: there is currently no way to construct device instances just by knowing their host and the token, making it necessary for downstreams to import the classes implementing the support and initializing it separately based on model information (or simply supporting a single implementation, like done by homeassistant's vacuum platform).
Goal: allow initializing device-derived objects by simply knowing their host and the token which simplifies downstream implementations.
Motivation: adding support for devices of the same device class (e.g., vacuums) is cumbersome as there is no well-defined API among the different implementations.
Goal: provide device-type based base classes to make adding support for new device integrations on downstream just a matter of upgrading the python-miio.
Tasks
Create base classes for individual device types where it makes sense to make it easier for downstreams to add support for a class of devices.
Add model detection based on miIO.info to consolidate handling of device-specific differences inside a single integration. Add model autodetection #1038
Add supported_features or similar feature flags to allow integrations specify which features is supported by the device model. This will allow moving these checks from downstream (homeassistant most prominently) to where this information belongs.
Make available sensors introspectable (status class properties could be extended to allow defining metadata for available sensors). [meta] Add introspectable interfaces #1495
Make available actions introspectable by exposing @commands.
Motivation: all new devices are using miot instead of custom protocols to control devices, so it makes sense to add first class support to the library.
Goal: all miot supporting devices can be controlled as long as internet-connectivity is available to fetch the required schema file.
Provide consolidated information (including descriptions, icons, etc.) for standard settings and actions using a yaml metadata file: Add metadata support for genericmiot #1618
This meta task will track the progress and tasks to do for the next major release, which aims to simplify the use of the library for downstream users and reorganize the organically grown code base to be more maintainable.
This issue will give an overview of the planned changes, which are discussed more in-depth under their corresponding issues linked below as they get written. This meta issue shall serve as a checklist for the changelog, and is open for discussions.
Repository structure
Tasks
miio/integrations/<name>
ormiio/integrations/<type of device>/<name>
. [meta] Restructure integrations to their own directories #1115__getattr__
tomiio
to inform about the breaking changes. #1696"Device factory"
Tasks
Add manifest files to integrations that describe supported models (miIO.info-based and mDNS entries) [meta] Add integration manifest files #1116Common APIs
Tasks
miIO.info
to consolidate handling of device-specific differences inside a single integration. Add model autodetection #1038supported_features
or similar feature flags to allow integrations specify which features is supported by the device model. This will allow moving these checks from downstream (homeassistant most prominently) to where this information belongs.@command
s.MiOT support
Tasks
Other changes
ValueError
instead of custom exception types) Clean up raised library exceptions #1558The text was updated successfully, but these errors were encountered: