This PR will make `__repr__` also work on smartdevices where only
discovery data is available by modifying the `model` property to
fallback to the data found in the discovery payloads.
No devices in `fixtures/smart/child` support the `get_device_time` or
`get_device_usage` methods so this PR tests for whether the device is a
hub child and marks those modules/methods as not supported. This
prevents features being erroneously created on child devices.
It also moves the logic for getting the time from the parent module
behind getting it from the child module which was masking the creation
of these unsupported modules.
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.
Addresses stability issues on older hw device versions
- Handles module timeout errors better by querying modules individually on errors and disabling problematic modules like Firmware that go out to the internet to get updates.
- Addresses an issue with the Led module on P100 hardware version 1.0 which appears to have a memory leak and will cause the device to crash after approximately 500 calls.
- Delays updates of modules that do not have regular changes like LightPreset and LightEffect and enables them to be updated on the next update cycle only if required values have changed.
Ensures that all modules try to access their data in `_post_update_hook` in a safe manner and disable themselves if there's an error.
Also adds parameters to get_preset_rules and get_on_off_gradually_info to fix issues with recent firmware updates.
[#1033](https://github.com/python-kasa/python-kasa/issues/1033)
Adds a new decorator that adds child options to a command and gets the
child device if the options are set.
- Single definition of options and error handling
- Adds options automatically to command
- Backwards compatible with `--index` and `--name`
- `--child` allows for id and alias for ease of use
- Omitting a value for `--child` gives an interactive prompt
Implements private `_update` to allow the CLI to patch a child `update`
method to call the parent device `update`.
Example help output:
```
$ kasa brightness --help
Usage: kasa brightness [OPTIONS] [BRIGHTNESS]
Get or set brightness.
Options:
--transition INTEGER
--child, --name TEXT Child ID or alias for controlling sub-
devices. If no value provided will show an
interactive prompt allowing you to select a
child.
--child-index, --index INTEGER Child index controlling sub-devices
--help Show this message and exit.
```
Fixes#769
Required for the P300 firmware update with `auto_off` module on child
devices. Will query child modules for parent devices that are not hubs.
Coverage will be fixed when the P300 fixture is added
https://github.com/python-kasa/python-kasa/pull/915
Replaces the logic to skip adding child modules to parent devices based
on whether a device is a wall switch and instead relies on the
`_check_supported` method. Is more future proof and will fix issue with
the P300 with child `auto_off` modules
https://github.com/python-kasa/python-kasa/pull/915 not supported on the
parent.
Adds light preset common module for switching to presets and saving presets.
Deprecates the `presets` attribute and `save_preset` method from the `bulb`
interface in favour of the modular approach. Allows setting preset for `iot`
which was not previously supported.
Address the inconsistent naming of smart modules by removing all "Module" suffixes and aligning filenames with class names. Removes the casting of modules to the correct module type now that is is redundant. Update the adding of iot modules to use the ModuleName class rather than a free string.
Passing in a string still works and returns either `IotModule` or
`SmartModule` type when called on `IotDevice` or `SmartDevice`
respectively. When calling on `Device` will return `Module` type.
Passing in a module type is then typed to that module, i.e.:
```py
smartdev.get_module(FanModule) # type is FanModule
smartdev.get_module("FanModule") # type is SmartModule
```
Only thing this doesn't do is check that you can't pass an `IotModule`
to a `SmartDevice.get_module()`. However there is a runtime check which
will return null if the passed `ModuleType` is not a subclass of
`SmartModule`.
Many thanks to @cdce8p for helping with this.
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.
Brings consistency to the api across Smart and Iot so the interfaces can be used for their specialist methods as well as the device methods (e.g. turn_on/off).
Enables the Fan interface for devices supporting that component.
Currently the only device with a fan is the ks240 which implements it as
a child device. This PR adds a method `get_module` to search the child
device for modules if it is a WallSwitch device type.
In order to support the ks240 which has children for the fan and light
components, this PR adds those modules at the parent level and hides the
children so it looks like a single device to consumers. It also decides
which modules not to take from the child because the child does not
support them even though it say it does. It does this for now via a
fixed list, e.g. `Time`, `Firmware` etc.
Also adds fixtures from two versions and corresponding tests.
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.
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.
Devices not connected to the internet will either error when querying
firmware queries (e.g. P300) or return misleading information (e.g.
P100). This PR adds the cloud connect query to the initial queries and
bypasses the firmware module if not connected.
