Add SMART.KASAHUB to the map of supported devices.
This also adds fixture files for KH100, KE100, and T310, and adapts affected modules and their tests accordingly.
---------
Co-authored-by: Steven B <51370195+sdb9696@users.noreply.github.com>
Also updates CI pypy versions to be 3.9 and 3.10 which are the currently
[supported
versions](https://www.pypy.org/posts/2024/01/pypy-v7315-release.html).
Otherwise latest cryptography doesn't ship with pypy3.8 wheels and is
unable to build on windows.
Also updates the `codecov-action` to v4 which fixed some intermittent
uploading errors.
This changes `state_information` to return the names and values of
all defined features.
It was originally a "temporary" hack to show some extra, device-specific
information in the cli tool, but now that we have device-defined
features we can leverage them.
Allow controlling the color temperature via features interface:
```
$ kasa --host 192.168.xx.xx feature color_temperature
Color temperature (color_temperature): 0
$ kasa --host 192.168.xx.xx feature color_temperature 2000
Setting color_temperature to 2000
Raised error: Temperature should be between 2500 and 6500, was 2000
Run with --debug enabled to see stacktrace
$ kasa --host 192.168.xx.xx feature color_temperature 3000
Setting color_temperature to 3000
$ kasa --host 192.168.xx.xx feature color_temperature
Color temperature (color_temperature): 3000
```
This improves the initial update cycle to fetch the information as early
as possible and avoid requesting unnecessary information (like the child
component listing) in every subsequent call of `update()`.
The initial update performs the following steps:
1. `component_nego` (for components) and `get_device_info` (for common
device info) are requested as first, and their results are stored in the
internal state to allow individual modules (like colortemp) to access
the data during the initialization later on.
2. If `child_device` component is available, the child device list and
their components is requested separately to initialize the children.
3. The modules are initialized based on component lists, making the
queries available for the regular `update()`.
4. Finally, a query requesting all module-defined queries is executed,
including also those that we already did above, like the device info.
All subsequent updates will only involve queries that are defined by the
supported modules. This also means that we do not currently support
adding & removing child devices on the fly.
The internal state contains now only the responses for the most recent
update (i.e., no component information is directly available anymore,
but needs to be accessed separately if needed). If component information
is wanted from homeassistant users via diagnostics reports, the
diagnostic platform needs to be adapted to acquire this separately.
Previously, only v1 of on_off_gradually is supported, and the newer versions are not backwards compatible.
This PR adds support for the newer versions of the component, and implements `number` type for `Feature` to expose the transition time selection.
This also adds a new `supported_version` property to the main module API.
Adds initial support for H100 and its alarmmodule.
Also implements the following modules for T315:
* reportmodule (reporting interval)
* battery
* humidity
* temperature
* Initialize children's modules (and features) using the child component negotiation results
* Set device_type based on the device response
* Print out child features in cli 'state'
* Add --child option to cli 'command' to allow targeting child devices
* Guard "generic" features like rssi, ssid, etc. only to devices which have this information
Note, we do not currently perform queries on child modules so some data may not be available. At the moment, a stop-gap solution to use parent's data is used but this is not always correct; even if the device shares the same clock and cloud connectivity, it may have its own firmware updates.
With the move towards autodetecting available features, there is no reason to keep SmartPlug around.
kasa.smart.SmartPlug is removed in favor of kasa.smart.SmartDevice which offers the same functionality.
Information about auto_off can be accessed using Features of the AutoOffModule on supported devices.
Co-authored-by: Steven B. <51370195+sdb9696@users.noreply.github.com>
Adds auto-off implementation. The feature stays enabled after the timer runs out, and it will start the countdown if the device is turned on again without explicitly disabling it.
New features:
* Switch to select if enabled: `Auto off enabled (auto_off_enabled): False`
* Setting to change the delay: `Auto off minutes (auto_off_minutes): 222`
* If timer is active, datetime object when the device gets turned off: `Auto off at (auto_off_at): None`
The initial steps to modularize the smartdevice. Modules are initialized based on the component negotiation, and each module can indicate which features it supports and which queries should be run during the update cycle.
This adds a generic interface for all device classes to introspect available device features,
that is necessary to make it easier to support a wide variety of supported devices with different set of features.
This will allow constructing generic interfaces (e.g., in homeassistant) that fetch and change these features without hard-coding the API calls.
`Device.features()` now returns a mapping of `<identifier, Feature>` where the `Feature` contains all necessary information (like the name, the icon, a way to get and change the setting) to present and change the defined feature through its interface.
* Fix for P100 on fw 1.1.3 login_version none
* Fix coverage
* Add delay before trying default login
* Move devtools and fixture out
* Change logging string
Co-authored-by: Teemu R. <tpr@iki.fi>
* Fix test
---------
Co-authored-by: Teemu R. <tpr@iki.fi>
