Merge pull request #2991 from esphome/bump-2023.6.0b1

2023.6.0b1

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         = 2023.5.5
+PROJECT_NUMBER         = 2023.6.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

Makefile

@@ -1,5 +1,5 @@
 ESPHOME_PATH = ../esphome
-ESPHOME_REF = 2023.5.5
+ESPHOME_REF = 2023.6.0b1
 
 .PHONY: html html-strict cleanhtml deploy help live-html Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify
 

_static/version

@@ -1 +1 @@
-2023.5.5
+2023.6.0b1

changelog/2023.4.0.rst

@@ -22,7 +22,7 @@ Voice Assistant
 
 This year is the Year of the Voice for Home Assistant, and ESPHome is charging ahead with this in mind.
 We've added a new :doc:`/components/voice_assistant` component that allows you to use ESPHome devices as an input
-for `assist <https://www.home-assistant.io/docs/assist/>`__ in Home Assistant **2023.5 or later**.
+for `assist <https://www.home-assistant.io/voice_control/>`__ in Home Assistant **2023.5 or later**.
 
 With this also comes preliminary :doc:`microphone </components/microphone/index>` support, which has been built in a way that multiple
 components, like ``voice_assistant`` can request start / stop of the microphone and get the data. We

changelog/2023.6.0.rst

@@ -0,0 +1,133 @@
+ESPHome 2023.6.0 - 21th June 2023
+=================================
+
+.. seo::
+    :description: Changelog for ESPHome 2023.6.0.
+    :image: /_static/changelog-2023.6.0.png
+    :author: Jesse Hills
+    :author_twitter: @jesserockz
+
+.. imgtable::
+    :columns: 2
+
+    Alarm Control Panel Core, components/alarm_control_panel/index, alarm-panel.svg
+    Template Alarm Control Panel, components/alarm_control_panel/template, description.svg
+    RP2040 PIO LED Strip, components/light/rp2040_pio_led_strip, color_lens.svg
+    TMP1075, components/sensor/tmp1075, tmp1075.jpg
+
+
+Full list of changes
+--------------------
+
+New Components
+^^^^^^^^^^^^^^
+
+- Rp2040 pio ledstrip :esphomepr:`4818` by :ghuser:`Papa-DMan` (new-integration)
+- Add support for TMP1075 temperature sensor :esphomepr:`4776` by :ghuser:`sybrenstuvel` (new-integration)
+- Add Alarm Control Panel :esphomepr:`4770` by :ghuser:`grahambrown11` (new-integration)
+
+Breaking Changes
+^^^^^^^^^^^^^^^^
+
+- Allow i2s microphone bits per sample to be configured :esphomepr:`4884` by :ghuser:`jesserockz` (breaking-change)
+- Move ESPTime into core esphome namespace :esphomepr:`4926` by :ghuser:`jesserockz` (breaking-change)
+- display: add `BaseImage` and provide only `Image::get_pixel` method :esphomepr:`4932` by :ghuser:`ayufan` (breaking-change)
+
+All changes
+^^^^^^^^^^^
+
+- Add minimum RSSI check to ble presence :esphomepr:`4646` by :ghuser:`nielsnl68`
+- Run black over tests folder :esphomepr:`4824` by :ghuser:`jesserockz`
+- Use token so PR checks are run :esphomepr:`4834` by :ghuser:`jesserockz`
+- Fix stale bot ignoring not-stale :esphomepr:`4836` by :ghuser:`jesserockz`
+- Rework CI into multiple dependent jobs :esphomepr:`4823` by :ghuser:`jesserockz`
+- Add DNS to Text info :esphomepr:`4821` by :ghuser:`max246`
+- allow to use MQTT for discovery of IPs if mDNS is no option  :esphomepr:`3887` by :ghuser:`Links2004`
+- Move some I2C logic out of header file :esphomepr:`4839` by :ghuser:`CarsonF`
+- Allow substitutions to be valid names :esphomepr:`4726` by :ghuser:`jgoguen`
+- Insert Europe Tank Types from mopeka_std_check :esphomepr:`4757` by :ghuser:`lukasl96`
+- Bump tornado from 6.3.1 to 6.3.2 :esphomepr:`4841` by :ghuser:`dependabot[bot]`
+- Bump pylint from 2.17.3 to 2.17.4 :esphomepr:`4843` by :ghuser:`dependabot[bot]`
+- Bump zeroconf from 0.60.0 to 0.62.0 :esphomepr:`4781` by :ghuser:`dependabot[bot]`
+- Bump pyupgrade from 3.3.2 to 3.4.0 :esphomepr:`4842` by :ghuser:`dependabot[bot]`
+- Bump platformio from 6.1.6 to 6.1.7 :esphomepr:`4795` by :ghuser:`dependabot[bot]`
+- Migrate e131 to use socket instead of WiFiUDP arduino library :esphomepr:`4832` by :ghuser:`jesserockz`
+- Add transparency support to all image types :esphomepr:`4600` by :ghuser:`guillempages`
+- Run YAML test 8 during CI and fix board used :esphomepr:`4862` by :ghuser:`kroimon`
+- Rp2040 pio ledstrip :esphomepr:`4818` by :ghuser:`Papa-DMan` (new-integration)
+- [ILI9xxx] Update ili9xxx_init.h code for the ILI9488 display for correct white balance :esphomepr:`4849` by :ghuser:`lucasreiners`
+- Update codeowners :esphomepr:`4875` by :ghuser:`freekode`
+- Fix rp2040_pio_led_strip color modes :esphomepr:`4887` by :ghuser:`jesserockz`
+- Add i2s mclk :esphomepr:`4885` by :ghuser:`rpatel3001`
+- Allow partially looping animations :esphomepr:`4693` by :ghuser:`guillempages`
+- Allow i2s microphone bits per sample to be configured :esphomepr:`4884` by :ghuser:`jesserockz` (breaking-change)
+- Add support for TMP1075 temperature sensor :esphomepr:`4776` by :ghuser:`sybrenstuvel` (new-integration)
+- move pio tools to LED component :esphomepr:`4903` by :ghuser:`ssieb`
+- add SUB_SELECT macro :esphomepr:`4897` by :ghuser:`regevbr`
+- add SUB_SWITCH macro :esphomepr:`4898` by :ghuser:`regevbr`
+- esp32_rmt_led_strip: fix compile with ESP-IDF >= 5 :esphomepr:`4856` by :ghuser:`stintel`
+- Bump aioesphomeapi from 13.7.5 to 13.9.0 :esphomepr:`4907` by :ghuser:`dependabot[bot]`
+- ota: fix compile with ESP-IDF >= 5 :esphomepr:`4857` by :ghuser:`stintel`
+- ota: fix TWDT with ESP-IDF >= 5 :esphomepr:`4858` by :ghuser:`stintel`
+- light: fix compile with ESP-IDF >= 5 :esphomepr:`4855` by :ghuser:`stintel`
+- Continuous voice_assistant and silence detection :esphomepr:`4892` by :ghuser:`jesserockz`
+- Allow WIFI to be disabled and enabled :esphomepr:`4810` by :ghuser:`jesserockz`
+- Bump frenck/action-yamllint from 1.4.0 to 1.4.1 :esphomepr:`4876` by :ghuser:`dependabot[bot]`
+- Bump pytest-cov from 4.0.0 to 4.1.0 :esphomepr:`4888` by :ghuser:`dependabot[bot]`
+- Bump zeroconf from 0.62.0 to 0.63.0 :esphomepr:`4890` by :ghuser:`dependabot[bot]`
+- Bump esptool from 4.5.1 to 4.6 :esphomepr:`4906` by :ghuser:`dependabot[bot]`
+- prometheus: fix compilation with EntityBase :esphomepr:`4895` by :ghuser:`mischief`
+- Support for Adafruit ESP32-S2 TFT Feather :esphomepr:`4912` by :ghuser:`PlainTechEnthusiast`
+- Add support for mdi images :esphomepr:`4654` by :ghuser:`guillempages`
+- Increase SNTP setup priority :esphomepr:`4917` by :ghuser:`droscy`
+- Bump aioesphomeapi from 13.9.0 to 14.0.0 :esphomepr:`4925` by :ghuser:`dependabot[bot]`
+- Bluetooth Proxy: Raw bundled advertisements :esphomepr:`4924` by :ghuser:`jesserockz`
+- Move ESPTime into core esphome namespace :esphomepr:`4926` by :ghuser:`jesserockz` (breaking-change)
+- Allow multiple MAC addresses for 'on_ble_advertise' filter :esphomepr:`4773` by :ghuser:`RoboMagus`
+- Add SVG image support :esphomepr:`4922` by :ghuser:`guillempages`
+- Add !extend to devcontainer's customTags :esphomepr:`4749` by :ghuser:`jimtng`
+- [max7219digit] fix 270° rotation :esphomepr:`4930` by :ghuser:`spezifisch`
+- proto generation updates :esphomepr:`4653` by :ghuser:`jesserockz`
+- I2S media player allow setting communication format for external DACs :esphomepr:`4918` by :ghuser:`ccorderor`
+- Add MULTI_CONF to pn53_i2c :esphomepr:`4938` by :ghuser:`jesserockz`
+- display: Improve Image rendering by removing usage of virtual functions :esphomepr:`4931` by :ghuser:`ayufan`
+- display: add `BaseImage` and provide only `Image::get_pixel` method :esphomepr:`4932` by :ghuser:`ayufan` (breaking-change)
+- Add Alarm Control Panel :esphomepr:`4770` by :ghuser:`grahambrown11` (new-integration)
+
+Past Changelogs
+---------------
+
+- :doc:`2023.5.0`
+- :doc:`2023.4.0`
+- :doc:`2023.3.0`
+- :doc:`2023.2.0`
+- :doc:`2022.12.0`
+- :doc:`2022.11.0`
+- :doc:`2022.10.0`
+- :doc:`2022.9.0`
+- :doc:`2022.8.0`
+- :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`

changelog/index.rst

@@ -2,7 +2,7 @@ Changelog
 =========
 
 .. redirect::
-    :url: /changelog/2023.5.0.html
+    :url: /changelog/2023.6.0.html
 
 .. toctree::
     :glob:

components/alarm_control_panel/index.rst

@@ -0,0 +1,203 @@
+Alarm Control Panel Component
+=============================
+
+.. seo::
+    :description: Instructions for setting up generic Alarm Control Panels in ESPHome.
+    :image: alarm-panel.svg
+
+.. _config-alarm_control_panel:
+
+Base Alarm COntrol Panel Configuration
+--------------------------------------
+
+.. code-block:: yaml
+
+    alarm_control_panel:
+      - platform: ...
+        name: Alarm Panel
+
+
+Configuration variables:
+
+- **name** (**Required**, string): The name of the alarm control panel.
+
+  .. note::
+
+      If you have a :ref:`friendly_name <esphome-configuration_variables>` set for your device and
+      you want the switch to use that name, you can set ``name: None``.
+
+- **on_state** (*Optional*, :ref:`Action <config-action>`): An automation to perform
+  when the alarm changes state. See :ref:`alarm_control_panel_on_state_trigger`.
+- **on_triggered** (*Optional*, :ref:`Action <config-action>`): An automation to perform
+  when the alarm triggers. See :ref:`alarm_control_panel_on_triggered_trigger`.
+- **on_cleared** (*Optional*, :ref:`Action <config-action>`): An automation to perform
+  when the alarm clears. See :ref:`alarm_control_panel_on_cleared_trigger`.
+
+
+Automation:
+-----------
+
+.. _alarm_control_panel_on_state_trigger:
+
+``on_state`` Trigger
+********************
+
+This trigger is activated each time the alarm changes state.
+
+.. code-block:: yaml
+
+    alarm_control_panel:
+      # ...
+      on_state:
+        then:
+          - logger.log: "Alarm Panel State Changed!"
+
+.. _alarm_control_panel_on_triggered_trigger:
+
+``on_triggered`` Trigger
+************************
+
+This trigger is activated when the alarm changes to triggered state.
+
+.. code-block:: yaml
+
+    alarm_control_panel:
+      # ...
+      on_triggered:
+        then:
+          - logger.log: "Alarm Triggered!"
+
+.. _alarm_control_panel_on_cleared_trigger:
+
+``on_cleared`` Trigger
+**********************
+
+This trigger is activated when the alarm changes from triggered back to either the previous armed state or disarmed.
+
+.. code-block:: yaml
+
+    alarm_control_panel:
+      # ...
+      on_cleared:
+        then:
+          - logger.log: "Alarm Cleared!"
+
+.. _alarm_control_panel_arm_away_action:
+
+``arm_away`` Action
+*******************
+
+This action arms the alarm in away mode. The ``code`` is required when *requires_code_to_arm* is *true*.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - alarm_control_panel.arm_away:
+            id: alarm
+            code: "1234"
+
+.. _alarm_control_panel_arm_home_action:
+
+``arm_home`` Action
+*******************
+
+This action arms the alarm in home mode. The ``code`` is required when *requires_code_to_arm* is *true*.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - alarm_control_panel.arm_home:
+            id: alarm
+            code: "1234"
+
+.. _alarm_control_panel_disarm_action:
+
+``disarm`` Action
+*****************
+
+This action disarms the alarm. The ``code`` is required when *codes* is not empty.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - alarm_control_panel.disarm:
+            id: alarm
+            code: "1234"
+
+.. _alarm_control_panel_pending_action:
+
+``pending`` Action
+******************
+
+This action puts the alarm in pending state (the state before triggered after *pending_time*).
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - alarm_control_panel.pending: alarm
+
+.. _alarm_control_panel_triggered_action:
+
+``triggered`` Action
+********************
+
+This action puts the alarm in triggered state.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - alarm_control_panel.triggered: alarm
+
+.. _alarm_control_panel_is_armed_condition:
+
+``is_armed`` Condition
+**********************
+
+This :ref:`Condition <config-condition>` checks if the alarm control panel is armed.
+
+.. code-block:: yaml
+
+    on_...:
+      if:
+        condition:
+          alarm_control_panel.is_armed: alarm
+
+
+.. _alarm_control_panel_lambda_calls:
+
+lambda calls
+************
+
+From :ref:`lambdas <config-lambda>`, you can call the following methods:
+
+- ``arm_away(code)``
+- ``arm_home(code)``
+- ``disarm(code)``
+
+.. code-block:: cpp
+
+    id(alarm).arm_away();
+    id(alarm).arm_home();
+    id(alarm).disarm("1234");
+
+
+Platforms
+---------
+
+.. toctree::
+    :maxdepth: 1
+    :glob:
+
+    *
+
+See Also
+--------
+
+- :doc:`/components/binary_sensor/index`
+- :apiref:`alarm_control_panel/alarm_control_panel.h`
+- :ghedit:`Edit`

components/alarm_control_panel/template.rst

@@ -0,0 +1,135 @@
+Template Alarm Control Panel
+============================
+
+.. seo::
+    :description: Instructions for setting up template Alarm Control Panels in ESPHome.
+    :image: description.svg
+
+The ``template`` alarm control panel platform allows you to turn your binary sensors into a state machine
+managed alarm control panel.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    alarm_control_panel:
+      - platform: template
+        name: Alarm Panel
+        codes:
+          - "1234"
+        binary_sensors:
+          - input: zone_1
+          - input: zone_2
+            bypass_armed_home: true
+
+Configuration variables:
+------------------------
+
+- **codes** (*Optional*, list of string): A list of codes for disarming the alarm, if *requires_code_to_arm* set to true then for arming the alarm too.
+- **requires_code_to_arm** (*Optional*, boolean): Code required for arming the alarm, *code* must be provided.
+- **arming_time** (*Optional*, :ref:`config-time`): The exit delay before the alarm is armed.
+- **pending_time** (*Optional*, :ref:`config-time`): The entry delay before the alarm is triggered.
+- **trigger_time** (*Optional*, :ref:`config-time`): The time after a triggered alarm before resetting to previous state if the sensors are cleared/off.
+- **binary_sensors** (*Optional*, *list*): A list of binary sensors the panel should use. Each consists of:
+
+  - **input** (**Required**, string): The id of the binary sensor component
+  - **bypass_armed_home** (*Optional*, boolean): This binary sensor will not trigger the alarm when in ``armed_home`` state.
+
+- **restore_mode** (*Optional*, enum):
+
+  - **ALWAYS_DISARMED** (Default): Always start in ``disarmed`` state.
+  - **RESTORE_DEFAULT_DISARMED**: Restore state or default to ``disarmed`` state if no saved state was found.
+
+- All other options from :ref:`Alarm Control Panel <config-alarm_control_panel>`
+
+.. note::
+
+    If ``binary_sensors`` is ommited then you're expected to trigger the alarm using
+    :ref:`alarm_control_panel_pending_action` or :ref:`alarm_control_panel_triggered_action`.
+
+
+.. _template_alarm_control_panel-state_flow:
+
+State Flow:
+-----------
+
+1. The alarm starts in ``DISARMED`` state
+2. When the ``arm_...`` method is invoked
+
+  a. ``arming_time`` greater than 0 the state is ``ARMING``
+  b. ``arming_time`` is 0 or after the ``arming_time`` delay the state is ``ARM_AWAY`` or ``ARM_HOME``
+
+3. When the alarm is tripped by a sensor state changing to ``on``
+
+  a. ``pending_time`` greater than 0 the state is ``PENDING``
+  b. ``pending_time`` is 0 or after the ``pending_time`` delay the state is ``TRIGGERED``
+
+4. If ``trigger_time`` greater than 0 and no sensors are ``on`` after ``trigger_time`` delay
+   the state returns to ``ARM_AWAY`` or ``ARM_HOME``
+
+Example:
+--------
+
+.. code-block:: yaml
+
+    alarm_control_panel:
+      platform: template
+      name: Alarm Panel
+      codes:
+        - "1234"
+      requires_code_to_arm: true
+      arming_time: 10s
+      pending_time: 15s
+      trigger_time: 5min
+      binary_sensors:
+        - input: zone_1
+        - input: zone_2
+          bypass_armed_home: true
+        - input: ha_test
+      on_state:
+        then:
+          - lambda: !lambda |-
+              ESP_LOGD("TEST", "State change %s", alarm_control_panel_state_to_string(id(acp1)->get_state()));
+      on_triggered:
+        then:
+          - switch.turn_on: siren
+      on_cleared:
+        then:
+          - switch.turn_off: siren
+
+    binary_sensor:
+      - platform: gpio
+        id: zone_1
+        name: Zone 1
+        device_class: door
+        pin:
+          number: D1
+          mode: INPUT_PULLUP
+          inverted: True
+      - platform: gpio
+        id: zone_2
+        name: Zone 2
+        device_class: motion
+        pin:
+          number: D2
+          mode: INPUT_PULLUP
+          inverted: True
+      - platform: homeassistant
+        id: ha_test
+        name: Zone 3
+        entity_id: input_boolean.test_switch
+
+    switch:
+      - platform: gpio
+        id: siren
+        name: Siren
+        icon: mdi:alarm-bell
+        pin: D7
+
+
+See Also
+--------
+
+- :doc:`index`
+- :doc:`/components/binary_sensor/index`
+- :apiref:`template/alarm_control_panel/template_alarm_control_panel.h`
+- :ghedit:`Edit`

components/binary_sensor/ble_presence.rst

@@ -22,6 +22,7 @@ Bluetooth Low Energy device.
       - platform: ble_presence
         mac_address: AC:37:43:77:5F:4C
         name: "ESP32 BLE Tracker Google Home Mini"
+        min_rssi: -80dB
       # Presence based on BLE Service UUID
       - platform: ble_presence
         service_uuid: '11aa'
@@ -58,6 +59,7 @@ Configuration variables:
    to be tracked. Usually used to identify beacons within an iBeacon group.
 -  **id** (*Optional*, :ref:`config-id`): Manually specify
    the ID used for code generation.
+-  **min_rssi** (*Optional*, int): at which minimum RSSI level would the component report the device be precent
 -  All other options from :ref:`Binary Sensor <config-binary_sensor>`.
 
 .. _esp32_ble_tracker-setting_up_devices:

components/captive_portal.rst

@@ -16,7 +16,7 @@ After 1 minute of unsuccessful WiFi connection attempts, the ESP will start a Wi
     :width: 70.0%
 
 In this web interface, you can manually override the WiFi settings of the device (please note
-this will be overwritten by any subsequent upload so make sure to also update your YAML configuration).
+this will be overwritten by any subsequent serial upload so make sure to also update your YAML configuration).
 
 Additionally, you can upload a new firmware file.
 

components/climate/haier.rst

@@ -5,7 +5,7 @@ Haier Climate
     :description: Instructions for setting up a Haier climate devices.
     :image: air-conditioner.svg
 
-The `haier` climate platform creates a Haier climate device.  
+The ``haier`` climate platform creates a Haier climate device.
 The component can be used as a replacement of a Haier proprietary WiFi modules such as KZW-W001 and KZW-W002.
 
 This component requires a :ref:`uart` to be setup.
@@ -33,7 +33,7 @@ Configuration variables:
 
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
 - **name** (**Required**, string): The name of the climate device.
-- **update_interval** (*Optional*, :ref:`config-time`): How often device will be polled for status. Defaults to `5s`.
+- **update_interval** (*Optional*, :ref:`config-time`): How often device will be polled for status. Defaults to ``5s``.
 - **supported_swing_modes** (*Optional*, list): List of supported swing modes. Possible values are: ``VERTICAL``, ``HORIZONTAL``, ``BOTH``.
 - All other options from :ref:`Climate <config-climate>`.
 
@@ -42,10 +42,10 @@ Hardware setup
 
 Most units will have a dedicated USB-A port for Haier WiFi module.
 The physical USB port is in fact UART and does not "speak" USB protocol.
-It uses four USB pins as 5V, GND, RX, TX. 
+It uses four USB pins as 5V, GND, RX, TX.
 You can use spare male USB cable to connect esphome device directly to the climate appliance.
 
-Other units will not have USB ports, but will still probably have UART exposed somewhere on the main board. 
+Other units will not have USB ports, but will still probably have UART exposed somewhere on the main board.
 
 .. list-table:: Haier UART pinout
     :header-rows: 1

components/climate/index.rst

@@ -52,8 +52,8 @@ Configuration variables:
   - **temperature_step** (*Optional*, float): The granularity with which the target temperature
     can be controlled. Can be a single number, or split as below:
 
-    - **target_temperature** (**Required**, float)
+    - **target_temperature** (**Required**, float): The granularity for target temperature
-    - **current_temperature** (**Required**, float)
+    - **current_temperature** (**Required**, float): The granularity for current temperature
 
 Advanced options:
 

components/climate/pid.rst

@@ -15,12 +15,12 @@ temperature to a user-specified setpoint.
 .. note::
 
     PID is like cruise control in the cars: it keeps the car's speed constant by continuously
-    adjusting the fuel quantity, based on load measurements. Eg when the car has to go up on a hill, 
+    adjusting the fuel quantity, based on load measurements. Eg when the car has to go up on a hill,
     the system notices the load increase thus immediately gives more fuel to the engine; and when it
     goes down on the other side of the hill, it notices the load decrease thus reduces or cuts off fuel
     completely so that car speed remains as constant as possible. The calculation takes in consideration
-    constants like car weight, wind resistance etc. 
+    constants like car weight, wind resistance etc.
-    
+
     This kind of math can be used for a heating or cooling system too, and an auto-tuning algorithm can help
     determining such constants, which mainly describe the heat loss of the room or building. Goal is to
     keep the temperature as constant as possible, and smooth out oscillations otherwise produced by
@@ -47,12 +47,12 @@ but there's a nice article explaining the function principle `here <https://blog
         deadband_parameters:
           threshold_high: 0.5°C       # deadband within +/-0.5°C of target_temperature
           threshold_low: -0.5°C
-          
+
 Configuration variables:
 ------------------------
 
 - **sensor** (**Required**, :ref:`config-id`): The sensor that is used to measure the current
-  temperature. 
+  temperature.
 - **default_target_temperature** (**Required**, float): The default target temperature (setpoint)
   for the control algorithm. This can be dynamically set in the frontend later.
 - **heat_output** (*Optional*, :ref:`config-id`): The ID of a :ref:`float output <config-output>`
@@ -72,37 +72,35 @@ Configuration variables:
     ``ki`` to prevent windup. Defaults to ``-1``.
   - **max_integral** (*Optional*, float): The minimum value of the integral term multiplied by
     ``ki`` to prevent windup. Defaults to ``1``.
-  - **starting_integral_term** (*Optional*, float): Set the initial output, by priming the integral 
+  - **starting_integral_term** (*Optional*, float): Set the initial output, by priming the integral
-    term. This is useful for when your system is rebooted and you don't want to wait 
+    term. This is useful for when your system is rebooted and you don't want to wait
     for it to get back equilibrium.
 
-  - **output_averaging_samples** (*Optional*, int): average the output over this many samples. PID controllers 
+  - **output_averaging_samples** (*Optional*, int): average the output over this many samples. PID controllers
-    can be quite sensitive to small changes on the input sensor. By averaging the last X output samples,  
+    can be quite sensitive to small changes on the input sensor. By averaging the last X output samples,
-    the temperature can be more stable. However, the larger the sampling window, the less responsive the 
+    the temperature can be more stable. However, the larger the sampling window, the less responsive the
     PID controller. Defaults to ``1`` which is no sampling/averaging.
 
-  - **derivative_averaging_samples** (*Optional*, int): average the derivative term over this many samples. Many 
+  - **derivative_averaging_samples** (*Optional*, int): average the derivative term over this many samples. Many
-    controllers don't use the derivative term because it is sensitive to slight changes in the input sensor. 
+    controllers don't use the derivative term because it is sensitive to slight changes in the input sensor.
-    By taking an average of the derivative term it might become more useful for you. Most PID controllers call 
+    By taking an average of the derivative term it might become more useful for you. Most PID controllers call
-    this derivative filtering. The derivative term is used to pre-act so don't filter too much. Defaults to ``1`` 
+    this derivative filtering. The derivative term is used to pre-act so don't filter too much. Defaults to ``1``
     which is no sampling/averaging.
 
-- **deadband_parameters** (*Optional*): Enables a deadband to stabilise and minimise changes in the 
+- **deadband_parameters** (*Optional*): Enables a deadband to stabilise and minimise changes in the
   output when the temperature is close to the target temperature. See `Deadband Setup`_.
 
-  - **threshold_low/threshold_high** (**Required**, float): Specifies a high/low 
+  - **threshold_high/threshold_low** (**Required**, float): Specifies a high/low
-    threshold defining the deadband 
+    threshold defining the deadband around the target temperature. For instance with
-    around the target temperature. For instance with `default_target_temperature` of ``21°C`` and 
+    ``default_target_temperature`` of ``21°C`` and thresholds of ``+/-0.5°C``, the deadband will be
-    thresholds of ``+/-0.5°C``, the deadband will be 
     between ``20.5°C - 21.5°C``. The PID controller will limit output changes within the deadband.
+  - **kp_multiplier** (*Optional*, float): Set the ``kp`` gain when inside the deadband. Defaults to ``0``.
+  - **ki_multiplier** (*Optional*, float): Set the ``ki`` gain when inside the deadband. Defaults to ``0``.
+  - **kd_multiplier** (*Optional*, float): Set the ``kd`` gain when inside the deadband. Recommended this
+    is set to ``0``. Defaults to ``0``.
 
-  - **kp_multiplier** (**Optional**, float): Set the ``kp`` gain when inside the deadband. Defaults to ``0``.
+  - **deadband_output_averaging_samples** (*Optional*, int): Typically when inside the deadband the PID Controller has
-  - **ki_multiplier** (**Optional**, float): Set the ``ki`` gain when inside the deadband. Defaults to ``0``.
+    reached a state of equilibrium, so it advantageous to use a higher number of output samples
-  - **kd_multiplier** (**Optional**, float): Set the ``kd`` gain when inside the deadband. Recommended this
-    is set to 0. Defaults to ``0``.
-
-  - **deadband_output_averaging_samples** (**Optional**, int): Typically when inside the deadband the PID Controller has 
-    reached a state of equilibrium, so it advantageous to use a higher number of output samples 
     like 10-30 samples. Defaults to ``1`` which is no sampling/averaging.
 
 - All other options from :ref:`Climate <config-climate>`.
@@ -116,7 +114,7 @@ To set up a PID climate controller, you need a couple of components:
 
 - A :ref:`Sensor <config-sensor>` to read the current temperature (``sensor``).
 - At least one :ref:`float output <config-output>` to drive for heating or cooling (or both).
-  This could for example be a PWM output via :doc:`/components/output/sigma_delta` or :doc:`/components/output/slow_pwm` that drives a heating unit.
+  This could for example be a PWM output via :doc:`/components/output/sigma_delta_output` or :doc:`/components/output/slow_pwm` that drives a heating unit.
 
   Please note the output *must* be controllable with continuous value (not only ON/OFF, but any state
   in between for example 50% heating power).
@@ -126,22 +124,22 @@ To set up a PID climate controller, you need a couple of components:
     The sensor should have a short update interval. The PID update frequency is tied to the update
     interval of the sensor. Set a short ``update_interval`` like ``5s`` on the sensor.
 
-    We recommend putting a filter on the sensor (see filters in :doc:`/components/sensor/index`) and 
+    We recommend putting a filter on the sensor (see filters in :doc:`/components/sensor/index`) and
     using ``output_averaging_samples`` to calm the PID sensor from a noisy input sensor.
 
 Deadband Setup
 --------------
-A deadband is used to prevent the PID controller from further adjusting the power 
+A deadband is used to prevent the PID controller from further adjusting the power
-once the temperature has settled within a range of the target temperature. 
+once the temperature has settled within a range of the target temperature.
 
-We do this by specifying a high/low threshold of the target temperature. 
+We do this by specifying a high/low threshold of the target temperature.
 
