Merge branch 'current' into beta

components/fan/hbridge.rst

@@ -50,7 +50,7 @@ Configuration variables:
 - **enable_pin** (*Optional*, :ref:`config-id`): The id of the
   :ref:`float output <output>` connected to the Enable pin of the h-bridge (if h-bridge uses enable).
 - **decay_mode** (*Optional*, string): The decay mode you want to use with
-  the h-bridge. Either ``slow`` (braking) or ``fast`` (coasting). Defaults to ``slow``.
+  the h-bridge. Either ``slow`` (coasting) or ``fast`` (braking). Defaults to ``slow``.
 - **speed_count** (*Optional*, int): Set the number of supported discrete speed levels. The value is used
   to calculate the percentages for each speed. E.g. ``2`` means that you have 50% and 100% while ``100``
   will allow 1% increments in the output. Defaults to ``100``.

components/matrix_keypad.rst

@@ -64,7 +64,7 @@ Individual keys can be added independently to ESPHome as ``binary_sensor``:
         id: key4
         row: 1
         col: 0
-      - platform: keypad
+      - platform: matrix_keypad
         id: keyA
         key: A
 

components/remote_receiver.rst

@@ -66,7 +66,9 @@ Configuration variables:
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. Use this if you have
   multiple remote receivers.
 
+
 Automations:
+------------
 
 - **on_aeha** (*Optional*, :ref:`Automation <automation>`): An automation to perform when a
   AEHA remote code has been decoded. A variable ``x`` of type :apiclass:`remote_base::AEHAData`
@@ -143,6 +145,21 @@ Automations:
   Toshiba AC remote code has been decoded. A variable ``x`` of type :apistruct:`remote_base::ToshibaAcData`
   is passed to the automation for use in lambdas.
 
+.. code-block:: yaml
+
+    # Example automation for decoded signals
+    remote_receiver:
+      ...
+      on_samsung:
+        then:
+        - if:
+            condition:
+              or:
+                - lambda: 'return (x.data == 0xE0E0E01F);'  # VOL+ newer type
+                - lambda: 'return (x.data == 0xE0E0E01F0);' # VOL+ older type
+            then:
+              - ...
+
 .. _remote-receiver-binary-sensor:
 
 Binary Sensor

components/sensor/mics_4514.rst

@@ -10,9 +10,12 @@ This component exposes the different gas concentration sensors from the `MiCS-45
 
 .. note::
 
+
     The sensor has a 3-minute warmup period where data is unreliable and ESPHome will only start publishing sensor values after this time.
     If the sensor was already powered only, such as if you restarted or updated your ESPHome device, then it will start publishing immediately.
 
+    The :ref:`I²C Bus <i2c>` is required to be set up in your configuration for this sensor to work.
+
 .. code-block:: yaml
 
     # Example configuration entry

components/time/index.rst

@@ -39,12 +39,19 @@ This :ref:`Condition <config-condition>` checks if time has been set and is vali
 
 .. code-block:: yaml
 
+    # Example configuration
     on_...:
       if:
         condition:
           time.has_time:
         then:
           - logger.log: Time has been set and is valid!
+    
+    # Example lambda
+    lambda: |-
+        if (id(my_time).now().is_valid()) {
+          //do something here
+        }
 
 .. _time-on_time:
 

components/uart.rst

@@ -30,12 +30,12 @@ In some cases only **TX** or **RX** exists as the device at the other end only a
     On the ESP32, this component uses the hardware UART units and is thus very accurate. On the ESP8266 however,
     ESPHome has to use a software implementation as there are no other hardware UART units available other than the
     ones used for logging. Therefore the UART data on the ESP8266 can have occasional data glitches especially with
-    higher baud rates..
+    higher baud rates. 
 
 .. note::
 
     From ESPHome 2021.8 the ``ESP8266SoftwareSerial`` UART ``write_byte`` function had the parity bit fixed to be correct
-    for the data being sent. This could cause unexpected issues if you are using the Software Serial and have devices that
+    for the data being sent. This could cause unexpected issues if you are using the Software UART and have devices that
     explicity check the parity. Most likely you will need to flip the ``parity`` flag in YAML.
 
 
@@ -65,7 +65,7 @@ Configuration variables:
 Hardware UARTs
 --------------
 
-Whenever possible, ESPHome will use the hardware UART unit on the processor for fast and accurate communication.
+Whenever possible, ESPHome will use the hardware UART unit on the ESP8266 for fast and accurate communication.
 When the hardware UARTs are all occupied, ESPHome will fall back to a software implementation that may not
 be accurate at higher baud rates.
 
@@ -74,12 +74,16 @@ be accurate at higher baud rates.
 logger and leave others available. If you have configured the logger to use a different hardware UART, the pins
 used for hardware sharing change accordingly.
 
-The ESP32 has three UARTs. Any pair of GPIO pins can be used, as long as they support the proper output/input modes.
+The ESP32 has three UARTs. ESP32 lite variant chips (ESP32-S3, ESP32-C3, ESP32-S2, etc) may have fewer UARTs (usually two). Any pair of GPIO pins can be used, as long as they support the proper output/input modes. 
 
 The ESP8266 has two UARTs; the second of which is TX-only. Only a limited set of pins can be used. ``UART0`` may
 use either ``tx_pin: GPIO1`` and ``rx_pin: GPIO3``, or ``tx_pin: GPIO15`` and ``rx_pin: GPIO13``. ``UART1`` must
 use ``tx_pin: GPIO2``. Any other combination of pins will result in use of a software UART.
 
+.. note::
+
+    The the Software UART is only available on the ESP8266. It is not available on ESP32 and variants.
+
 .. _uart-write_action:
 
 ``uart.write`` Action