Merge pull request #4500 from esphome/bump-2024.12.0b1

2024.12.0b1
2025-01-26 22:21:38 +01:00 · 2024-12-11 21:19:00 +13:00 · 2024-12-11 21:19:00 +13:00 · f6822e7094
commit f6822e7094
parent 1e973ba61b 2247710867
39 changed files with 881 additions and 41 deletions
--- a/2
+++ b/2
@ -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         = 2024.11.3
+PROJECT_NUMBER         = 2024.12.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
--- a/2
+++ b/2
@ -1,5 +1,5 @@
 ESPHOME_PATH = ../esphome
-ESPHOME_REF = 2024.11.3
+ESPHOME_REF = 2024.12.0b1
 PAGEFIND_VERSION=1.1.1
 PAGEFIND=pagefind
 NET_PAGEFIND=../pagefindbin/pagefind
--- a/_static/changelog-2024.12.0.png
+++ b/_static/changelog-2024.12.0.png
--- a/_static/version
+++ b/_static/version
@ -1 +1 @@
-2024.11.3
+2024.12.0b1
--- a/changelog/2024.11.0.rst
+++ b/changelog/2024.11.0.rst
@ -34,8 +34,17 @@ actually compile anything.
 OpenTherm
 ---------

-This release brings :doc:`/components/opentherm` support to ESPHome. Please see the :doc:`documentation </components/opentherm>` for detailed information about
-it and how to use it.
+This release brings :doc:`/components/opentherm` support to ESPHome. Please see the
+:doc:`documentation </components/opentherm>` for detailed information about it and how to use it.
+
+ESPHome ``armv7`` Docker Support
+--------------------------------
+
+We will be retiring ESPHome's Docker support for ``armv7`` hardware in the February 2025 release.
+
+This is due to both waning support as it relates to tooling and performance reasons. We strongly recommend moving to a
+more modern architecture, especiallly if you're using the ESPHome Device Compiler to build/compile firmware for your
+devices.

 Release 2024.11.1 - November 22
 -------------------------------