-To understand the benefit, consider a heating/cooling HVAC which is constantly 
+To understand the benefit, consider a heating/cooling HVAC which is constantly
-oscillating between heating and cooling as the thermostat records very minor 
+oscillating between heating and cooling as the thermostat records very minor
-changes from +0.1º to -0.1º. Clearly this is undesirable and will cause wear 
+changes from +0.1º to -0.1º. Clearly this is undesirable and will cause wear
-and tear as the HVAC oscillates.  With a deadband in place the heater won't 
+and tear as the HVAC oscillates.  With a deadband in place the heater won't
-activate until the thermostat breaches the low_threshold and the cooler won't activate 
+activate until the thermostat breaches the low_threshold and the cooler won't activate
-until the thermostat breaches the high_threshold. 
+until the thermostat breaches the high_threshold.
 
 The most basic setup specifies the threshold around the target temperature as follows:
 
@@ -153,7 +151,7 @@ The most basic setup specifies the threshold around the target temperature as fo
       threshold_high: 0.5°C
       threshold_low: -1.0°C
 
-In this example the deadband is between ``20.0°C - 21.5°C``. The PID controller will limit any output 
+In this example the deadband is between ``20.0°C - 21.5°C``. The PID controller will limit any output
 variation inside this deadband. How it limits depends on how you set the `Deadband Multipliers`_.
 
 .. figure:: images/deadband1.png
@@ -161,19 +159,19 @@ variation inside this deadband. How it limits depends on how you set the `Deadba
 Deadband Multipliers
 ********************
 
-Deadband Multipliers tell the controller how to operate when inside of the deadband. 
+Deadband Multipliers tell the controller how to operate when inside of the deadband.
 
-Each of the p,i and d terms can be controlled using the kp, ki and kd multipliers. For instance, if the kp_multiplier 
+Each of the p,i and d terms can be controlled using the kp, ki and kd multipliers. For instance, if the kp_multiplier
-is set to 0.05 then the final proportional term will be set to 5% of its normal value within the deadband. 
+is set to 0.05 then the final proportional term will be set to 5% of its normal value within the deadband.
 
-If all of the multipliers are set to 0, then the controller will not adjust power at all within the 
+If all of the multipliers are set to 0, then the controller will not adjust power at all within the
 deadband. This is the default behavior.
 
-Most deadband implementations set kp and ki multipliers to a small gain like ``0.05`` and set 
+Most deadband implementations set kp and ki multipliers to a small gain like ``0.05`` and set
-derivative to 0. This means that the PID output will calmly make minor adjustments over a 20x longer 
+derivative to 0. This means that the PID output will calmly make minor adjustments over a 20x longer
-timeframe to stay within the deadband zone. 
+timeframe to stay within the deadband zone.
 
-To start with we recommend just setting the ``ki_multiplier`` to ``0.05`` (5%). Then 
+To start with we recommend just setting the ``ki_multiplier`` to ``0.05`` (5%). Then
 set ``kp_multiplier`` to ``0.05`` (5%) if the controller is falling out of the deadband too often.
 
 .. code-block:: yaml
@@ -184,7 +182,7 @@ set ``kp_multiplier`` to ``0.05`` (5%) if the controller is falling out of the d
       threshold_high: 0.5°C
       threshold_low: -1.0°C
       kp_multiplier: 0.0   # proportional gain turned off inside deadband
-      ki_multiplier: 0.05  # integral accumulates at only 5% of normal ki 
+      ki_multiplier: 0.05  # integral accumulates at only 5% of normal ki
       kd_multiplier: 0.0   # derviative is turned off inside deadband
       deadband_output_averaging_samples: 15   # average the output over 15 samples within the deadband
 
@@ -192,8 +190,8 @@ set ``kp_multiplier`` to ``0.05`` (5%) if the controller is falling out of the d
 
 Deadband Output Averaging Samples
 *********************************
-Since we expect the PID Controller to be at equilibrium while inside the deadband, we can 
+Since we expect the PID Controller to be at equilibrium while inside the deadband, we can
-average the output over a longer range of samples, like 15 samples. This helps even further 
+average the output over a longer range of samples, like 15 samples. This helps even further
 with temperature and controller stability.
 
 .. _pid-autotune:
@@ -249,7 +247,7 @@ is automatically calculated. To do this, it needs to observe at least 3 oscillat
     device can reach. For example if the temperature of a room is to be controlled, the setpoint needs
     to be above the ambient temperature. If the ambient temperature is 20°C, the setpoint of the
     climate device should be set to at least ~24°C so that an oscillation can be induced.
-    
+
     Also take care of external influences, like for example when room temperature is severely affected by
     outdoor weather like sun, if it starts to warm up the room in parallel with the heating
     autotune will likely fail or give false results.
@@ -273,10 +271,10 @@ is automatically calculated. To do this, it needs to observe at least 3 oscillat
 .. note::
 
     In the output above, the autotuner is driving the heating output at 100% and trying to reach 24.25 °C.
-    
+
     This will continue for some time until data for 3 phases (6 crossings of the setpoint; or a bit more, depending on
     the data quality) have been acquired.
-    
+
     The autotune algorithm may take a long time to complete, it depends on the time needed to reproduce the
     heating up and cooling down oscillations the required number of times.
 
@@ -298,7 +296,7 @@ is automatically calculated. To do this, it needs to observe at least 3 oscillat
 
 As soon as the the autotune procedure finishes, the climate starts to work with the calculated parameters
 so that expected operation can be immediately verified.
-   
+
 If satisfied, copy the values in ``control_parameters`` into your configuration:
 
    .. code-block:: yaml
@@ -349,7 +347,7 @@ Configuration variables:
   Defaults to ``-1.0``.
 
 The ``positive_output`` and ``negative_output`` parameters can be used to compensate the heating or the
-cooling process during the autotune, in the cases when they are not changing the temperature at the 
+cooling process during the autotune, in the cases when they are not changing the temperature at the
 same rate, resulting in a not symmetrical oscillation. The autotune result will print a message when
 it's recommended to repeat the entire procedure with such parameters configured.
 
@@ -435,7 +433,7 @@ See Also
 - Åström, K. J. and T. Hägglund (1984a), 'Automatic tuning of simple regulators',
   Proceedings of IFAC 9th World Congress, Budapest, 1867-1872
 - :doc:`/components/climate/index`
-- :doc:`/components/output/sigma_delta`
+- :doc:`/components/output/sigma_delta_output`
 - :doc:`/components/output/slow_pwm`
 - `Principles of PID <https://blog.opticontrols.com/archives/344>`__
 - :apiref:`pid/pid_climate.h`

components/cover/custom.rst

@@ -30,6 +30,7 @@ two methods:
         traits.set_is_assumed_state(false);
         traits.set_supports_position(true);
         traits.set_supports_tilt(false);
