python-kasa/kasa/smart/modules/childdevicemodule.py

"""Implementation for child devices."""

from ..smartmodule import SmartModule


class ChildDeviceModule(SmartModule):
    """Implementation for child devices."""

    REQUIRED_COMPONENT = "child_device"
    QUERY_GETTER_NAME = "get_child_device_list"
Initial implementation for modularized smartdevice (#757) 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. 2024-02-19 17:01:31 +00:00			`"""Implementation for child devices."""`
Generalize smartdevice child support (#775) * 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. 2024-02-22 19:46:19 +00:00
Initial implementation for modularized smartdevice (#757) 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. 2024-02-19 17:01:31 +00:00			`from ..smartmodule import SmartModule`


			`class ChildDeviceModule(SmartModule):`
			`"""Implementation for child devices."""`

			`REQUIRED_COMPONENT = "child_device"`
Revise device initialization and subsequent updates (#807) 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. 2024-03-15 16:18:13 +00:00			`QUERY_GETTER_NAME = "get_child_device_list"`