Various documentation updates (#333)

* Add a note about socket sharing

* Show inherited members for apidocs

* Remove outdated note of emeters not being supported on smartstrips

* Describe emeter and usage modules, add note about NTP for time sync

* Describe lib design and modules

* Bump sphinx version, ignore d001 (line-length) for doc8

* demote energy & usage to 3rd level, promote api for 2nd

docs/source/design.rst

@@ -0,0 +1,50 @@
+.. py:module:: kasa.modules
+
+.. _library_design:
+
+Library Design & Modules
+========================
+
+This page aims to provide some details on the design and internals of this library.
+You might be interested in this if you want to improve this library,
+or if you are just looking to access some information that is not currently exposed.
+
+.. _update_cycle:
+
+Update Cycle
+************
+
+When :meth:`~kasa.SmartDevice.update()` is called,
+the library constructs a query to send to the device based on :ref:`supported modules <modules>`.
+Internally, each module defines :meth:`~kasa.modules.Module.query()` to describe what they want query during the update.
+
+The returned data is cached internally to avoid I/O on property accesses.
+All properties defined both in the device class and in the module classes follow this principle.
+
+While the properties are designed to provide a nice API to use for common use cases,
+you may sometimes want to access the raw, cached data as returned by the device.
+This can be done using the :attr:`~kasa.SmartDevice.internal_state` property.
+
+.. _modules:
+
+Modules
+*******
+
+The functionality provided by all :class:`~kasa.SmartDevice` instances is (mostly) done inside separate modules.
+While the individual device-type specific classes provide an easy access for the most import features,
+you can also access individual modules through :attr:`kasa.SmartDevice.modules`.
+You can get the list of supported modules for a given device instance using :attr:`~kasa.SmartDevice.supported_modules`.
+
+.. note::
+
+    If you only need some module-specific information,
+    you can call the wanted method on the module to avoid using :meth:`~kasa.SmartDevice.update`.
+
+
+API documentation for modules
+*****************************
+
+.. automodule:: kasa.modules
+    :members:
+    :inherited-members:
+    :undoc-members:

docs/source/index.rst

@@ -8,6 +8,7 @@
    cli
    discover
    smartdevice
+   design
    smartbulb
    smartplug
    smartdimmer

docs/source/smartbulb.rst

@@ -56,4 +56,5 @@ API documentation
 
 .. autoclass:: kasa.SmartBulb
     :members:
+    :inherited-members:
     :undoc-members:

docs/source/smartdevice.rst

@@ -1,12 +1,20 @@
+.. py:module:: kasa
+
 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 property accesses use the data obtained before by awaiting :func:`SmartDevice.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.
+See :ref:`library_design` for more detailed information.
 
-Methods changing the state of the device do not invalidate the cache (i.e., there is no implicit `update()`).
+.. note::
+    The device instances share the communication socket in background to optimize I/O accesses.
+    This means that you need to use the same event loop for subsequent requests.
+    The library gives a warning ("Detected protocol reuse between different event loop") to hint if you are accessing the device incorrectly.
+
+Methods changing the state of the device do not invalidate the cache (i.e., there is no implicit :func:`SmartDevice.update()` call made by the library).
 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.
 
@@ -22,28 +30,70 @@ Simple example script showing some functionality:
     async def main():
         p = SmartPlug("127.0.0.1")
 
-        await p.update()
-        print(p.alias)
+        await p.update()  # Request the update
+        print(p.alias)  # Print out the alias
+        print(p.emeter_realtime)  # Print out current emeter status
 
-        await p.turn_off()
+        await p.turn_off()  # Turn the device off
 
+    if __name__ == "__main__":
+        asyncio.run(main())
+
+If you want to perform updates in a loop, you need to make sure that the device accesses are done in the same event loop:
+
+.. code-block:: python
+
+    import asyncio
+    from kasa import SmartPlug
+
+    async def main():
+        dev = SmartPlug("127.0.0.1")  # We create the instance inside the main loop
+        while True:
+            await dev.update()  # Request an update
+            print(dev.emeter_realtime)
+            await asyncio.sleep(0.5)  # Sleep some time between updates
 
     if __name__ == "__main__":
         asyncio.run(main())
 
 
 Refer to device type specific classes for more examples:
+:class:`SmartPlug`, :class:`SmartBulb`, :class:`SmartStrip`,
+:class:`SmartDimmer`, :class:`SmartLightStrip`.
 
-* :class:`SmartPlug`
-* :class:`SmartBulb`
-* :class:`SmartStrip`
-* :class:`SmartDimmer`
-* :class:`SmartLightStrip`
+Energy Consumption and Usage Statistics
+***************************************
+
+.. note::
+    In order to use the helper methods to calculate the statistics correctly, your devices need to have correct time set.
+    The devices use NTP and public servers from `NTP Pool Project <https://www.ntppool.org/>`_ to synchronize their time.
+
+Energy Consumption
+~~~~~~~~~~~~~~~~~~
+
+The availability of energy consumption sensors depend on the device.
+While most of the bulbs support it, only specific switches (e.g., HS110) or strips (e.g., HS300) support it.
+You can use :attr:`~SmartDevice.has_emeter` to check for the availability.
+
+
+Usage statistics
+~~~~~~~~~~~~~~~~
+
+You can use :attr:`~SmartDevice.on_since` to query for the time the device has been turned on.
+Some devices also support reporting the usage statistics on daily or monthly basis.
+You can access this information using through the usage module (:class:`kasa.modules.Usage`):
+
+.. code-block:: python
+
+    dev = SmartPlug("127.0.0.1")
+    usage = dev.modules["usage"]
+    print(f"Minutes on this month: {usage.usage_this_month}")
+    print(f"Minutes on today: {usage.usage_today}")
 
 
 API documentation
-~~~~~~~~~~~~~~~~~
+*****************
 
-.. autoclass:: kasa.SmartDevice
+.. autoclass:: SmartDevice
     :members:
     :undoc-members:

docs/source/smartdimmer.rst

@@ -10,4 +10,5 @@ API documentation
 
 .. autoclass:: kasa.SmartDimmer
     :members:
+    :inherited-members:
     :undoc-members:

docs/source/smartlightstrip.rst

@@ -10,4 +10,5 @@ API documentation
 
 .. autoclass:: kasa.SmartLightStrip
     :members:
+    :inherited-members:
     :undoc-members:

docs/source/smartplug.rst

@@ -11,4 +11,5 @@ API documentation
 
 .. autoclass:: kasa.SmartPlug
     :members:
+    :inherited-members:
     :undoc-members:

docs/source/smartstrip.rst

@@ -1,11 +1,6 @@
 Smart strips
 ============
 
-
-.. note::
-
-    The emeter feature is currently not implemented for smart strips. See https://github.com/python-kasa/python-kasa/issues/64 for details.
-
 .. note::
 
     Feel free to open a pull request to improve the documentation!
@@ -34,4 +29,5 @@ API documentation
 
 .. autoclass:: kasa.SmartStrip
     :members:
+    :inherited-members:
     :undoc-members: