diff --git a/Doxygen b/Doxygen
index a040e2b49..b57e22baa 100644
--- a/Doxygen
+++ b/Doxygen
@@ -38,7 +38,7 @@ PROJECT_NAME           = "ESPHome"
 # could be handy for archiving the generated documentation or if some version
 # control system is used.
 
-PROJECT_NUMBER         = 2022.6.3
+PROJECT_NUMBER         = 2022.8.0b1
 
 # Using the PROJECT_BRIEF tag one can provide an optional one line description
 # for a project that appears at the top of each page and should give viewer a
diff --git a/Makefile b/Makefile
index e77437e6f..6ac329968 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
 ESPHOME_PATH = ../esphome
-ESPHOME_REF = 2022.6.3
+ESPHOME_REF = 2022.8.0b1
 
 .PHONY: html html-strict cleanhtml deploy help live-html Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify
 
diff --git a/_static/changelog-2022.8.0.png b/_static/changelog-2022.8.0.png
new file mode 100644
index 000000000..5c45baeeb
Binary files /dev/null and b/_static/changelog-2022.8.0.png differ
diff --git a/_static/version b/_static/version
index 0fb73964d..4715f73e3 100644
--- a/_static/version
+++ b/_static/version
@@ -1 +1 @@
-2022.6.3
\ No newline at end of file
+2022.8.0b1
\ No newline at end of file
diff --git a/changelog/2022.8.0.rst b/changelog/2022.8.0.rst
new file mode 100644
index 000000000..3fd816f7a
--- /dev/null
+++ b/changelog/2022.8.0.rst
@@ -0,0 +1,137 @@
+ESPHome 2022.8.0 - 17th August 2022
+===================================
+
+.. seo::
+    :description: Changelog for ESPHome 2022.8.0.
+    :image: /_static/changelog-2022.8.0.png
+    :author: Jesse Hills
+    :author_twitter: @jesserockz
+
+.. imgtable::
+    :columns: 3
+
+    DAC7678, components/output/dac7678, dac7678.svg
+    Sprinkler, components/sprinkler, sprinkler-variant.svg
+    Feedback Cover, components/cover/feedback, feedback_cover.svg
+    SMT100, components/sensor/smt100, smt100.jpg, Moisture & Temperature
+    Whynter IR Climate, components/climate/climate_ir, air-conditioner-ir.svg
+
+
+Full list of changes
+--------------------
+
+New Components
+^^^^^^^^^^^^^^
+
+- DAC7678 support :esphomepr:`3441` by :ghuser:`NickB1` (new-integration)
+- Add support for SMT100 Soil Moisture Sensor :esphomepr:`3654` by :ghuser:`piechade` (new-integration)
+- Adding support for Whynter ARC-14S/SH Air Conditioners :esphomepr:`3641` by :ghuser:`aeonsablaze` (new-integration)
+- Sprinkler controller component :esphomepr:`2249` by :ghuser:`kbx81` (new-integration)
+- Create feedback cover component :esphomepr:`3253` by :ghuser:`ianchi` (new-integration)
+
+Breaking Changes
+^^^^^^^^^^^^^^^^
+
+- Remove min_save_interval from intergration and total_daily_energy :esphomepr:`3498` by :ghuser:`jesserockz` (breaking-change)
+- Rework NaN handling in sensor filters :esphomepr:`3610` by :ghuser:`DAVe3283` (breaking-change)
+- Extend ST7789V component to support additional displays :esphomepr:`3651` by :ghuser:`kbx81` (breaking-change)
+- Refactor BedJet climate into Hub component :esphomepr:`3522` by :ghuser:`jhansche` (breaking-change)
+
+All changes
+^^^^^^^^^^^
+
+- Refactor vl53l0x to remove code from header. :esphomepr:`3536` by :ghuser:`RoboMagus`
+- Fix modbus user-defined function handling :esphomepr:`3527` by :ghuser:`gazoodle`
+- Language schema 202204 :esphomepr:`3492` by :ghuser:`glmnet`
+- Fix / Reverse order shutdown :esphomepr:`3585` by :ghuser:`RoboMagus`
+- RestoringGlobalsComponent: Store value on shutdown :esphomepr:`3586` by :ghuser:`RoboMagus`
+- Map LOLIN C3 mini board pins :esphomepr:`3587` by :ghuser:`mateusdemboski`
+- Bump platformio to 6.0.2 :esphomepr:`3566` by :ghuser:`jesserockz`
+- Bump pylint from 2.13.9 to 2.14.3 :esphomepr:`3589` by :ghuser:`dependabot[bot]`
+- DAC7678 support :esphomepr:`3441` by :ghuser:`NickB1` (new-integration)
+- Correcting ESP32 flash save/load key calculation algorithm :esphomepr:`3416` by :ghuser:`cinadr`
+- Bump aioesphomeapi from 10.8.2 to 10.10.0 :esphomepr:`3590` by :ghuser:`dependabot[bot]`
+- Do two substitutions passes to allow substitutions inside substitutions :esphomepr:`3583` by :ghuser:`jesserockz`
+- Update actions :esphomepr:`3592` by :ghuser:`wrt54g`
+- Add github-actions to dependabot :esphomepr:`3595` by :ghuser:`jesserockz`
+- Fix some typos found by codespell :esphomepr:`3598` by :ghuser:`misery`
+- #3358 Correct temperature validity detection issue in some conditions of pu… :esphomepr:`3545` by :ghuser:`Benoit3`
+- Remove min_save_interval from intergration and total_daily_energy :esphomepr:`3498` by :ghuser:`jesserockz` (breaking-change)
+- Bump zeroconf from 0.38.4 to 0.38.7 :esphomepr:`3562` by :ghuser:`dependabot[bot]`
+- fix EDict to dict mapping in helpers.py :esphomepr:`3599` by :ghuser:`jpeletier`
+- Fix slow_pwm output glitch :esphomepr:`3601` by :ghuser:`marshn`
+- Bump pyupgrade from 2.32.1 to 2.34.0 :esphomepr:`3591` by :ghuser:`dependabot[bot]`
+- Bump black from 22.3.0 to 22.6.0 :esphomepr:`3613` by :ghuser:`dependabot[bot]`
+- Bump colorama from 0.4.4 to 0.4.5 :esphomepr:`3614` by :ghuser:`dependabot[bot]`
+- Bump pylint from 2.14.3 to 2.14.4 :esphomepr:`3617` by :ghuser:`dependabot[bot]`
+- Bump pytest-mock from 3.7.0 to 3.8.1 :esphomepr:`3616` by :ghuser:`dependabot[bot]`
+- Update dfplayer condition function name :esphomepr:`3619` by :ghuser:`dab0g`
+- Added more sensor device classes :esphomepr:`3624` by :ghuser:`lal12`
+- Improvement pipsolar crc :esphomepr:`3316` by :ghuser:`andreashergert1984`
+- Fix configuration constants in core. :esphomepr:`3652` by :ghuser:`RoboMagus`
+- FIX: NVS preferences being written even if unchanged :esphomepr:`3647` by :ghuser:`jpeletier`
+- Add 'set_total_pulses' action to 'pulse_counter' sensor. :esphomepr:`3640` by :ghuser:`RoboMagus`
+- add option to publish initial state of binary sensors :esphomepr:`3636` by :ghuser:`ssieb`
+- update packages: nginx-light-1.18.0-6.1+deb11u2 nano-5.4-2+deb11u1 :esphomepr:`3631` by :ghuser:`peterg79`
+- Add support for SMT100 Soil Moisture Sensor :esphomepr:`3654` by :ghuser:`piechade` (new-integration)
+- Rework NaN handling in sensor filters :esphomepr:`3610` by :ghuser:`DAVe3283` (breaking-change)
+- Remove deprecated adc init call. :esphomepr:`3667` by :ghuser:`ssieb`
+- List webserver service on MDNS if enabled. :esphomepr:`3662` by :ghuser:`RoboMagus`
+- Show changes from python linting :esphomepr:`3677` by :ghuser:`jesserockz`
+- dalybms: support changing the address :esphomepr:`3676` by :ghuser:`ssieb`
+- Upgrade rweather/Crypto from 0.2.0 to 0.4.0 :esphomepr:`3593` by :ghuser:`sybrenstuvel`
+- Allow GPIO20 for ESP32 :esphomepr:`3680` by :ghuser:`ashald`
+- Remove old unused code in mcp23xxx_base :esphomepr:`3685` by :ghuser:`jesserockz`
+- Adding option to report signal strength on pvvx_mithermometer :esphomepr:`3688` by :ghuser:`doolbneerg`
+- Pass optional args to 'new_Pvariable' when creating new entities :esphomepr:`3690` by :ghuser:`RoboMagus`
+- fix sx1509 use of pullup and pulldown :esphomepr:`3689` by :ghuser:`ssieb`
+- Add a soft reset in setup() for bme280. :esphomepr:`3615` by :ghuser:`dbaarda`
+- Add get_ap() method to WiFi :esphomepr:`3684` by :ghuser:`anatoly-savchenkov`
+- Extend ST7789V component to support additional displays :esphomepr:`3651` by :ghuser:`kbx81` (breaking-change)
+- Fix panic abort when BLEClient reconnects :esphomepr:`3594` by :ghuser:`dentra`
+- Introduces ble_client.ble_write Action :esphomepr:`3398` by :ghuser:`rbaron`
+- Add helpers to switch python for schema and codegen :esphomepr:`3693` by :ghuser:`jesserockz`
+- Refactor BedJet climate into Hub component :esphomepr:`3522` by :ghuser:`jhansche` (breaking-change)
+- Added support for setting the current animation frame :esphomepr:`3681` by :ghuser:`davestubbs`
+- Adding support for Whynter ARC-14S/SH Air Conditioners :esphomepr:`3641` by :ghuser:`aeonsablaze` (new-integration)
+- Sprinkler controller component :esphomepr:`2249` by :ghuser:`kbx81` (new-integration)
+- add gradient color  :esphomepr:`3687` by :ghuser:`nielsnl68`
+- [Nextion] Add on_page trigger :esphomepr:`3673` by :ghuser:`anatoly-savchenkov`
+- Bump pyupgrade from 2.34.0 to 2.37.3 :esphomepr:`3670` by :ghuser:`dependabot[bot]`
+- Bump aioesphomeapi from 10.10.0 to 10.11.0 :esphomepr:`3669` by :ghuser:`dependabot[bot]`
+- Create feedback cover component :esphomepr:`3253` by :ghuser:`ianchi` (new-integration)
+- Bump pytest-asyncio from 0.18.3 to 0.19.0 :esphomepr:`3695` by :ghuser:`dependabot[bot]`
+- Bump zeroconf from 0.38.7 to 0.39.0 :esphomepr:`3694` by :ghuser:`dependabot[bot]`
+- Bump pytest-mock from 3.8.1 to 3.8.2 :esphomepr:`3622` by :ghuser:`dependabot[bot]`
+- Bump flake8 from 4.0.1 to 5.0.4 :esphomepr:`3703` by :ghuser:`dependabot[bot]`
+- Bump pylint from 2.14.4 to 2.14.5 :esphomepr:`3697` by :ghuser:`dependabot[bot]`
+- Add priority to on_shutdown trigger :esphomepr:`3644` by :ghuser:`RoboMagus`
+
+Past Changelogs
+---------------
+
+- :doc:`2022.6.0`
+- :doc:`2022.5.0`
+- :doc:`2022.4.0`
+- :doc:`2022.3.0`
+- :doc:`2022.2.0`
+- :doc:`2022.1.0`
+- :doc:`2021.12.0`
+- :doc:`2021.11.0`
+- :doc:`2021.10.0`
+- :doc:`2021.9.0`
+- :doc:`2021.8.0`
+- :doc:`v1.20.0`
+- :doc:`v1.19.0`
+- :doc:`v1.18.0`
+- :doc:`v1.17.0`
+- :doc:`v1.16.0`
+- :doc:`v1.15.0`
+- :doc:`v1.14.0`
+- :doc:`v1.13.0`
+- :doc:`v1.12.0`
+- :doc:`v1.11.0`
+- :doc:`v1.10.0`
+- :doc:`v1.9.0`
+- :doc:`v1.8.0`
+- :doc:`v1.7.0`
diff --git a/changelog/index.rst b/changelog/index.rst
index b395ce5f6..ff1d3bebd 100644
--- a/changelog/index.rst
+++ b/changelog/index.rst
@@ -2,7 +2,7 @@ Changelog
 =========
 
 .. redirect::
-    :url: /changelog/2022.6.0.html
+    :url: /changelog/2022.8.0.html
 
 .. toctree::
     :glob:
diff --git a/components/binary_sensor/index.rst b/components/binary_sensor/index.rst
index 97161a2a1..8dd0a8870 100644
--- a/components/binary_sensor/index.rst
+++ b/components/binary_sensor/index.rst
@@ -60,6 +60,8 @@ Advanced options:
 - **disabled_by_default** (*Optional*, boolean): If true, then this entity should not be added to any client's frontend,
   (usually Home Assistant) without the user manually enabling it (via the Home Assistant UI).
   Requires Home Assistant 2021.9 or newer. Defaults to ``false``.
+- **publish_initial_state** (*Optional*, boolean): If true, then the sensor will publish its initial state at boot or when
+  HA first connects, depending on the platform.  This means that any applicable triggers will be run. Defaults to ``false``.
 - **entity_category** (*Optional*, string): The category of the entity.
   See https://developers.home-assistant.io/docs/core/entity/#generic-properties
   for a list of available options. Requires Home Assistant 2021.11 or newer.
diff --git a/components/ble_client.rst b/components/ble_client.rst
index a846ed24e..00e4b385e 100644
--- a/components/ble_client.rst
+++ b/components/ble_client.rst
@@ -91,6 +91,34 @@ This automation is triggered when the client disconnects from a BLE device.
             - lambda: |-
                 ESP_LOGD("ble_client_lambda", "Disconnected from BLE device");
 
+.. _ble_client-ble_write_action:
+
+``ble_client.ble_write`` Action
+-------------------------------
+
+This action triggers a write to a specified BLE characteristic. The write is attempted in
+a best-effort fashion and will only succeed if the `ble_client`'s  connection has been
+established and the peripheral exposes the expected BLE service and characteristic.
+
+Example usage:
+
+.. code-block:: yaml
+
+    ble_client:
+      - mac_address: 11:22:33:44:55:66
+        id: my_ble_client
+
+    switch:
+      - platform: template
+        name: "My Switch"
+        turn_on_action:
+          - ble_client.ble_write:
+              id: my_ble_client
+              service_uuid: F61E3BE9-2826-A81B-970A-4D4DECFABBAE
+              characteristic_uuid: 6490FAFE-0734-732C-8705-91B653A081FC
+              # List of bytes to write.
+              value: [0x01, 0xab, 0xff]
+
 BLE Overview
 ------------
 This section gives a brief overview of the Bluetooth LE architecture
diff --git a/components/climate/bedjet.rst b/components/climate/bedjet.rst
index 78b15134a..e7e38abcc 100644
--- a/components/climate/bedjet.rst
+++ b/components/climate/bedjet.rst
@@ -5,8 +5,8 @@ BedJet
     :description: Instructions for setting up a BedJet climate device.
     :image: bedjet.png
 
-The ``bedjet`` climate platform creates a climate device which can be used to control
-a BedJet V3 Climate Comfort Sleep System.
+The ``bedjet`` component allows you to communicate with a BedJet V3 Climate Comfort
+Sleep System.
 
 This component supports the following functionality:
 
@@ -16,36 +16,40 @@ This component supports the following functionality:
 - Start one of the saved memory presets, including "Biorhythm" programs
 - Show the current status of the BedJet
 
-This platform uses the BLE peripheral on an ESP32, so you also need to enable
+This component uses the BLE peripheral on an ESP32, so you also need to enable
 this component. Please see the :doc:`/components/ble_client` docs for how to discover the MAC
 address of your BedJet device, or you can find the list of paired MAC addresses in
 the "DEVICE LIST" section of the BedJet mobile application.
 
+Component/Hub
+-------------
+
+This component is a global hub that maintains the connection to the BedJet device
+and delegates status updates to individual platform components.
+
 .. code-block:: yaml
 
-    ble_client:
-      - mac_address: 11:22:33:aa:bb:cc
-        id: ble_bedjet
+    esp32_ble_tracker:
 
-    climate:
-      - platform: bedjet
-        id: my_bedjet_fan
-        name: "My BedJet Fan"
-        ble_client_id: ble_bedjet
+    ble_client:
+      - mac_address: C4:4F:33:00:00:01
+        id: bedjet_ble_id1
+
+    bedjet:
+      - id: bedjet_1
+        ble_client_id: bedjet_ble_id1
 
 Configuration variables:
-------------------------
+************************
 
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
-- **name** (**Required**, string): The name of the climate device.
 - **ble_client_id** (**Required**, :ref:`config-id`): The ID of the BLE Client.
 - **time_id** (*Optional*, :ref:`config-id`): The ID of a :ref:`Time Component <time>` which
   can be used to set the time on the BedJet device.
-- **heat_mode** (*Optional*, string): The primary heating mode to use for `HVACMode.HEAT`:
-  - ``"heat"`` (Default) - Setting ``hvac_mode=heat`` uses the BedJet "HEAT" mode.
-  - ``"extended"`` - Setting ``hvac_mode=heat`` uses BedJet "EXT HEAT" mode.
-  - Whichever is not selected will be made available as a custom preset.
-- All other options from :ref:`Climate <config-climate>`.
+- **update_interval** (*Optional*, :ref:`config-time`): The interval to dispatch status
+  changes to child components. Defaults to ``5s``. Each child component can decide whether to
+  publish its own updated state on this interval, or use another (longer) update interval to
+  throttle its own updates.
 
 lambda calls
 ************
@@ -58,11 +62,37 @@ From :ref:`lambdas <config-lambda>`, you can call methods to do some advanced st
 
       button:
         - platform: template
-          name: "Check Bedjet Firmware"
+          name: "Check Bedjet(1) Firmware"
           on_press:
             then:
             - lambda: |-
-                id(my_bedjet_fan).upgrade_firmware();
+                id(bedjet_1).upgrade_firmware();
+
+``bedjet`` Climate Platform
+---------------------------
+
+The `climate` platform exposes the BedJet's climate-related functionality, including
+setting the mode and target temperature.
+
+.. code-block:: yaml
+
+    climate:
+      - platform: bedjet
+        id: my_bedjet_climate_entity
+        name: "My BedJet"
+        bedjet_id: bedjet_1
+
+Configuration variables:
+************************
+
+- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
+- **name** (**Required**, string): The name of the climate device.
+- **bedjet_id** (**Required**, :ref:`config-id`): The ID of the Bedjet component.
+- **heat_mode** (*Optional*, string): The primary heating mode to use for ``HVACMode.HEAT``:
+    - ``"heat"`` (Default) - Setting ``hvac_mode=heat`` uses the BedJet "HEAT" mode.
+    - ``"extended"`` - Setting ``hvac_mode=heat`` uses BedJet "EXT HEAT" mode.
+    - Whichever is not selected will be made available as a custom preset.
+- All other options from :ref:`Climate <config-climate>`.
 
 - ``.send_local_time``: If `time_id` is set, attempt to sync the clock now.
 
diff --git a/components/climate/climate_ir.rst b/components/climate/climate_ir.rst
index 718944768..e23d18755 100644
--- a/components/climate/climate_ir.rst
+++ b/components/climate/climate_ir.rst
@@ -48,6 +48,8 @@ submit a feature request (see FAQ).
 +---------------------------------------+---------------------+----------------------+
 | Yashima                               | ``yashima``         |                      |
 +---------------------------------------+---------------------+----------------------+
+| :ref:`Whynter<whynter>`               | ``whynter``         | yes                  |
++---------------------------------------+---------------------+----------------------+
 
 This component requires that you have configured a :doc:`/components/remote_transmitter`.
 
@@ -270,6 +272,29 @@ Configuration variables:
   - ``DG11J1-3A``: Temperature range is from 18 to 32 (default)
   - ``DG11J1-91``: Temperature range is from 16 to 30
 
+.. _whynter:
+
+``whynter`` Climate
+-------------------------
+
+Additional configuration is available for this platform
+
+
+Configuration variables:
+
+- **use_fahrenheit** (*Optional*, boolean): Allows you to transfer the temperature to the air conditioner in degrees Fahrenheit. The air conditioner display also shows the temperature in Fahrenheit. Defaults to ``false``.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    climate:
+      - platform: whynter
+        name: "AC"
+        sensor: room_temperature
+        use_fahrenheit: true
+        supports_heat: true
+
+
 
 See Also
 --------
diff --git a/components/cover/feedback.rst b/components/cover/feedback.rst
new file mode 100644
index 000000000..0fa995ecd
--- /dev/null
+++ b/components/cover/feedback.rst
@@ -0,0 +1,267 @@
+Feedback Cover
+==============
+
+.. seo::
+    :description: Instructions for setting up feedback covers in ESPHome.
+
+The ``feedback`` cover platform allows you to create covers with position control that 
+can optionally have feedback from sensors to detect the fully-open and fully-closed states (endstops), 
+and from sensors to detect actual movement (opening/closing). In all the cases the current
+position is approximated with the time the cover has been moving in a direction.
+
+It supports *open*, *close*, *stop* and *toggle* actions. Tilt control is not supported.
+
+.. figure:: images/more-info-ui.png
+    :align: center
+    :width: 50.0%
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    cover:
+      - platform: feedback
+        name: "Gate"
+
+        open_action:
+          - switch.turn_on: open_cover_switch
+        open_duration: 2.1min
+        open_endstop: open_endstop_binary_sensor
+        open_sensor: open_movement_binary_sensor
+
+        close_action:
+          - switch.turn_on: close_cover_switch
+        close_duration: 2min
+        close_endstop: close_endstop_binary_sensor
+        close_sensor: close_movement_binary_sensor
+
+        stop_action:
+          - switch.turn_off: open_cover_switch
+          - switch.turn_off: close_cover_switch
+
+Use Cases
+---------
+
+It is a versatile cover that can accommodate for a number of DIY setups, or monitoring an externally controlled cover:
+
+Time-Based
+**********
+
+Simplest case, when no sensors are available. The state is thus assumed.
+
+It is a drop-in replacement of :doc:`/components/cover/time_based`
+
+Endstop Sensors
+***************
+
+For cases where there are endstops at one or both ends of the cover to detect the fully-open and fully-closed states.
+When any of these endstops are reached, an actual state is read and updated and the cover optionally 
+stopped (via ``stop_action``). The state is not assumed.
+
+The extension also handles the case where the cover has builtin endstops, which stops the movement, independently to
+the component's logic. In this case, when the cover is fully closed (either if timed based or sensor based) the 
+``stop_action`` is not triggered.
+
+It is a drop-in replacement of :doc:`/components/cover/endstop`.
+
+Movement Sensors
+****************
+
+If movement feedback is available, the cover no longer operates in *optimistic mode* (assuming that movement starts
+as soon as an action is triggered) and can also react to commands issued to cover from an external control and still
+keep states in sync (useful for "smartization" of and existing cover).
+
+When there are no specific endstop sensors, and if the cover has builtin endstops and no external control logic,
+these movement sensors can optionally be use to infer the endstop state. 
+When the movement stops (with no stop action being requested) it is assumed that it was caused by
+the builtin endstops, and so the close/open state (according to current direction) was reached. 
+This function is activated setting ``infer_endstop`` to True.
+
+It can be used to replace a :doc:`/components/cover/current_based`, with some modifications in the yaml. See :ref:`migrating_current_based`
+
+Safety Features
+---------------
+
+To protect the cover hardware from damage, some safety options are available:
+
+- *Max duration*, to protect from faulty endstops
+- *Direction change wait time*, like an interlock wait time, to protect motors from sudden direction changes
+- *Obstacle sensors* and *rollback*, possibility to stop and optionally rollback the cover when some external sensors detects an obstacle 
+  (it might be a sensor for high current consumption or an infrared light detecting an obstruction in the path).
+
+
+Configuration variables
+-----------------------
+
+- **name** (**Required**, string): The name of the cover.
+- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
+
+- **stop_action** (**Required**, :ref:`Action <config-action>`): The action that should
+  be performed when the remote requests the cover to be closed or an endstop is reached.
+
+Open options:
+
+- **open_action** (**Required**, :ref:`Action <config-action>`): The action that should
+  be performed when the remote requests the cover to be opened.
+- **open_duration** (**Required**, :ref:`config-time`): The amount of time it takes the cover
+  to open up from the fully-closed state.
+- **open_endstop** (**Optional**, :ref:`config-id`): The ID of the
+  :ref:`Binary Sensor <config-binary_sensor>` that turns on when the open position is reached.
+- **open_sensor** (**Optional**, :ref:`config-id`): The ID of the
+  :ref:`Binary Sensor <config-binary_sensor>` that turns on when the cover is moving in the open direction.
+- **open_obstacle_sensor** (**Optional**, :ref:`config-id`): The ID of the
+  :ref:`Binary Sensor <config-binary_sensor>` that turns on when an obstacle that blocks the
+  open direction is detected.
+
+Close options:
+
+- **close_action** (**Required**, :ref:`Action <config-action>`): The action that should
+  be performed when the remote requests the cover to be closed.
+- **close_duration** (**Required**, :ref:`config-time`): The amount of time it takes the cover
+  to close from the fully-open state.
+- **close_endstop** (**Optional**, :ref:`config-id`): The ID of the
+  :ref:`Binary Sensor <config-binary_sensor>` that turns on when the closed position is reached.
+- **close_sensor** (**Optional**, :ref:`config-id`): The ID of the
+  :ref:`Binary Sensor <config-binary_sensor>` that turns on when the cover is moving in the close direction.
+- **close_obstacle_sensor** (**Optional**, :ref:`config-id`): The ID of the
+  :ref:`Binary Sensor <config-binary_sensor>` that turns on when an obstacle that blocks the
+  close direction is detected.
+
+Additional options:
+
+- **has_built_in_endstop** (*Optional*, boolean): Indicates that the cover has built in end stop
+  detectors. In this configuration the ``stop_action`` is not performed when the open or close
+  time is completed and if the cover is commanded to open or close the corresponding actions
+  will be performed without checking current state. Defaults to ``false``.
+- **infer_endstop_from_movement** (*Optional*, boolean): Whether to infer endstop state from the movement sensor. 
+  Requires movement sensors to be set, no endstop sensors and to have builtin endstops. Defaults to ``false``.
+- **assumed_state** (*Optional*, boolean): Whether the true state of the cover is not known.
+  This will make the Home Assistant frontend show buttons for both OPEN and CLOSE actions, instead
+  of hiding or disabling one of them. Defaults to ``true`` if no sensor is available to known
+  the actual state of the cover.
+- **max_duration** (*Optional*, :ref:`config-time`): The maximum duration the cover should be opening
+  or closing. Useful for protecting from dysfunctional endstops. 
+  Requires internal, builtin or inferred endstops.
+- **direction_change_wait_time** (*Optional*, :ref:`config-time`): Stops cover and forces a wait time between changes in direction,
+  and takes it into account when computing cover position (useful to protect motors). 
+  When this option is set (even at 0s) if an open/close action is invoked while the cover is moving in the opposite direction,
+  then and intermediate stop action will be invoked to generate the delay. 
+- **acceleration_wait_time** (*Optional*, :ref:`config-time`): Considers a wait time needed by the cover to actually 
+  start moving after command is issued and takes it into account when computing cover position 
+  (useful for heavy covers with large inertia). 
+  Intended to not accumulate error when doing multiple partial open/close actions). 
+  The open/close duration includes one instance of this delay, as it is the total amount of time from
+  issuing a command to reaching endstop.
+  Defaults to ``0s``.
+- **update_interval** (*Optional*, :ref:`config-time`): The interval
+  to publish updated position information to the UI while the cover is moving.
+  Defaults to ``1s``.
+- **obstacle_rollback** (*Optional*, percentage): The percentage of rollback the cover will perform in case of
+  obstacle detection while moving. Defaults to ``10%``.
+- All other options from :ref:`Cover <config-cover>`.
+
+Example Configurations
+----------------------
+
+.. _migrating_current_based:
+
+Migrating Current-Based Cover
+*****************************
+
+Most options can be left untouched, but some modifications are needed:
+
+
+1. All current sensing related options must be moved to auxiliary :doc:`/components/binary_sensor/analog_threshold`,
+   to convert current readings to binary sensors, using the corresponding thresholds and delays.
+
+   If there where any open/close obstacle current threshold defined, a separate binary sensor with that threshold should be defined.
+   The option ``start_sensing_delay`` should be directly replaced by a ``delayed_off`` filter in the movement sensors, or alternatively
+   hysteresis options could be used to reduce the noise.  
+2. To have the very same behavior implicit in current based cover, you must always set ``has_built_in_endstop`` and ``infer_endstop_from_movement``
+   to True.
+
+  .. code-block:: yaml
+
+      # Example original sensor configuration 
+      cover:
+        - platform: current_based
+          name: "Current Based Cover"
+
+          open_sensor: open_current_sensor
+          open_moving_current_threshold: 0.5
+          open_obstacle_current_threshold: 0.8
+          start_sensing_delay: 0.8s
+          # ...rest of options
+
+      # Example converted sensor configuration 
+      binary_sensor:
+        - platform: analog_threshold
+          id: open_binary_sensor
+          sensor_id: open_current_sensor
+          threshold: 0.5
+          filter:
+            - delayed_off: 0.8s
+        - platform: analog_threshold
+          id: open_obstacle_binary_sensor
+          sensor_id: open_current_sensor
+          threshold: 0.8
+        # ... repeat for close sensors
+
+      cover:
+        - platform: feedback
+          name: "Feedback Based Cover"
+          has_built_in_endstop: true
+          infer_endstop_from_movement: true
+
+          open_sensor: open_binary_sensor
+          open_obstacle_sensor: open_obstacle_binary_sensor
+          #... rest of options
+
+3. Malfunction detection is not directly supported by Feedback Cover, as the malfunction was very narrowly defined to a specif use case 
+   (while in other hardware configurations, the same situation is perfectly valid). 
+
+   The malfunction alerted specifically when there was current in the opposite direction of the requested operation (possibly due to a relay welded).
+   This detection can still be achieved by putting the logic directly in the switch, (or whatever needed according to your specific use case).
+
+  .. code-block:: yaml
+
+      # Example original malfunction configuration 
+      cover:
+        - platform: current_based
+          close_sensor: close_current        
+          close_action:
+            - switch.turn_on: open_relay
+          open_sensor: open_current 
+          open_action:
+            - switch.turn_on: open_relay 
+             
+          malfunction_detection: true
+          malfunction_action:
+            - logger.log: "Malfunction detected. Relay welded."   
+          #... rest of options 
+
+      # Example converted malfunction configuration 
+      switch:
+        - platform: gpio
+          id: open_relay
+          #... rest of options 
+          on_turn_off:
+            - delay: 200ms #allow for switching time and any discharge
+            - if:
+                condition: 
+                  binary_sensor.is_on: open_binary_sensor
+                  # alternative can check directly  
+                  # on sensor.in_range open_current
+                then:
+                  - logger.log: "Malfunction detected. Relay welded."   
+
+
+
+
+
+See Also
+--------
+
+- :doc:`index`
+- :ref:`automation`
+- :apiref:`feedback/feedback_cover.h`
+- :ghedit:`Edit`
diff --git a/components/display/index.rst b/components/display/index.rst
index b2792364e..243bdd972 100644
--- a/components/display/index.rst
+++ b/components/display/index.rst
@@ -625,7 +625,7 @@ Animation
 *********
 
 Allows to use animated images on displays. Animation inherits all options from the image component.
-It adds additional lambda methods: ``next_frame()`` and ``prev_frame()`` to change the shown picture of a gif.
+It adds additional lambda methods: ``next_frame()``, ``prev_frame()`` and ``set_frame()`` to change the shown picture of a gif.
 
 .. code-block:: yaml
 
@@ -636,7 +636,7 @@ It adds additional lambda methods: ``next_frame()`` and ``prev_frame()`` to chan
 
 The animation can be rendered just like the image component with the ``image()`` function of the display component.
 
-To show the next frame of the animation call ``id(my_animation).next_frame()``, to show the previous picture use ``id(my_animation).prev_frame()``.
+To show the next frame of the animation call ``id(my_animation).next_frame()``, to show the previous picture use ``id(my_animation).prev_frame()``. To show a specific picture use ``id(my_animation).set_frame(int frame)``.
 This can be combined with all Lambdas:
 
 .. code-block:: yaml
diff --git a/components/display/nextion.rst b/components/display/nextion.rst
index 516c7ef8e..8da2fceb0 100644
--- a/components/display/nextion.rst
+++ b/components/display/nextion.rst
@@ -63,13 +63,14 @@ Configuration variables:
   Defaults to ``5s``.
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
 - **tft_url** (*Optional*, string): The URL to download the TFT file from for updates. See :ref:`Nextion Upload <nextion_upload_tft>`.
-- **on_sleep** (*Optional*, :ref:`Action <config-action>`): An automation to perform when the Nextion goes to sleep.
-- **on_wake** (*Optional*, :ref:`Action <config-action>`): An automation to perform when the Nextion wakes up.
 - **touch_sleep_timeout** (*Optional*, int): Sets internal No-touch-then-sleep timer in seconds.
 - **wake_up_page** (*Optional*, int): Sets the page to display after waking up
 - **auto_wake_on_touch** (*Optional*, boolean): Sets if Nextion should auto-wake from sleep when touch press occurs.
+- **on_setup** (*Optional*, :ref:`Action <config-action>`): An action to be performed after ESPHome connects to the Nextion. See :ref:`Nextion Automation <nextion-on_setup>`.
+- **on_sleep** (*Optional*, :ref:`Action <config-action>`): An action to be performed when the Nextion goes to sleep. See :ref:`Nextion Automation <nextion-on_sleep>`.
+- **on_wake** (*Optional*, :ref:`Action <config-action>`): An action to be performed when the Nextion wakes up. See :ref:`Nextion Automation <nextion-on_sleep>`.
+- **on_page** (*Optional*, :ref:`Action <config-action>`): An action to be performed after a page change. See :ref:`Nextion Automation <nextion-on_page>`.
   
-
 .. _display-nextion_lambda:
 
 Rendering Lambda
@@ -108,7 +109,7 @@ Please see :ref:`display-printf` for a quick introduction into the ``printf`` fo
 Lambda Calls
 ************
 
-Several methods are available for use within :ref:`lambdas <config-lambda>` ; these permit advanced functionality beyond simple
+Several methods are available for use within :ref:`lambdas <config-lambda>`; these permit advanced functionality beyond simple
 display updates. See the full :apiref:`nextion/nextion.h` for more info. 
 
 .. _nextion_upload_tft:
@@ -182,6 +183,80 @@ The developer tools in Home Assistant can be used to trigger the update. The bel
   - WAVEFORM_SENSOR   4
   - NO_RESULT         5
 
+.. _display-nextion_automation:
+
+Nextion Automation
+------------------
+
+With Nextion displays, it's possible to define several automation actions. Depending on your setup, you may or may not need to use some of them.
+
+.. _nextion-on_setup:
+
+``on_setup``
+************
+
+This automation will be triggered once ESP establishes a connection with Nextion. This happens after a boot up and may take some
+noticeable time (e.g. hundreds of milliseconds) to establish a connection over UART. Typical use scenario for this automation is choosing of the initial
+page to display depending on some runtime conditions or simply showing a page with a non-zero index (Nextion shows page 0 by default).
+
+.. code-block:: yaml
+
+    wifi:
+      ap: {} # This spawns an AP with the device name and mac address with no password.
+
+    captive_portal:
+
+    display:
+      - platform: nextion
+        id: disp
+        on_setup:
+          then:
+            lambda: |-
+              // Check if WiFi hot-spot is configured
+              if (wifi::global_wifi_component->has_sta()) {
+                // Show the main page
+                id(disp).goto_page("main_page");
+              } else {
+                // Show WiFi Access Point QR code for captive portal, see https://qifi.org/
+                id(disp).goto_page("wifi_qr_page");
+              }
+
+.. _nextion-on_sleep:
+
+``on_sleep / on_wake``
+**********************
+
+The action is called before and after Nextion goes to sleep mode. Nextion is not responsive while in sleep mode. Use these triggers to prepare your code
+for that and :ref:`force-update <nextion_update_all_components>` the on-screen content once it's back.
+
+.. _nextion-on_page:
+
+``on_page``
+***********
+
+This automation is triggered when a page is changed on the Nextion display. This includes both ESP and Nextion initiated page changes.
+ESP initiates a page change by calling ``goto_page("page_name")`` function. Nextion can change pages as a reaction to user's activity (e.g. clicks) or using a timer.
+In either case, this automation can be helpful to update on-screen controls for the newly displayed page.
+
+If you fully own your Nextoin HMI design and follow the best practice of setting the components' vscope to global in the Nextion Editor, you'll probably never need this trigger.
+However, if this is not the case and all / some of your UI components have local visibility scope, ``on_page`` will be your remedy. Here you can initiate updates of the relevant components.
+
+Before actually updating components, you need to understand which page Nextion was switched to. ``x`` argument will contain a page id integer.
+Once you know the page id, it's time to update the components. Two strategies would be possible. The first one is to use :ref:`Nextion Sensors <nextion_sensor>` for every UI field and use one of the
+:ref:`update functions <nextion_update_all_components>`. The second is to manually set component text or value for each field:
+
+.. code-block:: yaml
+
+    on_page:
+      then:
+        lambda: |-
+          switch (x) {
+            case 0x02: // wifi_qr_page
+              // Manually trigger update for controls on page 0x02 here
+              id(disp).set_component_text_printf("qr_wifi", "WIFI:T:nopass;S:%s;P:;;", wifi::global_wifi_component->get_ap().get_ssid().c_str());
+              break;
+          }
+
 .. _nextion_upload_tft_file:
 
 Uploading A TFT File
diff --git a/components/display/st7789v.rst b/components/display/st7789v.rst
index cdb52d860..037b06d19 100644
--- a/components/display/st7789v.rst
+++ b/components/display/st7789v.rst
@@ -13,12 +13,7 @@ Usage
 The ``st7789v`` display platform allows you to use
 ST7789V (`datasheet <https://github.com/Xinyuan-LilyGO/TTGO-T-Display>`__,
 `Tindie <https://www.tindie.com/products/ttgo/lilygor-ttgo-t-display/>`__)
-displays with ESPHome. Note that this component utilizes the 4-Wire :ref:`SPI bus <spi>`; the physical
-connection is already in place on the TTGO T-Display module as shown below.
-
-.. note::
-
-    Currently this only supports 135x240 pixel ST7789V displays. Other sizes (e.g. 240x320, 240x240) are not supported.
+displays with ESPHome. Note that this component utilizes the 4-Wire :ref:`SPI bus <spi>`.
 
 .. figure:: images/st7789v-full.jpg
     :align: center
@@ -26,12 +21,15 @@ connection is already in place on the TTGO T-Display module as shown below.
 
     ST7789V TFT LCD on TTGO T-Display module
 
-This module has a USB-C connector with an on-board serial adapter for programming. Simply connect to a
-USB-C port to get started! (Depending on your operating system of choice, you might need to install an
-appropriate driver.) It is also possible to power the module via the 5V and G (ground) pins along
-the edges of the module, or via a battery attached to the connector on the bottom of the board. The
-ESP32's UART pins are not brought out to the headers, so the on-board serial adapter must be used for
-hardwired programming. (OTA updates are of course possible after ESPHome is initially installed.)
+The TTGO T-Display module shown has the display attached to the module's board and its connections to the ESP32
+cannot be changed. Other display modules have pin headers or other connectors which must be connected appropriately
+to an ESP module.
+
+.. note::
+
+    Displays larger than the 135x240 pixel display on the TTGO T-Display shown require a significant amount of RAM
+    to operate correctly. Some ESP devices, such as the ESP8266, do not have sufficient memory to support this display.
+    If you attempt to use this component and experience repeated crashes, this is likely the cause of the issue.
 
 .. code-block:: yaml
 
