Merge pull request #10 from esphome/next

Next

.github/workflows/component-image.yml

@@ -14,6 +14,7 @@ jobs:
     runs-on: ubuntu-latest
     outputs:
       name: ${{ steps.get_component.outputs.name }}
+      name_lower: ${{ steps.get_component.outputs.name_lower }}
       comment_id: ${{ steps.create-comment.outputs.result }}
     steps:
       - name: Comment
@@ -35,6 +36,7 @@ jobs:
           comment="${{ github.event.comment.body }}"
           component=$(echo $comment | sed -n 's/^@esphomebot generate image //p')
           echo "name=$component" >> $GITHUB_OUTPUT
+          echo "name_lower=${component,,}" >> $GITHUB_OUTPUT
 
   generate:
     name: Generate
@@ -52,7 +54,7 @@ jobs:
         id: upload-artifact
         with:
           name: ${{ needs.prepare.outputs.name }}
-          path: ${{ needs.prepare.outputs.name }}.svg
+          path: ${{ needs.prepare.outputs.name_lower }}.svg
 
       - name: Update Comment
         uses: actions/[email protected]

Makefile

@@ -1,5 +1,5 @@
 ESPHOME_PATH = ../esphome
-ESPHOME_REF = 2024.8.0
+ESPHOME_REF = 2024.8.3
 PAGEFIND_VERSION=1.1.0
 PAGEFIND=pagefind
 NET_PAGEFIND=../pagefindbin/pagefind

changelog/2024.8.0.rst

@@ -50,6 +50,26 @@ Thank you for your support
 We would like to thank all Home Assistant Cloud subscribers for their support. It allows `Nabu Casa <https://nabucasa.com/>`__ to
 employ two developers to maintain and further develop the ESPHome project.
 
+Release 2024.8.1 - August 28
+----------------------------
+
+- [lvgl] Bug fixes :esphomepr:`7338` by :ghuser:`clydebarrow`
+- [core] Clean build if the loaded integrations changed :esphomepr:`7344` by :ghuser:`clydebarrow`
+- [lvgl] Fix race condition involving numbers, switches etc. :esphomepr:`7345` by :ghuser:`clydebarrow`
+- [api] Fix sending the ``once`` flag on ha entity subscription :esphomepr:`7357` by :ghuser:`jesserockz`
+
+Release 2024.8.2 - September 3
+------------------------------
+
+- [datetime] Fix templated args :esphomepr:`7368` by :ghuser:`jesserockz`
+- Enable IPv6 when manual IPv4 is enabled :esphomepr:`7381` by :ghuser:`HeMan`
+- [core] Only clean build files with esp-idf :esphomepr:`7388` by :ghuser:`jesserockz`
+
+Release 2024.8.3 - September 3
+------------------------------
+
+- Bump Dockerfile dependencies :esphomepr:`7386` by :ghuser:`jesserockz`
+
 Full list of changes
 --------------------
 

components/binary_sensor/ble_presence.rst

@@ -82,35 +82,29 @@ Setting Up Devices
 ------------------
 
 To set up binary sensors for specific BLE beacons you first have to know which MAC address
-to track. Most devices show this screen in some setting menu. If you don't know the MAC address,
+to track. Most devices show this screen in some settings menu. If you don't know the MAC address,
 however, you can use the ``esp32_ble_tracker`` hub without any binary sensors attached and read through
 the logs to see discovered Bluetooth Low Energy devices.
 
-.. code-block:: yaml
-
-    # Example configuration entry for finding MAC addresses
-    esp32_ble_tracker:
-
-Using the configuration above, first you should see a ``Starting scan...`` debug message at
-boot-up. Then, when a BLE device is discovered, you should see messages like
-``Found device XX:XX:XX:XX:XX:XX`` together with some information about their
-address type and advertised name. If you don't see these messages, your device is unfortunately
-currently not supported.
-
 .. code-block:: yaml
 
     # Example configuration entry for finding
-    # Service UUIDs and iBeacon UUIDs and identifiers
+    # MAC addresses, Service UUIDs, iBeacon UUIDs, and identifiers
     esp32_ble_tracker:
+      on_ble_advertise:
+        - then:
 
     logger:
       level: VERY_VERBOSE
 
-You can increase the :ref:`log level <logger-log_levels>` to ``VERY_VERBOSE`` to review detailed
-data for each discovered BLE device. This will make ESPHome print Service UUIDs, iBeacon UUIDs,
-iBeacon major and minor identifiers, BLE manufacturer data, RSSI and other data useful for
-debugging purposes. Note that this is useful only during set-up and a less verbose log level
-should be specified afterwards.
+Using the configuration above, first, you should see a ``Starting scan...`` debug message at
+boot-up. Then, when a BLE device is discovered, you should see messages like
+``Parse Result:`` together with some information about their MAC address, address type,
+advertised name, Service UUIDs, iBeacon UUIDs, iBeacon major and minor identifiers,
+BLE manufacturer data, RSSI, and other data useful for debugging purposes.
+Note that this is useful only during set-up and a less verbose log level
+should be specified afterwards. If you don't see these messages, your device is unfortunately
+currently not supported.
 
 Please note that devices that show a ``RANDOM`` address type in the logs probably use a privacy
 feature called Resolvable Private Addresses to avoid BLE tracking. Since their MAC-address periodically

components/binary_sensor/udp.rst

@@ -0,0 +1,49 @@
+UDP Binary Sensor
+=================
+
+.. seo::
+    :description: Instructions for setting up a UDP binary sensor.
+    :image: udp.svg
+
+The ``udp`` binary sensor platform allows you to receive binary sensor data directly from another ESPHome node.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    binary_sensor:
+      - platform: udp
+        id: switch_status
+        provider: light-switch
+        remote_id: light_switch
+
+Configuration variables
+-----------------------
+
+-  **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
+-  **provider** (**Required**, string): The name of the provider node.
+-  **remote_id** (*Optional*, :ref:`config-id`): The ID of the original binary sensor in the provider device. If not specified defaults to the ID configured with ``id:``.
+-  **name** (*Optional*, string): The name of the binary sensor.
+-  **internal** (*Optional*, boolean): Whether the sensor should be exposed via API (e.g. to Home Assistant.) Defaults to ``true`` if name is not set, required if name is provided.
+-  All other options from :ref:`Binary Sensor <config-binary_sensor>`.
+
+At least one of ``id`` and ``remote_id`` must be configured.
+
+Publishing to Home Assistant
+----------------------------
+
+Typically this type of binary sensor would be used for internal automation purposes rather than having it published back to
+Home Assistant, since it would be a duplicate of the original sensor.
+
+If it *is* desired to expose the binary sensor to Home Assistant, then the ``internal:`` configuration setting needs to be explicitly
+set to ``false`` and a name provided.
+Only the state (i.e. binary value) of the remote sensor is received by the consumer, so any other attributes must be explicitly
+configured.
+
+See Also
+--------
+
+- :doc:`/components/udp`
+- :doc:`/components/sensor/index`
+- :ref:`automation`
+- :apiref:`udp/udp_component.h`
+- :ghedit:`Edit`

components/canbus/esp32_can.rst

@@ -26,6 +26,8 @@ Configuration variables:
 
 - **rx_pin** (**Required**, :ref:`Pin <config-pin>`): Receive pin.
 - **tx_pin** (**Required**, :ref:`Pin <config-pin>`): Transmit pin.
+- **rx_queue_len** (**Optional**, int): Length of RX queue.
+- **tx_queue_len** (**Optional**, int): Length of TX queue, 0 to disable.
 - All other options from :ref:`Canbus <config-canbus>`.
 
 .. _esp32-can-bit-rate:

components/ch422g.rst

