python-kasa/docs/source/smartdevice.rst

Common API
======================

The basic functionalities of all supported devices are accessible using the common :class:`SmartDevice` base class.

The property accesses use the data obtained before by awaiting :func:`update()`.
The values are cached until the next update call. In practice this means that property accesses do no I/O and are dependent, while I/O producing methods need to be awaited.

Methods changing the state of the device do not invalidate the cache (i.e., there is no implicit `update()`).
You can assume that the operation has succeeded if no exception is raised.
These methods will return the device response, which can be useful for some use cases.

Errors are raised as :class:`SmartDeviceException` instances for the library user to handle.


.. autoclass:: kasa.SmartDevice
    :members:
    :undoc-members:
Simplify API documentation by using doctests (#73) * Add doctests to SmartBulb * Add SmartDevice doctests, cleanup README.md * add doctests for smartplug and smartstrip * add discover doctests * Fix bulb mock * add smartdimmer doctests * add sphinx-generated docs, cleanup readme a bit * remove sphinx-click as it does not work with asyncclick * in preparation for rtd hooking, move doc deps to be separate from dev deps * pytestmark needs to be applied separately for each and every file, this fixes the tests * use pathlib for resolving relative paths * Skip discovery doctest on python3.7 The code is just fine, but some reason the mocking behaves differently between 3.7 and 3.8. The latter seems to accept a discrete object for asyncio.run where the former expects a coroutine.. 2020-06-30 00:29:52 +00:00			`Common API`
			`======================`

			The basic functionalities of all supported devices are accessible using the common :class:`SmartDevice` base class.

			The property accesses use the data obtained before by awaiting :func:`update()`.
			`The values are cached until the next update call. In practice this means that property accesses do no I/O and are dependent, while I/O producing methods need to be awaited.`

			Methods changing the state of the device do not invalidate the cache (i.e., there is no implicit `update()`).
			`You can assume that the operation has succeeded if no exception is raised.`
			`These methods will return the device response, which can be useful for some use cases.`

			Errors are raised as :class:`SmartDeviceException` instances for the library user to handle.


			`.. autoclass:: kasa.SmartDevice`
			`:members:`
			`:undoc-members:`