@@ -42,6 +40,7 @@ hardwired programming. (OTA updates are of course possible after ESPHome is init
 
     display:
       - platform: st7789v
+        model: TTGO TDisplay 135x240
         backlight_pin: GPIO4
         cs_pin: GPIO5
         dc_pin: GPIO16
@@ -57,9 +56,26 @@ hardwired programming. (OTA updates are of course possible after ESPHome is init
 Configuration variables:
 ************************
 
+- **model** (**Required**, string): The display model to use. One of the following options:
+
+  - ``TTGO TDisplay 135x240``
+  - ``Adafruit Funhouse 240x240``
+  - ``Adafruit RR 280x240`` (round-rectangular display -- some pixels are "deleted" from corners to form rounded shape)
+  - ``Custom`` (see details below)
+
 - **cs_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The CS pin.
 - **dc_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DC pin.
 - **reset_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
+- **height** (*Optional*, int): When ``model`` is set to "Custom", use this to specify the ``height`` of the display
+  in pixels. This option may not be specified when the ``model`` is not set to "Custom".
+- **width** (*Optional*, int): When ``model`` is set to "Custom", use this to specify the ``width`` of the display
+  in pixels. This option may not be specified when the ``model`` is not set to "Custom".
+- **offset_height** (*Optional*, int): When ``model`` is set to "Custom", use this to specify the display's vertical
+  offset in pixels. This option may not be specified when the ``model`` is not set to "Custom".
+- **offset_width** (*Optional*, int): When ``model`` is set to "Custom", use this to specify the display's horizontal
+  offset in pixels. This option may not be specified when the ``model`` is not set to "Custom".
+- **eightbitcolor** (*Optional*, boolean): Limits the supported color depth to eight bits. May be useful on
+  memory-constrained devices.
 - **backlight_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The display's backlight pin.
 - **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
   See :ref:`display-engine` for more information.
@@ -67,13 +83,15 @@ Configuration variables:
 - **pages** (*Optional*, list): Show pages instead of a single lambda. See :ref:`display-pages`.
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
 
+.. note::
+
+    On memory-constrained devices, it may be possible to use *part* of the display area by setting the model to "custom"
+    and specifying a smaller ``height`` and/or ``width`` than that of the actual display.
+
+
 Configuration examples
 **********************
 
-As of version 1.15, ESPHome supports color displays. To utilize the color capabilities of this display
-module, you'll likely want to add a ``color:`` section to your YAML configuration; please see
-:ref:`color <config-color>` for more detail on this configuration section.
-
 To use colors in your lambda:
 
 .. code-block:: yaml
diff --git a/components/esphome.rst b/components/esphome.rst
index 2ad9c9d89..d96877639 100644
--- a/components/esphome.rst
+++ b/components/esphome.rst
@@ -115,17 +115,26 @@ too many WiFi/MQTT connection attempts, Over-The-Air updates being applied or th
 .. note::
 
     It's not guaranteed that all components are in a connected state when this automation is triggered. For
-    example, the MQTT client may have already disconnected.
+    example, the MQTT client may have already disconnected. For use-cases that require specific shutdown ordering, look at the ``priority`` parameter.
 
 .. code-block:: yaml
 
     esphome:
       # ...
       on_shutdown:
+        priority: 700
         then:
           - switch.turn_off: switch_1
 
-Configuration variables: See :ref:`Automation <automation>`.
+Configuration variables:
+
+- **priority** (*Optional*, float): The priority to execute your custom shutdown code. A higher value
+  means a high priority and in case of shutdown triggers that the code is executed **later**. 
+  Priority is used primarily for the initialization order of components. Shutdowns for these components are handled in *reverse* order, such that e.g. sensors (600) are shutdown before the hardware components (800) they depend on.
+  Please note this is an ESPHome-internal value and any change will not be marked as a breaking change. 
+  Defaults to ``600``. For priority values refer to the list in the :ref:`esphome-on_boot` section.
+  
+- See :ref:`Automation <automation>`.
 
 .. _esphome-on_loop:
 
diff --git a/components/images/sprinkler-ui.jpg b/components/images/sprinkler-ui.jpg
new file mode 100644
index 000000000..a58f2af4b
Binary files /dev/null and b/components/images/sprinkler-ui.jpg differ
diff --git a/components/images/sprinkler.png b/components/images/sprinkler.png
new file mode 100644
index 000000000..65f30b79c
Binary files /dev/null and b/components/images/sprinkler.png differ
diff --git a/components/media_player/index.rst b/components/media_player/index.rst
index c0a3a579f..f5b288f84 100644
--- a/components/media_player/index.rst
+++ b/components/media_player/index.rst
@@ -146,7 +146,7 @@ Configuration variables:
 ``media_player.on_state`` Trigger
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-This trigger is activated each time the state of the media player is updated 
+This trigger is activated each time the state of the media player is updated
 (for example, if the player is stop playing audio or received some command).
 
 .. code-block:: yaml
diff --git a/components/output/dac7678.rst b/components/output/dac7678.rst
new file mode 100644
index 000000000..440dfeb1c
--- /dev/null
+++ b/components/output/dac7678.rst
@@ -0,0 +1,114 @@
+DAC7678
+=======
+
+.. seo::
+    :description: Instructions for setting up the DAC7678.
+    :image: dac7678.svg
+    :keywords: DAC7678
+
+.. _dac7678-component:
+
+Component/Hub
+-------------
+
+The DAC7678 component represents a DAC7678 12-bit 8 channel DAC with internal reference
+(`datasheet <https://www.ti.com/lit/ds/symlink/dac7678.pdf>`__) in ESPHome. It
+uses the :ref:`I²C Bus <i2c>` for communication.
+
+To use the channels of this components, you first need to setup the
+global ``dac7678`` hub and give it an id, and then define the
+:ref:`individual output channels <dac7678-output>`.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    dac7678:
+        address: 0x4A
+        id: dac7678_hub1
+        internal_reference: true
+
+    # Individual outputs
+    output:
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 0
+
+Configuration variables:
+************************
+
+-  **address** (*Optional*, int): The I²C address of the driver.
+   Defaults to ``0x48``.
+-  **id** (*Optional*, :ref:`config-id`): The id to use for
+   this dac7678 component. Use this if you have multiple DAC7678s connected at the same time
+-  **internal_reference** (*Optional*, bool): State of the internal reference.
+   Defaults to ``false``.
+
+.. _dac7678-output:
+
+DAC Output
+----------
+
+The DAC7678 output component exposes a DAC7678 DAC channel of a global
+:ref:`DAC7678 hub <dac7678-component>` as a float
+output.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    dac7678:
+        address: 0x4A
+        id: dac7678_hub1
+        internal_reference: true
+
+    # Individual outputs
+    output:
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 0
+        id: 'dac7678_1_ch0'
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 1
+        id: 'dac7678_1_ch1'
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 2
+        id: 'dac7678_1_ch2'
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 3
+        id: 'dac7678_1_ch3'
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 4
+        id: 'dac7678_1_ch4'
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 5
+        id: 'dac7678_1_ch5'
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 6
+        id: 'dac7678_1_ch6'
+      - platform: dac7678
+        dac7678_id: 'dac7678_hub1'
+        channel: 7
+        id: 'dac7678_1_ch7'
+
+
+Configuration variables:
+************************
+
+- **id** (**Required**, :ref:`config-id`): The id to use for this output component.
+- **channel** (**Required**, int): Chose the channel of the DAC7678 of
+  this output component. Must be in range from 0 to 7.
+- **dac7678_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the
+  :ref:`DAC7678 hub <dac7678-component>`.
+  Use this if you have multiple DAC7678 devices.
+- All other options from :ref:`Output <config-output>`.
+
+See Also
+--------
+
+- :doc:`/components/output/index`
+- :ghedit:`Edit`
diff --git a/components/sensor/daly_bms.rst b/components/sensor/daly_bms.rst
index 4d8e9c562..55777f792 100644
--- a/components/sensor/daly_bms.rst
+++ b/components/sensor/daly_bms.rst
@@ -88,6 +88,7 @@ Configuration variables:
 ************************
 
 - **update_interval** (*Optional*, :ref:`config-time`): Delay between data requests.
+- **address** (*Optional*, int): Address to use, defaults to ``0x80``.
 
 Sensor
 ------
diff --git a/components/sensor/images/smt100.jpg b/components/sensor/images/smt100.jpg
new file mode 100644
index 000000000..94a5efdde
Binary files /dev/null and b/components/sensor/images/smt100.jpg differ
diff --git a/components/sensor/integration.rst b/components/sensor/integration.rst
index 5b6ef472d..de9dc7f44 100644
--- a/components/sensor/integration.rst
+++ b/components/sensor/integration.rst
@@ -38,7 +38,6 @@ Configuration variables:
   that the value can be restored upon power cycle or reboot.
   Warning: this option can wear out your flash. Defaults to ``false``.
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
-- **min_save_interval** (*Optional*, :ref:`config-time`): The minimum time span between saving updated values to storage. This is to keep wearout of memory low. Defaults to ``0s``.
 - All other options from :ref:`Sensor <config-sensor>`.
 
 .. _sensor-integration-reset_action:
diff --git a/components/sensor/pulse_counter.rst b/components/sensor/pulse_counter.rst
index 3acba1982..68d6bd38b 100644
--- a/components/sensor/pulse_counter.rst
+++ b/components/sensor/pulse_counter.rst
@@ -101,10 +101,37 @@ measure the total consumed energy in kWh.
           filters:
             - multiply: 0.001  # (1/1000 pulses per kWh)
 
+(Re)Setting the total pulse count
+---------------------------------
+
+Using this action, you are able to reset/set the total pulse count. This can be useful
+if you would like the ``total`` sensor to match what you see on your meter you are
+trying to match.
+
+.. code-block:: yaml
+
+    # Set pulse counter total from home assistant using this service call:
+    api:
+      services:
+        - service: set_pulse_total
+          variables:
+            new_pulse_total: int
+          then:
+            - pulse_counter.set_total_pulses:
+                id: pulse_counter_id
+                value: !lambda 'return new_pulse_total;'
+
+.. note::
+
+    This value is the raw count of pulses, and not the value you see after the filters
+    are applied.
+
+
 See Also
 --------
 
 - :ref:`sensor-filters`
+- :doc:`/components/sensor/pulse_meter`
 - :doc:`rotary_encoder`
 - `esp-idf Pulse Counter API <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/pcnt.html>`__.
 - :apiref:`pulse_counter/pulse_counter_sensor.h`
diff --git a/components/sensor/smt100.rst b/components/sensor/smt100.rst
new file mode 100644
index 000000000..801b1c63d
--- /dev/null
+++ b/components/sensor/smt100.rst
@@ -0,0 +1,81 @@
+SMT100 Soil Moisture Sensor
+================================
+
+.. seo::
+    :description: Instructions for setting up SMT100 soil moisture and temperature sensor
+    :image: smt100.jpg
+    :keywords: smt100
+
+
+The SMT100 sensor platform allows you to use the SMT100 soil moisture and temperature with ESPHome.
+
+.. figure:: images/smt100.jpg
+    :align: center
+    :width: 50.0%
+
+
+The communication with this integration is done over a UART bus using a simple ASCII protocol. You must therefore have a ``uart:`` entry in your configuration with both the TX and RX pins set to some pins on your board and the baud rate set to 9600.
+
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    uart:
+      tx_pin: TX
+      rx_pin: RX
+      baud_rate: 9600
+
+    sensor:
+      - platform: smt100
+        counts:
+            name: "Counts"
+        permittivity:
+            name: "Permittivity"
+        temperature:
+            name: "Temperature"
+        moisture:
+            name: "Moisture"
+        voltage:
+            name: "Voltage"
+
+
+Configuration variables:
+------------------------
+
+- **counts** (*Optional*): Raw measurement data from the sensor electronics (dimensionless quantity). Higher counts mean less moisture. May be used for material specific calibrations. 
+
+  - **name** (**Required**): Sensor name.
+  - All other options from :ref:`Sensor <config-sensor>`.
+
+- **Permittivity** (*Optional*): Permittivity or dielectric coefficient of the material to be measured (dimensionless quantity. Higher permittivity means higher water content. May be used for material specific calibration.
+
+  - **name** (**Required**): Sensor name.
+  - All other options from :ref:`Sensor <config-sensor>`.
+
+- **temperature** (*Optional*): Soil temperature in degrees Celsius. Please note that the temperature sensor is inside the black sensor enclosure and requires some time to equilibrate with the soil temperature.
+
+  - **name** (**Required**): Sensor name.
+  - All other options from :ref:`Sensor <config-sensor>`.
+
+- **moisture** (*Optional*): Soil moisture (volumetric water content in %).
+
+  - **name** (**Required**): Sensor name.
+  - All other options from :ref:`Sensor <config-sensor>`.
+
+- **voltage** (*Optional*): Supply voltage of the sensor in Volt.
+
+  - **name** (**Required**): Sensor name.
+  - All other options from :ref:`Sensor <config-sensor>`.
+  
+- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
+  to use multiple UART buses.
+
+- **update_interval** (*Optional*, :ref:`config-time`): The interval to pull the sensor. Defaults is 60s.
+
+See Also
+--------
+
+- :doc:`/components/sensor/smt100`
+- :ref:`sensor-filters`
+- :apiref:`smt100/smt100.h`
+- :ghedit:`Edit`
diff --git a/components/sensor/total_daily_energy.rst b/components/sensor/total_daily_energy.rst
index 36891f933..45729da14 100644
--- a/components/sensor/total_daily_energy.rst
+++ b/components/sensor/total_daily_energy.rst
@@ -41,7 +41,6 @@ Configuration variables:
 - **restore** (*Optional*, boolean): Whether to store the intermediate result on the device so
   that the value can be restored upon power cycle or reboot.
   Defaults to ``true``.
-- **min_save_interval** (*Optional*, :ref:`config-time`): The minimum time span between saving updated values to storage. This is to keep wearout of memory low. Defaults to ``0s``.
 - **method** (*Optional*, string): The method to use for calculating the total daily energy. One of
   ``trapezoid``, ``left`` or ``right``. Defaults to ``right``.
 - All other options from :ref:`Sensor <config-sensor>`.
diff --git a/components/sensor/xiaomi_ble.rst b/components/sensor/xiaomi_ble.rst
index 52b187192..4b53d16b5 100644
--- a/components/sensor/xiaomi_ble.rst
+++ b/components/sensor/xiaomi_ble.rst
@@ -218,6 +218,8 @@ Configuration example for PVVX MiThermometer firmware set to "Custom" advertisem
           name: "PVVX Battery-Level"
         battery_voltage:
           name: "PVVX Battery-Voltage"
+        signal_strength:
+          name: "PVVX Signal"
 
 Configuration example for ATC MiThermometer firmware set to "Custom" advertisement:
 
@@ -622,7 +624,7 @@ To maximize the chances of catching advertisements of the sensors, you can set `
 .. code-block:: yaml
 
     esp32_ble_tracker:
-      scan_parameters: 
+      scan_parameters:
         interval: 5s # try with 300ms if you don't have LAN module
         window: 5s # try with 300ms if you don't have LAN module
         active: false
diff --git a/components/sprinkler.rst b/components/sprinkler.rst
new file mode 100644
index 000000000..4924db9d0
--- /dev/null
+++ b/components/sprinkler.rst
@@ -0,0 +1,1041 @@
+Sprinkler Controller
+====================
+
+.. seo::
+    :description: Instructions for setting up the sprinkler controller component in ESPHome to control sprinkler valves.
+    :image: sprinkler-variant.svg
+
+.. figure:: images/sprinkler.png
+    :align: center
+
+The ``sprinkler`` controller component aims to behave like a sprinkler/irrigation valve controller,
+much like those made by companies such as Rain Bird or Hunter. It does so by automating control of a
+number of :ref:`switch <config-switch>` components, each of which would typically be used to control
+an individual electric valve via a relay or other switching device. It provides a number of features
+you'd expect of a sprinkler controller, including:
+
+- Virtually any number of zones (sections of the sprinkler system) per controller instance, limited only by
+  available memory and/or GPIO (including I/O expanders!) pin availability on the ESP
+- The ability to run:
+
+  - One or more full cycles (iterations through all zones) of the system
+  - Only a single zone
+
+- Automatic cycle repeating
+- A multiplier value to proportionally increase or decrease the run duration for all zones
+- Support for pumps/main valves located upstream of distribution valves
+- Pausing and resuming a zone/cycle
+- Iterating through zones in forward or reverse order
+- Support for both latching ("pulsed") and non-latching valves (which can be arbitrarily mixed!)
+
+It reaches even further, however, offering several more advanced features, as well:
+
+- Multiple sprinkler controller instances can operate simultaneously on a single (ESP) device
+- Multiple pumps, each of which may be shared across controller instances
+- Enable/disable switches for each individual zone, allowing zones to be omitted from full cycles of the system
+- A valve/zone queuing mechanism aimed at providing advanced support for automation
+- Several valve management strategies to accommodate varying types of hardware/installations:
+
+  - Adjustable "valve open delay" to help ensure valves are fully closed before the next one is opened
+  - Adjustable "valve overlap" to help minimize banging of pipes due to water hammer
+  - Adjustable delay intervals to coordinate pump starting and stopping relative to distribution valve opening and closing
+
+.. note::
+
+    While the term "pump" is used throughout this document, the device controlled need not be a
+    physical pump. Instead, it may simply be another electric valve located upstream of distribution
+    valves (often known in the industry as a "main" or "master" valve). The pump or upstream valve
+    simply controls the water supply to other downstream valves.
+
+.. figure:: images/sprinkler-ui.jpg
+    :align: center
+    :width: 60.0%
+
+    Example Sprinkler Controller UI -- Note that this example leverages :ref:`number <config-number>` components
+    for setting run durations, repeat and multiplier values. More details below.
+
+.. code-block:: yaml
+
+    # Example minimal configuration entry
+    # (...but please see more detailed examples below!)
+    sprinkler:
+      - id: sprinkler_ctrlr
+        main_switch: "Sprinklers"
+        auto_advance_switch: "Sprinklers Auto Advance"
+        valves:
+          - valve_switch: "Front Lawn"
+            enable_switch: "Enable Front Lawn"
+            run_duration: 1800s
+            valve_switch_id: lawn_sprinkler_valve_sw0
+          - valve_switch: "Back Lawn"
+            enable_switch: "Enable Back Lawn"
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw1
+
+Please see the :ref:`sprinkler-controller-examples` section below for extensive, detailed configuration
+examples that are ready for you to copy and paste!
+
+Configuration variables:
+------------------------
+
+- **main_switch** (**Required** with more than one valve, *string*): The name for the sprinkler
+  controller's main switch as it will appear in the front end. This switch, when turned on, calls the
+  ``sprinkler.resume_or_start_full_cycle`` action; when turned off, it calls the ``sprinkler.shutdown``
+  action (see below). It will appear to be "on" when any valve on the controller is active. This switch
+  will not appear in the front end if the controller is configured with only one valve.
+- **auto_advance_switch** (**Required** with more than one valve, *string*): The name for the
+  sprinkler controller's "auto-advance" switch as it will appear in the front end. When this switch is
+  turned on while a valve is active, when the valve's ``run_duration`` is reached, the sprinkler
+  controller will automatically advance to the next enabled valve as a part of a "full cycle" of the
+  system. When turned off, the sprinkler controller will shut down after the active valve's
+  ``run_duration`` is reached (unless there are valves in the queue -- see
+  :ref:`sprinkler-controller-sprinkler_controller_queue` section below for more detail). This switch will
+  not appear in the front end if the controller is configured with only one valve.
+- **manual_selection_delay** (*Optional*, :ref:`config-time`): The amount of time the controller should
+  wait to activate a valve after the ``next_valve`` and ``previous_valve`` actions are called. Useful
+  if the control interface consists of only forward/reverse buttons as the button(s) may be pressed
+  multiple times to make the selection.
+- **queue_enable_switch** (*Optional*, *string*): The name for the sprinkler controller's queue enable
+  switch as it will appear in the front end. When this switch is turned on or not provided, the controller
+  will select the next valve/zone to run based on the contents of the queue; the queue takes precedence over
+  valves that would otherwise run as a part of a full cycle of the system (when auto-advance is on/enabled).
+  See :ref:`sprinkler-controller-sprinkler_controller_queue` section below for more detail.
+- **reverse_switch** (*Optional*, *string*): The name for the sprinkler controller's reverse switch
+  as it will appear in the front end. When this switch is turned on, the controller will iterate through
+  the valves in reverse order (last-to-first as they appear in the controller's configuration). When
+  this switch is turned off or not provided, the controller will iterate through the valves first-to-last.
+  This switch will not appear in the front end if the controller is configured with only one valve.
+- **valve_open_delay** (*Optional*, :ref:`config-time`): The *minimum* delay in seconds that should be
+  inserted between (distribution) valve switching -- in other words, the amount of time that must elapse
+  between one valve switching off and the next one switching on. Useful for systems with valves which depend
+  on sufficient water pressure to close. May not be used with *valve_overlap*.
+- **valve_overlap** (*Optional*, :ref:`config-time`): The amount of time in seconds that the current valve
+  and the next valve should run simultaneously as the next valve/zone starts up. This may help prevent pipes
+  from banging as valves close. May not be used with *valve_open_delay*.
+- **pump_switch_off_during_valve_open_delay** (*Optional*, boolean): If set to ``true``, the pump will be
+  switched off during the ``valve_open_delay`` interval; otherwise, it remains on. This may only be
+  specified when ``valve_open_delay`` is configured (see above). Defaults to ``false``.
+- **pump_start_pump_delay** (*Optional*, :ref:`config-time`): The delay in seconds from when a distribution
+  valve is opened to when the associated pump is activated. Useful to ensure pressure does not build
+  up from running the pump when no distribution valves are open. May not be used with *pump_start_valve_delay*.
+- **pump_start_valve_delay** (*Optional*, :ref:`config-time`): The delay in seconds from when a pump
+  is started to when the associated distribution valve is opened. Useful for systems where distribution
+  valves require sufficient pressure to fully/quickly close. May not be used with *pump_start_pump_delay*.
+- **pump_stop_pump_delay** (*Optional*, :ref:`config-time`): The delay in seconds from when a distribution
+  valve is closed to when the respective pump is deactivated. Useful for systems where distribution valves
+  require sufficient pressure to fully/quickly close. May not be used with *pump_stop_valve_delay*.
+- **pump_stop_valve_delay** (*Optional*, :ref:`config-time`): The delay in seconds from when a pump is
+  deactivated to when the respective distribution valve is closed. Useful to ensure pressure does not build
+  up from running the pump when no distribution valves are open or to allow the main line out to distribution
+  valves to drain. May not be used with *pump_stop_pump_delay*.
+- **pump_pulse_duration** (*Optional*, :ref:`config-time`): The *minimum* length of the pulse generated to
+  operate a pump in milliseconds. *Required* when one or more latching pumps is configured. Note that the *exact*
+  length of the pulse is determined by the frequency of the main application loop (as are other ``delay`` timers
+  used in ESPHome). Typically this is expected to provide a resolution of approximately 16 milliseconds, however
+  this may vary somewhat depending on your exact configuration. Regardless, it should provide
+  more-than-sufficient precision to operate any such valve.
+- **valve_pulse_duration** (*Optional*, :ref:`config-time`): The *minimum* length of the pulse generated to
+  operate a valve in milliseconds. *Required* when one or more latching valves is configured. Note that the *exact*
+  length of the pulse is determined by the frequency of the main application loop (as are other ``delay`` timers
+  used in ESPHome). Typically this is expected to provide a resolution of approximately 16 milliseconds, however
+  this may vary somewhat depending on your exact configuration. Regardless, it should provide more-than-sufficient
+  precision to operate any such valve.
+- **repeat** (*Optional*, int): The number of times a full cycle should be repeated. Defaults to 0.
+- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. While optional,
+  this is necessary to identify the controller instance (particularly in cases where more than one is
+  defined) when calling controller actions (see below) such as ``start_full_cycle`` or ``shutdown``.
+- **valves** (**Required**, *list*): A list of valves the controller should use. Each valve consists of:
+
+  - **enable_switch** (*Optional*, *string*): The name for the switch component to be used to enable
+    this valve to be run as a part of a full cycle of the system. When this switch is turned off, the valve
+    will be excluded from a full cycle of the system. When this switch is turned on or not provided, the
+    controller will include the valve in a full cycle of the system.
+  - **valve_switch** (**Required**, *string*): The name for the switch component to be used to control
+    the valve for this part of the sprinkler system (often referred to as a "zone"). When this switch is
+    turned on, the controller's "auto-advance" feature is disabled and it will activate the associated
+    valve for its ``run_duration`` multiplied by the controller's multiplier value. When this switch is
+    turned off, the ``sprinkler.shutdown`` action is called (see below).
+  - **pump_switch_id** (*Optional*, :ref:`Switch <config-switch>`): This is the :ref:`switch <config-switch>`
+    component to be used to control the valve's pump or upstream electric valve. Typically this would be a
+    :doc:`GPIO switch <switch/gpio>` wired to control a relay or other switching device which in turn would
+    activate the respective pump/valve. *It is not recommended to expose this switch to the front end; please
+    see* :ref:`sprinkler-controller-an_important_note_about_gpio_switches_and_control` *below for more detail.*
+    May not be specified with *pump_off_switch_id* or *pump_on_switch_id*.
+  - **pump_off_switch_id** (*Optional*, :ref:`Switch <config-switch>`): This is the :ref:`switch <config-switch>`
+    component to be used to *turn off* the valve's pump or upstream electric *latching* valve. Typically this
+    would be a :doc:`GPIO switch <switch/gpio>` wired to control a relay or other switching device which in turn
+    would *switch off* the respective pump/valve. *It is not recommended to expose this switch to the front end; please
+    see* :ref:`sprinkler-controller-an_important_note_about_gpio_switches_and_control` *below for more detail.*
+    May not be specified with *pump_switch_id*.
+  - **pump_on_switch_id** (*Optional*, :ref:`Switch <config-switch>`): This is the :ref:`switch <config-switch>`
+    component to be used to *turn on* the valve's pump or upstream electric *latching* valve. Typically this
+    would be a :doc:`GPIO switch <switch/gpio>` wired to control a relay or other switching device which in turn
+    would *switch on* the respective pump/valve. *It is not recommended to expose this switch to the front end; please
+    see* :ref:`sprinkler-controller-an_important_note_about_gpio_switches_and_control` *below for more detail.*
+    May not be specified with *pump_switch_id*.
+  - **run_duration** (**Required**, :ref:`config-time`): The duration in seconds this valve should
+    remain on/open after it is activated. When a given valve is activated, the controller's multiplier value
+    is multiplied by this value to determine the actual run duration for the valve, thus allowing the run
+    duration for all valves/zones to be proportionally increased or decreased as desired.
+  - **valve_switch_id** (**Required**, :ref:`Switch <config-switch>`): This is the :ref:`switch <config-switch>`
+    component to be used to control the valve that operates the given section or zone of the sprinkler
+    system. Typically this would be a :doc:`GPIO switch <switch/gpio>` wired to control a relay
+    or other switching device which in turn would activate the respective valve. *It is not recommended
+    to expose this switch to the front end; please see* :ref:`sprinkler-controller-an_important_note_about_gpio_switches_and_control`
+    *below for more detail.* May not be specified with *valve_off_switch_id* or *valve_on_switch_id*.
+  - **valve_off_switch_id** (**Required**, :ref:`Switch <config-switch>`): This is the :ref:`switch <config-switch>`
+    component to be used to *turn off* the *latching* valve that operates the given section or zone of the
+    sprinkler system. Typically this would be a :doc:`GPIO switch <switch/gpio>` wired to control a relay
+    or other switching device which in turn would *switch off* the respective valve. *It is not recommended
+    to expose this switch to the front end; please see* :ref:`sprinkler-controller-an_important_note_about_gpio_switches_and_control`
+    *below for more detail.* May not be specified with *valve_switch_id*.
+  - **valve_on_switch_id** (**Required**, :ref:`Switch <config-switch>`): This is the :ref:`switch <config-switch>`
+    component to be used to *turn on* the *latching* valve that operates the given section or zone of the
+    sprinkler system. Typically this would be a :doc:`GPIO switch <switch/gpio>` wired to control a relay
+    or other switching device which in turn would *switch on* the respective valve. *It is not recommended
+    to expose this switch to the front end; please see* :ref:`sprinkler-controller-an_important_note_about_gpio_switches_and_control`
+    *below for more detail.* May not be specified with *valve_switch_id*.
+
+.. _sprinkler-controller-an_important_note_about_gpio_switches_and_control:
+
+An Important Note about GPIO Switches and Control
+-------------------------------------------------
+
+The savvy and/or seasoned ESPHome user will quickly realize that ``pump_switch_id``, ``pump_off_switch_id``,
+``pump_on_switch_id``, ``valve_switch_id``, ``valve_off_switch_id`` and ``valve_on_switch_id`` (as described above)
+are really just pointers to other (GPIO) switches elsewhere in the ESPHome yaml configuration.
+
+It might seem reasonable to assume that these :doc:`GPIO switches <switch/gpio>` may be used to switch the various
+sprinkler zones on and off, however, this is **not** the case. It's important to note that the sprinkler controller
+provides a switch for each configured zone -- ultimately, this switch is to be used to switch any given zone on or
+off, **not** the :doc:`GPIO switch <switch/gpio>` the zone is configured with.
+
+Keep in mind that a :doc:`GPIO switch <switch/gpio>` directly controls the state of the GPIO pin it is associated
+with. While it's technically feasible to "override" this behavior, it might not always be desirable. For example,
+if you *wanted* to control the state of the switch/pin manually during testing of your system/configuration, this
+would make that impossible (or at least more difficult than necessary), presenting other complications. Ultimately,
+flexibility is key, as we've learned from any number of conversations on the ESPHome Discord server.
+
+As mentioned in the introduction, the sprinkler controller automates control of the :doc:`GPIO switches <switch/gpio>`
+you provide it with -- it does not "override" control of these switches or alter how they behave beyond simply
+switching them on or off as required based on the configured scheduling.
+
+So why not just use the :doc:`GPIO switch <switch/gpio>` to control the various sprinkler zones directly? As it relates
+to the sprinkler controller itself, the primary reason relates to *state* -- that is, we need to be able to ensure
+that the :doc:`GPIO switch <switch/gpio>` state(s) are kept consistent with the configuration of the sprinkler
+controller. While it's less important for systems that simply consist of one valve per zone, it becomes very important
+for systems with some additional complexity. Consider the example of a system with a pump and multiple distribution
+valves attached to said pump; the controller in this case is configured to switch the pump off three seconds *before*
+switching off any given distribution valve. If you suddenly manually switch off a :doc:`GPIO switch <switch/gpio>`
+connected to one of these distribution valves, what happens to the pump? What should the sprinkler controller do? Should
+it switch the distribution valve back on?...or maybe just switch the pump off, too? In either case, based on its
+configuration, the pump was supposed be shut down before the valve, but you just went and turned off the valve. The pump
+could be damaged. There are many other similar situations such as this that may occur, the simplest of which is little
+more than ensuring that any given valve is switched off after *some* duration and does not remain on/open perpetually.
+
+In summary, to ensure that your sprinkler controller consistently operates as expected:
+
+- Only use the switches provided by the sprinkler controller component to switch any given sprinkler zone on or off.
+- Do not use the :doc:`GPIO switches <switch/gpio>` you have in your configuration to control sprinkler zones/valves
+  outside of initial testing of your device configuration.
+- To help prevent accidents, it's probably best if the :doc:`GPIO switches <switch/gpio>` for each sprinkler zone are
+  **not** exposed to the front end. This can be accomplished in two ways:
+
+  - Do not provide a ``name:`` parameter to your :doc:`GPIO switches <switch/gpio>`, or
+  - Add ``internal: true`` to each of your :doc:`GPIO switch <switch/gpio>` configurations
+
+These simple configuration tweaks will help prevent any number of errors (human, automation, or otherwise) and may help
+to avert disaster!
+
+.. _sprinkler-controller-actions:
+
+Controller Actions
+------------------
+
+.. _sprinkler-controller-action_start_full_cycle:
+
+``sprinkler.start_full_cycle`` action
+*************************************
+
+Starts a full cycle of the system. This enables the controller's "auto-advance" feature and disables
+the queue. The controller will iterate through all enabled valves/zones. They will each run for their
+configured ``run_duration`` multiplied by the controller's multiplier value. *Note that if NO valves
+are enabled when this action is called, the controller will automatically enable all valves.*
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.start_full_cycle: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_start_from_queue:
+
+``sprinkler.start_from_queue`` action
+*************************************
+
+Starts the controller running valves from its queue. If no valves are in the queue, this action does
+nothing; otherwise, this disables the controller's "auto-advance" feature so that only queued
+valves/zones will run. Queued valves will remain on for either the amount of time specified in the
+queue request or for their configured ``run_duration`` multiplied by the controller's multiplier value
+(if the queue request run duration is not specified or is zero). *Note that queued valves ignore whether
+the valve is enabled; that is, queued valves will always run once the controller is started, unless, of
+course, the queue is (manually) cleared prior to the queue reaching them. Also note that, at present,
+the queue has a hard-coded limit of 100 entries to limit memory use.*
+See :ref:`sprinkler-controller-sprinkler_controller_queue` section below for more detail.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.start_from_queue:
+            id: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_start_single_valve:
+
+``sprinkler.start_single_valve`` action
+***************************************
+
+Starts a single valve. This disables the controller's "auto-advance" and queue features so that
+only this valve/zone will run. The valve will remain on for its configured ``run_duration``
+multiplied by the controller's multiplier value. *Note that this action ignores whether the valve
+is enabled; that is, when called, the specified valve will always run.* Valves are numbered in the
+order they appear in the sprinkler controller's configuration starting at zero (0).
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.start_single_valve:
+            id: sprinkler_ctrlr
+            valve_number: 0
+
+.. _sprinkler-controller-action_shutdown:
+
+``sprinkler.shutdown`` action
+*****************************
+
+Immediately (begins to) turns off all valves, effectively shutting down the system, respecting any
+configured pump or valve stop delays.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.shutdown: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_next_valve:
+
+``sprinkler.next_valve`` action
+*******************************
+
+Advances to the next valve (numerically). If ``manual_selection_delay`` is configured, the controller
+will wait before activating the selected valve. If no valve is active, the first valve (as they appear
+in the controller's configuration) will be started.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.next_valve: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_previous_valve:
+
+``sprinkler.previous_valve`` action
+***********************************
+
+Advances to the previous valve (numerically). If ``manual_selection_delay`` is configured, the controller
+will wait before activating the selected valve. If no valve is active, the last valve (as they appear in
+the controller's configuration) will be started.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.previous_valve: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_pause:
+
+``sprinkler.pause`` action
+**************************
+
+Immediately turns off all valves, saving the active valve and the amount of time remaining so that
+the cycle may be resumed later on.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.pause: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_resume:
+
+``sprinkler.resume`` action
+***************************
+
+Resumes a cycle placed on hold with ``sprinkler.pause``. If there is no paused cycle, this action
+will do nothing.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.resume: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_resume_or_start_full_cycle:
+
+``sprinkler.resume_or_start_full_cycle`` action
+***********************************************
+
+Resumes a cycle placed on hold with ``sprinkler.pause``, but if no cycle was paused, starts a full
+cycle (equivalent to ``sprinkler.start_full_cycle``).
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.resume_or_start_full_cycle: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_queue_valve:
+
+``sprinkler.queue_valve`` action
+********************************
+
+Adds the specified valve into the controller's queue. When the queue is enabled, valves in the queue
+take precedence over valves scheduled as a part of a full cycle of the system (when auto-advance is
+enabled). If ``run_duration`` is not specified or is zero, the sprinkler controller will use the
+valve's configured run duration. Valves are numbered in the order they appear in the sprinkler
+controller's configuration starting at zero (0). *Note that, at present, the queue has a hard-coded
+limit of 100 entries to limit memory use.* Please see :ref:`sprinkler-controller-sprinkler_controller_queue`
+section below for more detail and examples.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.queue_valve:
+            id: sprinkler_ctrlr
+            valve_number: 2
+            run_duration: 900s
+
+.. _sprinkler-controller-action_clear_queued_valves:
+
+``sprinkler.clear_queued_valves`` action
+****************************************
+
+Removes all queued valves from the controller's queue. Please see :ref:`sprinkler-controller-sprinkler_controller_queue`
+section below for more detail and examples.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.clear_queued_valves:
+            id: sprinkler_ctrlr
+
+.. _sprinkler-controller-action_set_multiplier:
+
+``sprinkler.set_multiplier`` action
+***********************************
+
+Sets the multiplier value used to proportionally increase or decrease the run duration for all valves/zones.
+When a given valve is activated, this value is multiplied by the valve's run duration (see below) to
+determine the valve's actual run duration.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.set_multiplier:
+            id: sprinkler_ctrlr
+            multiplier: 1.5
+
+.. _sprinkler-controller-action_set_repeat:
+
+``sprinkler.set_repeat`` action
+*******************************
+
+Specifies the number of times full cycles should be repeated. **Note that the total number of cycles
+the controller will run is equal to the repeat value plus one.** For example, with a ``repeat`` value
+of 1, the initial cycle will run, then the repeat cycle will run, resulting in a total of two cycles.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.set_repeat:
+            id: sprinkler_ctrlr
+            repeat: 2  # would run three cycles
+
+.. _sprinkler-controller-action_set_valve_run_duration:
+
+``sprinkler.set_valve_run_duration`` action
+*******************************************
+
+Sets the run duration for the specified valve. When the valve is activated, this value is multiplied
+by the multiplier value (see above) to determine the valve's actual run duration.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - sprinkler.set_valve_run_duration:
+            id: sprinkler_ctrlr
+            valve_number: 0
+            run_duration: 600s
+
+.. note::
+
+    - The ``next_valve``, ``previous_valve`` and ``start_single_valve`` actions ignore whether a valve
+      is enabled via its enable switch.
+    - The ``next_valve`` and ``previous_valve`` actions may not appear to respond immediately if either
+      ``manual_selection_delay`` or any of the various delay mechanisms described in the
+      :ref:`sprinkler-controller-pump_and_distribution_valve_coordination` section below are configured.
+      If you are using any of these configuration options, be sure to allow the delay intervals to elapse
+      before assuming something isn't working!
+    - If a valve is active when its ``run_duration`` or the multiplier value is changed, the active
+      valve's run duration will remain unaffected until the next time it is started.
+
+.. _sprinkler-controller-pump_and_distribution_valve_coordination:
+
+Pump and Distribution Valve Coordination
+----------------------------------------
+
+The sprinkler controller allows extensive flexibility relating to the switching of pumps and valves.
+Let's take a closer look at how to use these features to tune your system.
+
+Delayed Starting and/or Stopping of Pumps or Valves
+***************************************************
+
+For systems with pumps, it's generally a bad idea to run the pump with no distribution valves open.
+This causes pressure to build up and can even destroy the pump after some time. For systems with (a)
+pump(s), you'll likely want to add two configuration options:
+
+.. code-block:: yaml
+
+    sprinkler:
+      - id: lawn_sprinkler_ctrlr
+        pump_start_pump_delay: 3s
+        pump_stop_valve_delay: 3s
+        ...
+
+This will cause any given pump to start (in this example) three seconds *after* any associated distribution
+valve is opened. In addition, it will wait three seconds to close the *last* distribution valve *after*
+the pump is stopped. This would allow the pump to spin down, pressure to drop and lines to drain prior
+to switching off the (last) associated distribution valve. (In these configurations, it might also be
+desirable to enable ``valve_overlap``, as well -- more on this below.)
+
+Some types of electric valves require sufficient water pressure to (fully/quickly) close. These types of
+valves, when coupled with electric valves upstream of distribution valves (often known in the industry as
+"main" or "master" valves), may require that the upstream valve is switched on *before* any given distribution
+valve(s), allowing the water pressure to stabilize and force all distribution valves closed *before* any single
+distribution valve is opened. In these situations, the reverse of the above configuration may be desirable:
+
+.. code-block:: yaml
+
+    sprinkler:
+      - id: lawn_sprinkler_ctrlr
+        pump_start_valve_delay: 3s
+        pump_stop_pump_delay: 3s
+        ...
+
+In this example, the upstream valve would open three seconds prior to any given associated distribution
+valve, allowing the water pressure to force any attached distribution valves closed. After the delay, the
+required distribution valve is opened and the cycle starts. When the cycle is complete, the (last) distribution
+valve would be switched off three seconds prior to the upstream valve. (In these configurations, it might also
+be desirable to enable ``valve_open_delay``, as well.)
+
+.. note::
+
+    Using ``pump_stop_valve_delay`` or ``pump_stop_pump_delay`` with ``valve_open_delay`` and
+    ``pump_switch_off_during_valve_open_delay`` may increase the off-time inserted between the operation
+    of each zone, as the controller must wait for a given zone (pump *and* valve) to fully shut down before
+    it can be started again.
+
+Banging Pipes or Valves That Don't Consistently Close
+*****************************************************
+
+A common complaint people have with sprinkler systems is that of banging pipes. In other, less common situations,
+some systems suffer from valves that do not (fully/quickly) close. There are three controller options available to
+address either of these complaints/concerns:
+
+- ``valve_overlap``
+- ``valve_open_delay``
+- ``pump_switch_off_during_valve_open_delay``
+
+The first option, ``valve_overlap``, causes the current valve and the next valve (as the controller is iterating
+through valves) to run simultaneously for the duration specified. The idea here is that this causes a reduction
+in water pressure as the next zone starts up, therefore minimizing banging pipes (aka the "water hammer" effect)
+when the valve that is finishing up finally closes.
+
+The second and third options may be used to ensure sufficient water pressure is available to force valves closed.
+This may be useful for pressure-sensitive valves that don't quickly and/or fully close when water pressure is low.
+
+For systems with pumps, it may be desirable to switch off the pump before switching to the next distribution
+valve/zone. In these situations, ``pump_switch_off_during_valve_open_delay`` may prove useful in conjunction
+with ``valve_open_delay``.
+
+In any case, the examples in the next section illustrate how/where to add these options into your configuration.
+
+.. _sprinkler-controller-examples:
+
+Controller Examples
+-------------------
+
+Single Controller, Single Valve, No Pump
+****************************************
+
+This first example illustrates a complete, single-valve system with no pump/upstream valve(s). It
+could be useful for controlling a single valve independent of any other sprinkler controllers. A pump
+could easily be added by adding the ``pump_switch_id`` parameter and a :ref:`switch <config-switch>`.
+
+.. code-block:: yaml
+
+    esphome:
+        name: esp-sprinkler-controller
+        platform: ESP32
+        board: featheresp32
+
+    wifi:
+        ssid: "wifi_ssid"
+        password: "wifi_password"
+
+    logger:
+
+    sprinkler:
+      - id: garden_sprinkler_ctrlr
+        valves:
+          - valve_switch: "Flower Garden"
+            run_duration: 300s
+            valve_switch_id: garden_sprinkler_valve
+
+    switch:
+      - platform: gpio
+        id: garden_sprinkler_valve
+        pin: 5
+
+Single Controller, Three Valves, No Pump
+****************************************
+
+This example illustrates a complete, simple three-valve system with no pump/upstream valve(s):
+
+.. code-block:: yaml
+
+    esphome:
+        name: esp-sprinkler-controller
+        platform: ESP32
+        board: featheresp32
+
+    wifi:
+        ssid: "wifi_ssid"
+        password: "wifi_password"
+
+    logger:
+
+    sprinkler:
+      - id: lawn_sprinkler_ctrlr
+        main_switch: "Lawn Sprinklers"
+        auto_advance_switch: "Lawn Sprinklers Auto Advance"
+        reverse_switch: "Lawn Sprinklers Reverse"
+        valve_overlap: 5s
+        valves:
+          - valve_switch: "Front Lawn"
+            enable_switch: "Enable Front Lawn"
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw0
+          - valve_switch: "Side Lawn"
+            enable_switch: "Enable Side Lawn"
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw1
+          - valve_switch: "Back Lawn"
+            enable_switch: "Enable Back Lawn"
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw2
+
+    switch:
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw0
+        pin: 0
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw1
+        pin: 2
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw2
+        pin: 4
+
+Single Controller, Three Valves, Single Pump
+********************************************
+
+This example illustrates a complete three-valve system with a single pump/upstream valve:
+
+.. code-block:: yaml
+
+    esphome:
+        name: esp-sprinkler-controller
+        platform: ESP32
+        board: featheresp32
+
+    wifi:
+        ssid: "wifi_ssid"
+        password: "wifi_password"
+
+    logger:
+
+    sprinkler:
+      - id: lawn_sprinkler_ctrlr
+        main_switch: "Lawn Sprinklers"
+        auto_advance_switch: "Lawn Sprinklers Auto Advance"
+        reverse_switch: "Lawn Sprinklers Reverse"
+        valve_open_delay: 5s
+        valves:
+          - valve_switch: "Front Lawn"
+            enable_switch: "Enable Front Lawn"
+            pump_switch_id: sprinkler_pump_sw
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw0
+          - valve_switch: "Side Lawn"
+            enable_switch: "Enable Side Lawn"
+            pump_switch_id: sprinkler_pump_sw
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw1
+          - valve_switch: "Back Lawn"
+            enable_switch: "Enable Back Lawn"
+            pump_switch_id: sprinkler_pump_sw
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw2
+
+    switch:
+      - platform: gpio
+        id: sprinkler_pump_sw
+        pin: 12
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw0
+        pin: 0
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw1
+        pin: 2
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw2
+        pin: 4
+
+Single Controller, Three Latching Valves, Single Latching Pump
+**************************************************************
+
+This example is similar to the previous example, however it illustrates how a "latching" or "pulsed"
+valve can be configured. This type of valve requires two :doc:`GPIO switches <switch/gpio>` to
+operate -- one to switch the valve on and one to switch the valve off. To switch on the valve, the
+"on" :doc:`GPIO switch <switch/gpio>` is switched on for the configured duration and then switched
+off. To switch the valve off, the "off" :doc:`GPIO switch <switch/gpio>` is switched on for the
+configured duration and then switched off.
+
+Note that, while this example illustrates a configuration that uses exclusively latching valves,
+latching and non-latching valves may be mixed and matched in any configuration, even if attached to
+a common pump/upstream valve.
+
+.. code-block:: yaml
+
+    esphome:
+      name: esp-sprinkler-controller
+      platform: ESP32
+      board: featheresp32
+
+    wifi:
+      ssid: "wifi_ssid"
+      password: "wifi_password"
+
+    logger:
+
+    sprinkler:
+      - id: lawn_sprinkler_ctrlr
+        main_switch: "Lawn Sprinklers"
+        auto_advance_switch: "Lawn Sprinklers Auto Advance"
+        queue_enable_switch: "Lawn Sprinklers Queue Enable"
+        reverse_switch: "Lawn Sprinklers Reverse"
+        pump_pulse_duration: 250ms
+        valve_pulse_duration: 250ms
+        valve_open_delay: 5s
+        valves:
+          - valve_switch: "Front Lawn"
+            enable_switch: "Enable Front Lawn"
+            pump_off_switch_id: sprinkler_pump_sw_off
+            pump_on_switch_id: sprinkler_pump_sw_on
+            run_duration: 900s
+            valve_off_switch_id: lawn_sprinkler_valve_sw0_off
+            valve_on_switch_id: lawn_sprinkler_valve_sw0_on
+          - valve_switch: "Side Lawn"
+            enable_switch: "Enable Side Lawn"
+            pump_off_switch_id: sprinkler_pump_sw_off
+            pump_on_switch_id: sprinkler_pump_sw_on
+            run_duration: 900s
+            valve_off_switch_id: lawn_sprinkler_valve_sw1_off
+            valve_on_switch_id: lawn_sprinkler_valve_sw1_on
+          - valve_switch: "Back Lawn"
+            enable_switch: "Enable Back Lawn"
+            pump_off_switch_id: sprinkler_pump_sw_off
+            pump_on_switch_id: sprinkler_pump_sw_on
+            run_duration: 900s
+            valve_off_switch_id: lawn_sprinkler_valve_sw2_off
+            valve_on_switch_id: lawn_sprinkler_valve_sw2_on
+
+    switch:
+      - platform: gpio
+        id: sprinkler_pump_sw_off
+        pin: 14
+      - platform: gpio
+        id: sprinkler_pump_sw_on
+        pin: 15
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw0_off
+        pin: 0
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw0_on
+        pin: 2
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw1_off
+        pin: 4
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw1_on
+        pin: 5
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw2_off
+        pin: 12
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw2_on
+        pin: 13
+
+Dual Controller, Five Valves, Two Pumps
+***************************************
+
+This example illustrates a complete and more complex dual-controller system with a total of five
+valves (three on the first controller and two on the second controller) and two pumps/upstream
+valves, each of which are shared between the two controllers:
+
+.. code-block:: yaml
+
+    esphome:
+        name: esp-sprinkler-controller
+        platform: ESP32
+        board: featheresp32
+
+    wifi:
+        ssid: "wifi_ssid"
+        password: "wifi_password"
+
+    logger:
+
+    sprinkler:
+      - id: lawn_sprinkler_ctrlr
+        main_switch: "Lawn Sprinklers"
+        auto_advance_switch: "Lawn Sprinklers Auto Advance"
+        reverse_switch: "Lawn Sprinklers Reverse"
+        valve_overlap: 5s
+        valves:
+          - valve_switch: "Front Lawn"
+            enable_switch: "Enable Front Lawn"
+            pump_switch_id: sprinkler_pump_sw0
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw0
+          - valve_switch: "Side Lawn"
+            enable_switch: "Enable Side Lawn"
+            pump_switch_id: sprinkler_pump_sw0
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw1
+          - valve_switch: "Back Lawn"
+            enable_switch: "Enable Back Lawn"
+            pump_switch_id: sprinkler_pump_sw1
+            run_duration: 900s
+            valve_switch_id: lawn_sprinkler_valve_sw2
+      - id: garden_sprinkler_ctrlr
+        main_switch: "Garden Sprinklers"
+        auto_advance_switch: "Garden Sprinklers Auto Advance"
+        reverse_switch: "Garden Sprinklers Reverse"
+        valve_open_delay: 5s
+        valves:
+          - valve_switch: "Front Garden"
+            enable_switch: "Enable Front Garden"
+            pump_switch_id: sprinkler_pump_sw0
+            run_duration: 900s
+            valve_switch_id: garden_sprinkler_valve_sw0
+          - valve_switch: "Back Garden"
+            enable_switch: "Enable Back Garden"
+            pump_switch_id: sprinkler_pump_sw1
+            run_duration: 900s
+            valve_switch_id: garden_sprinkler_valve_sw1
+
+    switch:
+      - platform: gpio
+        id: sprinkler_pump_sw0
+        pin: 12
+      - platform: gpio
+        id: sprinkler_pump_sw1
+        pin: 13
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw0
+        pin: 0
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw1
+        pin: 2
+      - platform: gpio
+        id: lawn_sprinkler_valve_sw2
+        pin: 4
+      - platform: gpio
+        id: garden_sprinkler_valve_sw0
+        pin: 14
+      - platform: gpio
+        id: garden_sprinkler_valve_sw1
+        pin: 15
+
+.. note::
+
+    In this final complete configuration example, pump control is split among the two sprinkler
+    controller instances. This will behave as expected; multiple instances of the controller will
+    communicate to ensure any given pump is activated and deactivated only as necessary, even when
+    the controllers are operating simultaneously.
+
+Extending the Sprinkler Controller's Switches
+*********************************************
+
+It is worth noting that each of the various switches in the sprinkler controller's configuration are standard
+ESPHome :ref:`switch <config-switch>` components. Their configuration may be extended in a manner similar to
+the following example:
+
+.. code-block:: yaml
+
+    # Extended switch configuration for 'main_switch'
+    sprinkler:
+      - id: sprinkler_ctrlr
+        main_switch:
+          name: "Lawn Sprinklers"
+          id: sprinkler_ctrlr_main_switch_id
+          on_turn_on:
+            light.turn_on: my_light
+        ...
+
+This arrangement is possible for any other switch within the sprinkler controller's configuration block, with
+the exception of ``pump_off_switch_id``, ``pump_on_switch_id``, ``pump_switch_id``, ``valve_off_switch_id``,
+``valve_on_switch_id`` and ``valve_switch_id`` (because these are the IDs of other switch components already
+defined elsewhere in your configuration). In addition, specifying each switch ID enables the ability to refer
+to any of the sprinkler controller's switches from elsewhere in your configuration. Here's another brief example:
+
+.. code-block:: yaml
+
+    # Template switch as a secondary main switch
+    switch:
+      - platform: template
+        id: my_switch
+        name: "My Special Sprinkler Switch"
+        on_turn_off:
+          - switch.turn_off: sprinkler_ctrlr_main_switch_id
+          - light.turn_off: sprinkler_indicator_light
+        on_turn_on:
+          - switch.turn_on: sprinkler_ctrlr_main_switch_id
+          - light.turn_on: sprinkler_indicator_light
+        ...
+
+While the above example simply illustrates creating a secondary "main" switch, this approach could be extended
+to take advantage of other devices such as a moisture :ref:`sensor <config-sensor>` -- when the moisture level
+is too low (look for ``on_value`` or ``on_value_range``), the sprinkler controller (or a specific valve) could
+be activated by calling one of the controller's start-up actions, such as ``sprinkler.start_full_cycle``,
+``sprinkler.start_from_queue``, ``sprinkler.start_single_valve``, or ``sprinkler.resume_or_start_full_cycle``.
+
+.. _sprinkler-controller-sprinkler_controller_queue:
+
+The Sprinkler Controller Queue
+******************************
+
+The queuing mechanism is an unusual feature for a sprinkler controller; it becomes useful as a result of the
+extreme flexibility of both ESPHome and Home Assistant. Given the extensive ecosystem of devices available today,
+the sprinkler controller's queuing mechanism provides an advanced feature aimed at allowing even more advanced automation.
+
+In general, it comes down to flexibility: the more traditional "run full cycle" and "run single valve" functionality
+is intended for use by humans (via the front end or physical control interface) while the queuing mechanism is aimed
+at supporting automation.
+
+Here's a practical example:
+
+Consider a home with a yard divided into a number of sprinkler zones -- perhaps it even includes a garden or two
+(flowers and vegetables, of course!). An array of soil moisture sensors could be deployed throughout the various
+zones and gardens and when a given sensor falls below some defined threshold, that sensor's zone is entered into
+the sprinkler controller's queue.
+
+Then, each morning at some specific hour, Home Assistant (or even the ESP device itself!) calls the sprinkler
+controller's ``sprinkler.start_from_queue`` action, causing the controller to iterate only through queued zones.
+Because the run duration may be specified as a part of the queue request, this could be extended to compute a
+specific run duration for each zone depending on the specific moisture level of the soil on any given day. The
+possibilities are endless and are only limited by your creativity!
+
+It is important to note that, if *both* the auto-advance and queue switches are turned on/enabled, **queued valves
+take precedence over valves that would run as a part of a full cycle of the system.** In other words, if the queue
+is enabled and a valve is entered into the queue while a full cycle is active, at the next valve transition, the
+queue entry will be picked up *before* the next valve that would run as a part of the full cycle. At present, this
+behavior cannot be changed. It should also be noted that the queue has a hard-coded limit of 100 entries to limit
+memory use.
+
+Additional Tricks
+*****************
+
+Beyond what is shown in the configuration examples above, other ESPHome elements may be called into
+play to help build out an extensive interface for the controller in the front end (Home Assistant).
+For example, the :ref:`number <config-number>` component may be used to set valve run durations or
+the controller's multiplier value:
+
+.. code-block:: yaml
+
+    # Example configuration to set multiplier via number
+    number:
+      - platform: template
+        id: sprinkler_ctrlr_multiplier
+        name: "Sprinkler Controller Multiplier"
+        min_value: 0.1
+        max_value: 10.0
+        step: 0.1
+        initial_value: 1.0
+        lambda: "return id(lawn_sprinkler_ctrlr).multiplier();"
+        set_action:
+          - sprinkler.set_multiplier:
+              id: lawn_sprinkler_ctrlr
+              multiplier: !lambda 'return x;'
+
+Expose Sprinkler Controller Actions via user-API
+************************************************
+
+This configuration snippet illustrates how user-defined ESPHome API services may be used to expose
+various sprinkler controller actions to the front end. This could be useful to change settings
+and/or trigger sprinkler controller actions using automations.
+
+.. code-block:: yaml
+
+    api:
+      services:
+        - service: set_multiplier
+          variables:
+            multiplier: float
+          then:
+            - sprinkler.set_multiplier:
+                id: lawn_sprinkler_ctrlr
+                multiplier: !lambda 'return multiplier;'
+        - service: start_full_cycle
+          then:
+            - sprinkler.start_full_cycle: lawn_sprinkler_ctrlr
+        - service: start_single_valve
+          variables:
+            valve: int
+          then:
+            - sprinkler.start_single_valve:
+                id: lawn_sprinkler_ctrlr
+                valve_number: !lambda 'return valve;'
+        - service: next_valve
+          then:
+            - sprinkler.next_valve: lawn_sprinkler_ctrlr
+        - service: previous_valve
+          then:
+            - sprinkler.previous_valve: lawn_sprinkler_ctrlr
+        - service: shutdown
+          then:
+            - sprinkler.shutdown: lawn_sprinkler_ctrlr
+
+See Also
+--------
+
+- :apiref:`sprinkler/sprinkler.h`
+- :apiref:`switch/switch.h`
+- :ghedit:`Edit`
diff --git a/conf.py b/conf.py
index bd7203041..49a62e4d2 100644
--- a/conf.py
+++ b/conf.py
@@ -66,9 +66,9 @@ author = "ESPHome"
 # built documents.
 #
 # The short X.Y version.
-version = "2022.6"
+version = "2022.8"
 # The full version, including alpha/beta/rc tags.
-release = "2022.6.3"
+release = "2022.8.0b1"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
diff --git a/guides/automations.rst b/guides/automations.rst
index fb457796b..e3e84b9f1 100644
--- a/guides/automations.rst
+++ b/guides/automations.rst
@@ -374,6 +374,13 @@ All Actions
 - :ref:`stepper.set_target <stepper-set_target_action>` / :ref:`stepper.report_position <stepper-report_position_action>`
   / :ref:`stepper.set_speed <stepper-set_speed_action>`
 - :ref:`servo.write <servo-write_action>` / :ref:`servo.detach <servo-detach_action>`
+- :ref:`sprinkler.start_full_cycle <sprinkler-controller-action_start_full_cycle>` /   :ref:`sprinkler.start_from_queue <sprinkler-controller-action_start_from_queue>` /
+  :ref:`sprinkler.start_single_valve <sprinkler-controller-action_start_single_valve>` /   :ref:`sprinkler.shutdown <sprinkler-controller-action_shutdown>` /
+  :ref:`sprinkler.next_valve <sprinkler-controller-action_next_valve>` /   :ref:`sprinkler.previous_valve <sprinkler-controller-action_previous_valve>` /
+  :ref:`sprinkler.pause <sprinkler-controller-action_pause>` /   :ref:`sprinkler.resume <sprinkler-controller-action_resume>` /
+  :ref:`sprinkler.resume_or_start_full_cycle <sprinkler-controller-action_resume_or_start_full_cycle>` /   :ref:`sprinkler.queue_valve <sprinkler-controller-action_queue_valve>` /
+  :ref:`sprinkler.clear_queued_valves <sprinkler-controller-action_clear_queued_valves>` /   :ref:`sprinkler.set_multiplier <sprinkler-controller-action_set_multiplier>` /
+  :ref:`sprinkler.set_repeat <sprinkler-controller-action_set_repeat>` /   :ref:`sprinkler.set_valve_run_duration <sprinkler-controller-action_set_valve_run_duration>`
 - :ref:`globals.set <globals-set_action>`
 - :ref:`remote_transmitter.transmit_* <remote_transmitter-transmit_action>`
 - :ref:`climate.control <climate-control_action>`
@@ -394,6 +401,7 @@ All Actions
 - :ref:`select.set <select-set_action>` / :ref:`select.set_index <select-set_index_action>` / :ref:`select.first <select-first_action>` / :ref:`select.last <select-last_action>` / :ref:`select.previous <select-previous_action>`  / :ref:`select.next <select-next_action>`  / :ref:`select.operation <select-operation_action>`
 - :ref:`media_player.play <media_player-play>` / :ref:`media_player.pause <media_player-pause>` / :ref:`media_player.stop <media_player-stop>` / :ref:`media_player.toggle <media_player-toggle>`
   / :ref:`media_player.volume_up <media_player-volume_up>` / :ref:`media_player.volume_down <media_player-volume_down>` / :ref:`media_player.volume_set <media_player-volume_set>`
+- :ref:`ble_client.ble_write <ble_client-ble_write_action>`
 
 .. _config-condition:
 
diff --git a/guides/supporters.rst b/guides/supporters.rst
index 01c3fbdaf..60a83ca1c 100644
--- a/guides/supporters.rst
+++ b/guides/supporters.rst
@@ -35,6 +35,7 @@ Contributors
 - `ADeadPixel (@ADeadPixel) <https://github.com/ADeadPixel>`__
 - `Andrea Donno (@adonno) <https://github.com/adonno>`__
 - `Adrien Brault (@adrienbrault) <https://github.com/adrienbrault>`__
+- `Ian Blais (@aeonsablaze) <https://github.com/aeonsablaze>`__
 - `Johan Bloemberg (@aequitas) <https://github.com/aequitas>`__
 - `Stefan Agner (@agners) <https://github.com/agners>`__
 - `Anders (@ahd71) <https://github.com/ahd71>`__
@@ -188,6 +189,7 @@ Contributors
 - `Dav-id (@dav-id-org) <https://github.com/dav-id-org>`__
 - `DAVe3283 (@DAVe3283) <https://github.com/DAVe3283>`__
 - `Dave Richer (@davericher) <https://github.com/davericher>`__
+- `davestubbs (@davestubbs) <https://github.com/davestubbs>`__
 - `Dave T (@davet2001) <https://github.com/davet2001>`__
 - `Dave Wongillies (@davewongillies) <https://github.com/davewongillies>`__
 - `David De Sloovere (@DavidDeSloovere) <https://github.com/DavidDeSloovere>`__
@@ -196,6 +198,7 @@ Contributors
 - `David Zovko (@davidzovko) <https://github.com/davidzovko>`__
 - `Davy Landman (@DavyLandman) <https://github.com/DavyLandman>`__
 - `Darren Tucker (@daztucker) <https://github.com/daztucker>`__
+- `Donovan Baarda (@dbaarda) <https://github.com/dbaarda>`__
 - `David Buezas (@dbuezas) <https://github.com/dbuezas>`__
 - `dckiller51 (@dckiller51) <https://github.com/dckiller51>`__
 - `Debashish Sahu (@debsahu) <https://github.com/debsahu>`__
@@ -410,6 +413,7 @@ Contributors
 - `Jens-Christian Skibakk (@jenscski) <https://github.com/jenscski>`__
 - `Jérôme Laban (@jeromelaban) <https://github.com/jeromelaban>`__
 - `Jesse Hills (@jesserockz) <https://github.com/jesserockz>`__
+- `Yuval Brik (@jhamhader) <https://github.com/jhamhader>`__
 - `Joe (@jhansche) <https://github.com/jhansche>`__
 - `Jim Bauwens (@jimbauwens) <https://github.com/jimbauwens>`__
 - `jimtng (@jimtng) <https://github.com/jimtng>`__
@@ -476,6 +480,7 @@ Contributors
 - `kroimon (@kroimon) <https://github.com/kroimon>`__
 - `krunkel (@krunkel) <https://github.com/krunkel>`__
 - `Kendell R (@KTibow) <https://github.com/KTibow>`__
+- `Kuba Szczodrzyński (@kuba2k2) <https://github.com/kuba2k2>`__
 - `Jakub Šimo (@kubik369) <https://github.com/kubik369>`__
 - `Ken Davidson (@kwdavidson) <https://github.com/kwdavidson>`__
 - `Kyle Hendricks (@kylehendricks) <https://github.com/kylehendricks>`__
@@ -618,6 +623,7 @@ Contributors
 - `nickrout (@nickrout) <https://github.com/nickrout>`__
 - `Nick Whyte (@nickw444) <https://github.com/nickw444>`__
 - `nicuh (@nicuh) <https://github.com/nicuh>`__
+- `NP v/d Spek (@nielsnl68) <https://github.com/nielsnl68>`__
 - `Joakim Vindgard (@nigobo) <https://github.com/nigobo>`__
 - `nikito7 (@nikito7) <https://github.com/nikito7>`__
 - `niklasweber (@niklasweber) <https://github.com/niklasweber>`__
@@ -645,7 +651,6 @@ Contributors
 - `Omar Ghader (@omarghader) <https://github.com/omarghader>`__
 - `Ömer Şiar Baysal (@omersiar) <https://github.com/omersiar>`__
 - `Oncleben31 (@oncleben31) <https://github.com/oncleben31>`__
-- `onde2rock (@onde2rock) <https://github.com/onde2rock>`__
 - `Oscar Bolmsten (@oscar-b) <https://github.com/oscar-b>`__
 - `Trammell Hudson (@osresearch) <https://github.com/osresearch>`__
 - `Otamay (@Otamay) <https://github.com/Otamay>`__
@@ -656,7 +661,6 @@ Contributors
 - `Pablo Clemente Maseda (@paclema) <https://github.com/paclema>`__
 - `Derrick Lyndon Pallas (@pallas) <https://github.com/pallas>`__
 - `Panuruj Khambanonda (PK) (@panuruj) <https://github.com/panuruj>`__
-- `parats15 (@parats15) <https://github.com/parats15>`__
 - `Pasi Suominen (@pasiz) <https://github.com/pasiz>`__
 - `Patrick Felstead (@patfelst) <https://github.com/patfelst>`__
 - `Patrick van der Leer (@patvdleer) <https://github.com/patvdleer>`__
@@ -665,7 +669,6 @@ Contributors
 - `Paul Nicholls (@pauln) <https://github.com/pauln>`__
 - `Bartłomiej Biernacki (@pax0r) <https://github.com/pax0r>`__
 - `Paul Doidge (@pdoidge) <https://github.com/pdoidge>`__
-- `peq123 (@peq123) <https://github.com/peq123>`__
 - `per1234 (@per1234) <https://github.com/per1234>`__
 - `Peter Valkov (@peter-valkov) <https://github.com/peter-valkov>`__
 - `Peter Foreman (@peterforeman) <https://github.com/peterforeman>`__
@@ -896,4 +899,4 @@ Contributors
 - `Zack Barett (@zsarnett) <https://github.com/zsarnett>`__
 - `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
 
-*This page was last updated August 8, 2022.*
+*This page was last updated August 10, 2022.*
diff --git a/images/dac7678.svg b/images/dac7678.svg
new file mode 100644
index 000000000..8b6eae07f
--- /dev/null
+++ b/images/dac7678.svg
@@ -0,0 +1 @@
+<svg width="475.15" height="25mm" viewBox="0 0 125.717 25" xmlns="http://www.w3.org/2000/svg"><path style="fill:#000;fill-opacity:1;stroke-width:.133497;stroke-miterlimit:4;stroke-dasharray:none" d="M5 0h115.717c2.77 0 5 2.23 5 5v15c0 2.77-2.23 5-5 5H5c-2.77 0-5-2.23-5-5V5c0-2.77 2.23-5 5-5Z"/><g aria-label="DAC7678" style="font-size:10.5833px;line-height:1.25;letter-spacing:1.08479px;fill:#fffffc;stroke-width:.264583"><path d="M6.48 20.666V4.86h7.18q2.574 0 4.538.994 1.987.97 3.07 2.754 1.107 1.784 1.107 4.154 0 2.371-1.106 4.155-1.084 1.783-3.07 2.777-1.965.97-4.539.97zm7-3.003q2.37 0 3.77-1.31 1.422-1.332 1.422-3.59 0-2.257-1.422-3.567-1.4-1.332-3.77-1.332h-3.342v9.799zM41.635 20.666h-3.838l-1.4-3.387H29.06l-1.4 3.387h-3.747L30.956 4.86h3.612zM32.74 8.45l-2.506 6.051h5.013zM51.706 20.937q-2.416 0-4.38-1.039-1.942-1.061-3.07-2.912-1.107-1.874-1.107-4.223 0-2.348 1.106-4.199 1.13-1.874 3.07-2.913 1.965-1.06 4.403-1.06 2.055 0 3.703.722 1.671.722 2.8 2.077l-2.348 2.167q-1.603-1.851-3.974-1.851-1.467 0-2.619.655-1.151.632-1.806 1.783-.632 1.152-.632 2.62 0 1.467.632 2.618.655 1.152 1.806 1.807 1.152.632 2.62.632 2.37 0 3.973-1.874l2.348 2.167q-1.129 1.378-2.8 2.1-1.67.723-3.725.723zM60.49 10.415V4.861h12.666v2.37l-5.87 13.435h-3.974l5.667-12.824h-5.238v2.573zM83.023 10.754q1.513 0 2.755.61t1.964 1.738q.723 1.106.723 2.574 0 1.58-.79 2.777t-2.168 1.851q-1.355.633-3.025.633-3.32 0-5.193-2.032-1.874-2.032-1.874-5.803 0-2.687 1.016-4.606t2.822-2.912q1.829-.994 4.222-.994 1.264 0 2.416.294 1.174.27 1.987.79l-1.355 2.687q-1.174-.79-2.958-.79-2.01 0-3.183 1.174-1.174 1.174-1.265 3.409 1.4-1.4 3.906-1.4zm-.745 7.45q1.174 0 1.897-.631.745-.633.745-1.716 0-1.084-.745-1.716-.723-.655-1.942-.655-1.196 0-1.964.677-.768.655-.768 1.694 0 1.038.745 1.693t2.032.655zM90.498 10.415V4.861h12.666v2.37l-5.87 13.435H93.32l5.667-12.824h-5.238v2.573zM116.305 12.357q1.174.587 1.784 1.535.632.949.632 2.19 0 1.468-.835 2.574-.836 1.084-2.348 1.694-1.513.587-3.5.587t-3.5-.587q-1.49-.61-2.325-1.694-.813-1.106-.813-2.574 0-1.241.61-2.19.632-.948 1.783-1.535-.88-.542-1.354-1.355-.474-.835-.474-1.896 0-1.377.767-2.393.768-1.016 2.145-1.558 1.377-.565 3.161-.565 1.806 0 3.183.565 1.4.542 2.168 1.558.768 1.016.768 2.393 0 1.061-.475 1.896-.474.813-1.377 1.355zm-4.267-5.08q-1.106 0-1.784.542-.654.52-.654 1.445 0 .903.654 1.422.655.52 1.784.52t1.806-.52q.678-.519.678-1.422 0-.926-.678-1.445-.677-.542-1.806-.542zm0 10.973q1.377 0 2.167-.61.813-.632.813-1.67 0-1.04-.813-1.649-.79-.61-2.167-.61-1.355 0-2.145.61t-.79 1.649q0 1.06.79 1.67.79.61 2.145.61z" style="font-weight:700;font-size:22.5778px;font-family:Montserrat;-inkscape-font-specification:'Montserrat, Bold'"/></g></svg>
\ No newline at end of file
diff --git a/images/feedback_cover.svg b/images/feedback_cover.svg
new file mode 100644
index 000000000..ffb2f7af9
--- /dev/null
+++ b/images/feedback_cover.svg
@@ -0,0 +1,20 @@
+<svg width="24" height="24" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
+ <g class="layer">
+  <title>Layer 1</title>
+  <path d="m3.859691,11l4,0l0,-2l4,0l0,2l4,0l0,-7l-12,0l0,7m12,2l-12,0l0,7l12,0l0,-7m-12,-11l12,0a2,2 0 0 1 2,2l0,16a2,2 0 0 1 -2,2l-12,0a2,2 0 0 1 -2,-2l0,-16a2,2 0 0 1 2,-2z" id="svg_1" transform="matrix(1 0 0 1 0 0)"/>
+  <ellipse cx="19.177173" cy="20.221166" fill="#ffffff" id="svg_6" rx="2.437574" ry="2.437574" stroke="#000000" stroke-opacity="0"/>
+  <use fill="#000000" id="svg_3" stroke="#000000" stroke-opacity="0" transform="matrix(0.333333 0 0 0.333333 0 0)" x="45.303208" xlink:href="#svg_2" y="47.800236"/>
+  <use fill="#4c4c4c" id="svg_7" transform="matrix(0.232786 0 0 0.232786 62.8523 13.3204)" x="-194.266223" xlink:href="#svg_4" y="-13.118657"/>
+  <use fill="#4c4c4c" id="svg_8" transform="matrix(0.232786 0 0 0.232786 104.588 20.2169)" x="-373.555514" xlink:href="#svg_4" y="-74.414128"/>
+  <use fill="#4c4c4c" id="svg_9" transform="matrix(0.232786 0 0 0.232786 146.443 25.5677)" x="-553.866324" xlink:href="#svg_4" y="-76.45732"/>
+  <use fill="#4c4c4c" id="svg_10" transform="matrix(0.232786 0 0 0.232786 146.205 28.2869)" x="-552.333963" xlink:href="#svg_4" y="-98.421519"/>
+ </g>
+ <defs>
+  <symbol height="24" id="svg_2" version="1.1" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+   <path d="m12,20a7,7 0 0 1 -7,-7a7,7 0 0 1 7,-7a7,7 0 0 1 7,7a7,7 0 0 1 -7,7m7.03,-12.61l1.42,-1.42c-0.45,-0.51 -0.9,-0.97 -1.41,-1.41l-1.42,1.44c-1.55,-1.26 -3.5,-2 -5.62,-2a9,9 0 0 0 -9,9a9,9 0 0 0 9,9c5,0 9,-4.03 9,-9c0,-2.12 -0.74,-4.07 -1.97,-5.61m-8.03,6.61l2,0l0,-6l-2,0m4,-7l-6,0l0,2l6,0l0,-2z"/>
+  </symbol>
+  <symbol height="24" id="svg_4" version="1.1" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+   <path d="m1,11l2.17,0c0.41,-1.17 1.52,-2 2.83,-2c0.65,0 1.25,0.21 1.74,0.56l6.7,-4.69l1.14,1.63l-6.69,4.7c0.07,0.25 0.11,0.52 0.11,0.8a3,3 0 0 1 -3,3c-1.31,0 -2.42,-0.83 -2.83,-2l-2.17,0l0,-2m22,0l0,2l-2.17,0c-0.41,1.17 -1.52,2 -2.83,2a3,3 0 0 1 -3,-3a3,3 0 0 1 3,-3c1.31,0 2.42,0.83 2.83,2l2.17,0m-17,0a1,1 0 0 0 -1,1a1,1 0 0 0 1,1a1,1 0 0 0 1,-1a1,1 0 0 0 -1,-1m12,0a1,1 0 0 0 -1,1a1,1 0 0 0 1,1a1,1 0 0 0 1,-1a1,1 0 0 0 -1,-1z"/>
+  </symbol>
+ </defs>
+</svg>
\ No newline at end of file
diff --git a/images/smt100.jpg b/images/smt100.jpg
new file mode 100644
index 000000000..61220dabc
Binary files /dev/null and b/images/smt100.jpg differ
diff --git a/images/sprinkler-variant.svg b/images/sprinkler-variant.svg
new file mode 100644
index 000000000..a083aaa91
--- /dev/null
+++ b/images/sprinkler-variant.svg
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="24" height="24" viewBox="0 0 24 24"><path d="M10 10H14V22H10V10M7 9H9V7H7V9M4 8H6V6H4V8M4 11H6V9H4V11M1 13H3V11H1V13M1 7H3V5H1V7M1 10H3V8H1V10M18 11H20V9H18V11M21 10H23V8H21V10M21 5V7H23V5H21M21 13H23V11H21V13M15 9H17V7H15V9M18 8H20V6H18V8M10 7H10.33L11 9H13L13.67 7H14V6H10V7Z" /></svg>
\ No newline at end of file
diff --git a/index.rst b/index.rst
index ed5d6f224..4d69c4195 100644
--- a/index.rst
+++ b/index.rst
@@ -313,6 +313,7 @@ Environmental
     SHT3X-D, components/sensor/sht3xd, sht3xd.jpg, Temperature & Humidity
     SHT4X, components/sensor/sht4x, sht4x.jpg, Temperature & Humidity
     SHTCx, components/sensor/shtcx, shtc3.jpg, Temperature & Humidity
+    SMT100, components/sensor/smt100, smt100.jpg, Moisture & Temperature
     STS3X, components/sensor/sts3x, sts3x.jpg, Temperature
     TMP102, components/sensor/tmp102, tmp102.jpg, Temperature
     TMP117, components/sensor/tmp117, tmp117.jpg, Temperature
@@ -356,6 +357,7 @@ Miscellaneous
     Modbus Sensor, components/sensor/modbus_controller, modbus.png
     Nextion, components/sensor/nextion, nextion.jpg, Sensors from display
     Rotary Encoder, components/sensor/rotary_encoder, rotary_encoder.jpg
+    SMT100, components/sensor/smt100, smt100.jpg, Moisture & Temperature
     Tuya Sensor, components/sensor/tuya, tuya.png
     TX20, components/sensor/tx20, tx20.jpg, Wind speed & Wind direction
 
@@ -441,6 +443,7 @@ Output Components
     MCP4725, components/output/mcp4725, mcp4725.jpg
     MCP4728, components/output/mcp4728, mcp4728.jpg
     MCP47A1, components/output/mcp47a1, mcp47a1.svg
+    DAC7678, components/output/dac7678, dac7678.svg
     BLE Binary Output, components/output/ble_client, bluetooth.svg
     Modbus Output, components/output/modbus_controller, modbus.png
     Custom Output, components/output/custom, language-cpp.svg
@@ -562,6 +565,7 @@ Cover Components
 
     Cover Core, components/cover/index, folder-open.svg
     Template Cover, components/cover/template, description.svg
+    Feedback Cover, components/cover/feedback, feedback_cover.svg
     Endstop Cover, components/cover/endstop, electric-switch.svg
     Current-Based Cover, components/cover/current_based, flash.svg
     Time-Based Cover, components/cover/time_based, timer.svg
@@ -666,6 +670,7 @@ Misc Components
     ESP32 Camera Web Server, components/esp32_camera_web_server, camera.svg
     Stepper, components/stepper/index, stepper.svg
     Servo, components/servo, servo.svg
+    Sprinkler, components/sprinkler, sprinkler-variant.svg
 
     PCF8574 I/O Expander, components/pcf8574, pcf8574.jpg
     MCP230XX I/O Expander - I²C Bus, components/mcp230xx, mcp230xx.svg