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.
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)
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
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.
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.
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.
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 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.
* 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>
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.
* Separate fake protocols for iot and smart
* Move control_child impl into its own method
* Organize schemas into correct places
* Add test_childdevice
* Add missing return for _handle_control_child
* Pull has_emeter property up to tapodevice base class
This will also use the existence of energy_monitoring in the component_nego query to decide if the device has the service.
* Move emeter related functions to tapodevice
* Remove supported_modules override for now
This should be done in a separate PR, if we want to expose the available components to cli and downstreams
* Dedent extra reqs
* Move extra_reqs initialization
* Fix tests
* Do login entirely within AesTransport
* Remove login and handshake attributes from BaseTransport
* Add AesTransport tests
* Synchronise transport and protocol __init__ signatures and rename internal variables
* Update after review
* Add support for TAPO/SMART KLAP and seperate transports from protocols
* Add tests and some review changes
* Update following review
* Updates following review
This refactors `Discover.connect_single` by moving device instance construction into a separate device factory module.
New `SmartDevice.connect(host, *, port, timeout, credentials, device_type)` class method replaces the functionality of `connect_single`,
and also now allows constructing device instances without relying on UDP discovery for type discovery if `device_type` parameter is set.
---------
Co-authored-by: Teemu R. <tpr@iki.fi>
Several KASA devices seem to have pretty strict buffer size limitations on incoming/outgoing data transfers.
Testing on KL125-US and HL103 has shown that sending a request size larger than about ~768 bytes will immediately crash the device. Additionally, a query that generates a response larger than ~4096 bytes will crash the KL125-US. I was unable to generate such a large response to test the HL103.
The KL125-US will only return such large queries when its monthly usage stats have been populated. This means that a new bulb would work fine, but after a month of data collection the bulb would break the 4K limit and start to crash.
To work around this issue, an estimated worst-case response size is calculated before sending a request by summing up all modules estimated response size. If the estimated size is greater than the device's max_response_payload_size then the query will be split into multiple queries.
This PR implements splitting queries expected to have large responses and also removes the module 'skip list' which was a previous workaround to the crash (which worked by simply reducing the number of modules queried, which prevented the overflow) since it is no longer necessary.
This PR does not attempt to address the "input buffer size limit." Thus far this limit has not been an issue.
* Add plumbing for passing credentials as far as discovery
* Pass credentials to Smart devices
* Rename authentication exception
* Fix tests failure due to test_json_output leaving echo as nop
* Fix test_credentials test
* Do not print credentials, fix echo function bug and improve get type parameter
* Add device class constructor test
* Add comment for echo handling and move assignment