--- a/changelog/2024.12.0.rst
+++ b/changelog/2024.12.0.rst
@ -0,0 +1,226 @@
+ESPHome 2024.12.0 - 18th December 2024
+======================================
+
+.. seo::
+    :description: Changelog for ESPHome 2024.12.0.
+    :image: /_static/changelog-2024.12.0.png
+    :author: Jesse Hills
+    :author_twitter: @jesserockz
+
+.. imgtable::
+    :columns: 2
+
+    Seeed Studio MR60BHA2 mmWave, components/seeed_mr60bha2, seeed_mr60bha2.jpg
+    Seeed Studio MR60FDA2 mmWave, components/seeed_mr60fda2, seeed_mr60fda2.jpg
+    H-bridge Switch, components/switch/hbridge, hbridge-relay.jpg
+    Switch Binary Sensor, components/binary_sensor/switch, electric-switch.svg, dark-invert
+
+
+ESP-IDF
+-------
+
+ESPHome has now updated the core ESP32 code to use `ESP-IDF <https://github.com/espressif/esp-idf/>`__ 5.1.5.
+This is a major upgrade and should bring more features, chip support (Most notably the ESP32-C6 that people keep raving on about)
+and in general more stability.
+
+To acommodate this change, ESPHome has moved away from the "official" platformio provided ESP32 platform,
+and is now using a community fork `pioarduino/platform-espressif32 <https://github.com/pioarduino/platform-espressif32>`__ as platformio
+has decided to stop providing ESP-IDF updates to their platform for Espressif chips. As a user, you should not notice any difference.
+
+As we are unable to test every single component and board, there might be issues with specific configurations. Please report these in
+the `ESPHome issue tracker <https://github.com/esphome/issues/issues>`__ on GitHub.
+
+
+ESPHome ``armv7`` Docker Support
+--------------------------------
+
+We will be retiring ESPHome's Docker support for ``armv7`` hardware in the February 2025 release.
+
+This is due to both waning support as it relates to tooling and performance reasons. We strongly recommend moving to a
+more modern architecture, especially if you're using the ESPHome Device Compiler to build/compile firmware for your
+devices.
+
+
+
+Full list of changes
+--------------------
+
+New Components
+^^^^^^^^^^^^^^
+
+- Add: Seeed Studio mr60fda2 mmwave sensor :esphomepr:`7576` by :ghuser:`limengdu` (new-integration)
+- Add: Seeed Studio MR60BHA2 mmWave Sensor :esphomepr:`7589` by :ghuser:`limengdu` (new-integration)
+
+New Platforms
+^^^^^^^^^^^^^
+
+- binary_sensor for switch state :esphomepr:`7819` by :ghuser:`ssieb` (new-platform)
+- Add H-Bridge switch component :esphomepr:`7421` by :ghuser:`dwmw2` (new-platform)
+
+Breaking Changes
+^^^^^^^^^^^^^^^^
+
+- Fix entity name validation to allow "Off" and "On" :esphomepr:`7821` by :ghuser:`jesserockz` (breaking-change)
+- MQTT sensors handling of publishing NaN values  :esphomepr:`7768` by :ghuser:`kbullet` (breaking-change)
+- Synchronise esp32 boards with platform version 51.03.07 :esphomepr:`7945` by :ghuser:`jesserockz` (breaking-change)
+
+All changes
+^^^^^^^^^^^
+
+- Bump codecov/codecov-action from 4 to 5 :esphomepr:`7771` by :ghuser:`dependabot[bot]`
+- [remote_base] Fix extra comma in dump raw :esphomepr:`7774` by :ghuser:`swoboda1337`
+- [nextion] New trigger `on_buffer_overflow` :esphomepr:`7772` by :ghuser:`edwardtfn`
+- enable rp2040 for online_image :esphomepr:`7769` by :ghuser:`afflux`
+- [nextion] Add publish actions :esphomepr:`7646` by :ghuser:`pkejval`
+- [wifi] Make wifi_channel_() public :esphomepr:`7818` by :ghuser:`nielsnl68`
+- feat(WiFi): Add wifi.configure action :esphomepr:`7335` by :ghuser:`Rapsssito`
+- allow multiple graphical menus :esphomepr:`7809` by :ghuser:`ssieb`
+- Move ``CONF_NAME_ADD_MAC_SUFFIX`` to ``const.py`` :esphomepr:`7820` by :ghuser:`jesserockz`
+- binary_sensor for switch state :esphomepr:`7819` by :ghuser:`ssieb` (new-platform)
+- [nextion] Remove assignment within `if` :esphomepr:`7824` by :ghuser:`kbx81`
+- [ota] `void` functions should return nothing :esphomepr:`7825` by :ghuser:`kbx81`
+- [safe_mode] Remove unused capture :esphomepr:`7826` by :ghuser:`kbx81`
+- [stepper] Remove unnecessary ``#include`` :esphomepr:`7827` by :ghuser:`kbx81`
+- [sx1509] Fix up includes :esphomepr:`7828` by :ghuser:`kbx81`
+- [uart] `void` functions should return nothing :esphomepr:`7829` by :ghuser:`kbx81`
+- [audio] Header modernization :esphomepr:`7832` by :ghuser:`kbx81`
+- [opentherm] Follow variable naming convention :esphomepr:`7833` by :ghuser:`kbx81`
+- [opentherm] Add nolint for 8266 static global :esphomepr:`7837` by :ghuser:`kbx81`
+- [helpers] Add NOLINT for Mutex private field ``handle_`` :esphomepr:`7838` by :ghuser:`kbx81`
+- Add waveshare 1 45 in v2 b support :esphomepr:`7052` by :ghuser:`programmingbgloDE`
+- added Waveshare BWR Mode for the 7.5in Display :esphomepr:`7687` by :ghuser:`JonasB2497`
+- [homeassistant.number] Return when value not set :esphomepr:`7839` by :ghuser:`kbx81`
+- [CI] Add/update some system include paths :esphomepr:`7831` by :ghuser:`kbx81`
+- add on_key trigger to matrix_keypad :esphomepr:`7830` by :ghuser:`ssieb`
+- Add: Seeed Studio mr60fda2 mmwave sensor :esphomepr:`7576` by :ghuser:`limengdu` (new-integration)
+- [lvgl] clang-tidy fixes for #7822 :esphomepr:`7843` by :ghuser:`kbx81`
+- [xiaomi_ble] clang-tidy fixes for #7822 :esphomepr:`7860` by :ghuser:`kbx81`
+- [wireguard] clang-tidy fixes for #7822 :esphomepr:`7859` by :ghuser:`kbx81`
+- [dsmr] clang-tidy fixes for #7822 :esphomepr:`7848` by :ghuser:`kbx81`
+- Fix entity name validation to allow "Off" and "On" :esphomepr:`7821` by :ghuser:`jesserockz` (breaking-change)
+- [camera_web_server] Add ``NOLINT`` due to naming :esphomepr:`7823` by :ghuser:`kbx81`
+- [display_menu_base] clang-tidy fixes for #7822 :esphomepr:`7847` by :ghuser:`kbx81`
+- [nextion] clang-tidy fixes for #7822 :esphomepr:`7852` by :ghuser:`kbx81`
+- [shelly_dimmer] clang-tidy fixes for #7822 :esphomepr:`7844` by :ghuser:`kbx81`
+- [sim800l] clang-tidy fixes for #7822 :esphomepr:`7856` by :ghuser:`kbx81`
+- [nfc, pn532, pn7150, pn7160] clang-tidy fixes for #7822 :esphomepr:`7853` by :ghuser:`kbx81`
+- [output] clang-tidy fixes for #7822 :esphomepr:`7854` by :ghuser:`kbx81`
+- [sun_gtil2] clang-tidy fixes for #7822 :esphomepr:`7858` by :ghuser:`kbx81`
+- [pipsolar] clang-tidy fixes for #7822 :esphomepr:`7855` by :ghuser:`kbx81`
+- [ltr501] clang-tidy fixes for #7822 :esphomepr:`7850` by :ghuser:`kbx81`
+- [cse7766] clang-tidy fixes for #7822 :esphomepr:`7846` by :ghuser:`kbx81`
+- [alarm_control_panel] clang-tidy fixes for #7822 :esphomepr:`7845` by :ghuser:`kbx81`
+- [sprinkler] clang-tidy fixes for #7822 :esphomepr:`7857` by :ghuser:`kbx81`
+- [haier] clang-tidy fixes for #7822 :esphomepr:`7849` by :ghuser:`kbx81`
+- [mqtt] clang-tidy fixes for #7822 :esphomepr:`7851` by :ghuser:`kbx81`
+- [helpers, optional] clang-tidy fixes for #7822 :esphomepr:`7841` by :ghuser:`kbx81`
+- Move ``USE_CAPTIVE_PORTAL`` into all define groups it can be used with :esphomepr:`7863` by :ghuser:`jesserockz`
+- Bump docker/build-push-action from 6.9.0 to 6.10.0 in /.github/actions/build-image :esphomepr:`7866` by :ghuser:`dependabot[bot]`
+- python lint for platform components :esphomepr:`7864` by :ghuser:`tomaszduda23`
+- [max31865] clang-tidy fixes for #7822 :esphomepr:`7876` by :ghuser:`kbx81`
+- [esp32_ble] clang-tidy fixes for #7822 :esphomepr:`7883` by :ghuser:`kbx81`
+- [mqtt] clang-tidy fixes for #7822 :esphomepr:`7877` by :ghuser:`kbx81`
+- [uln2003] clang-tidy fixes for #7822 :esphomepr:`7881` by :ghuser:`kbx81`
+- [rotary_encoder] clang-tidy fixes for #7822 :esphomepr:`7880` by :ghuser:`kbx81`
+- [pca6416a, pca9554] clang-tidy fixes for #7822 :esphomepr:`7879` by :ghuser:`kbx81`
+- [nextion] clang-tidy fixes for #7822 :esphomepr:`7878` by :ghuser:`kbx81`
+- [various] clang-tidy fixes for #7822 :esphomepr:`7874` by :ghuser:`kbx81`
+- [logger] clang-tidy fixes for #7822 :esphomepr:`7875` by :ghuser:`kbx81`
+- [ezo] clang-tidy fixes for #7822 :esphomepr:`7873` by :ghuser:`kbx81`
+- [apds9306] clang-tidy fixes for #7822 :esphomepr:`7872` by :ghuser:`kbx81`
+- [dht] clang-tidy fixes for #7822 :esphomepr:`7871` by :ghuser:`kbx81`
+- [network] clang-tidy fixes for #7822 :esphomepr:`7870` by :ghuser:`kbx81`
+- [lvgl] Make image update via lambda work :esphomepr:`7886` by :ghuser:`clydebarrow`
+- [deep_sleep] fix deep_sleep not keeping awake when sleep_duration is defined :esphomepr:`7885` by :ghuser:`makstech`
+- [hx711] clang-tidy fixes for #7822 :esphomepr:`7900` by :ghuser:`kbx81`
+- [modbus_controller] Clang fixes :esphomepr:`7899` by :ghuser:`kbx81`
+- Add H-Bridge switch component :esphomepr:`7421` by :ghuser:`dwmw2` (new-platform)
+- [CI] Bump GHA runners to ``ubuntu-24.04`` :esphomepr:`7905` by :ghuser:`kbx81`
+- [font et. al.] Remove explicit check for pillow installed. :esphomepr:`7891` by :ghuser:`clydebarrow`
+- [CI] Update clang-tidy to 18.1.3 :esphomepr:`7822` by :ghuser:`kbx81`
+- MQTT sensors handling of publishing NaN values  :esphomepr:`7768` by :ghuser:`kbullet` (breaking-change)
+- [ble] Allow setting shorter name for ble advertisements :esphomepr:`7867` by :ghuser:`jesserockz`
+- [font] Restore correct default glyphs for bitmap fonts :esphomepr:`7907` by :ghuser:`clydebarrow`
+- [helpers] clang-tidy fix for #7706 :esphomepr:`7909` by :ghuser:`kbx81`
+- [docker] Fix clang-tidy installation :esphomepr:`7910` by :ghuser:`kbx81`
+- [sntp] Resolve warnings from ESP-IDF 5.x :esphomepr:`7913` by :ghuser:`clydebarrow`
+- Add strftime variant with background color :esphomepr:`7714` by :ghuser:`mikosoft83`
+- [i2s_audio] Bugfix: Follow configured bits per sample :esphomepr:`7916` by :ghuser:`kahrendt`
+- Haier AC quiet mode switch fix :esphomepr:`7902` by :ghuser:`paveldn`
+- [CI] Update clang-tidy to 18.1.8 :esphomepr:`7915` by :ghuser:`syssi`
+- [i2s_audio] Speaker type fix :esphomepr:`7919` by :ghuser:`kbx81`
+- [esp32_rmt_led_strip] Add ``COMPONENT_SCHEMA`` extending :esphomepr:`7918` by :ghuser:`jesserockz`
+- [esp32] Use pioarduino + IDF 5.1.5 as default for IDF builds :esphomepr:`7706` by :ghuser:`kbx81`
+- Bump actions/cache from 4.1.2 to 4.2.0 :esphomepr:`7926` by :ghuser:`dependabot[bot]`
+- Bump actions/cache from 4.1.2 to 4.2.0 in /.github/actions/restore-python :esphomepr:`7925` by :ghuser:`dependabot[bot]`
+- Add OCI Image Labels  :esphomepr:`7924` by :ghuser:`Passific`
+- Move docker oci labels to correct image :esphomepr:`7927` by :ghuser:`jesserockz`
+- Update project description :esphomepr:`7928` by :ghuser:`jesserockz`
+- [modbus] More clean-up :esphomepr:`7921` by :ghuser:`kbx81`
+- Add: Seeed Studio MR60BHA2 mmWave Sensor :esphomepr:`7589` by :ghuser:`limengdu` (new-integration)
+- Optimize QMC5883L reads :esphomepr:`7889` by :ghuser:`dnschneid`
+- [display] Fix strftime overload ignoring alignment :esphomepr:`7937` by :ghuser:`jesserockz`
+- Add font anti-aliasing for grayscale display :esphomepr:`7934` by :ghuser:`koreapyj`
+- Bump pypa/gh-action-pypi-publish from 1.12.2 to 1.12.3 :esphomepr:`7941` by :ghuser:`dependabot[bot]`
+- [adc] Split files by platform :esphomepr:`7940` by :ghuser:`edwardtfn`
+- [const] Move ``CONF_TEMPERATURE_COMPENSATION`` to common const.py :esphomepr:`7943` by :ghuser:`jesserockz`
+- [lvgl] Fix image `mode` property (Bugfix) :esphomepr:`7938` by :ghuser:`clydebarrow`
+- [lvgl] Add `on_change` event :esphomepr:`7939` by :ghuser:`clydebarrow`
+- Synchronise esp32 boards with platform version 51.03.07 :esphomepr:`7945` by :ghuser:`jesserockz` (breaking-change)
+- [i2c] Use correct macro to determine number of i2c peripherals for idf :esphomepr:`7947` by :ghuser:`jesserockz`
+
+
+Past Changelogs
+---------------
+
+- :doc:`2024.11.0`
+- :doc:`2024.10.0`
+- :doc:`2024.9.0`
+- :doc:`2024.8.0`
+- :doc:`2024.7.0`
+- :doc:`2024.6.0`
+- :doc:`2024.5.0`
+- :doc:`2024.4.0`
+- :doc:`2024.3.0`
+- :doc:`2024.2.0`
+- :doc:`2023.12.0`
+- :doc:`2023.11.0`
+- :doc:`2023.10.0`
+- :doc:`2023.9.0`
+- :doc:`2023.8.0`
+- :doc:`2023.7.0`
+- :doc:`2023.6.0`
+- :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`
--- a/changelog/index.rst
+++ b/changelog/index.rst
@ -2,7 +2,7 @@ Changelog
 =========

 .. redirect::
-    :url: /changelog/2024.11.0.html
+    :url: /changelog/2024.12.0.html

 .. toctree::
    :glob:
--- a/components/binary_sensor/nextion.rst
+++ b/components/binary_sensor/nextion.rst
@ -87,6 +87,50 @@ should be prefixed with the page name (page0/page1).

 ``nextion_component_name: page0.r0``

+.. _binary_sensor-nextion-publish_action:
+
+``binary_sensor.nextion.publish`` Action
+----------------------------------------
+
+You can also publish a state to a Nextion binary sensor from elsewhere in your YAML file
+with the ``binary_sensor.nextion.publish`` action.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    binary_sensor:
+      - platform: nextion
+        id: nextion_bsensor
+        ...
+    # in some trigger
+    on_...:
+      - binary_sensor.nextion.publish:
+          id: nextion_bsensor
+          state: true
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+      # Templated
+      - binary_sensor.nextion.publish:
+          id: nextion_bsensor
+          state: !lambda 'return true;'
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+
+Configuration variables:
+
+- **id** (**Required**, :ref:`config-id`): The ID of the Nextion switch.
+- **state** (**Required**, string, :ref:`templatable <config-templatable>`): The boolean state to publish.
+- **publish_state** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Home Assistant.
+  Default is true.
+- **send_to_nextion** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Nextion
+  display which will update component. Default is true.
+
+.. note::
+
+    This action can also be written in lambdas. See :ref:`nextion_binary_sensor_lambda_calls`
+
 .. _nextion_binary_sensor_lambda_calls:

 Lambda Calls
--- a/components/binary_sensor/switch.rst
+++ b/components/binary_sensor/switch.rst
@ -0,0 +1,36 @@
+.. _switch-binary-sensor:
+
+Switch Binary Sensor
+====================
+
+.. seo::
+    :description: Instructions for setting up switch binary sensors with ESPHome.
+
+The Switch Binary Sensor platform allows you to view the state of any switch component as a
+read-only binary sensor.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    binary_sensor:
+      - platform: switch
+        name: "Output state"
+        source_id: relay1
+
+    switch:
+      - platform: gpio
+        id: relay1
+        pin: GPIOXX
+
+Configuration variables:
+------------------------
+
+- **source_id** (**Required**, :ref:`config-id`): The source switch to observe.
+- All other options from :ref:`Binary Sensor <config-binary_sensor>`.
+
+See Also
+--------
+
+- :doc:`/components/binary_sensor/index`
+- :apiref:`switch/binary_sensor/switch_binary_sensor.h`
+- :ghedit:`Edit`
--- a/components/display/nextion.rst
+++ b/components/display/nextion.rst
@ -68,6 +68,7 @@ Configuration variables:
 - **on_wake** (*Optional*, :ref:`Action <config-action>`): An action to be performed when the Nextion wakes up. See :ref:`Nextion Automation <nextion-on_sleep>`.
 - **on_page** (*Optional*, :ref:`Action <config-action>`): An action to be performed after a page change. See :ref:`Nextion Automation <nextion-on_page>`.
 - **on_touch** (*Optional*, :ref:`Action <config-action>`): An action to be performed after a touch event (press or release). See :ref:`Nextion Automation <nextion-on_touch>`.
+- **on_buffer_overflow** (*Optional*, :ref:`Action <config-action>`): An action to be performed when the Nextion reports a buffer overflow. See :ref:`Nextion Automation <nextion-on_buffer_overflow>`.

 .. _display-nextion_lambda:

@ -281,6 +282,22 @@ The following arguments will be available:
          ESP_LOGD("nextion.on_touch", "Component Id: %i", component_id);
          ESP_LOGD("nextion.on_touch", "Event type: %s", touch_event ? "Press" : "Release");

+.. _nextion-on_buffer_overflow:
+
+``on_buffer_overflow``
+**********************
+
+This automation is triggered when the Nextion display reports a serial buffer overflow.
+When this happens, the Nextion's buffer will continue to receive the new instructions, but all previous instructions are lost and the Nextion queue may get out of sync.
+This automation will allow you handle this situation nicelly, like repeating some command to Nextion or restarting the system.
+
+.. code-block:: yaml
+
+    on_buffer_overflow:
+      then:
+        lambda: |-
+          ESP_LOGW("nextion.on_buffer_overflow", "Nextion reported a buffer overflow event!");
+
 .. _nextion_upload_tft_file:

 Uploading A TFT File
--- a/components/display/waveshare_epaper.rst
+++ b/components/display/waveshare_epaper.rst
@ -83,6 +83,7 @@ Configuration variables:

  - ``1.54in``
  - ``1.54inv2``
+  - ``1.54inv2-b`` - Black/White/Red
  - ``2.13in`` - not tested
  - ``2.13in-ttgo`` - T5_V2.3 tested. Also works for Wemos D1 Mini ePaper Shield 2.13 1.0.0 "LOLIN"
  - ``2.13in-ttgo-b73`` - T5_V2.3 with B73 display tested
@ -108,6 +109,7 @@ Configuration variables:
  - ``7.50in``
  - ``7.50in-bV2`` - also supports v3, B/W rendering only
  - ``7.50in-bV3`` - display with the '(V3)' sticker on the back, B/W rendering only
+  - ``7.50in-bV3-bwr`` - display with the '(V3)' sticker on the back, BWR rendering enabled (uses double the amount of RAM for the display buffer as B/W rendering)
  - ``7.50in-bc`` - display with version sticker '(C)' on the back, B/W rendering only
  - ``7.50inV2`` - Can't use with an ESP8266 as it runs out of RAM
  - ``7.50inV2alt`` (alternative version to the above ``7.50inV2``)
--- a/components/esp32_ble.rst
+++ b/components/esp32_ble.rst
@ -11,7 +11,7 @@ can run.
 .. warning::

    The BLE software stack on the ESP32 consumes a significant amount of RAM on the device.
-    
+
    **Crashes are likely to occur** if you include too many additional components in your device's
    configuration. Memory-intensive components such as :doc:`/components/voice_assistant` and other
    audio components are most likely to cause issues.
@ -36,6 +36,11 @@ Configuration variables:

 - **enable_on_boot** (*Optional*, boolean): If enabled, the BLE interface will be enabled on boot. Defaults to ``true``.

+- **name** (*Optional*, string): The name of the BLE device.
+    - Defaults to the hostname of the device.
+    - Must be 20 characters or less.
+    - Must be 13 characters or less when using ``name_add_mac_suffix: true`` - :ref:`esphome-mac_suffix`.
+
 ``ble.disable`` Action
 -----------------------

--- a/components/images/seeed_mr60bha2.jpg
+++ b/components/images/seeed_mr60bha2.jpg
--- a/components/images/seeed_mr60fda2.jpg
+++ b/components/images/seeed_mr60fda2.jpg
--- a/components/lvgl/index.rst
+++ b/components/lvgl/index.rst
@ -125,7 +125,7 @@ The following configuration variables apply to the main ``lvgl`` component, in o


 - **resume_on_input** (*Optional*, boolean): If LVGL is paused and the user interacts with the screen, resume the activity of LVGL. Defaults to ``true``. "Interacts" means to release a touch or button, or rotate an encoder.
- **color_depth** (*Optional*, string): The color deph at which the contents are generated. Currently only ``16`` is supported (RGB565, 2 bytes/pixel), which is the default value.
+- **color_depth** (*Optional*, string): The color depth at which the contents are generated. Currently only ``16`` is supported (RGB565, 2 bytes/pixel), which is the default value.
 - **buffer_size** (*Optional*, percentage): The percentage of screen size to allocate buffer memory. Default is ``100%`` (or ``1.0``). For devices without PSRAM, the recommended value is ``25%``.
 - **draw_rounding** (*Optional*, int): An optional value to use for rounding draw areas to a specified boundary. Defaults to 2. Useful for displays that require draw windows to be on specified boundaries (usually powers of 2.)
 - **log_level** (*Optional*, string): Set the logger level specifically for the messages of the LVGL library: ``TRACE``, ``INFO``, ``WARN``, ``ERROR``, ``USER``, ``NONE``. Defaults to ``WARN``.
--- a/components/lvgl/widgets.rst
+++ b/components/lvgl/widgets.rst
@ -311,7 +311,8 @@ If the ``adv_hittest`` :ref:`flag <lvgl-widget-flags>` is enabled the arc can be

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the knob changes the value of the arc. The new value is returned in the variable ``x``.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the arc value changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated when the arc value is changed by user interaction. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers which also return the value in ``x``.

 **Example:**
@ -347,7 +348,7 @@ If the ``adv_hittest`` :ref:`flag <lvgl-widget-flags>` is enabled the arc can be

 .. note::

-    The ``on_value`` trigger is sent as the arc knob is dragged or changed with keys. The event is sent *continuously* while the arc knob is being dragged; this generally has a negative effect on performance. To mitigate this, consider using a :ref:`universal interaction trigger <lvgl-automation-triggers>` like ``on_release``, to get the ``x`` variable once after the interaction has completed.
+    The ``on_value`` and ``on_change`` triggers are sent as the arc knob is dragged or changed with keys. The event is sent *continuously* while the arc knob is being dragged; this generally has a negative effect on performance. To mitigate this, consider using a :ref:`universal interaction trigger <lvgl-automation-triggers>` like ``on_release``, to get the ``x`` variable once after the interaction has completed.

 The ``arc`` can be also integrated as a :doc:`Number </components/number/lvgl>` or :doc:`Sensor </components/sensor/lvgl>` component.

@ -429,7 +430,8 @@ A notable state is ``checked`` (boolean) which can have different styles applied

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated after clicking. If ``checkable`` is ``true``, the boolean variable ``x``, representing the checked state, may be used by lambdas within this trigger.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated after clicking. If ``checkable`` is ``true``, the boolean variable ``x``, representing the checked state, may be used by lambdas within this trigger.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the checked value changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers.

 **Example:**
@ -630,7 +632,8 @@ The checkbox widget is made internally from a *tick box* and a label. When the c

 **Triggers:**

-``on_value`` :ref:`trigger <actions-trigger>` is activated when toggling the checkbox. The boolean variable ``x``, representing the checkbox's state, may be used by lambdas within this trigger.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated when interactively toggling the checkbox. The boolean variable ``x``, representing the checkbox's state, may be used by lambdas within this trigger.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the checkbox is toggled, either by user interaction or programmatically. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers which also return the value in ``x``.

 **Example:**
@ -701,7 +704,8 @@ The Dropdown widget is built internally from a *button* part and a *list* part (

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated only when you select an item from the list. The new selected index is returned in the variable ``x``. The :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers also apply, and they also return the selected index in ``x``.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated only when the user selects an item from the list. The new selected index is returned in the variable ``x``. The :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers also apply, and they also return the selected index in ``x``.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated the selection changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
 - ``on_cancel`` :ref:`trigger <actions-trigger>` is also activated when you close the dropdown without selecting an item from the list. The currently selected index is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers which also return the value in ``x``.

@ -1322,7 +1326,8 @@ Roller allows you to simply select one option from a list by scrolling.

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated when you select an item from the list. The new selected index is returned in the variable ``x``, and the text of the selected item is returned in the variable ``text``.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated only when the user selects an item from the list. The new selected index is returned in the variable ``x``. The :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers also apply, and they also return the selected index in ``x``.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated the selection changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers which also return the selected index in ``x``.

 **Example:**
@ -1388,7 +1393,8 @@ Normally, the slider can be adjusted either by dragging the knob, or by clicking

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the knob changes the value of the slider. The new value is returned in the variable ``x``.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the slider value changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated when the slider value is changed by user interaction. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers which also return the value in ``x``.

 **Example:**
@ -1469,7 +1475,7 @@ The spinbox contains a numeric value (as text) which can be increased or decreas

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the knob changes the value of the arc. The new value is returned in the variable ``x``.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the spinbox value changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers which also return the value in ``x``.

 **Example:**
@ -1577,7 +1583,8 @@ The switch looks like a little slider and can be used to turn something on and o

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated when toggling the switch. The boolean variable ``x``, representing the switch's state, may be used by lambdas within this trigger.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the switch value changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated when the switch value is changed by user interaction. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers which also return the value in ``x``.

 **Example:**
@ -1635,7 +1642,8 @@ The tabs are indexed (zero-based) in the order they appear in the configuration

 **Triggers:**

- ``on_value`` :ref:`trigger <actions-trigger>` is activated when displayed tab changes. The new value is returned in the variable ``tab`` as the ID of the now-visible tab.
+- ``on_value`` :ref:`trigger <actions-trigger>` is activated when the tab value changes, either by user interaction or programmatically. The new value is returned in the variable ``x``.
+- ``on_change`` :ref:`trigger <actions-trigger>` is activated when the tab value is changed by user interaction. The new value is returned in the variable ``x``.
 - :ref:`interaction <lvgl-automation-triggers>` LVGL event triggers.

 **Example:**
@ -1902,7 +1910,7 @@ These :ref:`actions <actions-action>` are shorthands for toggling the ``disabled
 Triggers
 ********

-Specific triggers like ``on_value`` are available for certain widgets; they are described above in their respective section.
+Specific triggers like ``on_value`` and ``on_change``` are available for certain widgets; they are described above in their respective section.
 Some universal triggers are also available for all of the widgets:

 ESPHome implements as universal triggers the following interaction events generated by LVGL:
