Different devices and different firmwares report overheated status in
different ways.
Some devices indicate support for `overheat_protect` component, but
there are devices that report `overheat_status` even when it is not
listed.
Some other devices use `overheated` boolean that was already previously
supported, but this PR adds support for much more devices that use
`overheat_status` for reporting.
The "overheated" feature is moved into its own module, and uses either
of the ways to report this information.
This will also rename `REQUIRED_KEY_ON_PARENT` to `SYSINFO_LOOKUP_KEYS`
and change its logic to check if any of the keys in the list are found
in the sysinfo.
```
tpr@lumipyry ~/c/p/tests (fix/overheated)> ag 'overheat_protect' -c|wc -l
15
tpr@lumipyry ~/c/p/tests (fix/overheated)> ag 'overheated' -c|wc -l
38
tpr@lumipyry ~/c/p/tests (fix/overheated)> ag 'overheat_status' -c|wc -l
20
```
---------
Co-authored-by: Steven B. <51370195+sdb9696@users.noreply.github.com>
Python 3.11 ships with latest Debian Bookworm.
pypy is not that widely used with this library based on statistics. It could be added back when pypy supports python 3.11.
To resolve issues with the calls to the tplink cloud to get the latest firmware.
Disables the automatic calling of `get_latest_fw` and requires firmware update checks to be triggered manually.
Re-query failed modules after some delay instead of immediately disabling them.
Changes to features so they can still be created when modules are erroring.
Expose reboot through the feature interface.
This can be useful in situations where one wants to reboot the device,
e.g., in recent cases where frequent update calls will render the device
unresponsive after a specific amount of time.
Fixes module to work with child devices, i.e. ks240
Interrogates the data to see whether maximums are available.
Fixes a bug whereby setting a duration while the feature is not
enabled does not actually enable it.
Starts structuring the documentation library usage into Tutorials, Guides, Explanations and Reference.
Continues migrating new docs from rst to markdown.
Extends the test framework discovery mocks to allow easy writing and testing of code examples.
Support the `light_effect` module which allows setting the effect to Off
or Party or Relax. Uses the new `Feature.Type.Choice`. Does not
currently allow editing of effects.
This adds a test to check that all feature.set_value() calls will cause
a query, i.e., that there are no self.call()s that are not awaited, and
fixes existing code in this context.
This also fixes an issue where it was not possible to print out the
feature if the value threw an exception.
This can be used to hint how the sensor value should be rounded when
displaying it to users.
The values are adapted from the values used by homeassistant.
Moves `FeatureType` into `Feature` to make it easier to use the API.
This also enforces that no invalid types are accepted (i.e.,
`Category.Config` cannot be a `Sensor`)
If `--verbose` is used with the cli tool, some extra information is
displayed for features when in the state command.
Adds `FeatureType.Action` making it possible to expose features like
"reboot", "test alarm", "pair" etc.
The `attribute_getter` is no longer mandatory, but it will raise an
exception if not defined for other types than actions.
Trying to read returns a static string `<Action>`.
This overloads the `set_value` to call the given callable on any value.
This also fixes the `play` and `stop` coroutines of the alarm module to
await the call.
Initial implementation for feature categories to help downstreams and
our cli tool to categorize the data for more user-friendly manner. As
more and more information is being exposed through the generic features
interface, it is necessary to give some hints to downstreams about how
might want to present the information to users.
This is not a 1:1 mapping to the homeassistant's mental model, and it
will be necessary to fine-tune homeassistant-specific parameters by
other means to polish the presentation.
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.
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
```
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 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`
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.
