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.
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 improves the temperature control features to allow implementing
climate platform support for homeassistant.
Also adds frostprotection module, which is also used to turn
the thermostat on and off.
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).
The fixture now includes the queries returned directly from the child devices which is stored under child_devices along with valid device ids.
Also fixes a bug in the test_cli.py::test_wifi_scan which fails with more than 9 networks.
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.
Pass a dummy object as context object as it will not be used by --help
anyway.
Also, allow defining --help anywhere in the argv, not just in the last
place.
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.
Exposes IOT emeter information using features, bases on #843 to allow
defining the units.
---------
Co-authored-by: Steven B <51370195+sdb9696@users.noreply.github.com>
When devices have lists greater than 10 for child devices only the first
10 are returned. This retrieves the rest of the items (currently with
single requests rather than multiple requests)
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.
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.
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.
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>
* Added https://github.com/mihai-dinculescu/tapo/ to the list of related
projects.
* Changed the `kasa.tapo` to `kasa.smart`
---------
Co-authored-by: Steven B <51370195+sdb9696@users.noreply.github.com>