--- a/components/matrix_keypad.rst
+++ b/components/matrix_keypad.rst
@ -34,6 +34,8 @@ Component
        - pin: GPIOXX
      keys: "123A456B789C*0#D"
      has_diodes: false
+      on_key:
+        - lambda: ESP_LOGI("KEY", "key %d pressed", x);


 Configuration variables:
@ -81,6 +83,13 @@ Configuration variables:
 Either the ``row`` and ``col`` parameters, or the ``key`` parameter has to be provided.


+Automations:
+------------
+
+- **on_key** (*Optional*, :ref:`Automation <automation>`): An automation to perform
+  when a key has been pressed. The key is in a variable called ``x``.
+
+
 .. note::

    Automatic handling of multiple keys (e.g. PIN code entry) is possible with the
--- a/components/mqtt.rst
+++ b/components/mqtt.rst
@ -106,6 +106,7 @@ Configuration variables:
 - **on_json_message** (*Optional*, :ref:`Automation <automation>`): An action to be
  performed when a JSON message on a specific MQTT topic is received. See :ref:`mqtt-on_json_message`.
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
+- **publish_nan_as_none** (*Optional*, bool): Publish ``None`` instead of ``NaN`` to handle Unknown/Unavailable sensor states in Home Assistant. Defaults to ``false``.

 .. _mqtt-message:

--- a/components/seeed_mr60bha2.rst
+++ b/components/seeed_mr60bha2.rst
@ -0,0 +1,69 @@
+Seeed Studio MR60BHA2 60GHz mmWave Breathing and Heartbeat Detection Sensor Kit
+===============================================================================
+
+.. seo::
+    :description: Instructions for setting up Seeed Studio MR60BHA2 60GHz mmWave Breathing and Heartbeat Detection Sensor Kit.
+    :image: seeed_mr60bha2.jpg
+
+Component/Hub
+-------------
+
+The ``seeed_mr60bha2`` platform allows you to use Seeed Studio MR60BHA2 60GHz mmWave Fall Detection Sensor Kit with XIAO ESP32C6 (`Product Page <https://www.seeedstudio.com/MR60BHA2-60GHz-mmWave-Sensor-Breathing-and-Heartbeat-Module-p-5945.html>`__) with ESPHome.
+
+The :ref:`UART <uart>` is required to be set up in your configuration for this sensor to work, ``parity`` and ``stop_bits`` **must be** respectively ``NONE`` and ``1``.
+You can use the ESP32 software or hardware serial to use this MR60BHA2, its default baud rate is 115200.
+
+.. figure:: images/seeed_mr60bha2.jpg
+    :align: center
+    :width: 50.0%
+
+    Seeed Studio MR60BHA2 60GHz mmWave Fall Detection Sensor Kit with XIAO ESP32C6
+
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    seeed_mr60bha2:
+
+Configuration variables:
+************************
+
+- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
+  to use multiple UART buses.
+- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this :doc:`seeed_mr60bha2` component if you need multiple components.
+
+Sensor
+------
+
+The ``seeed_mr60bha2`` sensor allows you to perform different measurements.
+
+.. code-block:: yaml
+
+    sensor:
+      - platform: seeed_mr60bha2
+        breath_rate:
+          name: "Real-time respiratory rate"
+        heart_rate:
+          name: "Real-time heart rate"
+        distance:
+          name: "Distance to detection object"
+
+Configuration variables:
+************************
+
+- **breath_rate** (*Optional*, int): Radar-detected respiratory rate during the first 60 seconds.
+  All options from :ref:`Sensor <config-sensor>`.
+- **heart_rate** (*Optional*, int): Heart rate during the first 60 seconds as detected by the radar.
+  All options from :ref:`Sensor <config-sensor>`.
+- **distance** (*Optional*, int): Straight-line distance between the radar and the monitoring object.
+  All options from :ref:`Sensor <config-sensor>`.
+
+
+See Also
+--------
+
+- `Official Using Documents for Seeed Studio MR60BHA2 60GHz mmWave Breathing and Heartbeat Detection Sensor Kit with XIAO ESP32C6 <https://wiki.seeedstudio.com/getting_started_with_mr60bha2_mmwave_kit/>`_
+- `Product Detail Page for Seeed Studio MR60BHA2 60GHz mmWave Breathing and Heartbeat Detection Sensor Kit with XIAO ESP32C6 <https://www.seeedstudio.com/MR60BHA2-60GHz-mmWave-Sensor-Breathing-and-Heartbeat-Module-p-5945.html>`_
+- `Source of inspiration for implementation <https://github.com/limengdu/MR60BHA2_ESPHome_external_components/>`_
+- :apiref:`seeed_mr60bha2/seeed_mr60bha2.h`
+- :ghedit:`Edit`
--- a/components/seeed_mr60fda2.rst
+++ b/components/seeed_mr60fda2.rst
@ -0,0 +1,112 @@
+Seeed Studio MR60FDA2 60GHz mmWave Fall Detection Sensor Kit
+============================================================
+
+.. seo::
+    :description: Instructions for setting up Seeed Studio MR60FDA2 60GHz mmWave Fall Detection Sensor Kit.
+    :image: seeed_mr60fda2.jpg
+
+Component/Hub
+-------------
+
+The ``seeed_mr60fda2`` platform allows you to use Seeed Studio's MR60FDA2 60GHz mmWave Fall Detection Sensor Kit with XIAO ESP32C6 (`Product Page <https://www.seeedstudio.com/MR60FDA2-60GHz-mmWave-Sensor-Fall-Detection-Module-p-5946.html>`__) with ESPHome.
+
+The :ref:`UART <uart>` is required to be set up in your configuration for this sensor to work, ``parity`` and ``stop_bits`` **must be** respectively ``NONE`` and ``1``.
+You can use the ESP32 software or hardware (recommended) serial to use the MR60FDA2; its default baud rate is 115200.
+
+.. figure:: images/seeed_mr60fda2.jpg
+    :align: center
+    :width: 50.0%
+
+    Seeed Studio MR60FDA2 60GHz mmWave Fall Detection Sensor Kit with XIAO ESP32C6
+
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    seeed_mr60fda2:
+
+Configuration variables:
+************************
+
+- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component <uart>` if you want
+  to use multiple UART buses.
+- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this :doc:`seeed_mr60fda2` component if you need multiple components.
+
+Binary Sensor
+-------------
+
+The ``seeed_mr60fda2`` binary sensor allows you to determine the presence of a human.
+
+.. code-block:: yaml
+
+    binary_sensor:
+      - platform: seeed_mr60fda2
+        people_exist:
+          name: "Person Information"
+        fall_detected:
+          name: "Falling Detected"
+
+Configuration variables:
+************************
+
+- **people_exist** (*Optional*): If true when target (person) is detected.
+  All options from :ref:`Binary Sensor <config-binary_sensor>`.
+- **fall_detected** (*Optional*): An indication of whether the radar has detected a fall.
+  All options from :ref:`Text Sensor <config-text_sensor>`.
+
+Button
+------
+
+The ``seeed_mr60fda2`` button allows you to perform actions.
+
+.. code-block:: yaml
+
+    button:
+      - platform: seeed_mr60fda2
+        get_radar_parameters:
+          name: "Get Radar Parameters"
+        factory_reset:
+          name: "Reset"
+
+Configuration variables:
+************************
+
+- **factory_reset**: Restore all radar settings to factory parameters. All options from :ref:`Button <config-button>`.
+- **get_radar_parameters**: Get all the current setup parameters of the radar.
+  All options from :ref:`Button <config-button>`.
+
+
+Select
+------
+
+The ``seeed_mr60fda2`` select allows you to control the configuration.
+
+.. code-block:: yaml
+
+    select:
+      - platform: seeed_mr60fda2
+        install_height:
+          name: "Set Install Height"
+        height_threshold:
+          name: "Set Height Threshold"
+        sensitivity:
+          name: "Set Sensitivity"
+
+Configuration variables:
+************************
+
+- **install_height**: Before using the MR60FDA2, please select the installation height of the radar according to the actual situation in order to obtain accurate identification results. The default is 3m.
+  All options from :ref:`Select <config-select>`.
+- **height_threshold**: To accurately distinguish between a person falling and sitting still in this area, you need to set the trigger height that triggers fall detection. This height refers to the distance between the person and the ground at the time of the fall. The default is 0.6m.
+  All options from :ref:`Select <config-select>`.
+- **sensitivity**: Fall sensitivity factor. Defaults to 1 with a range of 1-3, 3 = high and 1 = low.
+  All options from :ref:`Select <config-select>`.
+
+See Also
+--------
+
+- `Official Using Documents for Seeed Studio MR60FDA2 60GHz mmWave Fall Detection Sensor Kit with XIAO ESP32C6 <https://wiki.seeedstudio.com/getting_started_with_mr60fda2_mmwave_kit/>`_
+- `Product Detail Page for Seeed Studio MR60FDA2 60GHz mmWave Fall Detection Sensor Kit with XIAO ESP32C6 <https://www.seeedstudio.com/MR60FDA2-60GHz-mmWave-Sensor-Fall-Detection-Module-p-5946.html>`_
+- `Source of inspiration for implementation <https://github.com/limengdu/MR60FDA2_ESPHome_external_components>`_
+- :apiref:`seeed_mr60fda2/seeed_mr60fda2.h`
+- :ghedit:`Edit`
--- a/components/sensor/nextion.rst
+++ b/components/sensor/nextion.rst
@ -95,6 +95,50 @@ should be prefixed with the page name (page0/page1 or whatever you have changed

 ``component_name: page0.humidity``

+.. _sensor-nextion-publish_action:
+
+``sensor.nextion.publish`` Action
+---------------------------------
+
+You can also publish a state to a Nextion sensor from elsewhere in your YAML file
+with the ``sensor.nextion.publish`` action.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    sensor:
+      - platform: nextion
+        id: nextion_sensor
+        ...
+    # in some trigger
+    on_...:
+      - sensor.nextion.publish:
+          id: nextion_sensor
+          state: 100.0
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+      # Templated
+      - sensor.nextion.publish:
+          id: nextion_sensor
+          state: !lambda 'return 100.0;'
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+
+Configuration variables:
+
+- **id** (**Required**, :ref:`config-id`): The ID of the Nextion sensor.
+- **state** (**Required**, string, :ref:`templatable <config-templatable>`): The float state to publish.
+- **publish_state** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Home Assistant.
+  Default is true.
+- **send_to_nextion** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Nextion
+  display which will update component. Default is true.
+
+.. note::
+
+    This action can also be written in lambdas. See :ref:`nextion_sensor_lambda_calls`
+
 .. _nextion_sensor_lambda_calls:

 Lambda Calls
--- a/components/switch/hbridge.rst
+++ b/components/switch/hbridge.rst
@ -0,0 +1,46 @@
+H-bridge Switch
+===============
+
+.. seo::
+    :description: Instructions for setting up H-Bridge controlled switches (or relays).
+    :image: hbridge-relay.jpg
+
+The ``hbridge`` switch platform allows you to drive an *h-bridge* controlled latching relay.
+
+.. figure:: images/hbridge-relay.png
+    :align: center
+    :width: 50.0%
+
+    Omron G6CK-2117P relay module.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    switch:
+      - platform: hbridge
+        id: my_relay
+        name: "Relay"
+        on_pin: GPIOXX
+        off_pin: GPIOXX
+        pulse_length: 50ms
+        wait_time: 50ms
+
+Configuration variables:
+------------------------
+
+- **on_pin** (**Required**, :ref:`config-pin_schema`): The GPIO pin to pulse to turn on the switch.
+- **off_pin** (**Required**, :ref:`config-pin_schema`): The GPIO pin to pulse to turn off the switch.
+- **pulse_length** (*Optional*, :ref:`config-time`): The length in milliseconds of the pulse sent on ``on_pin`` and ``off_pin`` to change switch state. Defaults to ``100 ms``.
+- **wait_time** (*Optional*, :ref:`config-time`): The time in milliseconds to delay between pulses on ``off_pin`` and ``on_pin``. Defaults to no delay.
+- **optimistic** (*optional*, boolean): Whether to operate in optimistic mode - when in this mode,
+  any command sent to the switch will immediately update the reported state. Defaults to ``false``, and the reported state updates only at the end of the pulse.
+
+- All other options from :ref:`Switch Component <config-switch>`.
+
+See Also
+--------
+
+- :doc:`/components/output/index`
+- :doc:`/components/switch/index`
+- :apiref:`hbridge/switch/hbridge_switch.h`
+- :ghedit:`Edit`
--- a/components/switch/images/hbridge-relay.png
+++ b/components/switch/images/hbridge-relay.png
--- a/components/switch/nextion.rst
+++ b/components/switch/nextion.rst
@ -59,6 +59,50 @@ should be prefixed with the page name (page0/page1 or whatever you have changed

 ``component_name: page0.r0``

+.. _switch-nextion-publish_action:
+
+``switch.nextion.publish`` Action
+---------------------------------
+
+You can also publish a state to a Nextion switch from elsewhere in your YAML file
+with the ``switch.nextion.publish`` action.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    sensor:
+      - platform: nextion
+        id: nextion_switch
+        ...
+    # in some trigger
+    on_...:
+      - switch.nextion.publish:
+          id: nextion_switch
+          state: true
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+      # Templated
+      - switch.nextion.publish:
+          id: nextion_switch
+          state: !lambda 'return true;'
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+
+Configuration options:
+
+- **id** (**Required**, :ref:`config-id`): The ID of the Nextion switch.
+- **state** (**Required**, string, :ref:`templatable <config-templatable>`): The boolean state to publish.
+- **publish_state** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Home Assistant.
+  Default is true.
+- **send_to_nextion** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Nextion
+  display which will update component. Default is true.
+
+.. note::
+
+    This action can also be written in lambdas. See :ref:`nextion_switch_lambda_calls`
+
 .. _nextion_switch_lambda_calls:

 Lambda Calls
--- a/components/text_sensor/nextion.rst
+++ b/components/text_sensor/nextion.rst
@ -55,6 +55,50 @@ should be prefixed with the page name (page0/page1 or whatever you have changed

 ``component_name: page0.text0``

+.. _text_sensor-nextion-publish_action:
+
+``text_sensor.nextion.publish`` Action
+---------------------------------------
+
+You can also publish a state to a Nextion text sensor from elsewhere in your YAML file
+with the ``text_sensor.nextion.publish`` action.
+
+.. code-block:: yaml
+
+    # Example configuration entry
+    text_sensor:
+      - platform: nextion
+        id: nextion_text
+        ...
+    # in some trigger
+    on_...:
+      - text_sensor.nextion.publish:
+          id: nextion_text
+          state: "Hello World"
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+      # Templated
+      - text_sensor.nextion.publish:
+          id: nextion_text
+          state: !lambda 'return "Hello World";'
+          # These are optional. Defaults to true.
+          publish_state: true
+          send_to_nextion: true
+
+Configuration variables:
+
+- **id** (**Required**, :ref:`config-id`): The ID of the Nextion text sensor.
+- **state** (**Required**, string, :ref:`templatable <config-templatable>`): The string to publish.
+- **publish_state** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Home Assistant.
+  Default is true.
+- **send_to_nextion** (**Optional**, bool, :ref:`templatable <config-templatable>`): Publish new state to Nextion
+  display which will update component. Default is true.
+
+.. note::
+
+    This action can also be written in lambdas. See :ref:`nextion_text_sensor_lambda_calls`
+        
 .. _nextion_text_sensor_lambda_calls:

 Lambda Calls
--- a/components/vbus.rst
+++ b/components/vbus.rst
@ -27,7 +27,7 @@ The following table shows the currently supported models of Vbus devices.
    "Dux H3214","deltasol_bs_2009","427B", "Pump 2 unsupported"
    "DeltaSol C","deltasol_c","4212"
    "DeltaSol CS2","deltasol_cs2","1121"
-    "DeltaSol CS2 Plus","deltasol_cs2_plus","2211"
+    "DeltaSol CS Plus","deltasol_cs_plus","2211"

 The ``Config Value`` should be used for the ``model`` parameter in your ``sensor`` and ``binary_sensor`` entries.

--- a/components/wifi.rst
+++ b/components/wifi.rst
@ -327,6 +327,35 @@ This action turns on 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.

+.. _wifi-configure:
+
+``wifi.configure`` Action
+--------------------------------
+
+This action connects to an SSID and password, optionally saving it in persistent memory so that the next time the WiFi interface is enabled, it will connect to the stored access point.
+
+.. code-block:: yaml
+
+    on_...:
+      then:
+        - wifi.configure:
+            ssid: "MyHomeNetwork"
+            password: "VerySafePassword"
+            save: true
+            timeout: 30000ms
+            on_connect: 
+              - logger.log: "Connected to WiFi!"
+            on_error:
+              - logger.log: "Failed to connect to WiFi!"
+
+Configuration variables:
+
+- **ssid** (*Required*, string, :ref:`templatable <config-templatable>`): The name of the WiFi access point.
+- **password** (*Required*, string, :ref:`templatable <config-templatable>`): The password of the WiFi access point. Leave empty for no password.
+- **save** (*Optional*, boolean, :ref:`templatable <config-templatable>`): If set to ``true``, the SSID and password will be saved in persistent memory. Defaults to ``true``.
+- **timeout** (*Optional*, :ref:`config-time`, :ref:`templatable <config-templatable>`): The time to wait for the connection to be established. Defaults to 30 seconds.
+- **on_connect** (*Optional*, :ref:`Automation <automation>`): An action to be performed when a connection is established.
+- **on_error** (*Optional*, :ref:`Automation <automation>`): An action to be performed when the connection fails.

 .. _wifi-connected_condition:

--- a/conf.py
+++ b/conf.py
@ -71,9 +71,9 @@ author = "ESPHome"
 # built documents.
 #
 # The short X.Y version.
-version = "2024.11"
+version = "2024.12"
 # The full version, including alpha/beta/rc tags.
-release = "2024.11.3"
+release = "2024.12.0b1"

 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
--- a/guides/contributing.rst
+++ b/guides/contributing.rst
@ -546,9 +546,6 @@ wish to use it.
 Now you can open ESPHome in your IDE of choice (many of us are using `VSCode <https://code.visualstudio.com/download>`__)
 with the PlatformIO addons (see PlatformIO docs for more info) and develop the new feature with the guidelines below.

-All PRs are automatically checked and tested for some common formatting/code errors with Github Actions. *These checks*
-**must all pass** *before we will review (and eventually merge) your PR.*
-
 Setting Up Git Environment
 --------------------------

@ -597,7 +594,7 @@ near the top of the page (or, alternatively, go to branches and create it from t
 - Complete the Pull Request template:

  - Include a brief (but complete) summary of your changes.
-  - PRs without a descrption/summary of the changes will not be reviewed or merged, although exceptions may
+  - PRs without a description/summary of the changes will not be reviewed or merged, although exceptions may
    occasionally be made for small PRs and/or PRs made by frequent contributors/maintainers.
  - **Do not delete the template.**

@ -611,15 +608,47 @@ near the top of the page (or, alternatively, go to branches and create it from t
  it is ready. We do this because, if a PR is reviewed and then it changes, it must be re-reviewed. Reviewing a single
  PR multiple times is not a productive use of time and we try as much as possible to avoid doing so.

+So now that you've created your PR...you're not quite done! Read on to the next section below so you know what to
+expect next.
+
 Review Process
 **************

-ESPHome's maintainers work hard to maintain a high standard for its code, so reviews can take some time. At the bottom
-of each pull request you will see the "Github Actions" continuous integration (CI) checks which will automatically
-analyize all code changed in your branch. These checks try to spot (and suggest corrections for) errors. If any CI
-check fails, please look at the Github Actions log and fix all errors that appear there.
+.. _automated_checks:

-**All automated checks must be passing** before a given PR will be reviewed and (eventually) merged!
+Automated Checks
+^^^^^^^^^^^^^^^^
+
+At the bottom of each pull request you will see the "Github Actions" continuous integration (CI) checks which will
+automatically analyze all code changed in your branch. These checks try to spot (and suggest corrections for) common
+errors; they look like this:
+
+.. figure:: images/gha_checks.jpg
+    :align: center
+    :width: 100.0%
+    :alt: Automated checks on PR by GitHub Actions
+    :class: light-invert
+
+You can click the "Details" link to the right of each check to see the logs for that check. If a red ❌ appears next to
+any given check, *you'll need to view that check's logs and make the suggested changes so that the test will pass.*
+
+**Implementing Feedback from Automated Checks**
+
+Occasionally, an automated check may suggest a change that either isn't directly related to your PR or that may require
+changes to other components/platforms. When this happens, please create a new/additional PR to implement this change.
+
+For example, the automated checks may suggest moving a constant from your (new) component/platform into ``const.py``.
+This is a simple change, but we require that it is done in a separate PR.
+
+Ultimately, **all automated checks must be passing** before maintainers will review and (eventually) merge your PR!
+
+Review by Maintainers
+^^^^^^^^^^^^^^^^^^^^^
+
+ESPHome's maintainers work hard to maintain a high standard for its code, so reviews by a human can take some time.
+
+**All automated checks must be passing** before maintainers will review and (eventually) merge your PR! See
+:ref:`automated_checks` above.

 **When will my PR be reviewed/merged?**

@ -709,7 +738,7 @@ Beyond basic functionality (*"does it work?"*), here are a few other items we ch
 .. _prs-are-being-drafted-when-changes-are-needed:

 Why was my PR marked as a draft?
-************************************
+********************************

 If your PR was reviewed and changes were requested, our bot will automatically mark your PR as a draft. This means that
 the PR is not ready to be merged or further reviewed for the moment.
@ -1006,7 +1035,7 @@ it then attempts to read back the measurement from the sensor.
 :apiclass:`PollingComponent`.

 For any :apiclass:`Component` (which is nearly everything), the well-known ``set_timeout`` method is also available;
-this can be a handy alternative to implemeting a state machine.
+this can be a handy alternative to implementing a state machine.

 .. _a_note_about_custom_components:

@ -1124,8 +1153,8 @@ ESPHome's maintainers work hard to maintain a high standard for its code. We try

 - Components should dump their configuration using ``ESP_LOGCONFIG`` at startup in ``dump_config()``.
 - ESPHome uses a unified formatting tool for all source files (but this tool can be difficult to install).
-  When creating a new PR in GitHub, be sure to check the Github Actions output to see what formatting needs to be
-  changed and what potential problems are detected.
+  When creating a new PR in GitHub, be sure to check the :ref:`Github Actions<automated_checks>` output to see what
+  formatting needs to be changed and what potential problems are detected.
 - Use of external libraries should be kept to a minimum:

  - If the component you're developing has a simple communication interface, please consider implementing the library
@ -1135,7 +1164,7 @@ ESPHome's maintainers work hard to maintain a high standard for its code. We try
    communication abstractions.
  - If the library accesses a global variable/state (``Wire`` is a good example) then there's likely a problem because
    the component may not be modular. Put another way, this approach may mean that it's not possible to create multiple
-    instances of the component for use wihtin ESPHome.
+    instances of the component for use within ESPHome.

 - Components **must** use the provided abstractions like ``sensor``, ``switch``, etc. Components specifically should
  **not** directly access other components -- for example, to publish to MQTT topics.
--- a/guides/devboard_as_flasher.rst
+++ b/guides/devboard_as_flasher.rst
@ -0,0 +1,50 @@
+Using an ESP devboard as a USB-UART bridge
+==========================================
+
+.. _devboard-as-flasher:
+
+ESP development boards usually have an onboard USB interface, either built into the chip (e.g. ESP32-S3) or via an onboard USB-UART bridge chip.
+However some ESP based devices not designed for development work don't bother with this,
+and only expose the UART0 pins (TX and RX) for flashing purposes.
+
+Normally you would use a dedicated USB-UART interface board for this but what if you don't have one?
+In this "emergency" situation it is possible to use a development board that does have a USB-UART bridge chip to flash another device.
+This is achieved by holding the ESP chip in reset so that it doesn't interfere with the bridge chip operation.
+
+It does NOT require any firmware to be flashed onto the development board
+and will not change anything already flashed onto it - it's purely a way to use the serial interface chip.
+
+We will refer to the devboard with functional USB_UART bridge chip as flasher board for this guide.
+
+Make sure you've read the :doc:`/guides/physical_device_connection` for properly understanding the functionality of your flasher devboard.
+
+.. figure:: /guides/images/devboard-as-flasher.png
+    :align: center
+    :width: 75.0%
+
+    Connection diagram for an ESP flash target
+
+You need to make the following electrical connections:
+
+.. note::
+
+    - Most ESP32 S and C series boards do *not* have a separate USB-UART chip - they have it built into the ESP - so are not suitable for this application.
+    - The 5V connection on either board may be labelled either ``5V`` or ``VIN``. Some boards may not have a 5V connection and will require 3.3V only.
+    - Rather than powering the target board from the flasher board, it is also possible to use a separate power supply, just make sure all the ground pins are connected together.
+
+- connect both ``EN`` and ``GND`` together in the flasher devboard
+- ``+5.0V`` or ``3V3`` on the flasher devboard to ``VIN`` or ``3V3`` respectively of the target device
+- ``GND``, or ground of flasher devboard to ``GND`` of the target device
+- ``TX`` of flasher devboard to ``TX`` of the target device
+- ``RX`` of flasher devboard to ``RX`` of the target device
+
+Pulling down ``EN`` by connecting it to ``GND`` on the flasher board prevents
+the ESP chip on flasher module from booting and polluting the serial lines.
+
+.. note::
+
+    - If the board has not previously had ESPHome loaded, you may need to pull the ``IO0`` pin low (i.e. connected to ``GND``) to force the board into flash mode.
+      This must be done before power is applied.
+    - Do not connect 3V3 to VIN of the target devices with a 3V3 LDO as it may lead to brownouts.
+
+Once the connections are made, plug the flasher board into your computer via USB and proceed with flashing the target board via whichever means you intend to use.
--- a/guides/images/devboard-as-flasher-pi.jpg
+++ b/guides/images/devboard-as-flasher-pi.jpg
--- a/guides/images/devboard-as-flasher.png
+++ b/guides/images/devboard-as-flasher.png
--- a/guides/images/gha_checks.jpg
+++ b/guides/images/gha_checks.jpg
--- a/guides/physical_device_connection.rst
+++ b/guides/physical_device_connection.rst
@ -3,7 +3,7 @@ Physically Connecting to your Device

 The most difficult part of setting up a new ESPHome device is the initial
 installation, which requires connecting your ESP device to a computer using a
-cable.
+data cable.

 **You only need to do this once per device.** Once you've flashed ESPHome on a
 device, you can use :doc:`/components/ota/index` to upload new
@ -119,8 +119,9 @@ USB Port on Device

 Development boards often come with a USB port built in. This USB port is
 connected to a serial adapter, so you don't need a separate serial adapter. You
-can use just a :ref:`USB cable <usb-cable>` to connect it to your computer to
-program it.
+can use just a :ref:`USB data cable <usb-cable>` to connect it to your computer to
+program it. Additionally, a development board can also be used to flash other ESPs.
+:doc:`Read more here. </guides/devboard_as_flasher>`

 This isn't likely to be very useful without connecting additional sensors to it
 by either soldering or using a breadboard, but you do not need anything else to
@ -241,7 +242,8 @@ require different parts and tools.
        .. _usb-cable:
    * - :ref:`USB to micro-USB/mini-USB/USB-C <usb-cable>`
      - If your target device has a USB port on it, you need the appropriate
-        cable to connect to it.
+        data cable to connect to it. A power only USB cable that usually
+        comes presupplied with powerbanks won't work.
      - $3 to $10
      - .. image:: /guides/images/usb-cable.jpg
            :alt: From https://www.stockvault.net/photo/271754/usb-cable
@ -259,6 +261,9 @@ require different parts and tools.

        The `Tasmota website provides a good set of suggestions on what to buy
        <https://tasmota.github.io/docs/Getting-Started/#needed-hardware>`_.
+
+        Any ESP development board with functioning USB_UART bridge chip can also be used instead.
+        :doc:`Read instructions here. </guides/devboard_as_flasher>`
      - $3 to $10
      - .. image:: /guides/images/usb-serial-adapter.jpg
            :alt: From https://tasmota.github.io/docs/Getting-Started/
--- a/guides/supporters.rst
+++ b/guides/supporters.rst
@ -1614,6 +1614,7 @@ Contributors
 - `roscoegray (@roscoegray) <https://github.com/roscoegray>`__
 - `Ross Troha (@rosstroha) <https://github.com/rosstroha>`__
 - `rotarykite (@rotarykite) <https://github.com/rotarykite>`__
+- `Krzysztof Zdulski (@RouNNdeL) <https://github.com/RouNNdeL>`__
 - `Roving Ronin (@Roving-Ronin) <https://github.com/Roving-Ronin>`__
 - `Robert Paskowitz (@rpaskowitz) <https://github.com/rpaskowitz>`__
 - `Rajan Patel (@rpatel3001) <https://github.com/rpatel3001>`__
@ -2036,4 +2037,4 @@ Contributors
 - `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
 - `Zynth-dev (@Zynth-dev) <https://github.com/Zynth-dev>`__

-*This page was last updated December 6, 2024.*
+*This page was last updated December 11, 2024.*
--- a/images/hbridge-relay.jpg
+++ b/images/hbridge-relay.jpg
--- a/images/seeed_mr60bha2.jpg
+++ b/images/seeed_mr60bha2.jpg
--- a/images/seeed_mr60fda2.jpg
+++ b/images/seeed_mr60fda2.jpg
--- a/index.rst
+++ b/index.rst
@ -508,6 +508,14 @@ Environmental
    TMP117, components/sensor/tmp117, tmp117.jpg, Temperature
    XGZP68xx Series, components/sensor/xgzp68xx, 6897d.jpg, Differential Pressure

+Health/Safety
+*************
+
+.. imgtable::
+
+    Seeed Studio MR60BHA2 mmWave, components/seeed_mr60bha2, seeed_mr60bha2.jpg, Breathing & heartbeat detection
+    Seeed Studio MR60FDA2 mmWave, components/seeed_mr60fda2, seeed_mr60fda2.jpg, Presence & Fall detection
+
 Light
 *****

@ -637,6 +645,7 @@ Core
    GPIO, components/binary_sensor/gpio, gpio.svg
    Home Assistant, components/binary_sensor/homeassistant, home-assistant.svg, dark-invert
    Status, components/binary_sensor/status, server-network.svg, dark-invert
+    Switch, components/binary_sensor/switch, electric-switch.svg, dark-invert

 Capacitive Touch
 ****************
@ -1039,6 +1048,7 @@ Switch Components
    Factory Reset Switch, components/switch/factory_reset, restart-alert.svg, dark-invert
    Generic Output Switch, components/switch/output, upload.svg, dark-invert
    GPIO Switch, components/switch/gpio, gpio.svg
+    H-bridge Switch, components/switch/hbridge, hbridge-relay.jpg
    LVGL Widget, components/switch/lvgl, lvgl_c_swi.png
    Modbus Switch, components/switch/modbus_controller, modbus.png
    Nextion Switch, components/switch/nextion, nextion.jpg
 @ -1 +1 @@
 .11.3
 .12.0b1