@@ -0,0 +1,67 @@
+CH422G I/O Expander
+====================
+
+.. seo::
+    :description: Instructions for setting up CH422G digital port expanders in ESPHome.
+    :image: ch422g.svg
+
+
+The CH422G component allows you to use the **CH422G** I/O expander in ESPHome. 
+It uses an :ref:`I²C Bus <i2c>` for communication.
+
+Once configured, you can use any of the 8 available GPIO pins for your projects.
+Within ESPHome they can be used in place of internal GPIO pins in many of ESPHome's components such as the GPIO Binary Sensor or GPIO Switch. They are not usable for PWM or other situations requiring an internal GPIO pin.
+
+.. note::
+
+    This I/O Expander chip is used in the *Waveshare ESP32-S3-Touch-LCD-4.3*
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    ch422g:
+      - id: ch422g_hub
+        address: 0x24
+      
+    # Individual outputs
+    switch:
+      - platform: gpio
+        name: CH422G Pin 0
+        pin:
+          ch422g: ch422g_hub
+          number: 0
+          mode:
+            output: true
+          inverted: false
+
+
+Configuration variables:
+************************
+
+- **id** (**Required**, :ref:`config-id`): The id to use for this ``ch422g`` component.
+- **address** (*Optional*, int): The I²C address of the driver.
+  Defaults to ``0x24``.
+- **restore_value** (*Optional*, boolean): Writes default flags on setup, overriding values from chips cache.
+  Defaults to ``false``.
+
+
+
+Pin configuration variables:
+****************************
+
+- **ch422g** (**Required**, :ref:`config-id`): The id of the ``ch422g`` component of the pin.
+- **number** (**Required**, int): The pin number. Valid numbers are 0-7.
+- **inverted** (*Optional*, boolean): If all read and written values
+  should be treated as inverted. Defaults to ``false``.
+- **mode** (*Optional*, string): A pin mode to set the pin at. One of ``INPUT`` or ``OUTPUT``.
+
+
+See Also
+--------
+
+- :ref:`i2c`
+- :doc:`switch/gpio`
+- :doc:`binary_sensor/gpio`
+- `CH422G datasheet <https://www.wch-ic.com/downloads/file/315.html?time=2024-07-29%2002:02:32&code=Fxex1sTRHysGLS6ALgh7PTOOZnAACY6KTQx05vzD>`__ 
+- :apiref:`ch422g/ch422g.h`
+- :ghedit:`Edit`

components/climate/climate_ir.rst

