[META] 0.7 series - module support for SMART devices, support for introspectable device features and refactoring the library

[rytilahti]

This issue collects ideas and TODOs for the 0.7 and its patch releases.

Not everything has to be done for the initial release (all API breaking changes would be nice, though),
so this can be considered as sort of overview of things that should or could be implemented.

This is aimed to be a "living" issue to help keep track of things to do, so feel free to modify and/or add discussion points in comments.

General

• Nicer access for individual modules (enable type hinting, avoiding str indexing) Make get_module return typed module #892
• Convert device_specific_information to simply return key-val based on features, and remove output from the cli Change state_information to return feature values #804
• Need to create common interfaces for legacy and new devices #613
• Add command/raw_command to the common API not critical for 0.7.0

API breaking changes

• Combine smart{plug,light} into smartdevice #747
• Clean-up bulb API: move effects and presets to features Add LightEffectModule for dynamic light effects on SMART bulbs #887 Add light presets common module to devices. #907

Features

• Add support for feature units #843
• Extra metadata for features (entity_category, show_per_default, etc.) that can be interpreted downstreams how they wish Add hass_compat to feature #879 replaced by Improve categorization of features #904
• Implement feature categories #846
  • Informative (like MAC, device id, ..)
  • Settings/configuration (that change functionality, e.g., LED)
  • Debug? RSSI, Time, etc. values that change often and are not that important. Alternatively, a flag to allow homeassistant filtering such features from entity creation.
• Callables ("buttons" in homeassistant) Implement action feature #849
• Ranged features ("input", or metadata for homeassistant). For example, color_temperature. Support for on_off_gradually v2+ #793
• Convert IotDevice to expose the basic features, like emeter, for HA compat Expose IOT emeter info as features #844
• Chime as its own feature type? Could by used in siren platform for hubs. not worth having a separate type for this

Modules

• Default states (default_states), i.e., what happens on hard power off
• Presets (presets)?
• Overheat information (overheat_protection)
• Scheduling features (anti_theft, countdown, schedule)`
• trigger_logs for hub-connected devices Initial trigger logs implementation #900
• auto_light (color temp / brightness follows the sun?)

CLI

• Add indicator for changeable and callable features
• Group features based on type/module? Implement feature categories #846
• Extend cli to allow defining --child across all relevant commands #769 Not critical for 0.7.0

Tests

• Add tests for the base class interfaces
• Improve feature/module testing and coverage for SMART devices #778
  • Add tests for (smartdevice) modules
• Split IOT tests out from test_smartdevice

Docs

• Clean up the README #979
• Update documentation for new interfaces #779
• Document device features #755

Protocol/error handling

• Handling of device-reported timeouts (should be handled internally by the transport classes?)