+        traits.set_supports_stop(true);
         return traits;
       }
       void control(const CoverCall &call) override {

components/deep_sleep.rst

@@ -32,7 +32,7 @@ even Over The Air updates.
 
 .. note::
 
-    ESP8266 that have an onboard USB chip (e.g. D1 mini) one the chips' control lines is connected to the RST pin. This enables the flasher can reboot the ESP when required. This may interfere with deep sleep on some devices and prevent the ESP from waking when it's powered through its USB connector. Powering the ESP from a separate 3.3V source connected to the 3.3V pin and GND will solve this issue. In these cases using a USB to TTL adapter will allow you to log ESP activity. 
+    Some ESP8266s have an onboard USB chip (e.g. D1 mini) on the chips' control line that is connected to the RST pin. This enables the flasher to reboot the ESP when required. This may interfere with deep sleep on some devices and prevent the ESP from waking when it's powered through its USB connector. Powering the ESP from a separate 3.3V source connected to the 3.3V pin and GND will solve this issue. In these cases, using a USB to TTL adapter will allow you to log ESP activity. 
     
 Configuration variables:
 ------------------------

components/display/ili9xxx.rst

@@ -33,7 +33,6 @@ beyond the typical SPI connections, it is better suited for use with the ESP32.
     display:
       - platform: ili9xxx
         model: ili9341
-        cs_pin: 14
         dc_pin: 27
         reset_pin: 33
         lambda: |-
@@ -48,7 +47,6 @@ Configuration variables:
   - ``M5STACK``, ``TFT 2.4``, ``TFT 2.4R`` 
   - ``ILI9341``, ``ILI9342``, ``ILI9481``, ``ILI9486``, ``ILI9488``, ``ST7796``
 
-- **cs_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The CS pin.
 - **dc_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The DC pin.
 - **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
 - **rotation** (*Optional*): Set the rotation of the display. Everything drawn in the ``lambda:`` will be rotated
@@ -66,6 +64,7 @@ Configuration variables:
   - ``GRAYSCALE``
   - ``IMAGE_ADAPTIVE``
 - **color_palette_images** (*Optional*): A list of image files that will be used to generate the color pallet for the display.  This should only be used in conjunction with ``-color_palette: IMAGE_ADAPTIVE`` above.  The images will be analysed at compile time and a custom color pallet will be created based on the most commonly occuring colors.  A typical setting would be a sample image that represented the fully populated display.  This can significantly improve the quality of displayed images.  Note that these images are not stored on the ESP device, just the 256byte color pallet created from them.
+- **dimensions** (*Optional*): Dimensions of the screen with WIDTHxHEIGHT. Usually not needed since ``model:`` has good defaults.
 
 Configuration examples
 **********************
@@ -140,7 +139,6 @@ To configure an image adaptive color pallet to show greater than 8 bit color dep
     display:
       - platform: ili9xxx
         model: ili9341
-        cs_pin: 5
         dc_pin: 4
         reset_pin: 22
         rotation: 90

components/display/index.rst

@@ -660,22 +660,35 @@ Use this component to store graphical images on the device, you can then draw th
         id: my_image
         resize: 100x100
 
+.. code-block:: yaml
+
+    image:
+      - file: mdi:alert-outline
+        id: alert
+        resize: 80x80
+
 Configuration variables:
 
-- **file** (**Required**, string): The path (relative to where the .yaml file is) of the image file.
+- **file** (**Required**, string):
+
+  - **Local files**: The path (relative to where the .yaml file is) of the image file.
+  - **Material Design Icons**: Specify the `Material Design Icon <https://pictogrammers.com/library/mdi/>`_ id in the format ``mdi:icon-name``, and that icon will automatically be downloaded and added to the configuration.
 - **id** (**Required**, :ref:`config-id`): The ID with which you will be able to reference the image later
   in your display code.
 - **resize** (*Optional*, string): If set, this will resize the image to fit inside the given dimensions ``WIDTHxHEIGHT``
   and preserve the aspect ratio.
-- **type** (*Optional*): Specifies how to encode image internally. Defaults to ``BINARY``.
+- **type** (*Optional*): Specifies how to encode image internally. Defaults to ``BINARY`` for local images and ``TRANSPARENT_BINARY`` for MDIs.
 
   - ``BINARY``: Two colors, suitable for 1 color displays or 2 color image in color displays. Uses 1 bit
     per pixel, 8 pixels per byte.
-  - ``GRAYSCALE``: Full scale grey. Uses 8 bits per pixel, 1 pixel per byte.
-  - ``RGB24``: Full RGB color stored. Uses 3 bytes per pixel.
-  - ``RGB565``: Lossy RGB color stored. Uses 2 bytes per pixel.
   - ``TRANSPARENT_BINARY``: One color, any pixel that is fully transparent will not be drawn, and any other pixel
     will be the on color. Uses 1 bit per pixel, 8 pixels per byte.
+  - ``GRAYSCALE``: Full scale grey. Uses 8 bits per pixel, 1 pixel per byte.
+  - ``RGB565``: Lossy RGB color stored. Uses 2 bytes per pixel.
+  - ``RGB24``: Full RGB color stored. Uses 3 bytes per pixel.
+  - ``RGBA``: Full RGB color stored. Uses 4 bytes per pixel. Any pixel with an alpha value < 127 will not be drawn.
+
+- **use_transparency** (*Optional*): If set the alpha channel of the input image will be taken into account, and pixels with alpha < 127 will not be drawn. For image types without explicit alpha channel, the color (0, 0, 1) (very dark blue) will be mapped to black, to be able to store transparency information within the image. Explicitly transparent types (``TRANSPARENT_BINARY`` and ``RGBA``) default to ``True`` and cannot be set to ``False``; other types default to ``False``.
 
 - **dither** (*Optional*): Specifies which dither method used to process the image, only used in GRAYSCALE and BINARY type image. Defaults to ``NONE``. You can read more about it `here <https://pillow.readthedocs.io/en/stable/reference/Image.html?highlight=Dither#PIL.Image.Image.convert>`__ and `here <https://en.wikipedia.org/wiki/Dither>`__.
 
@@ -687,6 +700,9 @@ Configuration variables:
     To use images you will need to have the python ``pillow`` package installed.
     If you're running this as a Home Assistant add-on or with the official ESPHome docker image, it should already be
     installed. Otherwise you need to install it using ``pip install pillow``.
+    Additionally, if you want to use SVG images (including MDI images), you will additionally need to have the python ``cairosvg`` package installed.
+    If you're running this as a Home Assistant add-on or with the official ESPHome docker image, it should also already be
+    installed. Otherwise you need to install it using ``pip install cairosvg``.
 
 And then later in code:
 
@@ -769,9 +785,19 @@ Configuration variables:
 
   - ``BINARY``: Two colors, suitable for 1 color displays or 2 color image in color displays. Uses 1 bit
     per pixel, 8 pixels per byte.
+  - ``TRANSPARENT_BINARY``: One color, any pixel that is fully transparent will not be drawn, and any other pixel
+    will be the on color. Uses 1 bit per pixel, 8 pixels per byte.
   - ``GRAYSCALE``: Full scale grey. Uses 8 bits per pixel, 1 pixel per byte.
-  - ``RGB24``: Full RGB color stored. Uses 3 bytes per pixel.
   - ``RGB565``: Lossy RGB color stored. Uses 2 bytes per pixel.
+  - ``RGB24``: Full RGB color stored. Uses 3 bytes per pixel.
+  - ``RGBA``: Full RGB color stored. Uses 4 bytes per pixel. Any pixel with an alpha value < 127 will not be drawn.
+
+- **use_transparency** (*Optional*): If set the alpha channel of the input image will be taken into account, and pixels with alpha < 127 will not be drawn. For image types without explicit alpha channel, the color (0, 0, 1) (very dark blue) will be mapped to black, to be able to store transparency information within the image. Explicitly transparent types (``TRANSPARENT_BINARY`` and ``RGBA``) default to ``True`` and cannot be set to ``False``; other types default to ``False``.
+- **loop** (*Optional*): If you want to loop over a subset of your animation (e.g. a fire animation where the fire "starts", then "burns" and "dies") you can specify some frames to loop over.
+
+  - **start_frame** (*Optional*, int): The frame to loop back to when ``end_frame`` is reached. Defaults to the first frame in the animation.
+  - **end_frame** (*Optional*, int): The last frame to show in the loop; when this frame is reached it will loop back to ``start_frame``. Defaults to the last frame in the animation.
+  - **repeat** (*Optional*, int): Specifies how many times the loop will run. When the count is reached, the animation will continue with the next frame after ``end_frame``, or restart from the beginning if ``end_frame`` was the last frame. Defaults to "loop forever".
 
 .. _display-pages:
 

components/display/st7789v.rst

@@ -70,6 +70,7 @@ Configuration variables:
   - ``TTGO TDisplay 135x240``
   - ``Adafruit Funhouse 240x240``
   - ``Adafruit RR 280x240`` (round-rectangular display -- some pixels are "deleted" from corners to form rounded shape)
+  - ``Adafruit S2 TFT FEATHER 240X135`` (requires ``power_supply`` be specified, see below)
   - ``Custom`` (see details below)
 
 - **cs_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The CS pin.
@@ -86,6 +87,10 @@ Configuration variables:
 - **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.
+- **power_supply** (*Optional*, :ref:`config-id`): The :doc:`power supply </components/power_supply>` to connect to
+  this display. The power supply will be turned on before attempting to initialize the display. When ``model`` is set
+  to "Adafruit S2 TFT FEATHER 240X135" this option is required as there are variations of this board sold with differing
+  pin assignments.
 - **lambda** (*Optional*, :ref:`lambda <config-lambda>`): The lambda to use for rendering the content on the display.
   See :ref:`display-engine` for more information.
 - **update_interval** (*Optional*, :ref:`config-time`): The interval to re-draw the screen. Defaults to ``5s``.
@@ -271,5 +276,6 @@ See Also
 --------
 
 - :doc:`index`
+- :doc:`Power Supply Component </components/power_supply>`
 - :apiref:`st7789v_base/st7789v_base.h`
 - :ghedit:`Edit`

components/esp32_ble_tracker.rst

@@ -108,7 +108,9 @@ This automation will be triggered when a Bluetooth advertising is received. A va
 
     esp32_ble_tracker:
       on_ble_advertise:
-        - mac_address: 11:22:33:44:55:66
+        - mac_address: 
+            - 11:11:11:11:11:11
+            - 22:22:22:22:22:22
           then:
             - lambda: |-
                 ESP_LOGD("ble_adv", "New BLE device");
@@ -129,7 +131,7 @@ This automation will be triggered when a Bluetooth advertising is received. A va
 
 Configuration variables:
 
-- **mac_address** (*Optional*, MAC Address): The MAC address to filter for this automation.
+- **mac_address** (*Optional*, list of MAC Address): The MAC address to filter for this automation.
 - See :ref:`Automation <automation>`.
 
 .. _esp32_ble_tracker-on_ble_manufacturer_data_advertise:

components/fan/binary.rst

@@ -14,10 +14,18 @@ The ``binary`` fan platform lets you represent any binary :ref:`output` as a fan
 .. code-block:: yaml
 
     # Example configuration entry
+    output:
+      - id: fan_output
+        platform: gpio
+        pin: GPIO16
+        
     fan:
       - platform: binary
-        output: my_output_1
+        output: fan_output
         name: "Living Room Fan"
+        
+        
+        
 
 Configuration variables:
 ------------------------

components/i2s_audio.rst

@@ -20,8 +20,9 @@ This component only works on ESP32 based chips.
 Configuration variables:
 ------------------------
 
-- **i2s_lrclk_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The GPIO pin to use for the I²S ``LRCLK`` *(Left/Right Clock)* signal, also referred to as ``WS`` *(Word Select)* or ``FS`` *(Frame Sync)*.
+- **i2s_lrclk_pin** (**Required**, :ref:`config-pin`): The GPIO pin to use for the I²S ``LRCLK`` *(Left/Right Clock)* signal, also referred to as ``WS`` *(Word Select)* or ``FS`` *(Frame Sync)*.
-- **i2s_bclk_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The GPIO pin to use for the I²S ``BCLK`` *(Bit Clock)* signal, also referred to as ``SCK`` *(Serial Clock)*.
+- **i2s_bclk_pin** (*Optional*, :ref:`config-pin`): The GPIO pin to use for the I²S ``BCLK`` *(Bit Clock)* signal, also referred to as ``SCK`` *(Serial Clock)*.
+- **i2s_mclk_pin** (*Optional*, :ref:`config-pin`): The GPIO pin to use for the I²S ``MCLK`` *(Master Clock)* signal.
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this I²S bus if you need multiple.
 
 See also

components/index.rst

@@ -26,4 +26,5 @@ Components
     microphone/index
     speaker/index
     time/index
+    alarm_control_panel/index
     *

components/light/fastled.rst

@@ -20,6 +20,12 @@ FastLED Light
     - https://github.com/FastLED/FastLED/issues/1322
     - https://github.com/FastLED/FastLED/issues/1264
 
+.. warning::
+
+    FastLED does **not** work with ESP-IDF.
+
+    For addressable lights, you can use :doc:`esp32_rmt_led_strip`.
+
 .. _fastled-clockless:
 
 Clockless

components/light/neopixelbus.rst

@@ -5,6 +5,12 @@ NeoPixelBus Light
     :description: Instructions for setting up Neopixel addressable lights.
     :image: color_lens.svg
 
+.. warning::
+
+    NeoPixelBus does **not** work with ESP-IDF.
+
+    For addressable lights, you can use :doc:`esp32_rmt_led_strip`.
+
 The ``neopixelbus`` light platform allows you to create RGB lights
 in ESPHome for an individually addressable lights like NeoPixel or WS2812.
 

components/light/rp2040_pio_led_strip.rst

@@ -0,0 +1,63 @@
+RP2040 PIO LED Strip
+====================
+
+.. seo::
+    :description: Instructions for setting up addressable lights like NEOPIXEL on an RP2040 using the PIO peripheral.
+    :image: color_lens.svg
+
+This is a component using the RP2040 PIO peripheral to drive most addressable LED strips.
+
+.. code-block:: yaml
+
+    light:
+  - platform: rp2040_pio_led_strip
+        name: led_strip
+        id: led_strip
+        pin: GPIO13
+        num_leds: 10
+        pio: 0
+        rgb_order: GRB
+        chipset: WS2812B
+
+Configuration variables
+-----------------------
+
+- **pin** (**Required**, :ref:`config-pin`): The pin for the data line of the light.
+- **num_leds** (**Required**, int): The number of LEDs in the strip.
+- **pio** (**Required**, int): The PIO peripheral to use. If using multiple strips, you can use up to 4 strips per PIO. Must be one of ``0`` or ``1``.
+
+- **chipset** (**Required**, enum): The chipset to apply known timings from.
+    - ``WS2812``
+    - ``WS2812B``
+    - ``SK6812``
+    - ``SM16703``
+
+- **rgb_order** (**Required**, string): The RGB order of the strip.
+    - ``RGB``
+    - ``RBG``
+    - ``GRB``
+    - ``GBR``
+    - ``BGR``
+    - ``BRG``
+
+- **is_rgbw** (*Optional*, boolean): Set to ``true`` if the strip is RGBW. Defaults to ``false``.
+
+
+
+Manual Timings
+**************
+
+These can be used if you know the timings and your chipset is not set above. If you have a new specific chipset,
+please consider adding support to the codebase and add it to the list above.
+
+- **bit0_high** (*Optional*, :ref:`config-time`): The time to hold the data line high for a ``0`` bit.
+- **bit0_low** (*Optional*, :ref:`config-time`): The time to hold the data line low for a ``0`` bit.
+- **bit1_high** (*Optional*, :ref:`config-time`): The time to hold the data line high for a ``1`` bit.
+- **bit1_low** (*Optional*, :ref:`config-time`): The time to hold the data line low for a ``1`` bit.
+
+See Also
+--------
+
+- :doc:`/components/light/index`
+- :doc:`/components/power_supply`
+- :ghedit:`Edit`

components/matrix_keypad.rst

@@ -7,8 +7,8 @@ Matrix keypad
     :description: Matrix key input panel
 
 The ``matrix_keypad`` component allows you to integrate pads which
-have the keys connected at the intersection points of the rows and columns 
+have the keys connected at the intersection points of the rows and columns
-of a matrix. 
+of a matrix.
 
 .. figure:: ../images/matrix_keypad.jpg
     :align: center
@@ -44,14 +44,14 @@ Configuration variables:
 - **columns** (**Required**, list): A list of :ref:`pins <config-pin_schema>` where the vertical
   matrix lines are connected, in order from left to right.  These pins need to be input capable
   with pullups enabled.  If there is no internal pullup, then an external one is required.
-- **keys** (*Optional*, string): The keys present on the matrix, from top left to bottom right, 
+- **keys** (*Optional*, string): The keys present on the matrix, from top left to bottom right,
   row by row. Required for ``key_collector`` and ``binary_sensor`` (if using key selection).
-- **has_diodes** (*Optional*, boolean): For pads where row pins are outputs, and the keys are 
+- **has_diodes** (*Optional*, boolean): For pads where row pins are outputs, and the keys are
   connected with diodes. Defaults to ``false``.
 
 
-Binary Sensors
+Binary Sensor
---------------
+-------------
 
 Individual keys can be added independently to ESPHome as ``binary_sensor``:
 
@@ -82,7 +82,7 @@ Either the ``row`` and ``col`` parameters, or the ``key`` parameter has to be pr
 
 .. note::
 
-    Automatic handling of multiple keys (e.g. PIN code entry) is possible with the 
+    Automatic handling of multiple keys (e.g. PIN code entry) is possible with the
     the :ref:`Key Collector <key_collector>` component.
 
 See Also

components/mdns.rst

@@ -48,7 +48,7 @@ Configuration variables:
 - **disabled** (*Optional*, boolean): Set to true to disable mDNS usage. Defaults to false.
 - **services** (*Optional*, list): List of additional services to expose.
 
-  - **service** (*Required*, string): Name of extra service
+  - **service** (**Required**, string): Name of extra service.
-  - **protocol** (*Required*, string): Protocol of service (_udp or _tcp)
+  - **protocol** (**Required**, string): Protocol of service (_udp or _tcp).
-  - **port** (*Optional*, int): Port number of extra service
+  - **port** (*Optional*, int): Port number of extra service.
-  - **txt** (*Optional*, mapping): Additional text records to add to service
+  - **txt** (*Optional*, mapping): Additional text records to add to service.

components/media_player/i2s_audio.rst

@@ -1,4 +1,4 @@
-I2S Audio Media Player
+I²S Audio Media Player
 ======================
 
 .. seo::
@@ -35,6 +35,9 @@ External DAC
 - **mute_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The GPIO pin to use to mute the media player.
 - **mode** (*Optional*, string): The mode of the I²S bus. Can be ``mono`` or ``stereo``. Defaults to ``mono``.
 - **i2s_audio_id** (*Optional*, :ref:`config-id`): The ID of the :ref:`I²S Audio <i2s_audio>` you wish to use for this media player.
+- **i2s_comm_fmt** (*Optional*, string): I2S communication format. By default MSB format is used (AC101, PCM5102A). 
+  Set to ``lsb`` if using an external DAC that uses Japanese (Least Significant Bit Justified) format (like PT8211). 
+  Can be ``msb`` or ``lsb``. Defaults to ``msb``.
 
 For best results, keep the wires as short as possible.
 

components/microphone/i2s_audio.rst

@@ -32,6 +32,9 @@ Configuration variables:
   - ``internal``: Use the internal ADC of the ESP32. Only supported on ESP32, no variant support.
 
 - **channel** (*Optional*, enum): The channel of the microphone. One of ``left`` or ``right``. Defaults to ``right``.
+- **bits_per_sample** (*Optional*, enum): The bit depth of the audio samples. Note that while set to ``32bit``, the samples
+  will be scaled down to 16bit before being forwarded.
+  One of ``16bit`` or ``32bit``. Defaults to ``16bit``.
 - **i2s_audio_id** (*Optional*, :ref:`config-id`): The ID of the :ref:`I²S Audio <i2s_audio>` you wish to use for this microphone.
 - All other options from :ref:`Microphone <config-microphone>`
 

components/output/index.rst

@@ -98,7 +98,7 @@ This action turns the output with the given ID off when executed.
 ***************************
 
 This action sets the float output to the given level when executed. Note: This only
-works with floating point outputs like :doc:`/components/output/esp8266_pwm`, :doc:`/components/output/ledc`, :doc:`/components/output/sigma_delta`, :doc:`/components/output/slow_pwm`.
+works with floating point outputs like :doc:`/components/output/esp8266_pwm`, :doc:`/components/output/ledc`, :doc:`/components/output/sigma_delta_output`, :doc:`/components/output/slow_pwm`.
 
 .. code-block:: yaml
 

components/output/slow_pwm.rst

@@ -70,7 +70,7 @@ Example:
 .. note::
 
     If the duty cycle is not constrained to a maximum value, the
-    :doc:`/components/output/sigma_delta` component offers faster updates and
+    :doc:`/components/output/sigma_delta_output` component offers faster updates and
     greater control over the switching frequency. This is better for loads that
     need some time to fully change between on and off, like eletric thermal
     actuator heads or fans.
@@ -81,7 +81,7 @@ See Also
 - :doc:`/components/output/index`
 - :doc:`/components/output/esp8266_pwm`
 - :doc:`/components/output/ledc`
-- :doc:`/components/output/sigma_delta`
+- :doc:`/components/output/sigma_delta_output`
 - :doc:`/components/light/monochromatic`
 - :doc:`/components/fan/speed`
 - :doc:`/components/power_supply`

components/prometheus.rst

@@ -71,5 +71,9 @@ Set the ``id`` and ``name`` label values of the Prometheus metric for the sensor
 See Also
 --------
 
+- :doc:`/components/web_server`
+- :ref:`api-rest`
+- :doc:`/components/http_request`
 - :apiref:`prometheus/prometheus_handler.h`
+- `Prometheus <https://prometheus.io/>`__
 - :ghedit:`Edit`

components/remote_receiver.rst

@@ -204,13 +204,13 @@ Remote code selection (exactly one of these has to be included):
 - **canalsat**: Trigger on a decoded CanalSat remote code with the given data.
 
   - **device** (**Required**, int): The device to trigger on, see dumper output for more info.
-  - **address** (**Optional**, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0``
+  - **address** (*Optional*, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0``
   - **command** (**Required**, int): The command to listen for.
 
 - **canalsatld**: Trigger on a decoded CanalSatLD remote code with the given data.
 
   - **device** (**Required**, int): The device to trigger on, see dumper output for more info.
-  - **address** (**Optional**, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0``
+  - **address** (*Optional*, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0``
   - **command** (**Required**, int): The command to listen for.
 
 - **coolix**: Trigger on a decoded Coolix remote code with the given data.

components/remote_transmitter.rst

@@ -122,7 +122,7 @@ This :ref:`action <config-action>` sends a CanalSat infrared remote code to a re
 Configuration variables:
 
 - **device** (**Required**, int): The device to send to, see dumper output for more details.
-- **address** (**Optional**, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0``
+- **address** (*Optional*, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0``
 - **command** (**Required**, int): The command to send.
 - All other options from :ref:`remote_transmitter-transmit_action`.
 
@@ -149,7 +149,7 @@ This :ref:`action <config-action>` sends a CanalSatLD infrared remote code to a
 Configuration variables:
 
 - **device** (**Required**, int): The device to send to, see dumper output for more details.
-- **address** (**Optional**, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0``
+- **address** (*Optional*, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0``
 - **command** (**Required**, int): The command to send.
 - All other options from :ref:`remote_transmitter-transmit_action`.
 
@@ -283,7 +283,7 @@ This :ref:`action <config-action>` sends a 40-bit Midea code to a remote transmi
     on_...:
       - remote_transmitter.transmit_midea:
           code: [0xA2, 0x08, 0xFF, 0xFF, 0xFF]
-    
+
     on_...:
       - remote_transmitter.transmit_midea:
           code: !lambda |-

components/rtttl.rst

@@ -55,7 +55,7 @@ Plays an rtttl tone.
 
     on_...:
       then:
-        - rtttl.play: 'MissionImp:d=16,o=6,b=95:32d,32d#,32d,32d#,32d,32d#,32d,32d#,32d,32d,32d#,32e,32f,32f#,32g,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,a#,g,2d,32p,a#,g,2c#,32p,a#,g,2c,a#5,8c,2p,32p,a#5,g5,2f#,32p,a#5,g5,2f,32p,a#5,g5,2e,d#,8d'
+        - rtttl.play: 'siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e'
 
 Configuration options:
 
@@ -101,15 +101,17 @@ This Condition returns true while playback is active.
 Common beeps
 ------------
 
-You can do your own beep patterns too! Here are a few I made so you can just use right away or tweak them to your
+You can do your own beep patterns too! Here's a short collection so you can just use right away or tweak them to your like:
-like:
 
 .. code-block:: yaml
 
-    two short:d=4,o=5,b=100:16e6,16e6
+    two_short:d=4,o=5,b=100:16e6,16e6
     long:d=1,o=5,b=100:e6
     siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e
     scale_up:d=32,o=5,b=100:c,c#,d#,e,f#,g#,a#,b
+    star_wars:d=16,o=5,b=100:4e,4e,4e,8c,p,g,4e,8c,p,g,4e,4p,4b,4b,4b,8c6,p,g,4d#,8c,p,g,4e,8p
+    mission_imp:d=16,o=6,b=95:32d,32d#,32d,32d#,32d,32d#,32d,32d#,32d,32d,32d#,32e,32f,32f#,32g,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,a#,g,2d,32p,a#,g,2c#,32p,a#,g,2c,a#5,8c,2p,32p,a#5,g5,2f#,32p,a#5,g5,2f,32p,a#5,g5,2e,d#,8d
+    mario:d=4,o=5,b=100:16e6,16e6,32p,8e6,16c6,8e6,8g6,8p,8g,8p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,16p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16c7,16p,16c7,16c7,p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16d#6,8p,16d6,8p,16c6
 
 
 Test setup
@@ -120,7 +122,7 @@ E.g. for calling ``rtttl.play`` select the service ``esphome.test_esp8266_rtttl_
 
 .. code-block:: yaml
 
-    song_str: "mario:d=4,o=5,b=100:16e6,16e6,32p,8e6,16c6,8e6,8g6,8p,8g,8p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,16p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16c7,16p,16c7,16c7,p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16d#6,8p,16d6,8p,16c6"
+    song_str: 'scale_up:d=32,o=5,b=100:c,c#,d#,e,f#,g#,a#,b'
 
 Sample code
 ***********

components/sensor/ads1115.rst

@@ -96,8 +96,8 @@ Configuration variables:
 -  **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
 -  **resolution** (*Optional*, string): the resolution of this sensor. Defaults to ``16 bits``.
 
-  - **16 bits**
+  - ``16 bits``
-  - **12 bits**
+  - ``12 bits``
 
 
 Multiplexer and Gain
@@ -105,10 +105,10 @@ Multiplexer and Gain
 
 .. note::
 
-    As per (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) Section 7.3 Note 2: 
+    As per (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) Section 7.3 Note 2:
     "No more than VDD + 0.3V must be applied to the analog inputs of the device."
     This means if you power the device with 3.3V, take care not to supply the 4 AIN pins with more than 3.6V.
-    
+
 The ADS1115 has a multiplexer that can be configured to measure voltage between several pin configurations. These are:
 
  - ``A0_A1`` (between Pin 0 and Pin 1)
@@ -128,11 +128,11 @@ Additionally, the ADS1115 has a Programmable Gain Amplifier (PGA) that can help
  - ``1.024`` (measures up to 1.024V)
  - ``0.512`` (measures up to 0.512V)
  - ``0.256`` (measures up to 0.256V)
- 
+
 The ADS1115 can be used with defaults settings.
 When using an ADS1015, the resolution has to be specified and should be defined to ``12_BITS``
 (or equivalent notations like ``12 BITS`` or ``12 bits``).
- 
+
 See Also
 --------
 

components/sensor/ee895.rst

@@ -36,19 +36,19 @@ The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for thi
 Configuration variables:
 ------------------------
 
-- **temperature** (*Required*): The information for the Temperature sensor.
+- **temperature** (**Required**): The information for the Temperature sensor.
 
   - **name** (**Required**, string): The name for the temperature sensor.
   - **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
   - All other options from :ref:`Sensor <config-sensor>`.
 
-- **co2** (*Required*): The information for the CO₂ sensor.
+- **co2** (**Required**): The information for the CO₂ sensor.
 
   - **name** (**Required**, string): The name for the CO₂eq sensor.
   - **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
   - All other options from :ref:`Sensor <config-sensor>`.
 
-- **Pressure** (*Required*): The information for the Pressure sensor.
+- **pressure** (**Required**): The information for the Pressure sensor.
 
   - **name** (**Required**, string): The name for the Pressure sensor.
   - **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.

components/sensor/hmc5883l.rst

@@ -26,7 +26,7 @@ for this sensor to work.
     # Example configuration entry
     sensor:
       - platform: hmc5883l
-        address: 0x68
+        address: 0x1E
         field_strength_x:
           name: "HMC5883L Field Strength X"
         field_strength_y:

components/sensor/index.rst

@@ -415,7 +415,7 @@ Configuration variables:
 ``skip_initial``
 ****************
 
-A simple skip filter; `skip_initial: N` skips the first `N` sensor readings and passes on the
+A simple skip filter; ``skip_initial: N`` skips the first ``N`` sensor readings and passes on the
 rest. This can be used when the sensor needs a few readings to 'warm up'. After the initial
 readings have been skipped, this filter does nothing.
 

components/sensor/internal_temperature.rst

@@ -12,7 +12,7 @@ temperature sensor of the ESP32 and RP2040 chip.
 .. note::
 
     Some ESP32 variants return a large amount of invalid temperature
-    values. Invalid measurements are ignored by this component.
+    values, including 53.3°C which equates to a raw value of 128. Invalid measurements are ignored by this component.
 
 .. figure:: images/internal_temperature-ui.png
     :align: center

components/sensor/kuntze.rst

@@ -5,7 +5,7 @@ Kuntze pool monitor
     :description: Instructions for setting up Kuntze pool monitor in ESPHome.
     :image: kuntze.jpg
 
-The ``kuntze`` component allows you to integrate the Kuntze water measurement 
+The ``kuntze`` component allows you to integrate the Kuntze water measurement
 instrument in ESPHome. It uses :ref:`UART <uart>` (ModBUS) for communication.
 
 Once configured you can use sensors as described below for your projects.
@@ -19,25 +19,25 @@ Once configured you can use sensors as described below for your projects.
 Overview
 --------
 
-Kuntze devices have an RS485 (ModBUS RTU) communication port. Please see the 
+Kuntze devices have an RS485 (ModBUS RTU) communication port. Please see the
 Kuntze papers for the pinout of the RS485 connector on your unit. ModBUS line
 has to be terminated properly (with a ``120Ω`` resistor), and since this is likely
 your only unit connected to ESPHome, you should activate bus termination in the
-Network menu (this component doesn't support multiple Kuntze devices on the same 
+Network menu (this component doesn't support multiple Kuntze devices on the same
 bus). ModBUS address should remain at factory default value.
 
-The device communicates at ``19200`` baud ``8E1``. To connect to ESPHome, an RS485 
+The device communicates at ``19200`` baud ``8E1``. To connect to ESPHome, an RS485
-transceiver is needed. Choose a type which does not need a trigger to send and 
+transceiver is needed. Choose a type which does not need a trigger to send and
 receive data,  for example:
 
 .. figure:: ../../images/rs485.jpg
 
-The controller connects to the UART of the MCU. For ESP32 GPIO `16` to `TXD` and `17` 
+The controller connects to the UART of the MCU. For ESP32 GPIO `16` to `TXD` and `17`
 to RXD are the default ones but any other pins can be used as well. 3.3V to VCC and GND to GND.
 
 .. warning::
 
-    If you are using the :ref:`logger` make sure you are not using the same pins for it or otherwise disable the UART 
+    If you are using the :ref:`logger` make sure you are not using the same pins for it or otherwise disable the UART
     logging with the ``baud_rate: 0`` option.
 
 Component
@@ -66,14 +66,13 @@ A configured modbus component is optional. It will be automatically created.
 
 Configuration variables:
 
-- **ph**: Measured pH value
+- **ph** (*Optional*): Measured pH value.
-- **temperature**: Measured temperature value
+- **temperature** (*Optional*): Measured temperature value.
-- **dis1**: Measured DIS 1 value
+- **dis1** (*Optional*): Measured DIS 1 value.
-- **dis2**: Measured DIS 2 value
+- **dis2** (*Optional*): Measured DIS 2 value.
-- **redox**: Measured Redox value
+- **redox** (*Optional*): Measured Redox value.
-- **ec**: Measured EC value
+- **ec** (*Optional*): Measured EC value.
-- **oci**: Measured OCI value
+- **oci** (*Optional*): Measured OCI value.
-
 
 All sensors are *Optional* and support all other options from :ref:`Sensor <config-sensor>`.
 

components/sensor/ld2410.rst

@@ -75,7 +75,7 @@ and binary sensors.
   Value between ``0.75m`` and ``6m`` inclusive. Defaults to ``4.5m``.
 - **gX_move_threshold** (*Optional*, int): Threshold for the Xth gate for motion detection (X => 0 to 8).
   Above this level for the considered gate (distance), movement detection will be triggered. Defaults to ``see table below``.
-- **gX _still_threshold** (*Optional*, int): Threshold for the Xth gate for still detection. (X => 0 to 8).
+- **gX_still_threshold** (*Optional*, int): Threshold for the Xth gate for still detection. (X => 0 to 8).
   Above this level for the considered gate (distance), still detection will be triggered. Defaults to ``see table below``.
 
 .. list-table:: Default values for gate threshold

components/sensor/mics_4514.rst

@@ -6,7 +6,7 @@ MiCS 4514 Gas Sensor
     :image: mics_4514.jpg
     :keywords: MiCS, 4514, MICS-4514
 
-This component exposes the different gas concentration sensors from the `MiCS-4514 <https://www.dfrobot.com/product-2417.html>`__.
+This component exposes the different gas concentration sensors from the `MiCS-4514 <https://www.dfrobot.com/product-2417.html>`__. This is a differnet sensor than the MICS-4514 being sold on AliExpress.
 
 .. note::
 

components/sensor/mopeka_pro_check.rst

@@ -105,6 +105,9 @@ Currently supported Tank types are:
 - ``20LB_V`` - 20 LB vertical tank
 - ``30LB_V`` - 30 LB vertical tank
 - ``40LB_V`` - 40 LB vertical tank
+- ``EUROPE_6KG`` - 6kg vertical tank
+- ``EUROPE_11KG`` - 11kg vertical tank
+- ``EUROPE_14KG`` - 14kg vertical tank
 - ``CUSTOM`` - Allows you to define your own full and empty points
 
 Setting Up Devices

components/sensor/scd30.rst

@@ -6,7 +6,7 @@ SCD30 CO₂, Temperature and Relative Humidity Sensor
     :image: scd30.jpg
 
 The ``scd30`` sensor platform allows you to use your Sensirion SCD30 CO₂
-(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/9.5_CO2/Sensirion_CO2_Sensors_SCD30_Datasheet.pdf>`__) sensors with ESPHome.
+(`datasheet <https://sensirion.com/media/documents/4EAF6AF8/61652C3C/Sensirion_CO2_Sensors_SCD30_Datasheet.pdf>`__) sensors with ESPHome.
 The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for this sensor to work.
 
 .. figure:: images/scd30.jpg

components/sensor/sdp3x.rst

@@ -7,8 +7,8 @@ SDP3x / SDP800 Series Differential Pressure Sensor
     :keywords: SDP3x, SDP31, SDP32, SDP800 Series, SDP810, SDP810
 
 The SDP3x Differential Pressure sensor allows you to use your SDP3x
-(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/8_Differential_Pressure/Datasheets/Sensirion_Differential_Pressure_Datasheet_SDP3x_Digital.pdf>`__,
+(`datasheet <https://sensirion.com/media/documents/4D045D69/6375F34F/DP_DS_SDP3x_digital_D1.pdf>`__,
-`sparkfun <https://www.sparkfun.com/products/17874>`__) or SDP800 Series (`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/8_Differential_Pressure/Datasheets/Sensirion_Differential_Pressure_Datasheet_SDP8xx_Digital.pdf>`__)
+`sparkfun <https://www.sparkfun.com/products/17874>`__) or SDP800 Series (`datasheet <https://sensirion.com/media/documents/90500156/6167E43B/Sensirion_Differential_Pressure_Datasheet_SDP8xx_Digital.pdf>`__)
 sensors with ESPHome.
 
 .. figure:: images/sdp31.jpg

components/sensor/sht4x.rst

@@ -6,7 +6,7 @@ SHT4X Temperature and Humidity Sensor
     :image: sht4x.jpg
 
 The ``sht4x`` sensor platform  allows you to use your SHT4X temperature and humidity sensor
-(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/2_Humidity_Sensors/Datasheets/Sensirion_Humidity_Sensors_SHT4x_Datasheet.pdf>`__, `Adafruit`_) with ESPHome.
+(`datasheet <https://sensirion.com/media/documents/33FD6951/63E1087C/Datasheet_SHT4x_1.pdf>`__, `Adafruit`_) with ESPHome.
 
 The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for this sensor to work.
 
@@ -58,7 +58,7 @@ The heater can be enabled by setting ``heater_max_duty`` up to a maximum duty cy
 of ``5%`` (``0.05``). This runs the heater on a regular interval. While the heater
 is in operation the sensor disables measurements so no updates will be published.
 
-See the (`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/2_Humidity_Sensors/Datasheets/Sensirion_Humidity_Sensors_SHT4x_Datasheet.pdf>`__)
+See the (`datasheet <https://sensirion.com/media/documents/33FD6951/63E1087C/Datasheet_SHT4x_1.pdf>`__)
 for more information about heater operation.
 
 See Also

components/sensor/shtcx.rst

@@ -6,10 +6,10 @@ SHTCx Temperature+Humidity Sensors
     :image: shtc3.jpg
 
 The ``shtcx`` sensor platform Temperature+Humidity sensor allows you to use your Sensirion SHTC1
-(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/2_Humidity_Sensors/Datasheets/Sensirion_Humidity_Sensors_SHTC1_Datasheet.pdf>`__,
+(`datasheet <https://sensirion.com/media/documents/21BF77EA/63A5A411/Datasheet_SHTC1.pdf>`__,
 `Sensirion STHC1 <https://www.sensirion.com/en/environmental-sensors/humidity-sensors/digital-humidity-sensor-for-consumer-electronics-and-iot/>`__) and
 the newer SHTC3
-(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/2_Humidity_Sensors/Datasheets/Sensirion_Humidity_Sensors_SHTC3_Datasheet.pdf>`__,
+(`datasheet <https://sensirion.com/media/documents/643F9C8E/63A5A436/Datasheet_SHTC3.pdf>`__,
 `SparkFun`_ ) sensors with
 ESPHome. The :ref:`I²C Bus <i2c>` is
 required to be set up in your configuration for this sensor to work.

components/sensor/sps30.rst

@@ -6,7 +6,7 @@ SPS30 Particulate Matter Sensor
     :image: sps30.jpg
 
 The ``sps30`` sensor platform allows you to use your Sensirion SPS30
-(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/9.6_Particulate_Matter/Datasheets/Sensirion_PM_Sensors_Datasheet_SPS30.pdf>`__) sensors with ESPHome.
+(`datasheet <https://sensirion.com/media/documents/8600FF88/616542B5/Sensirion_PM_Sensors_Datasheet_SPS30.pdf>`__) sensors with ESPHome.
 The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for this sensor to work.
 This sensor supports both UART and I²C communication. However, at the moment only I²C communication is implemented.
 

components/sensor/sts3x.rst

@@ -6,7 +6,7 @@ STS3X Temperature Sensor
     :image: sts3x.jpg
 
 The ``sts3x`` sensor platform Temperature sensor allows you to use your Sensirion STS30-DIS, STS31-DIS or STS35-DIS
-(`datasheet <https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/3_Temperature_Sensors/Sensirion_Temperature_Sensors_Table_Overview.pdf>`__,
+(`datasheet <https://sensirion.com/media/documents/1DA31AFD/61641F76/Sensirion_Temperature_Sensors_STS3x_Datasheet.pdf>`__,
 `Sensirion STS3x <https://www.sensirion.com/sts3x/>`__) sensors with
 ESPHome. The :ref:`I²C Bus <i2c>` is
 required to be set up in your configuration for this sensor to work.

components/sensor/tmp1075.rst

@@ -0,0 +1,78 @@
+TMP1075 Temperature Sensor
+==========================
+
+.. seo::
+    :description: Instructions for setting up the TMP1075 Temperature sensor.
+    :image: tmp1075.jpg
+    :keywords: TMP1075
+
+The TMP1075 Temperature sensor allows you to use your TMP1075
+(`datasheet <https://www.ti.com/lit/gpn/tmp1075>`__)
+sensors with ESPHome.
+
+.. figure:: images/tmp1075.jpg
+    :align: center
+    :width: 30.0%
+
+    TMP1075 Temperature Sensor.
+    (Credit: `Texas Instruments <https://www.ti.com/content/dam/ticom/images/products/ic/sensing-products/chips/tmp1075-technical-chip-shot.png>`__, image cropped and compressed)
+
+The TMP1075 is a high precision temperature sensor that communicates over I²C.
+Each sensor is tested on a NIST tracable test setup during Texas Instruments'
+production process. Accuracy is typically ±0.25°C across the -55°C to +125°C
+range, with a maximum error of ±2°C in that same range and ±1°C in the -40°C to
++110°C range.
+
+To use the sensor, first set up an :ref:`I²C Bus <i2c>` and connect the sensor
+to the specified pins.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    sensor:
+      - platform: tmp1075
+        name: "Temperature TMP1075"
+        update_interval: 10s
+        i2c_id: i2c_bus
+        conversion_rate: 27.5ms
+        alert:
+          function: comparator
+          polarity: active_high
+          limit_low: 50
+          limit_high: 75
+          fault_count: 1
+
+Configuration variables:
+------------------------
+
+- **name** (**Required**, string): The name for the temperature sensor.
+- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for lambdas/multiple sensors.
+- **address** (*Optional*, int): The I²C address of the sensor.
+  See :ref:`I²C Addresses <tmp1075_i2c_addresses>` for more information. Defaults to ``0x48``.
+- **update_interval** (*Optional*, :ref:`config-time`): The interval to check
+  the sensor temperature. Defaults to ``60s``.
+- **conversion_rate** (*Optional*): The interval at which the IC performs a
+  temperature measurement. This setting also determines how fast the alert pin
+  responds to temperature changes, and is thus independent of how often ESPHome
+  checks the sensor. Possible values are ``27.5ms``, ``55ms``, ``110ms``, and
+  ``220ms``. Defaults to ``27.5ms``.
+- **alert** (*Optional*): Configure the alert pin behaviour.
+    - **function** (*Optional*, enum): Function of the alert pin, either ``comparator`` or ``interrupt``. Defaults to ``comparator``.
+    - **polarity** (*Optional*, enum): Polarity of the alert pin, either ``active_high`` or ``active_low``. Defaults to ``active_high``.
+    - **limit_low** (*Optional*, int): Lower temperature limit, in °C. Defaults to ``-128`` (the lowest possible limit value).
+    - **limit_high** (*Optional*, int): Higher temperature limit, in °C. Defaults to ``127.9375`` (the highest possible limit value).
+    - **fault_count** (*Optional*, int): Number of measurements. required for the alert pin to act. Must be between ``1`` and ``4``, inclusive. Defaults to ``1``.
+
+.. _tmp1075_i2c_addresses:
+
+I²C Addresses
+-------------
+
+In order to allow multiple sensors to be connected to the same I²C bus, the
+creators of this sensor hardware have included some options to change the I²C
+address. Three address pins can be connected to GND, VCC, SDA, or SCL, creating
+32 possible addresses. See section 9.3.2.2 of the `datasheet
+<https://www.ti.com/lit/gpn/tmp1075>`__ for the mapping table.
+
+When all address pins are connected to GND, the address is ``0x48``, which is
+the default address for this sesnsor component.

components/text_sensor/wifi_info.rst

@@ -23,6 +23,8 @@ via text sensors.
           name: ESP Mac Wifi Address
         scan_results:
           name: ESP Latest Scan Results
+        dns_address:
+          name: ESP DNS Address
 
 Configuration variables:
 ------------------------
@@ -37,6 +39,9 @@ Configuration variables:
   :ref:`Text Sensor <config-text_sensor>`.
 - **scan_results** (*Optional*): Expose the latest networks found during the latest scan. All options from
   :ref:`Text Sensor <config-text_sensor>`.
+- **dns_address** (*Optional*): Expose the DNS Address of the ESP as text sensor.
+  :ref:`Text Sensor <config-text_sensor>`.
+
 
 See Also
 --------

components/vbus.rst

@@ -176,8 +176,8 @@ All binary sensors are *Optional* and support all other options from :ref:`Binar
 ``Custom`` VBus sensors
 -----------------------
 
-Devices on a VBus are identified with a source address. There can be multiple devices on the same bus, 
+Devices on a VBus are identified with a source address. There can be multiple devices on the same bus,
-each device type has a different address. 
+each device type has a different address.
 
 
 .. code-block:: yaml
@@ -203,7 +203,7 @@ Configuration variables:
 - **sensors** (**Required**): A list of :ref:`Sensor <config-sensor>` definitions that include a ``lambda`` to do the decoding and return a ``float`` value.
 
 - **lambda** (**Required**, :ref:`lambda <config-lambda>`): Code to parse a value from the incoming data packets and return it.
-  The data packet is in a `std::vector<uint8_t>` called `x`.
+  The data packet is in a ``std::vector<uint8_t>`` called ``x``.
 
 
 ``custom`` VBus binary sensors
@@ -218,7 +218,7 @@ Configuration variables:
 - **binary_sensors** (**Required**): A list of :ref:`Binary Sensor <config-binary_sensor>` definitions that include a ``lambda`` to do the decoding and return a ``bool`` value.
 
 - **lambda** (**Required**, :ref:`lambda <config-lambda>`): Code to parse a value from the incoming data packets and return it.
-  The data packet is in a `std::vector<uint8_t>` called `x`.
+  The data packet is in a ``std::vector<uint8_t>`` called ``x``.
 
 To determine the correct values for the parameters above, visit `packet definitions list <http://danielwippermann.github.io/resol-vbus/#/vsf>`__. In the search field of the **Packets** table, enter the name of your device.
 

components/voice_assistant.rst

@@ -5,7 +5,7 @@ Voice Assistant
     :description: Instructions for setting up a Voice Assistant in ESPHome.
     :image: voice-assistant.svg
 
-ESPHome devices with a microphone are able to stream the audio to Home Assistant and be processed there by `assist <https://www.home-assistant.io/docs/assist/>`__.
+ESPHome devices with a microphone are able to stream the audio to Home Assistant and be processed there by `assist <https://www.home-assistant.io/voice_control/>`__.
 
 .. note::
 
@@ -25,6 +25,13 @@ Configuration:
 
 - **microphone** (**Required**, :ref:`config-id`): The :doc:`microphone </components/microphone/index>` to use for input.
 - **speaker** (*Optional*, :ref:`config-id`): The :doc:`speaker </components/speaker/index>` to use to output the response.
+  Cannot be used with ``media_player`` below.
+- **media_player** (*Optional*, :ref:`config-id`): The :doc:`media_player </components/media_player/index>` to use
+  to output the response. Cannot be used with ``speaker`` above.
+- **silence_detection** (*Optional*, bool): Whether Home Assistant uses Voice Activity Detection to detect when you
+  have stopped talking and start processing the command. Defaults to ``true``.
+- **on_listening** (*Optional*, :ref:`Automation <automation>`): An automation to
+  perform when the voice assistant starts listening.
 - **on_start** (*Optional*, :ref:`Automation <automation>`): An automation to
   perform when the voice assistant starts listening.
 - **on_end** (*Optional*, :ref:`Automation <automation>`): An automation to perform
@@ -50,8 +57,16 @@ Voice Assistant Actions
 The following actions are available for use in automations:
 
 - ``voice_assistant.start`` - Start listening for voice commands.
+- ``voice_assistant.start_continuous`` - Start listening for voice commands. This will start listening again after
+  the response audio has finished playing. Errors will stop the cycle. Call ``voice_assistant.stop`` to stop the cycle.
 - ``voice_assistant.stop`` - Stop listening for voice commands.
 
+Voice Assistant Conditions
+--------------------------
+
+The following conditions are available for use in automations:
+
+- ``voice_assistant.is_running`` - Returns true if the voice assistant is currently running.
 
 Push to Talk
 ------------
@@ -61,7 +76,8 @@ Here is an example offering Push to Talk with a :doc:`/components/binary_sensor/
 .. code-block:: yaml
 
     voice_assistant:
-      microphone: mic_id
+      microphone: ...
+      speaker: ...
 
     binary_sensor:
       - platform: gpio
@@ -71,6 +87,26 @@ Here is an example offering Push to Talk with a :doc:`/components/binary_sensor/
         on_release:
           - voice_assistant.stop:
 
+Click to Converse
+-----------------
+
+.. code-block:: yaml
+
+    voice_assistant:
+      microphone: ...
+      speaker: ...
+
+    binary_sensor:
+      - platform: gpio
+        pin: ...
+        on_click:
+          - if:
+              condition: voice_assistant.is_running
+              then:
+                - voice_assistant.stop:
+              else:
+                - voice_assistant.start_continuous:
+
 
 See Also
 --------

components/web_server.rst

@@ -7,27 +7,26 @@ Web Server Component
     :keywords: web server, http, REST API
 
 The ``web_server`` component creates a simple web server on the node that can be accessed
-through any browser and a simple `REST API`_. Please note that enabling this component
+through any browser and a simple :ref:`api-rest`. Please note that enabling this component
-will take up *a lot* of memory and can lead to problems, especially on the ESP8266.
+will take up *a lot* of memory and may decrease stability, especially on ESP8266.
+
+.. figure:: /components/images/web_server.png
+    :align: center
+    :width: 86.0%
+
+    Web server version 1
+
+
+.. figure:: /components/images/web_server-v2.png
+    :align: center
+    :width: 86.0%
+
+    Web server version 2
+
 
 To navigate to the web server in your browser, either use the IP address of the node or
 use ``<node_name>.local/`` (note the trailing forward slash) via mDNS.
 
-To conserve flash size, the CSS and JS files used on the root page to show a simple user
-interface are hosted by esphome.io. If you want to use your own service, use the
-``css_url`` and ``js_url`` options in your configuration.
-
-.. _REST API: /web-api/index.html
-
-.. figure:: /components/images/web_server.png
-
-    Example web server frontend (Version 1)
-
-Version 2:
-----------
-.. figure:: /components/images/web_server-v2.png
-
-    Web Components (Version 2)
 
 .. code-block:: yaml
 
@@ -50,7 +49,7 @@ Configuration variables:
 - **js_include** (*Optional*, local file): Path to local file to be included in web server index page.
   Contents of this file will be served as ``/0.js`` and used as JS script by internal webserver.
   Useful when building device without internet access, where you want to use built-in AP and webserver.
-- **auth** (*Optional*): Enables basic authentication with username and password.
+- **auth** (*Optional*): Enables a simple *Digest* authentication with username and password.
 
   - **username** (**Required**, string): The username to use for authentication.
   - **password** (**Required**, string): The password to check for authentication.
@@ -62,52 +61,53 @@ Configuration variables:
 - **local** (*Optional*, boolean): Include supporting javascript locally allowing it to work without internet access. Defaults to ``false``.
 - **version** (*Optional*, string): ``1`` or ``2``. Version 1 displays as a table. Version 2 uses web components and has more functionality. Defaults to ``2``.
 
-.. note::
+To conserve flash size, the CSS and JS files used on the root page to show a simple user
+interface are hosted by esphome.io. If you want to use your own service, use the
+``css_url`` and ``js_url`` options in your configuration.
 
-    Example web_server configuration using HTTP authentication:
+Example configurations:
+-----------------------
 
-    .. code-block:: yaml
+Enabling HTTP authentication:
 
-        # Example configuration entry
+.. code-block:: yaml
-        web_server:
-          port: 80
-          auth:
-            username: admin
-            password: !secret web_server_password
 
-    Example web_server configuration using version 1 (previous behaviour):
+    # Example configuration entry
+    web_server:
+      port: 80
+      auth:
+        username: !secret web_server_username
+        password: !secret web_server_password
 
-    .. code-block:: yaml
+Use version 1 user interface:
 
-        # Example configuration entry
+.. code-block:: yaml
-        web_server:
-          port: 80
-          version: 1
 
-    Example web_server configuration using version 2  - no internet/intranet required:
+    # Example configuration entry
+    web_server:
+      port: 80
+      version: 1
 
-    .. code-block:: yaml
+No internet/intranet required on the clients (all assets are inlined, compressed and served from flash):
 
-        # Example configuration entry
+.. code-block:: yaml
-        web_server:
+
-          local: true
+    # Example configuration entry
+    web_server:
+      local: true
 
 
-
+Advanced usage
-    All of the assets are inlined, compressed and served from flash
+--------------
-
-Here be Dragons
-===============
 
 The following assume copies of the files with local paths - which are config dependant.
 
-Example web_server version 1 configuration with CSS and JS included from esphome-docs.
+Example ``web_server`` version 1 configuration with CSS and JS included from esphome-docs.
 CSS and JS URL's are set to empty value, so no internet access is needed for this device to show it's web interface.
 Force to turn off OTA function because the missing authentication.
 
 .. code-block:: yaml
 
-    # Example configuration entry V1
     web_server:
       port: 80
       version: 1
@@ -117,26 +117,26 @@ Force to turn off OTA function because the missing authentication.
       js_include: "../../../esphome-docs/_static/webserver-v1.min.js"
       js_url: ""
 
-Example web_server version 2 configuration with JS included from a local file.
+Example ``web_server`` version 2 configuration with JS included from a local file.
-
 CSS and JS URL's are set to empty value, so no internet access is needed for this device to show it's web interface.
 V2 embeds the css within the js file so is not required, however you could include your own CSS.
 
 .. code-block:: yaml
 
-    # Example configuration entry V2
+    # Example configuration entry v2
     web_server:
       js_include: "./v2/www.js"
       js_url: ""
       version: 2
 
-
 Copy https://oi.esphome.io/v2/www.js to a V2 folder in your yaml folder.
 
 
 See Also
 --------
 
+- :ref:`api-event-source`
+- :ref:`api-rest`
 - :apiref:`web_server/web_server.h`
 - :doc:`prometheus`
 - :ghedit:`Edit`

components/wifi.rst

@@ -89,6 +89,8 @@ Configuration variables:
 - **enable_btm** (*Optional*, bool): Only on ``esp32`` with ``esp-idf``. Enable 802.11v BSS Transition Management support.
 - **enable_rrm** (*Optional*, bool): Only on ``esp32`` with ``esp-idf``. Enable 802.11k Radio Resource Management support.
 
+- **enable_on_boot** (*Optional*, boolean): If enabled, the WiFi interface will be enabled on boot. Defaults to ``true``.
+
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
 
 Access Point Mode
@@ -270,6 +272,18 @@ Configuration variables:
 - **key** (*Optional*, string): Path to a PEM encoded private key matching ``certificate`` for EAP-TLS authentication.
   Optionally encrypted with ``password``.
 
+
+Turning on and off WiFi
+-----------------------
+
+Using the actions ``wifi.enable`` and ``wifi.disable``, you can turn on and off the WiFi interface on demand.
+The configuration option ``enable_on_boot`` can be set to ``false`` if you do not want wifi to be enabled on boot.
+
+.. note::
+
+    Be aware that if you disable WiFi, the API timeout will need to be disabled otherwise the device will reboot.
+
+
 .. _wifi-connected_condition:
 
 ``wifi.connected`` Condition

conf.py

@@ -67,9 +67,9 @@ author = "ESPHome"
 # built documents.
 #
 # The short X.Y version.
-version = "2023.5"
+version = "2023.6"
 # The full version, including alpha/beta/rc tags.
-release = "2023.5.5"
+release = "2023.6.0b1"
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

cookbook/http_request_sensor.rst

@@ -0,0 +1,121 @@
+Share data directly between ESPHome nodes
+=========================================
+
+In certain special cases it might be desired to avoid placing any middleware like an MQTT or a home automation server just to transfer small bits of data from one node to another. Direct data polling is possibvle using HTTP, but beware that the involved components are resource hungry and may be less stable on long term. The webserver embedded in the node is not designed to constantly serve a large amount of requests.
+
+The primary node holding the data we need to retrieve from will be the server, and the others polling for it will be the clients (can be multiple). 
+
+Server part
+-----------
+
+Setting up a webserver using the  :doc:`/components/web_server` on the primary node will make available the required sensor data through a :ref:`api-rest` interface.
+
+.. code-block:: yaml
+
+    web_server:
+      port: 80
+
+Client part
+-----------
+
+On the client nodes we need an :doc:`/components/http_request` with an ``id`` set, and a :doc:`/components/sensor/template` to make it accessible locally.
+
+.. code-block:: yaml
+
+    http_request:
+      useragent: esphome/device
+      id: http_request_id
+
+    sensor:
+      - platform: template
+        name: "Template sensor on client"
+        id: template_sensor_id
+
+
+Pulling the data
+****************
+
+To automate the request for data, we use an :ref:`interval` requesting the URL pointing to the sensor id for which the state is needed. See :ref:`api-rest` on how to build up the URL for your sensors.
+
+In the example below we request the value of a sensor from the server node, and after parsing the resulted JSON string we publish it to the local template sensor:
+
+.. code-block:: yaml
+
+    interval:
+      - interval: 60s
+        then:
+          - http_request.get: 
+              url: http://ip or nodename.local/sensor/ID_of_the_sensor
+              on_response:
+                then:
+                  - lambda: |-
+                      json::parse_json(id(http_request_id).get_string(), [](JsonObject root) {
+                          id(template_sensor_id).publish_state(root["value"]);
+                      });
+
+                 
+Result
+------
+
+.. figure:: images/server.png
+    :align: center
+    :width: 95.0%
+
+    Server side real sensor
+
+
+.. figure:: images/clients.png
+    :align: center
+    :width: 95.0%
+
+    Client side template sensor
+
+
+Increasing security
+-------------------
+
+For security reasons, it's always recommended to protect the web interface of the nodes with authentication, even if you're using them on your local network.
+
+Server part
+***********
+
+Add authentication to the ``web_server`` component on the primary node:
+
+.. code-block:: yaml
+
+    web_server:
+      port: 80
+      auth:
+        username: !secret admin
+        password: !secret web_server_password
+
+Client part
+***********
+
+Add an ``Authorization`` header to your ``http_request.get`` action. The simplest way to determine a working authorization header is to visit the password-protected REST URL of the primary node using a browser while watching the network traffic in the browser's developer tools. If you look at the headers of the request sent by the browser, you'll find the ``Authorization`` header it sends to the node, and you can copy it for your own replay:
+
+.. code-block:: yaml
+
+    interval:
+      - interval: 60s
+        then:
+          - http_request.get: 
+              url: http://ip or nodename.local/sensor/ID_of_the_sensor
+              headers:
+                Authorization: 'Digest username="admin", realm="asyncesp", nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", uri="/sensor/ID_of_the_sensor", response="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", opaque="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", qop=auth, nc=xxxxxxxx, cnonce="xxxxxxxxxxxxxxxx"'
+              on_response:
+                then:
+                  - lambda: |-
+                      json::parse_json(id(http_request_id).get_string(), [](JsonObject root) {
+                          id(template_sensor_id).publish_state(root["value"]);
+                      });
+
+See Also
+--------
+
+- :doc:`/components/web_server`
+- :doc:`/components/http_request`
+- :doc:`/components/sensor/template`
+- :ref:`interval`
+- :ref:`api-rest`
+- :ghedit:`Edit`

custom/i2c.rst

@@ -29,6 +29,64 @@ them publish values.
       }
     };
 
+
+I²C Write
+---------
+It may be useful to write to a register via I²C using a numerical input. For example, the following yaml code snippet captures a user-supplied numerical input in the range 1--255 from the dashboard:
+
+.. code-block:: yaml
+
+    number:
+        - platform: template
+        name: "Input 1"
+        optimistic: true
+        min_value: 1
+        max_value: 255
+        initial_value: 20
+        step: 1
+        mode: box
+        id: input_1
+        icon: "mdi:counter"
+        
+We want to write this number to a ``REGISTER_ADDRESS`` on the slave device via I²C. The Arduino-based looping code shown above is modified following the guidance in :doc:`Custom Sensor Component </components/sensor/custom>`.
+ 
+.. code-block:: cpp
+
+    #include "esphome.h"
+ 
+    const uint16_t I2C_ADDRESS = 0x21;
+    const uint16_t REGISTER_ADDRESS = 0x78; 
+    const uint16_t POLLING_PERIOD = 15000; //milliseconds
+    char temp = 20; //Initial value of the register
+
+    class MyCustomComponent : public PollingComponent {
+     public:
+      MyCustomComponent() : PollingComponent(POLLING_PERIOD) {}
+      float get_setup_priority() const override { return esphome::setup_priority::BUS; } //Access I2C bus
+
+      void setup() override {
+        //Add code here as needed
+        Wire.begin();
+        }
+  
+      void update() override {  
+      char register_value = id(input_1).state; //Read the number set on the dashboard
+      //Did the user change the input?
+      if(register_value != temp){
+            Wire.beginTransmission(I2C_ADDRESS);
+            Wire.write(REGISTER_ADDRESS);
+            Wire.write(register_value);
+            Wire.endTransmission();
+            temp = register_value; //Swap in the new value
+            }
+        }
+    };
+        
+The ``Component`` class has been replaced with ``PollingComponent`` and the free-running ``loop()`` is changed to the  ``update()`` method with period set by ``POLLING_PERIOD``. The numerical value from the dashboard is accessed with its ``id`` tag and its state is set to the byte variable that we call ``register_value``.  To prevent an I²C write on every iteration, the contents of the register are stored in ``temp`` and checked for a change. Configuring the hardware with ``get_setup_priority()`` is explained in :doc:`Step 1 </components/sensor/custom>`.
+
+
+
+
 See Also
 --------
 

guides/configuration-types.rst

@@ -451,6 +451,76 @@ them locally with their own subsitution value.
       # shorthand form github://username/repository/[folder/]file-path.yml[@branch-or-tag]
       remote_package_three: github://esphome/non-existant-repo/file1.yml@main
 
+Packages as Templates
+*********************
+
+Since packages are incorporated using the ``!include`` system,
+variables can be provided to them.  This means that packages can be
+used as `templates`, allowing complex or repetitive configurations to
+be stored in a package file and then incorporated into the
+configuration more than once.
+
+As an example, if the configuration needed to support three garage
+doors using the ``gpio`` switch platform and the ``time_based`` cover
+platform, it could be constructed like this:
+
+.. code-block:: yaml
+
+    # In config.yaml
+    packages:
+      left_garage_door: !include
+        file: garage-door.yaml
+        vars:
+          door_name: Left
+          door_location: left
+          open_switch_gpio: 25
+          close_switch_gpio: 26
+      middle_garage_door: !include
+        file: garage-door.yaml
+        vars:
+          door_name: Middle
+          door_location: middle
+          open_switch_gpio: 27
+          close_switch_gpio: 29
+      right_garage_door: !include
+        file: garage-door.yaml
+        vars:
+          door_name: Right
+          door_location: right
+          open_switch_gpio: 15
+          close_switch_gpio: 18
+
+
+.. code-block:: yaml
+
+    # In garage-door.yaml
+    switch:
+      - id: open_${door_location}_door_switch
+        name: ${door_name} Garage Door Open Switch
+        platform: gpio
+        pin: ${open_switch_gpio}
+
+      - id: close_${door_location}_door_switch
+        name: ${door_name} Garage Door Close Switch
+        platform: gpio
+        pin: ${close_switch_gpio}
+
+    cover:
+      - platform: time_based
+        name: ${door_name} Garage Door
+
+        open_action:
+          - switch.turn_on: open_${door_location}_door_switch
+        open_duration: 2.1min
+
+        close_action:
+          - switch.turn_on: close_${door_location}_door_switch
+        close_duration: 2min
+
+        stop_action:
+          - switch.turn_off: open_${door_location}_door_switch
+          - switch.turn_off: close_${door_location}_door_switch
+
 
 See Also
 --------

guides/getting_started_command_line.rst

@@ -40,6 +40,12 @@ If you want to use `docker-compose` instead, here's a sample file:
         privileged: true
         network_mode: host
 
+.. note::
+
+    If you are using NFS share to back your container's config volume, you may 
+    need to mount the volume with the `nolock` option, otherwise platformio may 
+    freeze on container startup as per `platformIO-core Issue 3089 <https://github.com/platformio/platformio-core/issues/3089>`__
+
 The project provides multiple docker tags; please pick the one that suits you
 better:
 

guides/supporters.rst

@@ -27,6 +27,7 @@ Contributors
 - `Alessandro Campolo (@a13ssandr0) <https://github.com/a13ssandr0>`__
 - `Aalian Khan (@AalianKhan) <https://github.com/AalianKhan>`__
 - `Adam Liddell (@aaliddell) <https://github.com/aaliddell>`__
+- `Aapeli Vuorinen (@aapeliv) <https://github.com/aapeliv>`__
 - `Aaron Gamble (@aarongamble) <https://github.com/aarongamble>`__
 - `Aaron S. Jackson (@AaronJackson) <https://github.com/AaronJackson>`__
 - `Abel Matser (@abelmatser) <https://github.com/abelmatser>`__
@@ -40,7 +41,6 @@ Contributors
 - `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>`__
 - `Alexander Pohl (@ahpohl) <https://github.com/ahpohl>`__
@@ -97,6 +97,7 @@ Contributors
 - `aquaticus (@aquaticus) <https://github.com/aquaticus>`__
 - `Andy Allsopp (@arallsopp) <https://github.com/arallsopp>`__
 - `arantius (@arantius) <https://github.com/arantius>`__
+- `Ariff Saad (@arffsaad) <https://github.com/arffsaad>`__
 - `arturo182 (@arturo182) <https://github.com/arturo182>`__
 - `arunderwood (@arunderwood) <https://github.com/arunderwood>`__
 - `Arya (@Arya11111) <https://github.com/Arya11111>`__
@@ -203,6 +204,7 @@ Contributors
 - `cbialobos (@cbialobos) <https://github.com/cbialobos>`__
 - `Cameron Bulock (@cbulock) <https://github.com/cbulock>`__
 - `Ciprian Constantinescu (@cciprian5) <https://github.com/cciprian5>`__
+- `Carlos Cordero (@ccorderor) <https://github.com/ccorderor>`__
 - `cdmonk (@cdmonk) <https://github.com/cdmonk>`__
 - `ceaswaran (@ceaswaran) <https://github.com/ceaswaran>`__
 - `Cellie (@CelliesProjects) <https://github.com/CelliesProjects>`__
@@ -328,6 +330,7 @@ Contributors
 - `Daniel Hyles (@DotNetDann) <https://github.com/DotNetDann>`__
 - `dr-oblivium (@dr-oblivium) <https://github.com/dr-oblivium>`__
 - `Drew Perttula (@drewp) <https://github.com/drewp>`__
+- `drmodding (@drmodding) <https://github.com/drmodding>`__
 - `drmpf (@drmpf) <https://github.com/drmpf>`__
 - `drogfild (@drogfild) <https://github.com/drogfild>`__
 - `DrRob (@DrRob) <https://github.com/DrRob>`__
@@ -451,7 +454,7 @@ Contributors
 - `Germán Martín (@gmag11) <https://github.com/gmag11>`__
 - `Germain Masse (@gmasse) <https://github.com/gmasse>`__
 - `Garret Buell (@gmbuell) <https://github.com/gmbuell>`__
-- `Jelle Raaijmakers (@GMTA) <https://github.com/GMTA>`__
+- `Jelle Raaijmakers (@gmta) <https://github.com/gmta>`__
 - `Go0oSer (@Go0oSer) <https://github.com/Go0oSer>`__
 - `Gonzalo Paniagua Javier (@gonzalop) <https://github.com/gonzalop>`__
 - `gordon-zhao (@gordon-zhao) <https://github.com/gordon-zhao>`__
@@ -629,7 +632,6 @@ Contributors
 - `Harald Nagel (@k7hpn) <https://github.com/k7hpn>`__
 - `kaegi (@kaegi) <https://github.com/kaegi>`__
 - `kahrendt (@kahrendt) <https://github.com/kahrendt>`__
-- `Kamahat (@kamahat) <https://github.com/kamahat>`__
 - `Karl0ss (@karl0ss) <https://github.com/karl0ss>`__
 - `Kattni (@kattni) <https://github.com/kattni>`__
 - `Krzysztof Białek (@kbialek) <https://github.com/kbialek>`__
@@ -664,7 +666,6 @@ Contributors
 - `Jakub Šimo (@kubik369) <https://github.com/kubik369>`__
 - `Mark Kuchel (@kuchel77) <https://github.com/kuchel77>`__
 - `Kyle Hill (@kylhill) <https://github.com/kylhill>`__
-- `Kalashnikov Ilya (@l1bbcsg) <https://github.com/l1bbcsg>`__
 - `Limor "Ladyada" Fried (@ladyada) <https://github.com/ladyada>`__
 - `Luca Adrian L (@lal12) <https://github.com/lal12>`__
 - `Fredrik Lindqvist (@Landrash) <https://github.com/Landrash>`__
@@ -821,10 +822,8 @@ Contributors
 - `Bergont Nicolas (@nbergont) <https://github.com/nbergont>`__
 - `NMC (@ncareau) <https://github.com/ncareau>`__
 - `Nejc Koncan (@nejc-cc) <https://github.com/nejc-cc>`__
-- `NeoAcheron (@NeoAcheron) <https://github.com/NeoAcheron>`__
 - `Mike Meessen (@netmikey) <https://github.com/netmikey>`__
 - `Nicolas Graziano (@ngraziano) <https://github.com/ngraziano>`__
-- `Nick B. (@NickB1) <https://github.com/NickB1>`__
 - `nickrout (@nickrout) <https://github.com/nickrout>`__
 - `Nick Whyte (@nickw444) <https://github.com/nickw444>`__
 - `Nicky Ivy (@nickyivyca) <https://github.com/nickyivyca>`__
@@ -991,6 +990,7 @@ Contributors
 - `Abdelkader Boudih (@seuros) <https://github.com/seuros>`__
 - `SharkSharp (@SharkSharp) <https://github.com/SharkSharp>`__
 - `Sebastiaan (@SharkWipf) <https://github.com/SharkWipf>`__
+- `Alexander Dimitrov (@sharkydog) <https://github.com/sharkydog>`__
 - `Fabio Todaro (@SharpEdgeMarshall) <https://github.com/SharpEdgeMarshall>`__
 - `ShellAddicted (@ShellAddicted) <https://github.com/ShellAddicted>`__
 - `sherbang (@sherbang) <https://github.com/sherbang>`__
@@ -1159,4 +1159,4 @@ Contributors
 - `Zack Barett (@zsarnett) <https://github.com/zsarnett>`__
 - `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
 
-*This page was last updated May 29, 2023.*
+*This page was last updated June 15, 2023.*

images/alarm-panel.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 24 24"><path fill="currentColor" d="M20 3H4c-1.1 0-2 .9-2 2v14c0 1.1.9 2 2 2h16c1.1 0 2-.9 2-2V5c0-1.1-.9-2-2-2M8 19H5v-2h3v2m0-3H5v-2h3v2m0-3H5v-2h3v2m5.5 6h-3v-2h3v2m0-3h-3v-2h3v2m0-3h-3v-2h3v2m5.5 6h-3v-2h3v2m0-3h-3v-2h3v2m0-3h-3v-2h3v2m0-4H5V5h14v4Z"/></svg>

index.rst

@@ -317,6 +317,7 @@ Environmental
     TEE501, components/sensor/tee501, TEE501.png, Temperature
     TMP102, components/sensor/tmp102, tmp102.jpg, Temperature
     TMP117, components/sensor/tmp117, tmp117.jpg, Temperature
+    TMP1075, components/sensor/tmp1075, tmp1075.jpg, Temperature
     HYT271, components/sensor/hyt271, hyt271.jpg, Temperature & Humidity
 
 
@@ -499,7 +500,7 @@ Output Components
     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
-    Sigma-Delta Output, components/output/sigma_delta, sigma-delta.svg
+    Sigma-Delta Output, components/output/sigma_delta_output, sigma-delta.svg
     Template Output, components/output/template, description.svg
     BP1658CJ, components/output/bp1658cj, bp1658cj.svg
     BP5758D, components/output/bp5758d, bp5758d.svg
@@ -524,6 +525,7 @@ Light Components
     RGBCT Light, components/light/rgbct, rgbw.png
 
     ESP32 RMT, components/light/esp32_rmt_led_strip, color_lens.svg
+    RP2040 PIO, components/light/rp2040_pio_led_strip, color_lens.svg
     FastLED Light, components/light/fastled, color_lens.svg
     NeoPixelBus Light, components/light/neopixelbus, color_lens.svg
     Light Partition, components/light/partition, color_lens.svg
@@ -748,6 +750,14 @@ Home Assistant Companion Components
     Text Sensor, components/text_sensor/homeassistant, home-assistant.svg
     Binary Sensor, components/binary_sensor/homeassistant, home-assistant.svg
 
+Alarm Control Panel Components
+------------------------------
+
+.. imgtable::
+
+    Alarm Control Panel Core, components/alarm_control_panel/index, alarm-panel.svg
+    Template Alarm Control Panel, components/alarm_control_panel/template, description.svg
+
 Miscellaneous Components
 ------------------------
 
@@ -838,6 +848,7 @@ Cookbook
     Sonoff Fishpond Pump, cookbook/sonoff-fishpond-pump, cookbook-sonoff-fishpond-pump.jpg
     Arduino Port Extender, cookbook/arduino_port_extender, arduino_logo.svg
     EHMTX a matrix status/text display, cookbook/ehmtx, ehmtx.jpg
+    Share data directly between ESPHome nodes, cookbook/http_request_sensor, connection.svg
 
 Do you have other awesome automations or cool setups? Please feel free to add them to the
 documentation for others to copy. See :doc:`Contributing </guides/contributing>`.

schema_doc.py

@@ -81,6 +81,8 @@ PLATFORMS_TITLES = {
     "Stepper": "stepper",
     "Switch": "switch",
     "I²C": "i2c",
+    "Media Player": "media_player",
+    "Microphone": "microphone",
 }
 
 CUSTOM_DOCS = {
@@ -196,6 +198,8 @@ CUSTOM_DOCS = {
     },
 }
 
+REQUIRED_OPTIONAL_TYPE_REGEX = r"(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s"
+
 
 def get_node_title(node):
     return list(node.traverse(nodes.title))[0].astext()
@@ -250,7 +254,6 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
                     ]
 
             else:  # sub component, e.g. output/esp8266_pwm
-
                 # components here might have a core / hub, eg. dallas, ads1115
                 # and then they can be a binary_sensor, sensor, etc.
                 self.platform = self.path[1]
@@ -775,7 +778,6 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
             and (self.props or self.multi_component)
             and self.bullet_list_level > 1
         ):
-
             self.prop_stack.append((self.current_prop, node))
             self.accept_props = True
             return
@@ -844,7 +846,7 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
         try:
             name_type = markdown[: markdown.index(": ") + 2]
             ntr = re.search(
-                r"(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s",
+                REQUIRED_OPTIONAL_TYPE_REGEX,
                 name_type,
                 re.IGNORECASE,
             )
@@ -875,7 +877,6 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
         return markdown
 
     def update_prop(self, node, props):
-
         prop_name = None
 
         for s_prop, n in self.prop_stack:
@@ -901,10 +902,10 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
                             found = True
                             if enum_docs:
                                 enum_docs = enum_docs.strip()
-                                if "values_docs" not in inner:
+                                if inner["values"][name] is None:
-                                    inner["values_docs"] = {name: enum_docs}
+                                    inner["values"][name] = {"docs": enum_docs}
                                 else:
-                                    inner["values_docs"][name] = enum_docs
+                                    inner["values"][name]["docs"] = enum_docs
                                 statistics.props_documented += 1
                                 statistics.enums_good += 1
                     if not found:
@@ -941,12 +942,19 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
             return prop_name, False
 
         # Example properties formats are:
-        # **name** (**Required**, string): Long Description...
+        # **prop_name** (**Required**, string): Long Description...
-        # **name** (*Optional*, string): Long Description... Defaults to ``value``.
+        # **prop_name** (*Optional*, string): Long Description... Defaults to ``value``.
-        # **name** (*Optional*): Long Description... Defaults to ``value``.
+        # **prop_name** (*Optional*): Long Description... Defaults to ``value``.
+        # **prop_name** can be a list of names separated by / e.g. **name1/name2** (*Optional*) see climate/pid/ threshold_low/threshold_high
+
+        PROP_NAME_REGEX = r"\*\*(\w*(?:/\w*)*)\*\*"
+
+        FULL_ITEM_PROP_NAME_TYPE_REGEX = (
+            r"\* " + PROP_NAME_REGEX + r"\s" + REQUIRED_OPTIONAL_TYPE_REGEX
+        )
 
         ntr = re.search(
-            r"\* \*\*(\w*)\*\*\s(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s",
+            FULL_ITEM_PROP_NAME_TYPE_REGEX,
             name_type,
             re.IGNORECASE,
         )
@@ -956,14 +964,14 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
             param_type = ntr.group(7)
         else:
             s2 = re.search(
-                r"\* \*\*(\w*)\*\*\s(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s",
+                FULL_ITEM_PROP_NAME_TYPE_REGEX,
                 markdown,
                 re.IGNORECASE,
             )
             if s2:
                 # this is e.g. when a property has a list inside, and the list inside are the options.
                 # just validate **prop_name**
-                s3 = re.search(r"\* \*\*(\w*)\*\*:\s", name_type)
+                s3 = re.search(r"\* " + PROP_NAME_REGEX + r"*:\s", name_type)
                 if s3 is not None:
                     prop_name = s3.group(1)
                 else:
@@ -977,61 +985,61 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
                 )
                 return prop_name, False
 
-        k = str(prop_name)
+        prop_names = str(prop_name)
+        for k in prop_names.split("/"):
+            config_var = props.get(k)
 
-        config_var = props.get(k)
+            if not config_var:
+                # Create docs for common properties when descriptions are overridden
+                # in the most specific component.
 
-        if not config_var:
+                if k in [
-            # Create docs for common properties when descriptions are overridden
+                    "id",
-            # in the most specific component.
+                    "name",
-
+                    "internal",
-            if k in [
+                    # i2c
-                "id",
+                    "address",
-                "name",
+                    "i2c_id",
-                "internal",
+                    # polling component
-                # i2c
+                    "update_interval",
-                "address",
+                    # uart
-                "i2c_id",
+                    "uart_id",
-                # polling component
+                    # light
-                "update_interval",
+                    "effects",
-                # uart
+                    "gamma_correct",
-                "uart_id",
+                    "default_transition_length",
-                # light
+                    "flash_transition_length",
-                "effects",
+                    "color_correct",
-                "gamma_correct",
+                    # display
-                "default_transition_length",
+                    "lambda",
-                "flash_transition_length",
+                    "pages",
-                "color_correct",
+                    "rotation",
-                # display
+                    # spi
-                "lambda",
+                    "spi_id",
-                "pages",
+                    "cs_pin",
-                "rotation",
+                    # output (binary/float output)
-                # spi
+                    "inverted",
-                "spi_id",
+                    "power_supply",
-                "cs_pin",
+                    # climate
-                # output (binary/float output)
+                    "receiver_id",
-                "inverted",
-                "power_supply",
-                # climate
-                "receiver_id",
-            ]:
-                config_var = props[k] = {}
-            else:
-                if self.path[1] == "esphome" and k in [
-                    # deprecated esphome
-                    "platform",
-                    "board",
-                    "arduino_version",
-                    "esp8266_restore_from_flash",
                 ]:
-                    return prop_name, True
+                    config_var = props[k] = {}
-                return prop_name, False
+                else:
+                    if self.path[1] == "esphome" and k in [
+                        # deprecated esphome
+                        "platform",
+                        "board",
+                        "arduino_version",
+                        "esp8266_restore_from_flash",
+                    ]:
+                        return prop_name, True
+                    return prop_name, False
 
-        desc = markdown[markdown.index(": ") + 2 :].strip()
+            desc = markdown[markdown.index(": ") + 2 :].strip()
-        if param_type:
+            if param_type:
-            desc = "**" + param_type + "**: " + desc
+                desc = "**" + param_type + "**: " + desc
 
-        config_var["docs"] = desc
+            config_var["docs"] = desc
 
         statistics.props_documented += 1
 
@@ -1084,7 +1092,11 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
 
         def _find_extended(self, component, key):
             for extended in component.get("extends", []):
-                schema = self.visitor.get_component_schema(extended).get("schema", {})
+                c = self.visitor.get_component_schema(extended)
+                if c.get("type") == "typed":
+                    p = self.visitor.Props(self.visitor, c)
+                    return p[key]
+                schema = c.get("schema", {})
                 for k, cv in schema.get("config_vars", {}).items():
                     if k == key:
                         return SetObservable(
@@ -1124,7 +1136,7 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor):
                 )
 
         def _set_typed(self, inner_key, original_dict, key, value):
-            if inner_key == self.component.get("typed_key"):
+            if inner_key == self.component.get("typed_key", "type"):
                 self.component[key] = value
             else:
                 for tk, tv in self.component["types"].items():

web-api/index.rst

@@ -24,6 +24,8 @@ While it's currently recommended to use ESPHome directly through Home Assistant,
 to integrate ESPHome with an external or self-built application you can use two available
 APIs: the real-time event source API and REST API.
 
+.. _api-event-source:
+
 Event Source API
 ~~~~~~~~~~~~~~~~
 
@@ -56,6 +58,8 @@ states so that the client can catch up with reality.
 The payloads of these state events are also the same as the payloads of the REST API GET calls.
 I would recommend just opening the network debug panel of your web browser to see what's sent.
 
+.. _api-rest:
+
 REST API
 --------
 
@@ -297,3 +301,11 @@ method is ``set``. The following parameter can be used:
    minimum and maximum range of the number otherwise it will be ignored.
 
 For example POST ``/number/desired_delay/set?value=24`` will set the number to 24.
+
+See Also
+--------
+
+- :doc:`/components/web_server`
+- :doc:`/components/prometheus`
+- :doc:`/components/http_request`
+- :ghedit:`Edit`