@@ -162,6 +162,7 @@ The Daikin ARC remotes (``daikin_arc`` climate, ``daikin_arc417``, ``daikin_arc4
   - ``yaa``
   - ``yac``
   - ``yac1fb9``
+  - ``yx1ff``
 
 .. code-block:: yaml
 
@@ -248,7 +249,7 @@ These air conditioners support two protocols: Midea and Coolix. Therefore, when
 
 .. note::
 
-    - While they are identified as separate models here, the ``RAC-PT1411HWRU-C`` and ``RAC-PT1411HWRU-C`` are
+    - While they are identified as separate models here, the ``RAC-PT1411HWRU-C`` and ``RAC-PT1411HWRU-F`` are
       in fact the same physical model/unit. They are separated here only because different IR codes are used
       depending on the desired unit of measurement. This only affects how temperature is displayed on the unit itself.
 

components/datetime/index.rst

@@ -121,7 +121,7 @@ The ``date`` provided can be in one of 3 formats:
         id: my_datetime_date
         date: !lambda |-
           // Return an ESPTime struct
-          return {.day_of_month: 4, .month: 12, .year: 2023};
+          return {.day_of_month = 4, .month = 12, .year = 2023};
 
 Configuration variables:
 
@@ -192,7 +192,7 @@ The ``time`` provided can be in one of 3 formats:
         id: my_datetime_time
         time: !lambda |-
           // Return an ESPTime struct
-          return {.second: 56, .minute: 34, .hour: 12};
+          return {.second = 56, .minute = 34, .hour = 12};
 
 Configuration variables:
 
@@ -266,7 +266,7 @@ The ``datetime`` provided can be in one of 3 formats:
         id: my_datetime
         datetime: !lambda |-
           // Return an ESPTime struct
-          return {.second: 56, .minute: 34, .hour: 12, .day_of_month: 31, .month: 12, .year: 2024};
+          return {.second = 56, .minute = 34, .hour = 12, .day_of_month = 31, .month = 12, .year = 2024};
 
 Configuration variables:
 

components/display/ili9xxx.rst

@@ -61,9 +61,8 @@ beyond the basic SPI connections, and a reasonable amount of RAM, it is not well
         model: ili9341
         dc_pin: GPIOXX
         reset_pin: GPIOXX
-        lambda: |-
-          it.fill(COLOR_BLACK);
-          it.print(0, 0, id(my_font), id(my_red), TextAlign::TOP_LEFT, "Hello World!");
+        invert_colors: false
+        show_test_card: true
 
 Configuration variables:
 ************************
@@ -101,7 +100,7 @@ Configuration variables:
     - **offset_width** (*Optional*, int): Specify an offset for the x-direction of the display, typically used when an LCD is smaller than the maximum supported by the driver chip. Default is 0
     - **offset_height** (*Optional*, int): Specify an offset for the y-direction of the display. Default is 0.
 
-- **invert_colors** (*Optional*): With this boolean option you can invert the display colors.
+- **invert_colors** (**Required**): Specifies whether the display colors should be inverted. Options are ``true`` or ``false`` - if you are unsure, use ``false`` and change if the colors are not as expected.
 - **pixel_mode** (*Optional*): Allows forcing the display into 18 or 16 bit mode. Options are ``18bit`` or ``16bit``. If unspecified, the pixel mode will be determined by the model choice. Not all displays will work in both modes.
 - **rotation** (*Optional*): Rotate the display presentation in software. Choose one of ``0°``, ``90°``, ``180°``, or ``270°``. This option cannot be used with ``transform``.
 - **transform** (*Optional*): Transform the display presentation using hardware. All defaults are ``false``. This option cannot be used with ``rotation``.
@@ -265,6 +264,7 @@ This config rotates the display into landscape mode using the driver chip.
           mirror_x: false
           mirror_y: true
         color_order: bgr
+        invert_colors: true
         data_rate: 80MHz
         cs_pin: GPIOXX
         dc_pin: GPIO13

components/display/rpi_dpi_rgb.rst

@@ -77,6 +77,7 @@ Configuration variables:
 - **pclk_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The PCLK pin.
 - **hsync_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The Horizontal sync pin.
 - **vsync_pin** (**Required**, :ref:`Pin Schema <config-pin_schema>`): The Vertical sync pin.
+- **enable_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The ENABLE pin.
 - **reset_pin** (*Optional*, :ref:`Pin Schema <config-pin_schema>`): The RESET pin.
 - **hsync_pulse_width** (*Optional*, int): The horizontal sync pulse width.
 - **hsync_front_porch** (*Optional*, int): The horizontal front porch length.

components/display/st7701s.rst

@@ -130,6 +130,8 @@ The ``init_sequence`` requires a list of elements, one of which may be a single
 sequence (the default and currently the only sequence is 1), the remainder must be byte arrays providing additional
 init commands, each consisting of a command byte followed by zero or more data bytes.
 
+A delay may be specified with ``delay <N>ms``
+
 These will be collected and sent to the display via SPI during initialisation.
 
 Example configurations
@@ -165,6 +167,7 @@ Seeed Sensecap Indicator
         pclk_pin: 21
         init_sequence:
           - 1 # select canned init sequence number 1
+          - delay 5ms
           - [ 0xE0, 0x1F ]  # Set sunlight readable enhancement
         data_pins:
           red:

components/light/esp32_rmt_led_strip.rst

@@ -34,6 +34,7 @@ Configuration variables
       "ESP32-C3", "0, 1"
 
 - **chipset** (**Required**, enum): The chipset to apply known timings from. Not used if specifying the timings manually, see below.
+    - ``WS2811``
     - ``WS2812``
     - ``SK6812``
     - ``APA106``
@@ -67,6 +68,10 @@ please consider adding support to the codebase and add it to the list above.
 - **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.
+- **reset_high** (*Optional*, :ref:`config-time`): The time to hold the data line high after writing
+  the state. Defaults to ``0 us``.
+- **reset_low** (*Optional*, :ref:`config-time`): The time to hold the data line low after writing
+  the state. Defaults to ``0 us``.
 
 See Also
 --------