diff --git a/Makefile b/Makefile
index fb441c6e38..4bdad21c90 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
ESPHOME_PATH = ../esphome
-ESPHOME_REF = 2025.7.5
+ESPHOME_REF = 2025.8.0b1
PAGEFIND_VERSION=1.1.1
PAGEFIND=pagefind
NET_PAGEFIND=../pagefindbin/pagefind
diff --git a/_static/changelog-2025.8.0.png b/_static/changelog-2025.8.0.png
new file mode 100644
index 0000000000..8ea7cb72e0
Binary files /dev/null and b/_static/changelog-2025.8.0.png differ
diff --git a/_static/version b/_static/version
index f2eb60bec3..24f593709e 100644
--- a/_static/version
+++ b/_static/version
@@ -1 +1 @@
-2025.7.5
\ No newline at end of file
+2025.8.0b1
\ No newline at end of file
diff --git a/changelog/2025.8.0.rst b/changelog/2025.8.0.rst
new file mode 100644
index 0000000000..c30c57b560
--- /dev/null
+++ b/changelog/2025.8.0.rst
@@ -0,0 +1,660 @@
+ESPHome 2025.8.0 - 20th August 2025
+===================================
+
+.. seo::
+ :description: Changelog for ESPHome 2025.8.0.
+ :image: /_static/changelog-2025.8.0.png
+ :author: Jesse Hills
+ :author_twitter: @jesserockz
+
+.. imgtable::
+ :columns: 3
+
+ NRF52, components/nrf52, nrf52.svg
+ ESP-NOW, components/espnow, esp-now.svg
+ MIPI DSI Displays, components/display/mipi_dsi, tab5.jpg
+ LD2412, components/sensor/ld2412, ld2412.jpg
+ Runtime Stats, components/runtime_stats, pulse.svg, dark-invert
+
+
+Release Overview
+----------------
+
+ESPHome 2025.8.0 expands platform support with the introduction of Nordic nRF52 devices,
+adds mesh communication capabilities, and delivers significant performance improvements. This release
+focuses on architectural innovation and memory optimization while introducing new hardware possibilities.
+
+**Key Highlights:**
+
+- **New nRF52 platform** based on Zephyr RTOS opens Nordic semiconductor ecosystem
+- **ESP-NOW mesh communication** enables direct device-to-device connectivity
+- **High-performance MIPI DSI displays** for ESP32-P4 professional applications
+- **Extensive memory optimizations** with up to 10x performance improvements in key areas
+- **Python 3.11+ requirement** (breaking change - Python 3.10 support dropped)
+
+
+NRF52 Platform Support
+----------------------
+
+ESPHome 2025.8.0 introduces comprehensive support for Nordic nRF52 series microcontrollers through the new
+:doc:`/components/nrf52` platform. This implementation is built on the Zephyr RTOS, providing a robust
+foundation for Nordic semiconductor devices.
+
+**Key Features:**
+
+- **Complete platform integration** with ESPHome's component ecosystem
+- **ADC support** for analog sensor reading with configurable resolution
+- **GPIO functionality** with interrupt support and pin configuration
+- **Zephyr debug component** for advanced debugging and development
+
+The nRF52 platform opens up new possibilities for low-power, Bluetooth-enabled devices while maintaining
+the familiar ESPHome configuration syntax and component compatibility.
+
+
+ESP-NOW Communication
+---------------------
+
+The new :doc:`/components/espnow` component brings device-to-device communication to ESP32 platforms without
+requiring WiFi infrastructure. ESP-NOW enables direct communication between ESP32 devices using the 2.4GHz
+band with minimal power consumption.
+
+**Applications:**
+
+- **Mesh sensor networks** - Sensors can communicate directly without WiFi routers
+- **Remote control systems** - Direct device control with low latency
+- **Backup communication** - Fallback when WiFi is unavailable
+- **Battery-powered devices** - Efficient communication for power-constrained applications
+
+This protocol is particularly valuable for distributed sensor networks and scenarios where traditional
+WiFi infrastructure is impractical or unavailable.
+
+
+MIPI DSI Display Support
+------------------------
+
+ESPHome now supports high-performance MIPI DSI displays through the new :doc:`/components/display/mipi_dsi`
+component, specifically designed for ESP32-P4 processors with DSI interfaces.
+
+**Benefits:**
+
+- **High-resolution displays** with excellent performance
+- **Hardware acceleration** through dedicated DSI controllers
+- **Reduced CPU overhead** compared to traditional SPI displays
+- **Professional display quality** for advanced applications
+
+This addition significantly expands ESPHome's display capabilities, enabling professional-grade user interfaces
+and high-resolution graphics applications.
+
+
+Memory & Performance Optimizations
+----------------------------------
+
+ESPHome 2025.8.0 includes extensive optimizations focused on reducing memory usage and improving performance:
+
+**Flash Memory Savings:**
+
+- Conditional compilation removes unused API features (thousands of bytes saved)
+- Optimized protobuf implementations with zero-copy techniques
+- Reduced code duplication across components
+- Streamlined error handling and logging systems
+
+**Runtime Performance:**
+
+- 10x faster string encoding with optimized memcpy operations
+- Enhanced scheduler with reduced millis() calls
+- Improved BLE scanning with batched processing
+- Zero-copy protobuf fields for reduced memory allocations
+
+
+Python 3.11+ Requirement
+------------------------
+
+Starting with ESPHome 2025.8.0, **Python 3.11 or higher is required** to run ESPHome. This change enables us to:
+
+- Utilize modern Python features and improvements
+- Remove legacy compatibility code that was needed for older Python versions
+- Maintain a more secure and efficient codebase
+
+**Why This Change?**
+
+Python 3.10 reaches its `end of life in October 2026 `__. This
+upgrade is necessary for the project to move forward with modern development practices and maintain
+long-term security and maintainability.
+
+**What You Need to Do**
+
+.. list-table::
+ :widths: 30 70
+ :header-rows: 1
+
+ * - Installation Method
+ - Action Required
+ * - Home Assistant Add-on
+ - **No action needed** - Already uses Python 3.12
+ * - Container Images (Docker)
+ - **No action needed** - Already uses Python 3.12
+ * - Direct Installation (pip)
+ - **Upgrade Python to 3.11+** before updating ESPHome
+
+.. warning::
+
+ If you're running ESPHome directly on your machine with Python 3.10 or older, running ``pip install -U esphome``
+ will not upgrade beyond version 2025.7.x. You must upgrade your Python installation first.
+
+
+Full list of changes
+--------------------
+
+New Features
+^^^^^^^^^^^^
+
+- [nrf52] add adc :esphomepr:`9321` by :ghuser:`tomaszduda23` (new-feature)
+- [espnow] Basic communication between ESP32 devices :esphomepr:`9582` by :ghuser:`nielsnl68` (new-component) (new-feature)
+- [esp32] Add config option to execute from PSRAM :esphomepr:`9907` by :ghuser:`clydebarrow` (new-feature)
+- [color][lvgl] Allow Color to be used for lv_color_t :esphomepr:`10016` by :ghuser:`clydebarrow` (new-feature)
+- [esp32] Add framework migration warning for upcoming ESP-IDF default change :esphomepr:`10030` by :ghuser:`bdraco` (new-feature)
+- Add CO5300 display support :esphomepr:`9739` by :ghuser:`mschnaubelt` (new-feature)
+- [remote_transmitter] Add digital_write automation :esphomepr:`10069` by :ghuser:`swoboda1337` (new-feature)
+- Support multiple --device arguments for address fallback :esphomepr:`10003` by :ghuser:`bdraco` (new-feature)
+- Add device class absolute_humidity to the absolute humidity component :esphomepr:`10100` by :ghuser:`mbo18` (new-feature)
+- [switch] Add ``switch.control`` automation action :esphomepr:`10105` by :ghuser:`edwardtfn` (new-feature)
+- [switch] Add ``control()`` method to API :esphomepr:`10118` by :ghuser:`edwardtfn` (new-feature)
+- [switch] Add trigger ``on_state`` :esphomepr:`10108` by :ghuser:`edwardtfn` (new-feature)
+- [nrf52, zephyr_debug] add zephyr debug component :esphomepr:`8319` by :ghuser:`tomaszduda23` (new-feature)
+- [sensor] Extend timeout filter with option to return last value received :esphomepr:`10115` by :ghuser:`kbx81` (new-feature)
+- [substitutions] Add some safe built-in functions to jinja parsing :esphomepr:`10178` by :ghuser:`jesserockz` (new-feature)
+- [ld2412] New component :esphomepr:`9075` by :ghuser:`Rihan9` (new-component) (new-feature) (new-platform)
+
+New Components
+^^^^^^^^^^^^^^
+
+- [nrf52, core] nrf52 core based on zephyr :esphomepr:`7049` by :ghuser:`tomaszduda23` (new-component)
+- Add runtime_stats component for performance debugging and analysis :esphomepr:`9386` by :ghuser:`bdraco` (new-component)
+- [mipi_dsi] New display driver for P4 DSI :esphomepr:`9403` by :ghuser:`clydebarrow` (new-component) (new-platform)
+- [espnow] Basic communication between ESP32 devices :esphomepr:`9582` by :ghuser:`nielsnl68` (new-component) (new-feature)
+- [ld2412] New component :esphomepr:`9075` by :ghuser:`Rihan9` (new-component) (new-feature) (new-platform)
+
+New Platforms
+^^^^^^^^^^^^^
+
+- [mipi_dsi] New display driver for P4 DSI :esphomepr:`9403` by :ghuser:`clydebarrow` (new-component) (new-platform)
+- [ld2412] New component :esphomepr:`9075` by :ghuser:`Rihan9` (new-component) (new-feature) (new-platform)
+
+Breaking Changes
+^^^^^^^^^^^^^^^^
+
+- Remove parsed advertisement support from bluetooth_proxy to save memory :esphomepr:`9489` by :ghuser:`bdraco` (breaking-change)
+- Drop Python 3.10 support, require Python 3.11+ :esphomepr:`9522` by :ghuser:`bdraco` (breaking-change)
+- Remove legacy unique_id field from entities :esphomepr:`9022` by :ghuser:`bdraco` (breaking-change)
+- [api] Remove deprecated protobuf fields to reduce flash usage :esphomepr:`9679` by :ghuser:`bdraco` (breaking-change)
+- [api] Add conditional compilation for Home Assistant state subscriptions :esphomepr:`9898` by :ghuser:`bdraco` (breaking-change)
+- [api] Add conditional compilation for Home Assistant service subscriptions :esphomepr:`9900` by :ghuser:`bdraco` (breaking-change)
+- [esp32_touch] Work around ESP-IDF v5.4 regression in `touch_pad_read_filtered` :esphomepr:`9957` by :ghuser:`bdraco` (breaking-change)
+- [ld2410] Replace ``throttle`` with native filters :esphomepr:`10019` by :ghuser:`kbx81` (breaking-change)
+- [esp32_ble] Conditionally compile BLE advertising to reduce flash usage :esphomepr:`10099` by :ghuser:`bdraco` (breaking-change)
+- [esp32_ble_client] Conditionally compile BLE service classes to reduce flash usage :esphomepr:`10114` by :ghuser:`bdraco` (breaking-change)
+- [bluetooth_proxy] Remove V1 connection support :esphomepr:`10107` by :ghuser:`bdraco` (breaking-change)
+- [esp32] Add IDF log_level option :esphomepr:`10134` by :ghuser:`swoboda1337` (breaking-change)
+- [ld2450] Replace ``throttle`` with native filters :esphomepr:`10196` by :ghuser:`kbx81` (breaking-change)
+
+All changes
+^^^^^^^^^^^
+
+.. collapse:: Show
+ :open:
+
+ - [web_server] fix ``Arudino`` typo :esphomepr:`9404` by :ghuser:`ximex`
+ - Speed up clang-tidy CI by 80%+ with incremental checking :esphomepr:`9396` by :ghuser:`bdraco`
+ - Fix PlatformIO cache in CI by adding platformio.ini hash to cache key :esphomepr:`9411` by :ghuser:`bdraco`
+ - Fix clang-tidy triggering full scan on Python-only core file changes :esphomepr:`9412` by :ghuser:`bdraco`
+ - Implement shared PlatformIO cache for integration tests :esphomepr:`9413` by :ghuser:`bdraco`
+ - Fix Python cache for all pytest CI jobs :esphomepr:`9415` by :ghuser:`bdraco`
+ - Fix Python cache key mismatch for all pytest jobs :esphomepr:`9417` by :ghuser:`bdraco`
+ - Adding support for Airthings Wave Gen2 :esphomepr:`8460` by :ghuser:`precurse`
+ - Fix Windows virtual environment activation in CI workflows :esphomepr:`9420` by :ghuser:`bdraco`
+ - Fix clang-tidy not finding changed files on squash-merge commits :esphomepr:`9421` by :ghuser:`bdraco`
+ - [config] Add bitrate validator :esphomepr:`9423` by :ghuser:`clydebarrow`
+ - [esp32] remove debug log :esphomepr:`9424` by :ghuser:`ssieb`
+ - CI: Centralize test determination logic to reduce unnecessary job runners :esphomepr:`9432` by :ghuser:`bdraco`
+ - Disable WiFi when using Ethernet to save memory :esphomepr:`9456` by :ghuser:`bdraco`
+ - Fix pre-commit CI failures by skipping local hooks that require virtual environment :esphomepr:`9476` by :ghuser:`bdraco`
+ - Fix clang-tidy skipping when Python linters are skipped :esphomepr:`9463` by :ghuser:`bdraco`
+ - Refactor format_hex_pretty functions to eliminate code duplication :esphomepr:`9480` by :ghuser:`bdraco`
+ - Fix pre-commit CI issues by switching to lite mode :esphomepr:`9484` by :ghuser:`bdraco`
+ - Refactor WebServer request handling for improved maintainability :esphomepr:`9470` by :ghuser:`bdraco`
+ - Fix WebServer routes constant naming convention :esphomepr:`9497` by :ghuser:`bdraco`
+ - Remove redundant pyupgrade CI job (follow-up to #9484) :esphomepr:`9493` by :ghuser:`bdraco`
+ - Add pre-commit hooks to fix common formatting issues causing CI failures :esphomepr:`9494` by :ghuser:`bdraco`
+ - Remove yamllint job from CI since its now handled by pre-commit job :esphomepr:`9500` by :ghuser:`bdraco`
+ - Fix blocked CI cancellation caused by always() in clang-tidy workflow :esphomepr:`9503` by :ghuser:`bdraco`
+ - Include entire platformio.ini in clang-tidy hash calculation :esphomepr:`9509` by :ghuser:`bdraco`
+ - Enable issue tracking :esphomepr:`9515` by :ghuser:`jesserockz`
+ - [repo] Fix issue template config.yml :esphomepr:`9516` by :ghuser:`jesserockz`
+ - [ms8607] Fix humidity calc :esphomepr:`9499` by :ghuser:`LorbusChris`
+ - [nrf52, core] nrf52 core based on zephyr :esphomepr:`7049` by :ghuser:`tomaszduda23` (new-component)
+ - remove duplication from component_iterator :esphomepr:`7210` by :ghuser:`tomaszduda23`
+ - [adc] Use new library with ESP-IDF v5 :esphomepr:`9021` by :ghuser:`edwardtfn`
+ - [mipi_spi] Template code, partial buffer support :esphomepr:`9314` by :ghuser:`clydebarrow`
+ - Remove dead code: 64-bit protobuf types never used in 7 years :esphomepr:`9471` by :ghuser:`bdraco`
+ - Add runtime_stats component for performance debugging and analysis :esphomepr:`9386` by :ghuser:`bdraco` (new-component)
+ - Make API ConnectRequest optional for passwordless connections :esphomepr:`9445` by :ghuser:`bdraco`
+ - Improve API protobuf decode method readability and reduce code size :esphomepr:`9455` by :ghuser:`bdraco`
+ - Reduce API component flash usage by consolidating error logging :esphomepr:`9468` by :ghuser:`bdraco`
+ - Remove parsed advertisement support from bluetooth_proxy to save memory :esphomepr:`9489` by :ghuser:`bdraco` (breaking-change)
+ - Drop Python 3.10 support, require Python 3.11+ :esphomepr:`9522` by :ghuser:`bdraco` (breaking-change)
+ - Optimize MedianFilter memory allocation by adding vector reserve :esphomepr:`9531` by :ghuser:`bdraco`
+ - [i2c] Use new driver with IDF 5.4.2+ :esphomepr:`8483` by :ghuser:`swoboda1337`
+ - Optimize scheduler timing by reducing millis() calls :esphomepr:`9524` by :ghuser:`bdraco`
+ - Optimize API component LOGCONFIG usage for flash memory savings :esphomepr:`9526` by :ghuser:`bdraco`
+ - Skip API log message calls for unsubscribed log levels :esphomepr:`9514` by :ghuser:`bdraco`
+ - Optimize API connection batch priority message handling to reduce flash usage :esphomepr:`9510` by :ghuser:`bdraco`
+ - Reduce flash usage by replacing ProtoSize template with specialized methods :esphomepr:`9487` by :ghuser:`bdraco`
+ - [ssd1306_base] fix typo ``brighrness`` :esphomepr:`9491` by :ghuser:`ximex`
+ - Fix CI failures from merge collisions :esphomepr:`9535` by :ghuser:`bdraco`
+ - Remove legacy unique_id field from entities :esphomepr:`9022` by :ghuser:`bdraco` (breaking-change)
+ - Reduce binary size with field-level conditional compilation for protobuf messages :esphomepr:`9473` by :ghuser:`bdraco`
+ - [adc] Test platforms on IDF :esphomepr:`9536` by :ghuser:`edwardtfn`
+ - Refactor API connection entity encoding to reduce code duplication :esphomepr:`9505` by :ghuser:`bdraco`
+ - Reduce API proto vtable overhead by splitting decode functionality :esphomepr:`9541` by :ghuser:`bdraco`
+ - Add ability to have same entity names on different sub devices :esphomepr:`9355` by :ghuser:`bdraco`
+ - Synchronise Device Classes from Home Assistant :esphomepr:`9513` by :ghuser:`esphomebot`
+ - Update script/helpers.py to use ESPHome YAML parser for integration fixtures :esphomepr:`9544` by :ghuser:`bdraco`
+ - [adc] Add ESP32-C5 support :esphomepr:`9486` by :ghuser:`edwardtfn`
+ - Move CONF_ALTITUDE_COMPENSATION to const.py :esphomepr:`9563` by :ghuser:`mikelawrence`
+ - Revert "Bump ESP32 IDF version to 5.4.2 and Arduino version to 3.2.1" :esphomepr:`9574` by :ghuser:`jesserockz`
+ - Workflow to auto label PRs based on changes :esphomepr:`9585` by :ghuser:`jesserockz`
+ - [dependabot] Use specific labels for github-actions updates :esphomepr:`9586` by :ghuser:`jesserockz`
+ - [CI] Add ``by-code-owner`` labelling :esphomepr:`9589` by :ghuser:`jesserockz`
+ - [CI] Add ``needs-docs`` labelling :esphomepr:`9591` by :ghuser:`jesserockz`
+ - Skip compilation of web_server_v1.cpp when not using version 1 :esphomepr:`9590` by :ghuser:`bdraco`
+ - Update Issues / Feature Requests links in Readme :esphomepr:`9600` by :ghuser:`RubenKelevra`
+ - Add some AI instructions :esphomepr:`9606` by :ghuser:`jesserockz`
+ - Update Issues / Feature Requests links :esphomepr:`9607` by :ghuser:`RubenKelevra`
+ - [ci] Implement external component PR workflow :esphomepr:`9595` by :ghuser:`clydebarrow`
+ - [ci] attempt to fix permission for workflow :esphomepr:`9610` by :ghuser:`clydebarrow`
+ - Refactor API send_message from template to non-template implementation :esphomepr:`9561` by :ghuser:`bdraco`
+ - Fix scheduler rollover detection with concurrent task calls :esphomepr:`9624` by :ghuser:`bdraco`
+ - adds nRF52840 to PR templates :esphomepr:`9631` by :ghuser:`tomaszduda23`
+ - [code quality] move const to esphome/const.py :esphomepr:`9632` by :ghuser:`tomaszduda23`
+ - [esp32] Allow variant in place of board :esphomepr:`9427` by :ghuser:`clydebarrow`
+ - [scheduler] Fix LibreTiny compilation error due to missing atomic operations :esphomepr:`9643` by :ghuser:`bdraco`
+ - Fix bluetooth_proxy heap allocations during BLE scanning :esphomepr:`9633` by :ghuser:`bdraco`
+ - core/schedule: fixup out of sync code comment :esphomepr:`9649` by :ghuser:`RubenKelevra`
+ - [CI] New workflow to mention codeowners on issues :esphomepr:`9658` by :ghuser:`jesserockz`
+ - [CI] Add codeowners mention workflow :esphomepr:`9651` by :ghuser:`jesserockz`
+ - [CI] Fix by-code-owner labelling :esphomepr:`9661` by :ghuser:`jesserockz`
+ - [scheduler] Add integration tests for set_retry functionality :esphomepr:`9644` by :ghuser:`bdraco`
+ - Use message_source_map consistently in proto generation :esphomepr:`9542` by :ghuser:`bdraco`
+ - esp32cam: add fb location config option :esphomepr:`9630` by :ghuser:`RubenKelevra`
+ - [i2s_audio] Bugfix: cast adc_channel_t to adc1_channel_t :esphomepr:`9688` by :ghuser:`kahrendt`
+ - Add core team as codeowner of .github folder :esphomepr:`9663` by :ghuser:`jesserockz`
+ - [CI] Fix clang-tidy not running when platformio.ini changes :esphomepr:`9678` by :ghuser:`bdraco`
+ - [api] Fix missing ifdef guards for field_ifdef fields in protobuf base classes :esphomepr:`9693` by :ghuser:`bdraco`
+ - [const] Move CONF_FLIP_X and CONF_FLIP_Y to ``const.py`` :esphomepr:`9741` by :ghuser:`DT-art1`
+ - core/scheduler: Make ``millis_64_`` rollover monotonic on SMP :esphomepr:`9716` by :ghuser:`RubenKelevra`
+ - [bluetooth_proxy] Fix service discovery on disconnect and refactor connection handling :esphomepr:`9697` by :ghuser:`bdraco`
+ - [esp32_ble_tracker] Batch BLE advertisement processing to reduce overhead :esphomepr:`9699` by :ghuser:`bdraco`
+ - [api] Memory optimizations for API frame helper buffering :esphomepr:`9724` by :ghuser:`bdraco`
+ - [api] Eliminate heap allocation in ``process_batch_`` using stack-allocated PacketInfo array :esphomepr:`9703` by :ghuser:`bdraco`
+ - [api] Remove deprecated protobuf fields to reduce flash usage :esphomepr:`9679` by :ghuser:`bdraco` (breaking-change)
+ - [CI] Only mention codeowners once :esphomepr:`9727` by :ghuser:`jesserockz`
+ - [api] Consolidate error handling and remove unused code :esphomepr:`9726` by :ghuser:`bdraco`
+ - [api] Fix missing ifdef guards for AreaInfo and DeviceInfo messages :esphomepr:`9730` by :ghuser:`bdraco`
+ - [core] Refactor scheduler to eliminate hidden side effects in ``empty_`` :esphomepr:`9743` by :ghuser:`bdraco`
+ - [api] Reduce memory usage by eliminating duplicate client info strings :esphomepr:`9740` by :ghuser:`bdraco`
+ - [CI] Label PR too-big if it has more than 1000 lines changed :esphomepr:`9744` by :ghuser:`jesserockz`
+ - [CI] Keep original labels when PR has too many lines :esphomepr:`9745` by :ghuser:`jesserockz`
+ - [CI] Fetch platform components and target platforms from hosted json file :esphomepr:`9747` by :ghuser:`jesserockz`
+ - [CI] Add url and dismiss reviews once conditions are met :esphomepr:`9748` by :ghuser:`jesserockz`
+ - [api] Split frame helper implementation into protocol-specific files :esphomepr:`9746` by :ghuser:`bdraco`
+ - [CI] Fix codeowner workflow requesting the same multiple times :esphomepr:`9750` by :ghuser:`jesserockz`
+ - [CI] Use comment marker in too-big reviews :esphomepr:`9751` by :ghuser:`jesserockz`
+ - [CI] Dont create new review if existing and dont count tests :esphomepr:`9753` by :ghuser:`jesserockz`
+ - [api] Sync uses_password field_ifdef optimization from aioesphomeapi :esphomepr:`9756` by :ghuser:`bdraco`
+ - [tests] Fix flaky scheduler retry test timing :esphomepr:`9760` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Optimize service discovery with in-place construction :esphomepr:`9765` by :ghuser:`bdraco`
+ - Factor PlatformIO buildgen out of writer.py :esphomepr:`9378` by :ghuser:`stellar-aria`
+ - [api] Implement zero-copy for all protobuf bytes fields :esphomepr:`9761` by :ghuser:`bdraco`
+ - [api] Optimize string encoding with memcpy for 10x performance improvement :esphomepr:`9778` by :ghuser:`bdraco`
+ - [api] Optimize noise handshake with memcpy for faster connection setup :esphomepr:`9779` by :ghuser:`bdraco`
+ - [nrf52] Add missing CoreModel define for scheduler :esphomepr:`9777` by :ghuser:`bdraco`
+ - [esp32_ble_tracker] Write require feature defines after all clients are registered :esphomepr:`9780` by :ghuser:`jesserockz`
+ - [api] Optimize protobuf memory usage with fixed-size arrays for Bluetooth UUIDs :esphomepr:`9782` by :ghuser:`bdraco`
+ - [api] Implement zero-copy string optimization for outgoing protobuf messages :esphomepr:`9790` by :ghuser:`bdraco`
+ - [schema-gen] fix referenced schemas when schema in component platform :esphomepr:`9755` by :ghuser:`glmnet`
+ - [audio] fix typo ``gneneral`` and ``divison`` :esphomepr:`9808` by :ghuser:`ximex`
+ - [sgp4x] Fix build :esphomepr:`9794` by :ghuser:`swoboda1337`
+ - [http_request] set correct duration_ms for failed requests :esphomepr:`9789` by :ghuser:`stas-sl`
+ - [udp] Move ``on_receive`` to const :esphomepr:`9811` by :ghuser:`jesserockz`
+ - Bump ESP32 IDF version to 5.4.2 and Arduino version to 3.2.1 :esphomepr:`9770` by :ghuser:`swoboda1337`
+ - Workflow - check all comments to find previous bot comment :esphomepr:`9815` by :ghuser:`clydebarrow`
+ - [core] Match LockFreeQueue initialization order :esphomepr:`9813` by :ghuser:`jesserockz`
+ - [CI] Paginate codeowner comments to make sure we find it :esphomepr:`9817` by :ghuser:`jesserockz`
+ - [CI] Paginate codeowner comments to make sure we find it :esphomepr:`9818` by :ghuser:`jesserockz`
+ - [core] Initialize ``looping_components_`` before setup blocking phase :esphomepr:`9820` by :ghuser:`bdraco`
+ - [i2c] Use ``i2c_master_probe`` to scan i2c bus :esphomepr:`9831` by :ghuser:`jesserockz`
+ - [core] Restore COMPONENT_STATE_LOOP_DONE check in calculate_looping_components :esphomepr:`9832` by :ghuser:`bdraco`
+ - [ci] Support C++17 nested namespace syntax in linter :esphomepr:`9826` by :ghuser:`bdraco`
+ - [modem] network component change :esphomepr:`9801` by :ghuser:`oarcher`
+ - [interval] Fix startup behaviour :esphomepr:`9793` by :ghuser:`clydebarrow`
+ - [mipi] Refactor constants and functions :esphomepr:`9853` by :ghuser:`clydebarrow` (new-component)
+ - Update post_build.py.script to Fix #7137 :esphomepr:`9578` by :ghuser:`Maeur1`
+ - [helpers] Add "unknown" value handling to ``Deduplicator`` :esphomepr:`9855` by :ghuser:`kbx81`
+ - [ld2450] Set ``accuracy_decimals=0`` as default for "target" entities :esphomepr:`9842` by :ghuser:`bharvey88`
+ - [logger] remove unnecessary call to setTxTimeoutMs :esphomepr:`9854` by :ghuser:`tjhorner`
+ - [i2s_audio] Speaker improvements: CPU core agnostic and more accurate timestamps :esphomepr:`9800` by :ghuser:`kahrendt`
+ - [esp32] Fix threading model for single-core variants (S2, C3, C6, H2) :esphomepr:`9851` by :ghuser:`bdraco`
+ - [api] Replace magic numbers with MESSAGE_TYPE constants in protobuf switch cases :esphomepr:`9776` by :ghuser:`bdraco`
+ - [api] Simplify generated authentication check code :esphomepr:`9806` by :ghuser:`bdraco`
+ - [api] Reduce code duplication in protobuf dump methods with helper functions :esphomepr:`9809` by :ghuser:`bdraco`
+ - [api] Use emplace_back for TemplatableKeyValuePair construction in HomeAssistant services :esphomepr:`9804` by :ghuser:`bdraco`
+ - [core] Fix component state documentation and add state helper method :esphomepr:`9824` by :ghuser:`bdraco`
+ - [bluetooth_proxy] [esp32_ble_tracker] [esp32_ble] Use C++17 nested namespace syntax :esphomepr:`9825` by :ghuser:`bdraco`
+ - [ld2410] Use ``Deduplicator`` for sensors :esphomepr:`9584` by :ghuser:`kbx81`
+ - [api] Use C++17 nested namespace syntax :esphomepr:`9856` by :ghuser:`bdraco`
+ - [mipi] Keep models from different drivers separate :esphomepr:`9865` by :ghuser:`clydebarrow`
+ - [ld2450] Use ``Deduplicator`` for sensors :esphomepr:`9863` by :ghuser:`kbx81`
+ - [core] Revert #9851 and rename ESPHOME_CORES to ESPHOME_THREAD :esphomepr:`9862` by :ghuser:`bdraco`
+ - [CI] Refactor auto-label workflow: modular architecture, CODEOWNERS automation, and performance improvements :esphomepr:`9860` by :ghuser:`jesserockz`
+ - [factory_reset] Allow factory reset by rapid power cycle :esphomepr:`9749` by :ghuser:`clydebarrow`
+ - [gps] Patches to build on IDF, other optimizations :esphomepr:`9728` by :ghuser:`kbx81`
+ - [sound_level] fix spelling mistake :esphomepr:`9843` by :ghuser:`tomaszduda23`
+ - rc522: fix buffer overflow in UID/buffer formatting helpers :esphomepr:`9375` by :ghuser:`RubenKelevra`
+ - [platformio.ini] Move GPS to common lib_deps :esphomepr:`9883` by :ghuser:`kbx81`
+ - [ruff] Enable SIM rules and fix code simplification violations :esphomepr:`9872` by :ghuser:`bdraco`
+ - [platformio.ini] Add GPS to nrf52-zephyr lib_deps :esphomepr:`9884` by :ghuser:`kbx81`
+ - Remove redundant platformio environments :esphomepr:`9886` by :ghuser:`jesserockz`
+ - [CI] Better mega-pr label handling :esphomepr:`9888` by :ghuser:`jesserockz`
+ - [CI] Fix auto-label workflow - codeowners & listFiles :esphomepr:`9890` by :ghuser:`jesserockz`
+ - [mqtt] Don’t log state topic subscription for buttons :esphomepr:`9887` by :ghuser:`GilDev`
+ - [scheduler] Fix retry race condition on cancellation :esphomepr:`9788` by :ghuser:`bdraco`
+ - [ruff] Enable PERF rules and fix all violations :esphomepr:`9874` by :ghuser:`bdraco`
+ - [scheduler] Fix null pointer crash :esphomepr:`9893` by :ghuser:`clydebarrow`
+ - [core] Centralize component setup logging to reduce flash usage :esphomepr:`9885` by :ghuser:`bdraco`
+ - [mipi_dsi] New display driver for P4 DSI :esphomepr:`9403` by :ghuser:`clydebarrow` (new-component) (new-platform)
+ - [api] Add missing USE_API_PASSWORD guards to reduce flash usage :esphomepr:`9899` by :ghuser:`bdraco`
+ - [api] Add conditional compilation for Home Assistant state subscriptions :esphomepr:`9898` by :ghuser:`bdraco` (breaking-change)
+ - [i2c] Fix logging level for bus scan results in dump_config :esphomepr:`9904` by :ghuser:`bdraco`
+ - [ruff] Enable FURB rules for code modernization :esphomepr:`9896` by :ghuser:`bdraco`
+ - [core] Fix format error in log printf :esphomepr:`9911` by :ghuser:`clydebarrow`
+ - [logger] Use C++17 nested namespace syntax :esphomepr:`9916` by :ghuser:`bdraco`
+ - [wifi] Allow config to use PSRAM :esphomepr:`9866` by :ghuser:`clydebarrow`
+ - [ci-custom] Report actual changes needed for absolute import :esphomepr:`9919` by :ghuser:`clydebarrow`
+ - [light] Reduce flash memory usage by optimizing validation and color mode logic :esphomepr:`9921` by :ghuser:`bdraco`
+ - [power_supply] Optimize logging, reduce flash footprint :esphomepr:`9923` by :ghuser:`kbx81`
+ - [wifi] Disallow psram config with arduino :esphomepr:`9922` by :ghuser:`clydebarrow`
+ - [core] Use nullptr defaults in status_set_error/warning to reduce flash usage :esphomepr:`9931` by :ghuser:`bdraco`
+ - [light] Reduce flash usage by 832 bytes through code optimization :esphomepr:`9924` by :ghuser:`bdraco`
+ - [api] Reduce code duplication in send_noise_encryption_set_key_response :esphomepr:`9918` by :ghuser:`bdraco`
+ - replace os.getlogin() with getpass.getuser() :esphomepr:`9928` by :ghuser:`cmaxl`
+ - [packages] add example from documentation to component tests :esphomepr:`9891` by :ghuser:`tomaszduda23`
+ - [api] Add conditional compilation for Home Assistant service subscriptions :esphomepr:`9900` by :ghuser:`bdraco` (breaking-change)
+ - [api] Fix string lifetime issue in Home Assistant service calls with templated values :esphomepr:`9909` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Fix service discovery cache pollution and descriptor count parameter bug :esphomepr:`9902` by :ghuser:`bdraco`
+ - [config_validation] extend should combine extra validations :esphomepr:`9939` by :ghuser:`clydebarrow`
+ - [scheduler] Eliminate more runtime string allocations from retry :esphomepr:`9930` by :ghuser:`bdraco`
+ - [api] Remove unnecessary string copies from optional access :esphomepr:`9897` by :ghuser:`bdraco`
+ - [heatpumpir] Bump library to 1.0.37 :esphomepr:`9944` by :ghuser:`jesserockz`
+ - [api] Optimize protobuf empty message handling to reduce flash and runtime overhead :esphomepr:`9908` by :ghuser:`bdraco`
+ - [api] Align ProtoSize API design with ProtoWriteBuffer pattern :esphomepr:`9920` by :ghuser:`bdraco`
+ - [esp32] Enable LWIP core locking on ESP-IDF to reduce socket operation overhead :esphomepr:`9857` by :ghuser:`bdraco`
+ - [sensor] Add support for default filters :esphomepr:`9934` by :ghuser:`kbx81`
+ - [binary_sensor] Add support for default filters :esphomepr:`9935` by :ghuser:`kbx81`
+ - [text_sensor] Add support for default filters :esphomepr:`9936` by :ghuser:`kbx81`
+ - [heatpumpir] Fix issue with IRremoteESP8266 being included on ESP32 :esphomepr:`9950` by :ghuser:`swoboda1337`
+ - Openthread add Teardown :esphomepr:`9275` by :ghuser:`rwrozelle`
+ - [gps] Fix slow parsing :esphomepr:`9953` by :ghuser:`kbx81`
+ - [output] Add ``set_min_power`` & ``set_max_power`` actions for ``FloatOutput`` :esphomepr:`8934` by :ghuser:`DjordjeMandic`
+ - [esp32] Bump platform to 54.03.21-1 and add support for tagged releases :esphomepr:`9926` by :ghuser:`swoboda1337`
+ - [adc] Enable ADC on ESP32-P4 :esphomepr:`9954` by :ghuser:`clydebarrow`
+ - [esp32] Fix post build :esphomepr:`9951` by :ghuser:`jesserockz`
+ - [component] Revert setup messages to LOG_CONFIG level :esphomepr:`9956` by :ghuser:`clydebarrow`
+ - Media player API enumeration alignment and feature flags :esphomepr:`9949` by :ghuser:`rwrozelle`
+ - [mipi_dsi] Add dependencies :esphomepr:`9952` by :ghuser:`clydebarrow`
+ - Fix WiFi to prefer strongest AP when multiple APs have same SSID :esphomepr:`9963` by :ghuser:`dayowe`
+ - [api] Eliminate heap allocations when populating repeated fields from containers :esphomepr:`9948` by :ghuser:`bdraco`
+ - [wifi] add more disconnect reason descriptions :esphomepr:`9955` by :ghuser:`ssieb`
+ - [sensor] Add new filter: ``throttle_with_priority`` :esphomepr:`9937` by :ghuser:`kbx81`
+ - [template] Add tests for more sensor filters :esphomepr:`9973` by :ghuser:`kbx81`
+ - [esp32_ble_client] Fix connection failures with short discovery timeout devices and speed up BLE connections :esphomepr:`9971` by :ghuser:`bdraco`
+ - media_player add off on capability :esphomepr:`9294` by :ghuser:`rwrozelle`
+ - [core] Fix regex for lambda id() replacement :esphomepr:`9975` by :ghuser:`clydebarrow`
+ - [CI] Add labels for checkboxes :esphomepr:`9991` by :ghuser:`jesserockz`
+ - [api] Bump APIVersion to 1.11 :esphomepr:`9990` by :ghuser:`rwrozelle`
+ - [api] Reduce flash usage through targeted optimizations :esphomepr:`9979` by :ghuser:`bdraco`
+ - [esp32_touch] Work around ESP-IDF v5.4 regression in `touch_pad_read_filtered` :esphomepr:`9957` by :ghuser:`bdraco` (breaking-change)
+ - [esp32_ble] Fix spurious BLE 5.0 event warnings on ESP32-S3 :esphomepr:`9969` by :ghuser:`bdraco`
+ - [tm1651] Remove dependency on Arduino Library :esphomepr:`9645` by :ghuser:`mrtoy-me`
+ - [wifi] Allow fast_connect with multiple networks :esphomepr:`9947` by :ghuser:`GilDev`
+ - [esp32_ble_client] Fix BLE connection stability for WiFi-based proxies :esphomepr:`9993` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Batch BLE service discovery messages for 67% reduction in API traffic :esphomepr:`9992` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Optimize UUID transmission with efficient short_uuid field :esphomepr:`9995` by :ghuser:`bdraco`
+ - [esp32] Bump ESP32 platform to 54.03.21-2 :esphomepr:`10000` by :ghuser:`swoboda1337`
+ - [esp32] Fix strapping pin validation for P4 and H2 :esphomepr:`9980` by :ghuser:`clydebarrow`
+ - [bluetooth_proxy] Implement dynamic service batching based on MTU constraints :esphomepr:`10001` by :ghuser:`bdraco`
+ - [midea] Use c++17 constexpr and inline static in IrFollowMeData :esphomepr:`10002` by :ghuser:`DjordjeMandic`
+ - [image] Improve schemas :esphomepr:`9791` by :ghuser:`clydebarrow`
+ - [nrf52] add adc :esphomepr:`9321` by :ghuser:`tomaszduda23` (new-feature)
+ - [ruff] Enable RET and fix all violations :esphomepr:`9929` by :ghuser:`bdraco`
+ - [sensor] Fix bug in percentage based delta filter :esphomepr:`8157` by :ghuser:`swoboda1337`
+ - [sensor] A little bit of filter clean-up :esphomepr:`9986` by :ghuser:`kbx81`
+ - [espnow] Basic communication between ESP32 devices :esphomepr:`9582` by :ghuser:`nielsnl68` (new-component) (new-feature)
+ - [nrf52, debug] debug component for nrf52 :esphomepr:`8315` by :ghuser:`tomaszduda23`
+ - [nrf52, gpio] check different port notation :esphomepr:`9737` by :ghuser:`tomaszduda23`
+ - [esp32] Add config option to execute from PSRAM :esphomepr:`9907` by :ghuser:`clydebarrow` (new-feature)
+ - [wifi] Fix crash during WiFi reconnection on ESP32 with poor signal quality :esphomepr:`9989` by :ghuser:`bdraco`
+ - [CI] Allow multiple grep options for clang-tidy :esphomepr:`10004` by :ghuser:`jesserockz`
+ - [bluetooth_proxy] Eliminate heap allocations in connection state reporting :esphomepr:`10010` by :ghuser:`bdraco`
+ - [core] Convert entity vectors to static allocation for reduced memory usage :esphomepr:`10018` by :ghuser:`bdraco`
+ - [syslog] Fix RFC3164 timestamp compliance for single-digit days :esphomepr:`10034` by :ghuser:`Copilot`
+ - [core] Fix compilation errors when platform sections have no entities :esphomepr:`10023` by :ghuser:`bdraco`
+ - [config] Fix reversion of excessive yaml output after error :esphomepr:`10043` by :ghuser:`clydebarrow`
+ - [color][lvgl] Allow Color to be used for lv_color_t :esphomepr:`10016` by :ghuser:`clydebarrow` (new-feature)
+ - Update esp32-camera library version to 2.1.0 :esphomepr:`9527` by :ghuser:`RubenKelevra`
+ - [core] Replace std::find and std::max_element with simple loops to reduce binary size :esphomepr:`10044` by :ghuser:`bdraco`
+ - [core] Convert components, devices, and areas vectors to static allocation :esphomepr:`10020` by :ghuser:`bdraco`
+ - [core] Replace std::stable_sort with insertion sort to save 3.5KB flash :esphomepr:`10035` by :ghuser:`bdraco`
+ - [web_server_idf] Replace std::find_if with simple loop to reduce binary size :esphomepr:`10042` by :ghuser:`bdraco`
+ - [core] Optimize Application::pre_setup() to reduce duplicate MAC address operations :esphomepr:`10039` by :ghuser:`bdraco`
+ - [web_server] Reduce binary size by using EntityBase and minimizing template instantiations :esphomepr:`10033` by :ghuser:`bdraco`
+ - [web_server] Conditionally compile authentication code to save flash memory :esphomepr:`10022` by :ghuser:`bdraco`
+ - [core] Update to esptool 5.0+ command syntax :esphomepr:`10011` by :ghuser:`bdraco`
+ - [wifi] Replace std::stable_sort with insertion sort to save 2.4KB flash :esphomepr:`10037` by :ghuser:`bdraco`
+ - [esp32] Add framework migration warning for upcoming ESP-IDF default change :esphomepr:`10030` by :ghuser:`bdraco` (new-feature)
+ - [api] Use static allocation for areas and devices in DeviceInfoResponse :esphomepr:`10038` by :ghuser:`bdraco`
+ - [AI] Add note about the defines.h file needing to include all new defines added :esphomepr:`10054` by :ghuser:`jesserockz`
+ - [nfc] Rename ``binary_sensor`` source files :esphomepr:`10053` by :ghuser:`jesserockz`
+ - [core] Move docs url generator to helpers.py :esphomepr:`10056` by :ghuser:`jesserockz`
+ - [esp32_ble_tracker] Remove unnecessary STOPPED scanner state to reduce latency :esphomepr:`10055` by :ghuser:`bdraco`
+ - [esp32_ble_client] Use FAST connection parameters for all v3 connections :esphomepr:`10052` by :ghuser:`bdraco`
+ - [esp32_ble_client] Connect immediately on READY_TO_CONNECT to reduce latency :esphomepr:`10051` by :ghuser:`bdraco`
+ - [esp32_ble] Fix BLE connection slot waste by aligning ESP-IDF timeout with client timeout :esphomepr:`10013` by :ghuser:`bdraco`
+ - [gt911] Use timeout instead of delay, shortened log msg :esphomepr:`10024` by :ghuser:`DjordjeMandic`
+ - [espnow, web_server_idf] Fix IDF 5.5 compile issues :esphomepr:`10068` by :ghuser:`swoboda1337`
+ - Add CO5300 display support :esphomepr:`9739` by :ghuser:`mschnaubelt` (new-feature)
+ - [api] Add helpful compile-time errors for Custom API Device methods :esphomepr:`10076` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Warn about BLE connection timeout mismatch on Arduino framework :esphomepr:`10063` by :ghuser:`bdraco`
+ - [esp32_ble_client] Start MTU negotiation earlier following ESP-IDF examples :esphomepr:`10062` by :ghuser:`bdraco`
+ - [esp32_ble_tracker] Optimize connection by promoting client immediately after scan stop trigger :esphomepr:`10061` by :ghuser:`bdraco`
+ - [esp32_ble_tracker] Eliminate redundant ring buffer for lower latency :esphomepr:`10057` by :ghuser:`bdraco`
+ - [esp32_ble_client] Fix connection parameter timing by setting preferences before connection :esphomepr:`10059` by :ghuser:`bdraco`
+ - [tests] Add datetime entities to host_mode_many_entities integration test :esphomepr:`10032` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Optimize memory usage with fixed-size array and const string references :esphomepr:`10015` by :ghuser:`bdraco`
+ - [esp32_dac] Always use esp-idf APIs :esphomepr:`9833` by :ghuser:`jesserockz`
+ - [core] Allow extra args on cli and just ignore them :esphomepr:`9814` by :ghuser:`jesserockz`
+ - [gpio_expander] Fix bank caching :esphomepr:`10077` by :ghuser:`jesserockz`
+ - [remote_transmitter] Add digital_write automation :esphomepr:`10069` by :ghuser:`swoboda1337` (new-feature)
+ - Support multiple --device arguments for address fallback :esphomepr:`10003` by :ghuser:`bdraco` (new-feature)
+ - [core] Update core component codeowners to ``@esphome/core`` :esphomepr:`10082` by :ghuser:`jesserockz`
+ - Add myself to multiple bluetooth codeowners :esphomepr:`10083` by :ghuser:`bdraco`
+ - [speaker] Media player fixes for IDF5.4 :esphomepr:`10088` by :ghuser:`kahrendt`
+ - [espnow] Small changes and fixes :esphomepr:`10014` by :ghuser:`nielsnl68`
+ - [select] Fix new_select() not forwarding constructor args while preserving keyword-only options parameter :esphomepr:`10036` by :ghuser:`Copilot`
+ - [mcp23xxx] Use CachedGpioExpander :esphomepr:`10078` by :ghuser:`jesserockz`
+ - update espressif's esp32-camera library to 2.1.1 :esphomepr:`10090` by :ghuser:`RubenKelevra`
+ - [esp32_ble_tracker] Add missing USE_ESP32_BLE_DEVICE guard for ``already_discovered_`` member :esphomepr:`10085` by :ghuser:`bdraco`
+ - [esp32_ble_tracker] Refactor loop() method for improved readability and performance :esphomepr:`10074` by :ghuser:`bdraco`
+ - [esp32_rmt_led_strip] Work around IDFGH-16195 :esphomepr:`10093` by :ghuser:`swoboda1337`
+ - [bme680] Eliminate warnings due to unused functions :esphomepr:`9735` by :ghuser:`pgolawsk`
+ - [light] Allow light effect schema to be a schema object already :esphomepr:`10091` by :ghuser:`jesserockz`
+ - [bluetooth_proxy] Reduce flash usage by consolidating duplicate logging :esphomepr:`10094` by :ghuser:`bdraco`
+ - [esp32_ble_tracker] Simplify state machine guards with helper functions :esphomepr:`10092` by :ghuser:`bdraco`
+ - [deep_sleep] enable sleep pull up/down for wakeup pin :esphomepr:`9395` by :ghuser:`candrews`
+ - [esp32_ble] Make BLE notification limit configurable to fix ESP_GATT_NO_RESOURCES errors :esphomepr:`10098` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Replace std::find with simple loop for small fixed array :esphomepr:`10102` by :ghuser:`bdraco`
+ - [ld2410] Replace ``throttle`` with native filters :esphomepr:`10019` by :ghuser:`kbx81` (breaking-change)
+ - [esp32_ble_client] Convert to C++17 nested namespace syntax :esphomepr:`10111` by :ghuser:`bdraco`
+ - [esp32_ble] Conditionally compile BLE advertising to reduce flash usage :esphomepr:`10099` by :ghuser:`bdraco` (breaking-change)
+ - [bluetooth_proxy] Consolidate dump_config() log calls :esphomepr:`10103` by :ghuser:`bdraco`
+ - [bluetooth_proxy][esp32_ble_tracker][esp32_ble_client] Consolidate duplicate logging code to reduce flash usage :esphomepr:`10097` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Remove unnecessary heap allocation for response object :esphomepr:`10104` by :ghuser:`bdraco`
+ - Add device class absolute_humidity to the absolute humidity component :esphomepr:`10100` by :ghuser:`mbo18` (new-feature)
+ - [esp32_touch] Restore get_value() for ESP32-S2/S3 variants :esphomepr:`10112` by :ghuser:`bdraco`
+ - [esp32_ble_client] Avoid iterating empty services vector for bluetooth_proxy connections :esphomepr:`10110` by :ghuser:`bdraco`
+ - [esp32_ble_tracker] Optimize member variable ordering to reduce memory padding :esphomepr:`10113` by :ghuser:`bdraco`
+ - [esp32_ble_client] Conditionally compile BLE service classes to reduce flash usage :esphomepr:`10114` by :ghuser:`bdraco` (breaking-change)
+ - [bluetooth_proxy] Remove V1 connection support :esphomepr:`10107` by :ghuser:`bdraco` (breaking-change)
+ - [switch] Add ``switch.control`` automation action :esphomepr:`10105` by :ghuser:`edwardtfn` (new-feature)
+ - [mdns] Conditionally compile extra services to reduce flash usage :esphomepr:`10129` by :ghuser:`bdraco`
+ - [esp32_ble_client] Reduce flash usage by optimizing logging strings :esphomepr:`10119` by :ghuser:`bdraco`
+ - [wifi] Reduce flash usage by optimizing logging :esphomepr:`10127` by :ghuser:`bdraco`
+ - [cover] Reduce flash usage by optimizing validation messages :esphomepr:`10130` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Optimize connection loop to reduce CPU usage :esphomepr:`10133` by :ghuser:`bdraco`
+ - [switch] Add ``control()`` method to API :esphomepr:`10118` by :ghuser:`edwardtfn` (new-feature)
+ - [switch] Add trigger ``on_state`` :esphomepr:`10108` by :ghuser:`edwardtfn` (new-feature)
+ - [esp32_ble_tracker] Fix false reboots when event loop is blocked :esphomepr:`10144` by :ghuser:`bdraco`
+ - [esp32] Add IDF log_level option :esphomepr:`10134` by :ghuser:`swoboda1337` (breaking-change)
+ - [dashboard] Fix port fallback regression when device is offline :esphomepr:`10135` by :ghuser:`bdraco`
+ - [web_server] Reduce flash usage by consolidating parameter parsing :esphomepr:`10154` by :ghuser:`bdraco`
+ - [ade7880] Fix duplicate sensor name validation error :esphomepr:`10155` by :ghuser:`bdraco`
+ - Optimize subprocess performance with close_fds=False :esphomepr:`10145` by :ghuser:`bdraco`
+ - [CI] Print more info for when consts are duplicated :esphomepr:`10166` by :ghuser:`jesserockz`
+ - [neopixelbus] Fix neopixelbus on esp32 :esphomepr:`10123` by :ghuser:`swoboda1337`
+ - [lvgl] Various validation fixes :esphomepr:`10141` by :ghuser:`clydebarrow`
+ - [lvgl] fix allocation of reduced size buffer with rotation :esphomepr:`10147` by :ghuser:`clydebarrow`
+ - [nrf52, zephyr_debug] add zephyr debug component :esphomepr:`8319` by :ghuser:`tomaszduda23` (new-feature)
+ - [display] Disallow ``show_test_card: true`` and ``update_interval: never`` :esphomepr:`9927` by :ghuser:`ChadMatsalla`
+ - [sensor] Extend timeout filter with option to return last value received :esphomepr:`10115` by :ghuser:`kbx81` (new-feature)
+ - [esphome] Fix OTA watchdog resets during port scanning and network delays :esphomepr:`10152` by :ghuser:`bdraco`
+ - [api] Optimize single vector writes to use write() instead of writev() :esphomepr:`10193` by :ghuser:`bdraco`
+ - [bluetooth_proxy] Replace dynamic vector with fixed array for BLE advertisements :esphomepr:`10174` by :ghuser:`bdraco`
+ - [substitutions] Add some safe built-in functions to jinja parsing :esphomepr:`10178` by :ghuser:`jesserockz` (new-feature)
+ - [core] Improve entity duplicate validation error messages :esphomepr:`10184` by :ghuser:`bdraco`
+ - [api] Add constexpr optimizations to protobuf encoding :esphomepr:`10192` by :ghuser:`bdraco`
+ - [wifi] Remove restriction from using NONE power saving mode with BLE :esphomepr:`10181` by :ghuser:`kahrendt`
+ - [const] Add CONF_POWER_MODE :esphomepr:`10173` by :ghuser:`joshuasing`
+ - [core] Reset pin registry after target platform validations :esphomepr:`10199` by :ghuser:`jesserockz`
+ - [ld2412] New component :esphomepr:`9075` by :ghuser:`Rihan9` (new-component) (new-feature) (new-platform)
+ - [atm90e32] energy meter calibration log output enhancements & software SPI fix :esphomepr:`10143` by :ghuser:`CircuitSetup`
+ - [ld2450] Replace ``throttle`` with native filters :esphomepr:`10196` by :ghuser:`kbx81` (breaking-change)
+ - [bme280_base, bmp280_base] add reasons to the fails, clean up logging :esphomepr:`10209` by :ghuser:`ssieb`
+ - [bluetooth_proxy] Remove ESPBTUUID dependency to save 296 bytes of flash :esphomepr:`10213` by :ghuser:`bdraco`
+
+Dependency Changes
+^^^^^^^^^^^^^^^^^^
+
+.. collapse:: Show
+
+ - Bump ruff from 0.12.2 to 0.12.3 :esphomepr:`9446` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 34.2.1 to 35.0.1 :esphomepr:`9474` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 35.0.1 to 36.0.0 :esphomepr:`9567` by :ghuser:`dependabot[bot]`
+ - Bump pytest-asyncio from 1.0.0 to 1.1.0 :esphomepr:`9588` by :ghuser:`dependabot[bot]`
+ - Bump pytest-xdist from 3.7.0 to 3.8.0 :esphomepr:`9287` by :ghuser:`dependabot[bot]`
+ - Bump ruff from 0.12.3 to 0.12.4 :esphomepr:`9634` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 36.0.0 to 36.0.1 :esphomepr:`9636` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 36.0.1 to 37.0.0 :esphomepr:`9677` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.0.0 to 37.0.1 :esphomepr:`9685` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.0.1 to 37.0.2 :esphomepr:`9738` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.0.2 to 37.0.3 :esphomepr:`9754` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.0.3 to 37.0.4 :esphomepr:`9764` by :ghuser:`dependabot[bot]`
+ - Bump ruff from 0.12.4 to 0.12.5 :esphomepr:`9871` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.0.4 to 37.1.0 :esphomepr:`9905` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.1.0 to 37.1.2 :esphomepr:`9910` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.1.2 to 37.1.3 :esphomepr:`9943` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.1.3 to 37.1.4 :esphomepr:`9964` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.1.4 to 37.1.5 :esphomepr:`9977` by :ghuser:`dependabot[bot]`
+ - Bump ruff from 0.12.5 to 0.12.7 :esphomepr:`9976` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.1.5 to 37.1.6 :esphomepr:`9988` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.1.6 to 37.2.0 :esphomepr:`9996` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.2.0 to 37.2.1 :esphomepr:`9998` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.2.1 to 37.2.2 :esphomepr:`10009` by :ghuser:`dependabot[bot]`
+ - Bump esptool from 4.9.0 to 5.0.2 :esphomepr:`9983` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.2.2 to 37.2.3 :esphomepr:`10012` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.2.3 to 37.2.4 :esphomepr:`10050` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.2.4 to 37.2.5 :esphomepr:`10080` by :ghuser:`dependabot[bot]`
+ - Bump docker/login-action from 3.4.0 to 3.5.0 in the docker-actions group :esphomepr:`10081` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 37.2.5 to 38.0.0 :esphomepr:`10109` by :ghuser:`dependabot[bot]`
+ - Bump actions/download-artifact from 4.3.0 to 5.0.0 :esphomepr:`10106` by :ghuser:`dependabot[bot]`
+ - Bump actions/cache from 4.2.3 to 4.2.4 in /.github/actions/restore-python :esphomepr:`10125` by :ghuser:`dependabot[bot]`
+ - Bump actions/cache from 4.2.3 to 4.2.4 :esphomepr:`10128` by :ghuser:`dependabot[bot]`
+ - Bump ruff from 0.12.7 to 0.12.8 :esphomepr:`10126` by :ghuser:`dependabot[bot]`
+ - Bump tornado from 6.5.1 to 6.5.2 :esphomepr:`10142` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 38.0.0 to 38.1.0 :esphomepr:`10176` by :ghuser:`dependabot[bot]`
+ - Bump pylint from 3.3.7 to 3.3.8 :esphomepr:`10177` by :ghuser:`dependabot[bot]`
+ - Bump aioesphomeapi from 38.1.0 to 38.2.1 :esphomepr:`10197` by :ghuser:`dependabot[bot]`
+ - Bump actions/checkout from 4 to 5 :esphomepr:`10198` by :ghuser:`dependabot[bot]`
+
+
+Past Changelogs
+---------------
+
+.. collapse:: Show
+
+ - :doc:`2025.7.0`
+ - :doc:`2025.6.0`
+ - :doc:`2025.5.0`
+ - :doc:`2025.4.0`
+ - :doc:`2025.3.0`
+ - :doc:`2025.2.0`
+ - :doc:`2024.12.0`
+ - :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`
diff --git a/changelog/index.rst b/changelog/index.rst
index d9b1e30f9a..6ebcfefde1 100644
--- a/changelog/index.rst
+++ b/changelog/index.rst
@@ -2,7 +2,7 @@ Changelog
=========
.. redirect::
- :url: /changelog/2025.7.0.html
+ :url: /changelog/2025.8.0.html
.. toctree::
:glob:
diff --git a/components/api.rst b/components/api.rst
index 49b281d6d8..59fb73d74b 100644
--- a/components/api.rst
+++ b/components/api.rst
@@ -98,6 +98,8 @@ Configuration variables:
WiFi performance with many rapidly-changing sensors. Only use this setting when necessary.
- **custom_services** (*Optional*, boolean): Enable compilation of custom API services for external components that use the C++ ``CustomAPIDevice`` class. Only needed when external components register their own services via the native API. Defaults to ``false``.
+- **homeassistant_services** (*Optional*, boolean): Enable compilation of Home Assistant service call support for external components that use the C++ ``CustomAPIDevice::call_homeassistant_service()`` or ``CustomAPIDevice::fire_homeassistant_event()`` methods. This is automatically enabled when using ``homeassistant.service`` or ``homeassistant.event`` actions, or the ``homeassistant`` platform for number or switch components. Only needs to be manually set when external components call Home Assistant services without using the built-in actions. Defaults to ``false``.
+- **homeassistant_states** (*Optional*, boolean): Enable compilation of Home Assistant state subscription support for external components that use the C++ ``CustomAPIDevice::subscribe_homeassistant_state()`` method. This is automatically enabled when using any ``homeassistant`` platform components (sensor, binary_sensor, text_sensor, switch, or number). Only needs to be manually set when external components subscribe to Home Assistant states without using the built-in components. Defaults to ``false``.
- **reboot_timeout** (*Optional*, :ref:`config-time`): The amount of time to wait before rebooting when no
client connects to the API. This is needed because sometimes the low level ESP functions report that
the ESP is connected to the network, when in fact it is not - only a full reboot fixes it.
diff --git a/components/binary_sensor/packet_transport.rst b/components/binary_sensor/packet_transport.rst
index c3575d1bbb..2bed54fd08 100644
--- a/components/binary_sensor/packet_transport.rst
+++ b/components/binary_sensor/packet_transport.rst
@@ -27,8 +27,8 @@ It requires a ``packet_transport`` component to be configured.
- platform: ...
-Configuration variables
------------------------
+Configuration variables:
+------------------------
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **provider** (**Required**, string): The name of the provider node.
diff --git a/components/button/factory_reset.rst b/components/button/factory_reset.rst
index f8ed5a97a7..b6559aa237 100644
--- a/components/button/factory_reset.rst
+++ b/components/button/factory_reset.rst
@@ -40,6 +40,7 @@ Configuration variables:
See Also
--------
+- :doc:`/components/factory_reset`
- :doc:`shutdown`
- :doc:`restart`
- :doc:`safe_mode`
diff --git a/components/display/ili9xxx.rst b/components/display/ili9xxx.rst
index e57f8c275c..49c581d112 100644
--- a/components/display/ili9xxx.rst
+++ b/components/display/ili9xxx.rst
@@ -41,6 +41,11 @@ ILI9341 (`datasheet `__) a
displays from the same chip family with ESPHome. As this is a somewhat higher resolution display and requires additional pins
beyond the basic SPI connections, and a reasonable amount of RAM, it is not well suited for the ESP8266.
+.. warning::
+
+ This component has been made redundant since this class of displays is now supported by the :ref:`mipi_spi`.
+ This component may be removed in a future release.
+
.. note::
PSRAM is not automatically enabled on the ESP32 (this changed with the 2025.2 release.) If PSRAM is available, you
diff --git a/components/display/mipi_dsi.rst b/components/display/mipi_dsi.rst
new file mode 100644
index 0000000000..1a98bdc1e6
--- /dev/null
+++ b/components/display/mipi_dsi.rst
@@ -0,0 +1,178 @@
+.. seo::
+ :description: Details for the MIPI DSI display driver component in ESPHome
+ :image: tab5.jpg
+
+.. _mipi_dsi:
+
+MIPI DSI Display Driver
+=======================
+
+Introduction
+------------
+
+This driver is for displays that use the MIPI DSI display interface available in the ESP32-P4.
+
+.. figure:: /images/tab5.jpg
+ :align: center
+ :width: 75.0%
+
+ M5STACK-TAB5 with ESP32-P4
+
+Background
+----------
+
+The MIPI (Mobile Industry Processor Interface) Alliance publishes various hardware and software interface specifications
+including the Display Serial Interface (DSI), which transfers pixel data over a high-speed serial bus to an LCD display.
+
+The display panels controlled by the driver may be of various types, including TFT, IPS, and others. Each driver
+chip and panel combination requires a specific set of initialisation commands, and standard initialisation sequences are provided for many common
+boards and chips, but the driver is also designed to be customisable in YAML for other displays.
+
+Supported boards and driver chips
+---------------------------------
+
+There are specific configurations for several ESP32 boards with integrated displays. For those boards
+the predefined configuration will set the correct pins and dimensions for the display.
+
+For custom displays, the driver can be configured with the correct pins and dimensions, and the driver chip can be
+specified, or a custom init sequence can be provided.
+
+Driver chips
+^^^^^^^^^^^^
+
+.. csv-table::
+ :header: "Driver Chip", "Typical Dimensions"
+ :widths: 15, 20
+
+ "CUSTOM", "Customisable"
+
+Boards with integrated displays
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. csv-table::
+ :header: "Model", "Manufacturer", "Product Description"
+ :widths: 30, 20, 30
+
+ "JC1060P470", "Guition", "https://aliexpress.com/item/1005008328088576.html"
+ "M5STACK-TAB5", "M5Stack", "https://shop.m5stack.com/products/m5stack-tab5-iot-development-kit-esp32-p4"
+ "WAVESHARE-P4-NANO-10.1", "Waveshare", "https://www.waveshare.com/esp32-p4-nano.htm?sku=29031"
+ "WAVESHARE-P4-86-PANEL", "Waveshare", "https://www.waveshare.com/esp32-p4-wifi6-touch-lcd-4b.htm?sku=31570"
+
+
+Configuration
+-------------
+
+.. code-block:: yaml
+
+ # Example minimal configuration entry
+ display:
+ - platform: mipi_dsi
+ model: WAVESHARE-P4-NANO-10.1
+
+Configuration options
+^^^^^^^^^^^^^^^^^^^^^
+
+All :ref:`graphical display configuration` options are available, plus the following. For integrated display boards
+most of the configuration will be set by default, but can be overridden if needed.
+
+- **model** (**Required**): Chosen from the lists of supported chips and models above, or ``CUSTOM`` for custom displays.
+- **reset_pin** (*Optional*, :ref:`Pin Schema `): The RESET pin, if required.
+- **enable_pin** (*Optional*, :ref:`Pin Schema `): An optional pin to enable the display, if required. A list of pins can be provided for displays that require multiple enable pins. A full pin configuration may be provided
+ to set the pin mode and inverted property. By default the pin will be driven high to enable the display.
+- **color_order** (*Optional*): Should be one of ``bgr`` (default) or ``rgb``. This specifies the order of the color channels in the display panel. The default is ``bgr`` for most displays, but some displays may require ``rgb``. It does not affect the color order of the display buffer, which is always RGB.
+- **dimensions** (*Optional*): Dimensions of the screen, specified either as *width* **x** *height* (e.g ``320x240``) or with separate config keys. If not provided the dimensions will be determined by the model selected. This is required for the ``CUSTOM`` model, and is optional for other models. The dimensions are specified in pixels, and the width and height must be greater than 0. The following keys are available:
+
+ - **height** (**Required**, int): Specifies height of display in pixels.
+ - **width** (**Required**, int): Specifies width of display.
+ - **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*, boolean): Specifies whether the display colors should be inverted. Options are ``true`` or ``false``. Defaults to ``false``.
+- **rotation** (*Optional*): Rotate the display presentation in software. Choose one of ``0°``, ``90°``, ``180°``, or ``270°``. If the driver chip supports hardware rotation for the given orientation this will be translated to the appropriate hardware command. If hardware rotation is not supported, the display will be rotated in software.
+- **transform** (*Optional*): If ``rotation`` is not sufficient, use this to transform the display. If this option is specified, then the ``dimensions`` option must also be provided. Options are:
+
+ - **swap_xy** (**Required**, boolean): If true, exchange the x and y axes.
+ - **mirror_x** (**Required**, boolean): If true, mirror the x axis.
+ - **mirror_y** (**Required**, boolean): If true, mirror the y axis.
+
+- **hsync_pulse_width** (*Optional*, int): The horizontal sync pulse width.
+- **hsync_front_porch** (*Optional*, int): The horizontal front porch length.
+- **hsync_back_porch** (*Optional*, int): The horizontal back porch length.
+- **vsync_pulse_width** (*Optional*, int): The vertical sync pulse width.
+- **vsync_front_porch** (*Optional*, int): The vertical front porch length.
+- **vsync_back_porch** (*Optional*, int): The vertical back porch length.
+- **pclk_frequency** (*Optional*): Set the pixel clock speed. Default is 40MHz.
+- **pclk_inverted** (*Optional*, bool): If the pclk is active negative (default is True)
+- **lanes** (*Optional*, int): Number of serial data lanes to use - 1 or 2. Default is 2.
+- **lane_bit_rate** (*Optional*, int): The bit rate of the serial data lanes. No default unless a non-custom model is selected.
+
+Advanced options
+^^^^^^^^^^^^^^^^
+
+- **init_sequence** (*Optional*): Allows custom initialisation sequences to be added. See below for more information.
+- **pixel_mode** (*Optional*): Select the interface mode for the display driver. Options are ``16bit`` (default) and ``24bit``.
+- **color_depth** (*Optional*): The color depth of the display buffer, expressed in bits. Options are ``16`` (default) and ``24``. Preferably should be the same as the ``pixel_mode`` option.
+- **draw_rounding** (*Optional*): The rounding factor for drawing operations. Defaults to 2. Some chips require a higher value to avoid display artifacts. Must be a power of 2.
+- **use_axis_flips** (*Optional*): If true, the driver will use alternate bits in the MADCTL register to implement x and y mirroring. Defaults to false.
+- **byte_order** (*Optional*): The byte order of the display buffer. Options are ``big_endian`` and ``little_endian`` (default). This affects the byte order for the buffer when
+ using 16 bit color depth. The default is appropriate for the majority of displays.
+
+
+Additional initialisation sequences
+-----------------------------------
+
+The ``init_sequence`` option allows additional configuration of the driver chip. Provided commands will be sent to the
+driver chip in addition to, and after the chosen model's pre-defined commands. It requires a list of byte sequences:
+
+.. code-block:: yaml
+
+ init_sequence:
+ - [ 0xD0, 0x07, 0x42, 0x18]
+ - delay 10ms
+ - [ 0xD1, 0x00, 0x07, 0x10]
+
+Each entry represents a single-byte command followed by zero or more data bytes. Delays can be inserted with the ``delay`` keyword followed by a time in milliseconds. The delay is not precise, but will be at least the specified time.
+If converting from other code, make sure the length byte, if present, is not copied as the length of each command sequence is determined by the number of bytes in the list.
+
+CUSTOM model
+------------
+
+The ``CUSTOM`` model selection is provided for otherwise unsupported displays, and requires both ``dimensions:`` and ``init_sequence:`` to be specified. There is no pre-defined init sequence.
+
+Using the ``transform`` options
+-------------------------------
+
+In most cases, the ``rotation`` option will be sufficient to orient the display correctly. However, some displays may require additional transformations. The ``transform`` option allows for these transformations to be applied in any of 8 different
+combinations. It may be necessary to experiment with different combinations to achieve the desired result. When using the ``transform`` option, the ``rotation`` option should not be set unless the display does not support axis-swapping.
+If the ``swap_xy`` option is set, then the ``dimensions`` option is required, and the ``width`` and ``height`` values should be set to reflect the final screen dimensions after rotation.
+
+.. code-block:: yaml
+
+ transform:
+ swap_xy: true
+ mirror_x: true
+ mirror_y: false
+ dimensions:
+ height: 480
+ width: 320
+
+
+LCD Backlights
+--------------
+
+Many displays have an integrated backlight, which may need to be turned on for the display to show. This backlight is not controlled
+by the driver, but can be controlled by a separate GPIO pin. Depending on the display, the backlight may be active high or active low, and may
+be able to be dimmed using a :doc:`/components/light/monochromatic` with a :doc:`/components/output/ledc`.
+
+Touchscreens
+------------
+
+A touchscreen, if present, must be configured separately. See the :doc:`/components/touchscreen/index` documentation for more information.
+
+See Also
+--------
+
+- :doc:`index`
+- :doc:`/components/lvgl/index`
+- :apiref:`mipi_dsi/mipi_dsi.h`
+- :ghedit:`Edit`
diff --git a/components/display/mipi_spi.rst b/components/display/mipi_spi.rst
index 5f75e6ce2e..35a2e79b28 100644
--- a/components/display/mipi_spi.rst
+++ b/components/display/mipi_spi.rst
@@ -1,12 +1,12 @@
-MIPI SPI Display Driver
-=======================
-
.. seo::
:description: Details for the MIPI SPI display driver component in ESPHome
:image: ili9341.jpg
.. _mipi_spi:
+MIPI SPI Display Driver
+=======================
+
Introduction
------------
@@ -56,6 +56,7 @@ Driver chips
"GC9D01N", "240x240"
"AXS15231", "320x240"
"ST7735", "128x160"
+ "CO5300", "466x466"
"CUSTOM", "Customisable"
Boards with integrated displays
@@ -65,11 +66,14 @@ Boards with integrated displays
:header: "Model", "Manufacturer", "Product Description"
:widths: 30, 20, 30
+ "ADAFRUIT-S2-TFT-FEATHER", "Adafruit", "https://www.adafruit.com/product/6312"
+ "ADAFRUIT-FUNHOUSE", "Adafruit", "https://www.adafruit.com/product/4985"
"M5CORE", "M5Stack", "https://docs.m5stack.com/en/core/BASIC%20v2.6"
"S3BOX", "Espressif", "https://www.espressif.com/en/products/devkits/esp32-s3-box"
"S3BOXLITE", "Espressif", "https://www.espressif.com/en/products/devkits/esp32-s3-box-lite"
"WAVESHARE-4-TFT", "Waveshare", "https://www.waveshare.com/4inch-tft-touch-shield.htm"
"PICO-RESTOUCH-LCD-3.5", "Waveshare", "https://www.waveshare.com/pico-restouch-lcd-3.5.htm"
+ "WAVESHARE-ESP32-S3-TOUCH-AMOLED-1.75", "Waveshare", "https://www.waveshare.com/esp32-s3-touch-amoled-1.75.htm"
"WT32-SC01-PLUS", "Wireless-Tag", "https://www.wireless-tag.com/portfolio/wt32-sc01-plus/"
"ESP32-2432S028", "Sunton", "https://www.espressif.com/en/products/devkits/esp32-2432s028"
"JC3248W535", "Guition", "https://www.aliexpress.com/item/1005007566332450.html"
@@ -138,6 +142,8 @@ most of the configuration will be set by default, but can be overridden if neede
- **mirror_y** (**Required**, boolean): If true, mirror the y axis.
- **color_depth** (*Optional*): The color depth of the display buffer, expressed in bits. Options are ``16`` (default) and ``8``. 8 bit depth will result in only 256 possible colors and should be used only if the microcontroller has limited memory. The driver will convert the 8 bit color to the display chip's required format.
+- **buffer_size** (*Optional*): The percentage of screen size to allocate buffer memory. The default is ``100%`` when PSRAM is configured, and otherwise will be calculated to
+ achieve a buffer size less than 20K bytes. See the discussion below about buffer sizes.
Advanced options
^^^^^^^^^^^^^^^^
@@ -148,13 +154,35 @@ Advanced options
- **data_rate** (*Optional*): The SPI data rate. Defaults to 10MHz but board presets may override this.
- **spi_mode** (*Optional*): The SPI mode. Options are ``MODE0``, ``MODE1``, ``MODE2``, and ``MODE3``. Defaults to ``MODE0`` for single bit SPI and ``MODE3`` for octal SPI (parallel bus.)
- **draw_rounding** (*Optional*): The rounding factor for drawing operations. Defaults to 2. Some chips require a higher value to avoid display artifacts. Must be a power of 2.
-- **draw_from_origin** (*Optional*): If true, drawing operations will always start from the origin (0,0) of the display. Defaults to false.
- **use_axis_flips** (*Optional*): If true, the driver will use alternate bits in the MADCTL register to implement x and y mirroring. Defaults to false.
+- **byte_order** (*Optional*): The byte order of the display buffer. Options are ``big_endian`` (default) and ``little_endian``. This affects the byte order for the buffer when
+ using 16 bit color depth. The default is appropriate for the majority of displays.
**Note:** The maximum achievable data rate will depend on the chip type (e.g. ESP32 vs ESP32-S3) the pins used (on ESP32 using the default SPI pins allows higher rates) and the connection type (on-board connections will support higher rates than long cables or DuPont wires.) If in doubt, start with a low speed and test higher rates to find what works. A MISO pin should preferably not be specified, as this will limit the maximum rate in some circumstances, and is not required if the SPI bus is used only for the display.
+
+Buffer Size
+------------
+
+The display driver writes data from a buffer to the display chip. When using :doc:`/components/lvgl/index` no buffer is required in the display driver itself, as LVGL will
+allocate and use its own buffer.
+When instead using a lambda function to update the display (and not LVGL), a buffer is required to be allocated by the display driver.
+The size of this buffer is determined by the ``buffer_size`` option. The default is ``100%`` when PSRAM is configured, and otherwise will be calculated to
+achieve a buffer size less than 20K bytes. For example a display of size 320x240 will have a buffer size of ``320 * 240 * 2`` bytes (for RGB565) = ``153600`` bytes.
+If the buffer size is set to ``50%``, then the buffer would occupy ``76800`` bytes. If 8 bit color depth is used, then each pixel occupies only 1 byte.
+
+Effect on Drawing Performance
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The buffer size is a trade-off between the size of the buffer and the performance of the display driver. A larger buffer size will provide better performance,
+but on boards with limited memory, a smaller buffer size may be required to avoid running out of memory. When using a buffer less than 100%, the driver will
+call the drawing lambda multiple times to draw each chunk of the display. For example, with a 25% buffer size, the driver will call the drawing lambda four times to draw the display.
+This has an effect on performance, and should be considered when setting the buffer size, but it is also important that the drawing lambda does not have
+side effects - this should be avoided in any case, but becomes more critical when using a buffer less than 100%.
+
+
Additional inititialisation sequences
-*************************************
+--------------------------------------
The ``init_sequence`` option allows additional configuration of the driver chip. Provided commands will be sent to the
driver chip in addition to, and after the chosen model's pre-defined commands. It requires a list of byte sequences:
@@ -170,12 +198,12 @@ Each entry represents a single-byte command followed by zero or more data bytes.
If converting from other code, make sure the length byte, if present, is not copied as the length of each command sequence is determined by the number of bytes in the list.
CUSTOM model
-************
+------------
The ``CUSTOM`` model selection is provided for otherwise unsupported displays, and requires both ``dimensions:`` and ``init_sequence:`` to be specfied. There is no pre-defined init sequence.
Using the ``transform`` options
-*******************************
+-------------------------------
In most cases, the ``rotation`` option will be sufficient to orient the display correctly. However, some displays may require additional transformations. The ``transform`` option allows for these transformations to be applied in any of 8 different
combinations. It may be necessary to experiment with different combinations to achieve the desired result. When using the ``transform`` option, the ``rotation`` option should not be set unless the display does not support axis-swapping.
@@ -209,5 +237,6 @@ See Also
--------
- :doc:`index`
+- :doc:`/components/lvgl/index`
- :apiref:`mipi_spi/mipi_spi.h`
- :ghedit:`Edit`
diff --git a/components/display/st7789v.rst b/components/display/st7789v.rst
index e56924b6cf..39d5075f61 100644
--- a/components/display/st7789v.rst
+++ b/components/display/st7789v.rst
@@ -27,15 +27,15 @@ to an ESP module.
.. warning::
- This component has been made redundant since the ST7789V is now supported by the :ref:`ILI9XXX component `. It is recommended
- that you use the ``ili9xxx`` component as it will be maintained, whereas this component may not be, or may be removed completely
- in the future.
+ This component has been made redundant since the ST7789V is now supported by the :ref:`mipi_spi`.
+ This component will be removed in a future release.
.. note::
Displays larger than the 135x240 pixel display on the TTGO T-Display shown require a significant amount of RAM
to operate correctly. Some ESP devices, such as the ESP8266, do not have sufficient memory to support this display.
If you attempt to use this component and experience repeated crashes, this is likely the cause of the issue.
+ The :ref:`mipi_spi` component has features that can be used to address this issue.
.. code-block:: yaml
diff --git a/components/esp32.rst b/components/esp32.rst
index ea7b0e04be..0de952a7b2 100644
--- a/components/esp32.rst
+++ b/components/esp32.rst
@@ -11,16 +11,25 @@ This component contains platform-specific options for the ESP32 platform.
# Example configuration entry
esp32:
- board: esp32dev
+ variant: esp32s3
Configuration variables:
------------------------
-- **board** (**Required**, string): The PlatformIO board ID that should be used. Choose the appropriate board from
+- **variant** (*Optional*, string): The ESP32 mcu/chip to use for this device configuration. One of ``esp32``,
+ ``esp32s2``, ``esp32s3``, ``esp32c2``, ``esp32c3``, ``esp32c5``, ``esp32c6``, ``esp32h2`` or ``esp32p4``.
+ This must match the hardware in use, or it will fail to flash.
+- **board** (*Optional*, string): The PlatformIO board ID that should be used. Choose the appropriate board from
`this list `__ (the icon next
- to the name can be used to copy the board ID). *This only affects pin aliases, flash size and some internal settings*;
- if unsure or you cannot find your exact board, using a generic board (from Espressif) such as ``esp32dev`` almost
- always works just fine.
+ to the name can be used to copy the board ID). *This only affects pin aliases and some internal settings*;
+ This setting is no longer recommended, ``variant`` should be used instead.
+
+.. note::
+
+ At least one of ``board`` or ``variant`` must be specified. If ``variant`` alone is specified (the recommended practice),
+ the board configuration will be automatically filled using a standard Espressif devkit board
+ suitable for that variant. Both may be specified (for backwards compatibility) but they must define the same variant.
+
- **flash_size** (*Optional*, string): The amount of flash memory available on the ESP32 board/module. One of ``2MB``,
``4MB``, ``8MB``, ``16MB`` or ``32MB``. Defaults to ``4MB``. **Warning: specifying a size larger than that available
on your board will cause the ESP32 to fail to boot.**
@@ -28,9 +37,6 @@ Configuration variables:
``360MHz`` or ``400MHz``. Defaults to ``160MHz``. Not all values are available for all chips.
- **partitions** (*Optional*, filename): The name of (optionally including the path to) the file containing the
partitioning scheme to be used. When not specified, partitions are automatically generated based on ``flash_size``.
-- **variant** (*Optional*, string): The variant of the ESP32 that is used on this board. One of ``esp32``,
- ``esp32s2``, ``esp32s3``, ``esp32c2``, ``esp32c3``, ``esp32c5``, ``esp32c6``, ``esp32h2`` and ``esp32p4``. Defaults
- to the variant that is detected from the board; if a board that's unknown to ESPHome is used, this option is mandatory.
- **framework** (*Optional*): Options for the underlying framework used by ESPHome. See :ref:`esp32-arduino_framework`
and :ref:`esp32-espidf_framework`.
@@ -102,6 +108,8 @@ Configuration variables:
- **sdkconfig_options** (*Optional*, mapping): Custom sdkconfig
`compiler options `__
to set in the ESP-IDF project.
+- **log_level** (*Optional*, string): Log level of the framework, one of ``ERROR`` (default), ``NONE``, ``WARN``, ``INFO``,
+ ``DEBUG`` or ``VERBOSE``.
- **advanced** (*Optional*, mapping): See :ref:`esp32-advanced_configuration` below.
- **components** (*Optional*, list of components): See :ref:`esp32-idf_components` below.
@@ -123,6 +131,9 @@ Advanced Configuration
disabling LWIP assertions. Defaults to ``true`` (as recommended by Espressif). See
`Espressif's documentation `__
for more information.
+- **execute_from_psram** (*Optional*, boolean): On ESP32S3 only may be set to ``true`` to enable executing code from PSRAM.
+ With octal PSRAM this can be faster than executing from FLASH memory, and enables code such as display drawing
+ to execute normally when writing to FLASH, e.g. during an OTA update. The default is ``false``.
- **ignore_efuse_custom_mac** (*Optional*, boolean): Can be set to ``true`` for devices on which the burned-in custom
MAC address is not valid.
- **ignore_efuse_mac_crc** (*Optional*, boolean): Can be set to ``true`` for devices on which the burned-in MAC
@@ -134,19 +145,45 @@ Advanced Configuration
**LWIP Optimization Options (ESP-IDF only):**
-The following options are available under the ``advanced`` section when using the ESP-IDF framework to disable unused
-LWIP (Lightweight IP) features and save flash memory (approximately 4KB):
+The following options are available under the ``advanced`` section when using the ESP-IDF framework to optimize
+LWIP (Lightweight IP) behavior. Some options improve performance while others save flash memory:
- **enable_lwip_dhcp_server** (*Optional*, boolean): Enable DHCP server functionality. Only needed if the device will act
as a DHCP server (necessary for WiFi AP mode). When the WiFi component is used, it automatically handles enabling/disabling
the DHCP server based on whether AP mode is configured. When WiFi is not used, defaults to ``false``.
-- **enable_lwip_mdns_queries** (*Optional*, boolean): Enable mDNS query support in the DNS resolver. ESPHome uses its own
- mDNS implementation, so this is rarely needed. Defaults to ``true``.
+- **enable_lwip_mdns_queries** (*Optional*, boolean): Enable mDNS query support in the DNS resolver. This allows resolving
+ local hostnames (like ``broker.local``) for MQTT brokers and other services. While ESPHome has its own mDNS responder
+ for advertising, this option is needed for resolving mDNS names. Defaults to ``true``.
- **enable_lwip_bridge_interface** (*Optional*, boolean): Enable bridge interface support for bridging multiple network
interfaces. Defaults to ``false``.
+- **enable_lwip_tcpip_core_locking** (*Optional*, boolean): Enable LWIP TCP/IP core locking for better socket performance.
+ This uses direct function calls with mutex protection instead of mailbox message passing between threads. Enabling this
+ improves socket operation performance by 20-200% but may reduce multi-threaded scalability. Defaults to ``true``.
+- **enable_lwip_check_thread_safety** (*Optional*, boolean): Enable LWIP thread safety checks to detect incorrect usage of
+ the TCP/IP stack from multiple threads. This helps catch thread safety issues when core locking is enabled. Defaults to ``true``.
-These optimizations are applied automatically and save flash memory without affecting typical ESPHome functionality. The
-features can be enabled if needed by setting the corresponding option to ``true``.
+Some options can be disabled to save flash memory without affecting typical ESPHome functionality. The performance
+options (defaulting to ``true``) improve socket operation performance but can be disabled if you need better
+multi-threaded scalability (which is uncommon since ESPHome uses an event loop).
+
+**Example configuration with advanced LWIP options:**
+
+.. code-block:: yaml
+
+ # Example configuration entry
+ esp32:
+ board: esp32dev
+ framework:
+ type: esp-idf
+ advanced:
+ # Performance options (enabled by default)
+ enable_lwip_tcpip_core_locking: true # Better socket performance
+ enable_lwip_check_thread_safety: true # Thread safety validation
+
+ # Memory saving options
+ enable_lwip_dhcp_server: false # Disabled by default, only needed for AP mode
+ enable_lwip_mdns_queries: false # Enabled by default, can disable if not using .local hostnames
+ enable_lwip_bridge_interface: false # Disabled by default
.. _esp32-idf_components:
diff --git a/components/esp32_ble.rst b/components/esp32_ble.rst
index 6b2f0ae5b2..07e8438597 100644
--- a/components/esp32_ble.rst
+++ b/components/esp32_ble.rst
@@ -23,6 +23,9 @@ can run.
esp32_ble:
io_capability: keyboard_only
disable_bt_logs: true # Default, saves flash
+ connection_timeout: 20s # Default, matches client timeout
+ # advertising: true # Only needed for advanced use cases
+ max_notifications: 12 # Default, increase if needed
Configuration variables:
------------------------
@@ -48,6 +51,32 @@ Configuration variables:
The ``disable_bt_logs`` option intelligently disables only the Bluetooth logging categories that are not required by your configuration. Each Bluetooth component registers the specific loggers it needs, and all unused loggers are automatically disabled during compilation. This includes loggers for Classic Bluetooth features (like RFCOMM, A2DP, HID) that are not used by ESPHome's BLE implementation.
+- **connection_timeout** (*Optional*, :ref:`config-time`): The maximum time to wait for a BLE connection to be established. Only available when using ESP-IDF framework. Defaults to ``20s``.
+
+ - Range: 10 to 180 seconds
+ - This timeout should align with the timeout used by your BLE client software to prevent connection slot waste
+
+.. note::
+
+ The ``connection_timeout`` option is particularly important when using ESPHome as a Bluetooth proxy. The default of 20 seconds matches the timeout used by aioesphomeapi and bleak-retry-connector. If a connection attempt times out on the client side but ESP-IDF continues trying to connect, the connection slot remains occupied and unavailable for new connections. Setting this to match your client timeout ensures connection slots are freed immediately when a connection fails.
+
+- **advertising** (*Optional*, boolean): Manually enable BLE advertising support. This is automatically enabled when using :doc:`esp32_ble_server` or :doc:`esp32_ble_beacon`. Only set this to ``true`` if you need advertising functionality without those components. Defaults to ``false``.
+
+.. note::
+
+ The ``advertising`` option is an advanced feature that manually enables BLE advertising compilation. In most cases, you don't need to set this as advertising is automatically enabled when using components that require it (like ``esp32_ble_server`` or ``esp32_ble_beacon``). This option is primarily useful for custom components or special use cases where you need advertising functionality without the standard server or beacon components.
+
+- **advertising_cycle_time** (*Optional*, :ref:`config-time`): The time interval for cycling through multiple advertisements. Only applicable when advertising is enabled. Defaults to ``10s``.
+- **max_notifications** (*Optional*, integer): The maximum number of BLE characteristics that can have notifications enabled across all connections. Only available when using ESP-IDF framework. Defaults to ``12``.
+
+ - Range: 1 to 64
+ - This is a global limit shared across all BLE connections
+ - Increase if you see ``ESP_GATT_NO_RESOURCES`` (status=128) errors when enabling notifications
+
+.. note::
+
+ The ``max_notifications`` option controls the ``CONFIG_BT_GATTC_NOTIF_REG_MAX`` ESP-IDF setting. This limit is per GATT client interface, not per connection. If you're using ESPHome as a Bluetooth proxy with multiple devices that have many characteristics requiring notifications, you may need to increase this value. The error ``status=128`` in logs indicates you've hit this limit.
+
``ble.disable`` Action
-----------------------
diff --git a/components/esp32_camera.rst b/components/esp32_camera.rst
index c58110070a..84e827dd7f 100644
--- a/components/esp32_camera.rst
+++ b/components/esp32_camera.rst
@@ -72,6 +72,9 @@ Frame Settings:
is requesting a full stream. Defaults to ``0.1 fps``.
- **frame_buffer_count** (*Optional*, int): The number of frame buffers to use when reading from the camera sensor.
Must be between 1 and 2. Defaults to ``1``.
+- **frame_buffer_location** (*Optional*, enum): The memory area used for storing the frame buffers. Defaults to ``PSRAM``.
+ - ``PSRAM``
+ - ``DRAM``
Image Settings:
@@ -483,17 +486,15 @@ Configuration examples
.. code-block:: yaml
# Example configuration entry
- external_components:
- - source: github://pr#9630
- components: [ esp32_camera ]
-
+ i2c:
+ - id: camera_i2c
+ sda: GPIO4
+ scl: GPIO5
esp32_camera:
external_clock:
pin: GPIO15
frequency: 20MHz
- i2c_pins:
- sda: GPIO4
- scl: GPIO5
+ i2c_id: camera_i2c
data_pins: [GPIO11, GPIO9, GPIO8, GPIO10, GPIO12, GPIO18, GPIO17, GPIO16]
vsync_pin: GPIO6
href_pin: GPIO7
@@ -531,13 +532,15 @@ Configuration examples
.. code-block:: yaml
+ i2c:
+ - id: camera_i2c
+ sda: GPIO48
+ scl: GPIO47
esp32_camera:
external_clock:
pin: GPIO3
frequency: 20MHz
- i2c_pins:
- sda: GPIO48
- scl: GPIO47
+ i2c_id: camera_i2c
data_pins: [GPIO41, GPIO45, GPIO46, GPIO42, GPIO40, GPIO38, GPIO15, GPIO18]
vsync_pin: GPIO1
href_pin: GPIO2
diff --git a/components/espnow.rst b/components/espnow.rst
new file mode 100644
index 0000000000..7456eef899
--- /dev/null
+++ b/components/espnow.rst
@@ -0,0 +1,236 @@
+ESPNow communication Component
+==============================
+
+.. seo::
+ :description: Instructions for setting up the basic ESPNow component in ESPHome.
+ :image: esp-now.svg
+
+This component allows ESPHome to communicate with esp32 devices in a simple and unrestricted way.
+It enables the option to interact with other esp32 devices over the Espressif's ESP-NOW protocol, see
+`documentation `__
+
+.. note::
+
+ Broadcasting data is not recommended, this will also reach devices not controlled by you that use the esp-now protocol.
+ The best solution is to minimize the broadcasting as much as possible and use it only for identification purposes.
+
+.. code-block:: yaml
+
+ # Example configuration entry
+ espnow:
+
+Configuration variables:
+------------------------
+
+- **channel** (*Optional*, int): The Wi-Fi channel that the esp-now communication will use to send/receive data packets.
+ Cannot be set when the :doc:`wifi` is used, as it will use the same channel as the wifi network.
+- **auto_add_peer** (*Optional*, boolean): This will allow the esp-now component to automatically add any new incoming device as a peer.
+ See :ref:`espnow-peers` below. Defaults to ``false``.
+- **enable_on_boot** (*Optional*, boolean): Enable the esp-now component on boot. Defaults to ``true``.
+- **peers** (*Optional*, list): A peer is the name for devices that use esp-now. The list will have all MAC addresses from
+ the devices where this device may communicate with. See :ref:`espnow-peers` below.
+
+Automations:
+
+- **on_receive** (*Optional*, :ref:`Automation `): An automation to perform when data is received. See :ref:`espnow-on_receive`.
+- **on_unknown_peer** (*Optional*, :ref:`Automation `): An automation to perform when data is received from an unknown peer. See :ref:`espnow-on_unknown_peer`.
+- **on_broadcast** (*Optional*, :ref:`Automation `): An automation to perform when a broadcast packet is received.
+ See :ref:`espnow-on_broadcast`.
+
+Automations
+-----------
+
+There will be 3 variables available to automations. Their memory will be cleaned up after the automation is
+done and will not be available if there are any `delay` actions or others that do work "asynchronously" in the automation.
+
+- **info**: :apistruct:`espnow::ESPNowRecvInfo` with information about the received packet.
+- **data**: A `const uint8_t *` - pointer to the data.
+- **size**: The size of the data in bytes.
+
+.. code-block:: yaml
+
+ espnow:
+ on_...:
+ - logger.log:
+ format: "Sent to %s from %s: %s RSSI: %ddBm"
+ args:
+ - format_mac_address_pretty(info.des_addr).c_str()
+ - format_mac_address_pretty(info.src_addr).c_str()
+ - format_hex_pretty(data, size).c_str()
+ - info.rx_ctrl->rssi
+
+.. _espnow-on_receive:
+
+``on_receive``
+**************
+
+This automation will be triggered when data is received from a registered peer.
+
+Configuration variables:
+
+- **address** (*Optional*, MAC Address): Filter this trigger to packets where the source address matches. If not set, it will match any device.
+
+.. _espnow-on_unknown_peer:
+
+``on_unknown_peer``
+*******************
+
+This automation will be triggered when data is received from a peer that is not in the list of known peers. This trigger gives you one possibility to decide if the unknown peer can be added or not.
+
+.. _espnow-on_broadcast:
+
+``on_broadcast``
+****************
+
+This automation will be triggered when a broadcast packet is received.
+
+Configuration variables:
+
+- **address** (*Optional*, MAC Address): Filter this trigger to packets where the source address matches. If not set, it will match any device.
+
+
+.. _espnow-send-action:
+
+``espnow.send`` Action
+***********************
+
+This is an :ref:`Action ` for sending a data packet over the espnow protocol.
+
+.. code-block:: yaml
+
+ on_...:
+ - espnow.send:
+ address: 11:22:33:44:55:66
+ data: "The big angry wolf awakens"
+ - espnow.send:
+ address: 11:22:33:44:55:66
+ data: !lambda "return {0x00, 0x00, 0x34, 0x5d};"
+ - espnow.send:
+ address: !lambda "return {0x11, 0x22, 0x33, 0x44, 0x55, 0x66};"
+ data: [0x00, 0x00, 0x34, 0x5d]
+ - espnow.send:
+ address: !lambda "return {0x11, 0x22, 0x33, 0x44, 0x55, 0x66};"
+ data: !lambda "return {0x00, 0x00, 0x34, 0x5d};"
+
+
+Configuration variables:
+
+- **address** (**Required**, :ref:`templatable `, MAC Address): The MAC address of the receiving device to send to.
+- **data** (**Required**, :ref:`templatable `, string or list of bytes): The data to be sent.
+- **wait_for_sent** (*Optional*, boolean): The automation will wait for the data to be sent and for the ``on_sent`` or ``on_error``
+ actions to be finished before continuing with the next action.
+ Defaults to ``true``.
+- **continue_on_error** (*Optional*, boolean): If set to ``false``, the next action will not be triggered if the data could not be sent.
+ Defaults to ``true``.
+
+Automations:
+
+- **on_sent** (*Optional*, :ref:`Automation `): An automation to perform when the data is sent successfully.
+- **on_error** (*Optional*, :ref:`Automation `): An automation to perform when the data could not be sent.
+
+
+.. _espnow-broadcast-action:
+
+``espnow.broadcast`` Action
+***************************
+
+This is an :ref:`Action ` for sending a data packet over the espnow protocol to any device that is listening.
+
+.. code-block:: yaml
+
+ on_...:
+ - espnow.broadcast:
+ data: "The big angry wolf awakens"
+ - espnow.broadcast:
+ data: !lambda "return {0x00, 0x00, 0x34, 0x5d};"
+ - espnow.broadcast:
+ data: [0x00, 0x00, 0x34, 0x5d]
+
+Configuration variables:
+
+- **data** (**Required**, :ref:`templatable `, string or list of bytes): The data to be sent.
+
+
+.. _espnow-peer_add-action:
+
+``espnow.peer.add`` Action
+**************************
+
+This is an :ref:`Action ` to add a new peer to the internal allowed peers list.
+
+.. code-block:: yaml
+
+ on_...:
+ - espnow.peer.add:
+ address: 11:22:33:44:55:66
+ - espnow.peer.add:
+ address: !lambda "return {0x11, 0x22, 0x33, 0x44, 0x55, 0x66};"
+
+
+Configuration variables:
+
+- **address** (**Required**, MAC Address): The Peer address that needs to be added to the list of allowed peers.
+
+
+.. _espnow-peer_delete-action:
+
+``espnow.peer.delete`` Action
+*****************************
+
+This is an :ref:`Action ` to remove a known peer from the internal allowed peers list.
+
+.. code-block:: yaml
+
+ on_...:
+ - espnow.peer.delete:
+ address: 11:22:33:44:55:66
+ - espnow.peer.delete:
+ address: !lambda "return {0x11, 0x22, 0x33, 0x44, 0x55, 0x66};"
+
+Configuration variables:
+
+- **address** (**Required**, MAC Address): The Peer address that needs to be removed from the list of allowed peers.
+
+.. _espnow-set_channel-action:
+
+``espnow.set_channel`` Action
+*****************************
+
+This is an :ref:`Action ` to change the channel that espnow is sending and receiving on.
+
+.. code-block:: yaml
+
+ on_...:
+ - espnow.set_channel:
+ channel: 1
+ - espnow.set_channel: 1
+
+Configuration variables:
+
+- **channel** (**Required**, int): This can be a value between ``0`` and ``15``. The maximum channel number depends on the country or region where you are using the device (for example, channels 1-11 are allowed in the US and most of Europe, 1-13 in many other countries, and 1-14 in Japan). For details, see the `Wi-Fi channel regulations by country `__ or consult the `Espressif ESP-NOW documentation `__. ``0`` means that espnow will set the channel number itself (most of the time it would be ``1``).
+
+
+.. _espnow-peers:
+
+Peers
+-----
+
+A peer is a device that this device is allowed to send to. Broadcast and unencrypted unicast data can be received from
+any device without explicitly adding it as a peer.
+
+If ``auto_add_peer`` is set to ``false`` and you have not added any peers, then only broadcasts can be sent and there
+will be an error when trying to send data to a peer.
+
+Setting ``auto_add_peer`` to ``true`` will allow the component to automatically add any incoming device as a peer, and will
+automatically add any peer that data is sent to.
+
+
+See Also
+--------
+
+- :apiref:`espnow/espnow.h`
+- :ghedit:`Edit`
+
+.. toctree::
+ :maxdepth: 1
+ :glob:
diff --git a/components/factory_reset.rst b/components/factory_reset.rst
new file mode 100644
index 0000000000..c8e6fcd76e
--- /dev/null
+++ b/components/factory_reset.rst
@@ -0,0 +1,79 @@
+Factory Reset
+=============
+
+.. seo::
+ :description: Instructions for setting up conditions that can remotely invalidate all ESPHome preferences stored in flash and reboot ESP.
+
+The ``factory_reset`` component allows you to invalidate (reset) all ESPHome :ref:`preferences ` stored in flash memory and reboot your node.
+After reboot all states, parameters and variables will be reinitialized with their default values. This is useful:
+
+- for devices preflashed with ESPHome to reset behavior back to factory state
+- in case of moving a device to a new environment or starting a new use-case (e.g. reset counters or state)
+- for privacy concerns when giving away a device
+
+.. note::
+
+ **USE WITH GREAT CAUTION!** All credentials, global variables, counters and saved states stored in non-volatile memory will be lost with no chance of recovering them.
+ Even raw reading of flash memory with ``esptool`` will not help, since data is physically erased from flash memory.
+
+ For devices configured using :doc:`captive portal `, this will reset WiFi settings as well, thus making such devices offline.
+ You'll need to be in close proximity to your device to configure it again using a built-in WiFi access point and captive portal.
+
+Reset by Fast Power Cycling
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``factory_reset`` component can be configured to clear stored preferences by repeatedly pressing the reset button or power cycling,
+which can be useful to clear the data stored in non-volatile memory on devices that can't be
+connected with a serial cable. The required number of power cycles and the maximum delay between them can be configured in the
+``factory_reset`` component configuration. Points to note:
+
+- The maximum delay affects only the time when the device is powered on,
+ not the time when it is powered off (this can't be measured).
+- The reset count will be cleared to zero when any other kind of reset occurs,
+ or if the device remains powered on and running for longer than the maximum delay.
+- Not available on RP2040 and RP2350 as the reset cause is not able to be determined.
+- On ESP8266 this feature requires the ``restore_from_flash`` feature to be enabled in the :doc:`ESP8266 platform `.
+
+.. code-block:: yaml
+
+ factory_reset:
+ resets_required: 5
+ max_delay: 10s
+
+Configuration variables:
+------------------------
+
+- **resets_required** (*Optional*, integer): The number of power cycles after which the device will be reset.
+ No default, if not configured the power cycle reset feature will be disabled
+- **max_delay** (*Optional*, :ref:`Time `): The maximum delay between power cycles. Default: 10s
+
+``on_increment`` Trigger
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+A trigger is available that will be triggered whenever the current reset cycle count changes. This happens when the
+``factory_reset`` component detects a power cycle, or when the
+cycle count is cleared to zero by timeout or a different type of reset. Arguments passed to the trigger are:
+
+- ``x``: The current cycle count
+- ``target``: The target cycle count
+
+.. code-block:: yaml
+
+ factory_reset:
+ resets_required: 5
+ max_delay: 10s
+ on_increment:
+ - logger.log:
+ format: "Fast power cycle count now %u, target %u"
+ args: [x, target]
+
+See Also
+--------
+
+- :doc:`/components/switch/factory_reset`
+- :doc:`/components/button/factory_reset`
+- :doc:`/components/button/shutdown`
+- :doc:`/components/button/restart`
+- :doc:`/components/button/safe_mode`
+- :apiref:`factory_reset/factory_reset.h`
+- :ghedit:`Edit`
diff --git a/components/image.rst b/components/image.rst
index f698055c04..38388d96ac 100644
--- a/components/image.rst
+++ b/components/image.rst
@@ -83,14 +83,39 @@ Configuration variables:
additionally need to have the python ``cairosvg`` package installed. These are automatically installed when
setting up ESPHome via the usual methods.
+
+Setting defaults
+----------------
+
+For the situation where most or all of your images share common attributes, you can use another schema style to provide default values. In this case
+the ``defaults:`` option will provide fallback values for all images. When using this format the ``images:`` key takes a list of image definitions.
+
+.. code-block:: yaml
+
+ image:
+ defaults:
+ type: rgb565
+ transparency: opaque
+ resize: 100x100
+ images:
+ - file: "image1.png"
+ id: image1
+ - file: "image2.png"
+ id: image2
+ resize: 200x200 # overrides the default resize
+
Grouping images by type
-----------------------
-You can group images by type to make it easier to manage them. This is useful when you have a lot of images to be encoded in the same way, and avoids having to repeat the same type for each image. The type name is used as the key for the group. For example:
+You can group images by type to make it easier to manage them. This is useful when you have a lot of images to be encoded in the same way,
+and avoids having to repeat the same type for each image. A ``defaults:`` group can be used to specify default values other than the type.
+The type name is used as the key for the group. For example:
.. code-block:: yaml
image:
+ defaults:
+ resize: 100x100
grayscale:
- file: "image1.png"
id: image1
@@ -119,23 +144,6 @@ In addition, the default transparency type can be set within a type group by usi
opaque:
- file: "image2.png"
-For the situation where most or all of your images share common attributes, you can use another schema style to provide default values. In this case
-the ``defaults:`` option will provide fallback values for all images. When using this format the ``images:`` key takes only a list of image definitions.
-
-.. code-block:: yaml
-
- image:
- defaults:
- type: rgb565
- transparency: opaque
- resize: 100x100
- images:
- - file: "image1.png"
- id: image1
- - file: "image2.png"
- id: image2
- resize: 200x200 # overrides the default resize
-
Displaying Images
-----------------
diff --git a/components/index.rst b/components/index.rst
index 16c4f5fd9c..b34c68a4d0 100644
--- a/components/index.rst
+++ b/components/index.rst
@@ -37,6 +37,7 @@ Supported Microcontrollers
RTL87xx, components/libretiny, rtl87xx.svg
LN882x, components/libretiny, ln882x.svg
Host, components/host, host.svg, dark-invert
+ NRF52, components/nrf52, nrf52.svg
Microcontroller Peripherals
---------------------------
@@ -82,6 +83,7 @@ ESPHome-specific components or components supporting ESPHome device provisioning
Mapping, components/mapping, mapping.svg, dark-invert
XXTEA, components/xxtea, xxtea.svg
Script, components/script, description.svg, dark-invert
+ Factory Reset, components/factory_reset, restart-alert.svg, dark-invert
Network Hardware
----------------
@@ -101,6 +103,7 @@ Network Protocols
Network Core, components/network, server-network.svg, dark-invert
Native API, components/api, server-network.svg, dark-invert
MQTT, components/mqtt, mqtt.png
+ ESP-NOW, components/espnow, esp-now.svg
HTTP Request, components/http_request, connection.svg, dark-invert
mDNS, components/mdns, radio-tower.svg, dark-invert
WireGuard, components/wireguard, wireguard_custom_logo.svg, dark-invert
@@ -522,6 +525,7 @@ Motion
APDS9960, components/sensor/apds9960, apds9960.jpg, Colour & Gesture
BMI160, components/sensor/bmi160, bmi160.jpg, Accelerometer & Gyroscope
LD2410, components/sensor/ld2410, ld2410.jpg, Motion & Presence
+ LD2412, components/sensor/ld2412, ld2412.jpg, Motion & Presence
LD2420, components/sensor/ld2420, ld2420.jpg, Motion & Presence
LD2450, components/sensor/ld2450, ld2450.png, Motion & Presence
MPU6050, components/sensor/mpu6050, mpu6050.jpg, Accelerometer & Gyroscope
@@ -629,6 +633,7 @@ Presence Detection
AT581X, components/at581x, at581x.png
DFRobot mmWave Radar, components/dfrobot_sen0395, dfrobot_sen0395.jpg
LD2410, components/sensor/ld2410, ld2410.jpg
+ LD2412, components/sensor/ld2412, ld2412.jpg
LD2420, components/sensor/ld2420, ld2420.jpg
LD2450, components/sensor/ld2450, ld2450.png
Seeed Studio MR24HPC1 mmWave, components/seeed_mr24hpc1, seeed-mr24hpc1.jpg
@@ -758,6 +763,7 @@ Display Hardware Platforms
.. imgtable::
Addressable Light, components/display/addressable_light, addressable_light.jpg
+ MIPI DSI Displays, components/display/mipi_dsi, tab5.jpg
MIPI SPI Displays, components/display/mipi_spi, t4-s3.jpg
ILI9xxx, components/display/ili9xxx, ili9341.jpg
ILI9341, components/display/ili9xxx, ili9341.svg
diff --git a/components/lvgl/index.rst b/components/lvgl/index.rst
index 59f0944df0..0b490c7ad4 100644
--- a/components/lvgl/index.rst
+++ b/components/lvgl/index.rst
@@ -243,14 +243,22 @@ Colors can be specified anywhere in the LVGL configuration either by referencing
You may also use any of the `standard CSS color names `__, e.g. ``springgreen``.
-When using a lambda to provide a color you should use the ``lv_color_hex`` function, for example:
+When using a lambda to provide a color you can use the ``lv_color_hex`` function to convert a hex value, or
+return a :ref:`config-color` ID - this is useful when using the :doc:`/components/mapping`. Examples:
.. code-block:: yaml
label:
+ id: my_label
text: 'Hello World!'
color: !lambda return lv_color_hex(0xFF0000);
+ on_...:
+ lvgl.label.update:
+ id: my_label
+ text: 'Hello Mars!'
+ color: !lambda return id(mapping_color_map)[x];
+
.. _lvgl-opacity:
Opacity
diff --git a/components/media_player/index.rst b/components/media_player/index.rst
index b93b2f563a..096b34777c 100644
--- a/components/media_player/index.rst
+++ b/components/media_player/index.rst
@@ -53,6 +53,8 @@ Media Player Actions
All ``media_player`` actions can be used without specifying an ``id`` if you have only one ``media_player`` in
your configuration YAML.
+The actions ``turn_off`` and ``turn_on`` are optional and based on the platform implementing the ``supports_turn_off_on`` trait.
+
Configuration variables:
**id** (*Optional*, :ref:`config-id`): The media player to control. Defaults to the only one in YAML.
@@ -115,6 +117,20 @@ Configuration variables:
This action will pause or resume the current playback.
+.. _media_player-turn_off:
+
+``media_player.turn_off`` Action
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This action will turn off the media player.
+
+.. _media_player-turn_on:
+
+``media_player.turn_on`` Action
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This action will turn on the media player.
+
.. _media_player-volume_up:
``media_player.volume_up`` Action
@@ -230,6 +246,36 @@ This trigger is activated every time the media player plays an announcement.
on_announcement:
- logger.log: "Announcing!"
+.. _media_player-on_turn_off_trigger:
+
+``media_player.on_turn_off`` Trigger
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This trigger is activated every time the media player is turned off.
+
+.. code-block:: yaml
+
+ media_player:
+ - platform: ... # any platform implementing the ``supports_turn_off_on`` trait
+ # ...
+ on_turn_off:
+ - logger.log: "Media Player is Turned Off"
+
+.. _media_player-on_turn_on_trigger:
+
+``media_player.on_turn_on`` Trigger
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This trigger is activated every time the media player is turned on.
+
+.. code-block:: yaml
+
+ media_player:
+ - platform: ... # any platform implementing the ``supports_turn_off_on`` trait
+ # ...
+ on_turn_on:
+ - logger.log: "Media Player is Turned On"
+
.. _media_player-is_idle_condition:
``media_player.is_idle`` Condition
@@ -290,6 +336,36 @@ This condition checks if the media player is playing an announcement.
condition:
media_player.is_announcing:
+.. _media_player-is_off_condition:
+
+``media_player.is_off`` Condition
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This condition checks if the media player is turned off.
+
+.. code-block:: yaml
+
+ # In some trigger:
+ on_...:
+ if:
+ condition:
+ media_player.is_off:
+
+.. _media_player-is_on_condition:
+
+``media_player.is_on`` Condition
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This condition checks if the media player is turned on.
+
+.. code-block:: yaml
+
+ # In some trigger:
+ on_...:
+ if:
+ condition:
+ media_player.is_on:
+
Play media in order
-------------------
diff --git a/components/nrf52.rst b/components/nrf52.rst
new file mode 100644
index 0000000000..87169e842a
--- /dev/null
+++ b/components/nrf52.rst
@@ -0,0 +1,82 @@
+NRF52 Platform
+===============
+
+.. seo::
+ :description: Configuration for the NRF52 platform for ESPHome.
+ :image: nrf52.svg
+
+This component contains platform-specific options for the NRF52 platform.
+
+.. note::
+
+ Support for all aspects of ESPHome on the NRF52 is still in development.
+
+.. code-block:: yaml
+
+ # Example configuration entry
+ nrf52:
+ board: adafruit_feather_nrf52840
+
+Configuration variables:
+------------------------
+
+- **board** (*Required*, string): The board type. Valid options are ``adafruit_feather_nrf52840``, ``adafruit_itsybitsy_nrf52840``, ``xiao_ble``. Other boards should work with those configuration as well.
+- **bootloader** (*Optional*, string): Bootloader type. Valid options are ``mcuboot``, ``adafruit``, ``adafruit_nrf52_sd132``, ``adafruit_nrf52_sd140_v6``, ``adafruit_nrf52_sd140_v7``. Default value depends on board type.
+
+Getting Started
+---------------
+
+The nRF52840 requires a bootloader, with two supported options: ``MCUboot`` and ``Adafruit nRF52 Bootloader``. It is recommended to use MCUboot as it supports OTA (Over-The-Air) updates. Your board most likely comes with a manufacturer-provided bootloader. ESPHome determines the bootloader type based on the board name.
+
+Examples of low power `nRF52840 boards `__.
+
+
+Flashing with MCUboot
+----------------------
+
+Flashing this bootloader requires an SWD connection, for which a programmer is necessary. A cheap ST-Link V2 can be utilized.
+
+1. Connect the board to the PC via SWD.
+2. Run ``esphome upload yourfile.yaml --device PYOCD``.
+
+.. code-block:: yaml
+
+ # Example configuration entry
+ nrf52:
+ board: adafruit_feather_nrf52840
+
+Flashing with Adafruit nRF52 Bootloader
+---------------------------------------
+
+For flashing via a flash drive.
+
+1. Connect the board to the PC via USB.
+2. Quickly short the reset pin to ground twice.
+3. Copy the UF2 package to the flash drive.
+
+This bootloader supports updates over USB CDC.
+
+1. Connect the board to the PC via USB.
+2. Quickly short the reset pin to ground twice.
+3. Run ``esphome upload yourfile.yaml``.
+
+.. code-block:: yaml
+
+ # Example configuration entry
+ nrf52:
+ board: adafruit_itsybitsy_nrf52840
+
+GPIO Pin Numbering
+------------------
+
+There are two ways to reference GPIO pins:
+
+1. By pin name, e.g., ``P0.15`` or ``P1.11``.
+2. By pin number, e.g., ``15`` or ``43``.
+
+See Also
+--------
+
+- :doc:`esphome`
+- :ghedit:`Edit`
+- `Guidelines for Adafruit Bootloader Memory Map `__
diff --git a/components/output/index.rst b/components/output/index.rst
index 7c00c46dc0..396b1d4aed 100644
--- a/components/output/index.rst
+++ b/components/output/index.rst
@@ -49,6 +49,10 @@ Float outputs only:
- **zero_means_zero** (*Optional*, boolean): Sets the output to use actual 0 instead of ``min_power``.
Defaults to ``false``.
+.. note::
+
+ The ``min_power`` and ``max_power`` values are automatically clamped to ensure ``0.0 ≤ min_power ≤ max_power ≤ 1.0``.
+ This prevents invalid configurations and ensures stable output behavior.
.. _output-turn_on_action:
@@ -97,8 +101,13 @@ This action turns the output with the given ID off when executed.
``output.set_level`` Action
***************************
-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_output`, :doc:`/components/output/slow_pwm`.
+This action sets the float output to the given level when executed.
+
+.. note::
+
+ This only works with floating point outputs like :doc:`/components/output/ac_dimmer`,
+ :doc:`/components/output/esp8266_pwm`, :doc:`/components/output/ledc`,
+ :doc:`/components/output/sigma_delta_output`, :doc:`/components/output/slow_pwm`.
.. code-block:: yaml
@@ -117,6 +126,68 @@ works with floating point outputs like :doc:`/components/output/esp8266_pwm`, :d
// range is 0.0 (off) to 1.0 (on)
id(light_1).set_level(0.5);
+.. _output-set_min_power_action:
+
+``output.set_min_power`` Action
+*******************************
+
+This action sets the minimum output power level for the specified float output platform.
+It allows you to dynamically adjust the ``min_power`` configuration variable at runtime.
+
+.. note::
+
+ This only works with floating point outputs like :doc:`/components/output/ac_dimmer`,
+ :doc:`/components/output/esp8266_pwm`, :doc:`/components/output/ledc`,
+ :doc:`/components/output/sigma_delta_output`, :doc:`/components/output/slow_pwm`.
+
+.. code-block:: yaml
+
+ on_...:
+ then:
+ - output.set_min_power:
+ id: light_1
+ min_power: 20%
+
+.. note::
+
+ This action can also be expressed in :ref:`lambdas `:
+
+ .. code-block:: cpp
+
+ // range is 0.0 (off) to 1.0 (on)
+ id(light_1).set_min_power(0.2);
+
+.. _output-set_max_power_action:
+
+``output.set_max_power`` Action
+*******************************
+
+This action sets the maximum output power level for the specified float output platform.
+It allows you to dynamically adjust the ``max_power`` configuration variable at runtime.
+
+.. note::
+
+ This only works with floating point outputs like :doc:`/components/output/ac_dimmer`,
+ :doc:`/components/output/esp8266_pwm`, :doc:`/components/output/ledc`,
+ :doc:`/components/output/sigma_delta_output`, :doc:`/components/output/slow_pwm`.
+
+.. code-block:: yaml
+
+ on_...:
+ then:
+ - output.set_max_power:
+ id: light_1
+ max_power: 80%
+
+.. note::
+
+ This action can also be expressed in :ref:`lambdas `:
+
+ .. code-block:: cpp
+
+ // range is 0.0 (off) to 1.0 (on)
+ id(light_1).set_max_power(0.8);
+
Full Output Index
-----------------
diff --git a/components/remote_receiver.rst b/components/remote_receiver.rst
index f83a2d48b2..7b8f5e3eaf 100644
--- a/components/remote_receiver.rst
+++ b/components/remote_receiver.rst
@@ -80,7 +80,15 @@ Configuration variables:
- **filter** (*Optional*, :ref:`config-time`): Filter any pulses that are shorter than this. Useful for removing
glitches from noisy signals. Allowed values are in range ``0`` to ``4294967295us``. Defaults to ``50us``.
- **idle** (*Optional*, :ref:`config-time`): The amount of time that a signal should remain stable/unchanged for it to
- be considered complete. The maximum value is ``65536us`` on ESP32, and ``4294967295us`` on other platforms. Defaults to ``10ms``.
+ be considered complete. The maximum allowable value is:
+
+ - ``65536us`` on the ``ESP32`` and ``ESP32-S2`` variants
+ - ``32767us`` on all other ESP32 variants
+ - ``4294967295us`` on all other platforms
+
+ Note: The ESP32 values listed above assume the default ``clock_resolution``. If a different ``clock_resolution`` is used,
+ the values are scaled by 1000000 / ``clock_resolution``.
+
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. Useful when multiple
receivers are configured on a single device.
diff --git a/components/remote_transmitter.rst b/components/remote_transmitter.rst
index 41b8bdc6fb..b4b7d3bbb9 100644
--- a/components/remote_transmitter.rst
+++ b/components/remote_transmitter.rst
@@ -1024,6 +1024,24 @@ Configuration variables:
Toto remotes repeat all codes three times at a 36ms interval. This behavior will occur by default, but may be overridden by specifying ``repeat`` and ``wait time`` configuration variables.
+.. _remote_transmitter-digital_write:
+
+``remote_transmitter.digital_write`` **Action**
+***********************************************
+
+This :ref:`action ` sets the output value of the pin.
+
+.. code-block:: yaml
+
+ on_...:
+ - remote_transmitter.digital_write:
+ value: true
+
+Configuration variables:
+
+- **transmitter_id** (*Optional*, :ref:`config-id`): The remote transmitter to set the pin value on. Defaults to
+ the first one defined in the configuration.
+- **value** (**Required**, bool): The output value of the pin.
.. _remote_transmitter-rc_switch-protocol:
diff --git a/components/runtime_stats.rst b/components/runtime_stats.rst
new file mode 100644
index 0000000000..3660f8ca10
--- /dev/null
+++ b/components/runtime_stats.rst
@@ -0,0 +1,112 @@
+Runtime Statistics
+==================
+
+.. seo::
+ :description: Instructions for setting up the runtime statistics component to analyze component performance in ESPHome.
+ :image: chart-line.svg
+
+The ``runtime_stats`` component allows you to collect and analyze runtime performance statistics for all components in your ESPHome device. This is a powerful debugging and optimization tool that helps identify components that may be blocking the event loop or consuming excessive processing time.
+
+.. warning::
+
+ This component is intended for **debugging and troubleshooting**. While it can be temporarily enabled in production to diagnose issues, it should not be left enabled long-term because:
+
+ - The statistics collection adds overhead to every component execution
+ - It increases memory usage to store statistics
+ - The periodic logging can clutter your logs
+
+ Enable it when needed to find problems, then disable it once your investigation is complete.
+
+.. code-block:: yaml
+
+ # Example configuration entry
+ runtime_stats:
+ log_interval: 60s
+
+Configuration variables:
+------------------------
+
+- **log_interval** (*Optional*, :ref:`config-time`): How often to log the statistics. Defaults to ``60s``.
+
+ - Minimum value is ``1s``
+ - Setting this too low will increase log spam
+
+Understanding the Output
+------------------------
+
+.. note::
+
+ Runtime statistics use ``millis()`` for time measurement, which provides millisecond resolution. This means:
+
+ - Components that execute in less than 1ms will show as 0ms
+ - Very fast operations cannot be accurately measured
+ - The statistics are best suited for finding components that take multiple milliseconds
+
+The component logs two types of statistics:
+
+**Period Statistics**
+ Shows statistics for the most recent logging interval. Useful for identifying transient performance issues.
+
+**Total Statistics**
+ Shows cumulative statistics since boot. Useful for understanding overall system behavior.
+
+For each component, the following metrics are reported:
+
+- **count**: Number of times the component executed
+- **avg**: Average execution time in milliseconds
+- **max**: Maximum execution time observed
+- **total**: Total cumulative execution time
+
+Components are sorted by total execution time (descending) to highlight the most impactful components first.
+
+Example Output
+--------------
+
+.. code-block:: text
+
+ [09:55:52][I][runtime_stats:042]: Component Runtime Statistics
+ [09:55:52][I][runtime_stats:043]: Period stats (last 60000ms):
+ [09:55:52][I][runtime_stats:066]: wifi: count=60, avg=0.50ms, max=5ms, total=30ms
+ [09:55:52][I][runtime_stats:066]: api: count=120, avg=0.01ms, max=1ms, total=1ms
+ [09:55:52][I][runtime_stats:066]: sensor: count=600, avg=0.00ms, max=1ms, total=2ms
+ [09:55:52][I][runtime_stats:070]: Total stats (since boot):
+ [09:55:52][I][runtime_stats:084]: wifi: count=600, avg=0.45ms, max=5ms, total=270ms
+ [09:55:52][I][runtime_stats:084]: api: count=1200, avg=0.01ms, max=1ms, total=12ms
+ [09:55:52][I][runtime_stats:084]: sensor: count=6000, avg=0.00ms, max=1ms, total=20ms
+
+Use Cases
+---------
+
+**Identifying Blocking Components**
+ Look for components with high ``max`` times. These may be blocking the event loop and causing issues with other components.
+
+**Optimization Targets**
+ Components with high ``total`` times are good candidates for optimization, especially if they execute frequently.
+
+**Performance Regression Testing**
+ Compare statistics before and after changes to ensure performance hasn't degraded.
+
+**Troubleshooting Timing Issues**
+ If components are missing deadlines or behaving erratically, runtime statistics can help identify the cause.
+
+Tips for Effective Use
+----------------------
+
+1. **Start with default interval**: The 60-second default provides a good balance between detail and log volume.
+
+2. **Focus on outliers**: Components with significantly higher execution times than others are usually the best optimization targets.
+
+3. **Consider execution frequency**: A component that takes 1ms but runs 1000 times per minute has more impact than one that takes 10ms but runs once per minute.
+
+4. **Watch for patterns**: Execution times that increase over time may indicate memory leaks or resource exhaustion.
+
+5. **Disable when done**: Always remove or comment out the runtime_stats component when you're finished debugging.
+
+See Also
+--------
+
+- :doc:`debug`
+- :doc:`logger`
+- :ref:`automation`
+- :apiref:`runtime_stats/runtime_stats.h`
+- :ghedit:`Edit`
diff --git a/components/sensor/adc.rst b/components/sensor/adc.rst
index d7cc650e4a..f645a4f87c 100644
--- a/components/sensor/adc.rst
+++ b/components/sensor/adc.rst
@@ -9,9 +9,9 @@ The Analog To Digital (``adc``) Sensor allows you to use the built-in
ADC in your device to measure a voltage on certain pins.
- ESP8266: Only pin A0 (GPIO17) can be used.
-- ESP32: GPIO32 through GPIO39 can be used.
+- ESP32: Available pins vary by variant, see :ref:`adc-esp32_pins`.
- RP2040: GPIO26 through GPIO29 can be used.
-
+- nRF52840: AIN0 through AIN7, VDD, VDDHDIV5 can be used.
.. figure:: images/adc-ui.png
:align: center
@@ -81,10 +81,9 @@ To simplify this, we provide the setting ``attenuation: auto`` for an automatic/
.. _adc-esp32_pins:
-ESP32 pins
-----------
+ESP32 pins and Hardware Details
+-------------------------------
-``ADC2`` pins are only usable when Wi-Fi is not configured on the device.
.. list-table::
:header-rows: 1
@@ -101,6 +100,9 @@ ESP32 pins
* - ESP32-C3
- GPIO0 - GPIO4
- GPIO5
+ * - ESP32-C5
+ - GPIO1 - GPIO6
+ - no ``ADC2``
* - ESP32-C6
- GPIO0 - GPIO6
- no ``ADC2``
@@ -113,6 +115,21 @@ ESP32 pins
* - ESP32-S3
- GPIO1 - GPIO10
- GPIO11 - GPIO20
+ * - ESP32-P4
+ - GPIO16 - GPIO23
+ - GPIO49 - GPIO54
+
+Different ESP32 variants use different ADC calibration methods:
+
+* Original ESP32 (non-variant) & ESP32-S2: Use line-fitting calibration
+* ESP32-C3, ESP32-C5, ESP32-C6, ESP32-H2, ESP32-S3 & ESP32-P4: Use curve-fitting calibration
+
+This is handled automatically by the code, but it's worth noting if you're debugging ADC readings or need to understand the calibration process.
+
+
+.. warning::
+
+ On ESP32-C5, GPIO2 is a strapping pin used during boot. While it can be used as an ADC input, avoid connecting circuits that might interfere with the boot process.
.. _adc-raw:
@@ -166,10 +183,13 @@ To measure the VCC voltage, set ``pin:`` to ``VCC`` and make sure nothing is con
On Raspberry Pi Pico
~~~~~~~~~~~~~~~~~~~~
-On the Raspberry Pi Pico and Pico W the ADC can measure VSYS voltage.
+On the Raspberry Pi Pico and Pico W, setting ``pin:`` to ``VCC`` allows you to measure the VSYS voltage through ADC3 (GPIO29).
+
+The reading will reflect either:
+- Direct power supply voltage when powered through the VSYS pin
+- USB voltage (VBUS) minus diode drop when powered via USB
-Depending on how VSYS is powered the readings will have different meanings - either power supply voltage when it is connected to VSYS pin directly, or USB voltage (VBUS) minus some drop on the Schottky diode the Raspberry Pi Pico has between those pins.
-Our experiments indicate the drop being ~0.1V for Pico and ~0.25V for Pico W; you can use sensor filters to adjust the final value.
+Our experiments indicate the diode drop being ~0.1V for Pico and ~0.25V for Pico W; you can use sensor filters to adjust the final value.
.. note::
diff --git a/components/sensor/airthings_ble.rst b/components/sensor/airthings_ble.rst
index 56267a672b..5a4758f7fe 100644
--- a/components/sensor/airthings_ble.rst
+++ b/components/sensor/airthings_ble.rst
@@ -132,6 +132,60 @@ Configuration example:
will result in the battery voltage being reported once per polling
interval.
+Airthings Wave Radon (Gen 2) Sensor
+***********************************
+
+AirThings Wave Radon (Gen 2) tracks radon (24h and long term), temperature, atmospheric pressure and humidity.
+
+.. note::
+
+ The Wave Gen2 device does NOT support CO2 or TVOC sensors - only radon, temperature, pressure, humidity, and illuminance are available.
+
+.. figure:: images/airthings_wave_radon.jpg
+ :align: center
+ :width: 60.0%
+
+Configuration variables:
+------------------------
+
+- **device_type** (*Optional*): Specifies the type of AirThings Wave device. Defaults to ``WAVE_PLUS``.
+
+ - ``WAVE_PLUS``: For AirThings Wave Plus devices (supports all sensors including CO2 and TVOC)
+ - ``WAVE_GEN2``: For AirThings Wave Radon Gen 2 devices (does not support CO2 or TVOC sensors)
+
+Configuration example:
+**********************
+
+
+.. code-block:: yaml
+
+ sensor:
+ - platform: airthings_wave_plus
+ name: wave_gen2
+ ble_client_id: airthings01
+ device_type: WAVE_GEN2 # Required for Wave Gen2 devices (default is WAVE_PLUS)
+ update_interval: 5min # default
+ battery_update_interval: 24h # default
+ temperature:
+ name: "WaveG2 Temperature"
+ radon:
+ name: "WaveG2 Radon"
+ radon_long_term:
+ name: "WaveG2 Radon Long Term"
+ pressure:
+ name: "WaveG2 Pressure"
+ humidity:
+ name: "WaveG2 Humidity"
+ illuminance:
+ name: "WaveG2 ambient light"
+ battery_voltage:
+ name: "WaveG2 Battery Voltage"
+
+ ble_client:
+ - mac_address: XX:XX:XX:XX:XX:XX
+ id: airthings01
+
+ esp32_ble_tracker:
Battery Level Reporting
***********************
diff --git a/components/sensor/images/airthings_wave_radon.jpg b/components/sensor/images/airthings_wave_radon.jpg
new file mode 100644
index 0000000000..e40415d021
Binary files /dev/null and b/components/sensor/images/airthings_wave_radon.jpg differ
diff --git a/components/sensor/images/ld2412.png b/components/sensor/images/ld2412.png
new file mode 100644
index 0000000000..9782a87f6b
Binary files /dev/null and b/components/sensor/images/ld2412.png differ
diff --git a/components/sensor/index.rst b/components/sensor/index.rst
index cd185d088d..36d8f46afc 100644
--- a/components/sensor/index.rst
+++ b/components/sensor/index.rst
@@ -156,6 +156,11 @@ Filters are applied in the order they are defined in your configuration.
send_every: 15
- throttle: 1s
- throttle_average: 1s
+ - throttle_with_priority:
+ timeout: 1s
+ value:
+ - 42.0
+ - 43.0
- heartbeat: 5s
- debounce: 0.1s
- timeout: 1min
@@ -209,6 +214,8 @@ Filters are applied in the order they are defined in your configuration.
.. include:: sensor-filter-throttle_average.rst
+.. include:: sensor-filter-throttle_with_priority.rst
+
.. include:: sensor-filter-timeout.rst
.. include:: sensor-filter-to_ntc_resistance.rst
diff --git a/components/sensor/ld2410.rst b/components/sensor/ld2410.rst
index b53a6d6f43..8179822ec3 100644
--- a/components/sensor/ld2410.rst
+++ b/components/sensor/ld2410.rst
@@ -16,8 +16,10 @@ There are three variants with similar communication protocols:
- LD2410B (`datasheet and user manual `__)
- LD2410C (`datasheet and user manual `__)
-The :ref:`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``.
-Use of hardware UART pins is highly recommended, in order to support the out-of-the-box 256000 baud rate of the LD2410 sensor.
+The :ref:`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``.
+
+Use of hardware UART pins is highly recommended to best support the out-of-the-box 256000 baud rate of the sensor.
.. figure:: images/ld2410.jpg
:align: center
@@ -35,14 +37,13 @@ Configuration variables:
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component ` if you want
to use multiple UART buses.
-- **throttle** (*Optional*, int): Time in milliseconds to control the rate of data updates. Defaults to ``1000ms``.
-- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this :doc:`ld2410` component if you need multiple components.
+- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this :doc:`ld2410` component if you need multiple
+ components.
Binary Sensor
-------------
-The ``ld2410`` binary sensor allows you to use your :doc:`ld2410` to perform different
-measurements.
+The ``ld2410`` binary sensors allow you to quickly determine various states reported by the sensor.
.. code-block:: yaml
@@ -55,7 +56,7 @@ measurements.
has_still_target:
name: Still Target
out_pin_presence_status:
- name: out pin presence status
+ name: Out pin presence status
Configuration variables:
************************
@@ -66,23 +67,38 @@ Configuration variables:
All options from :ref:`Binary Sensor `.
- **has_still_target** (*Optional*): If true a still target is detected.
All options from :ref:`Binary Sensor `.
-- **out_pin_presence_status** (*Optional*): When in :ref:`engineering mode`, indicates whether the OUT pin indicates presence or not, otherwise ``false``.
- OUT pin indication depends on the :ref:`light function` configuration. Might need latest firmware to work.
+- **out_pin_presence_status** (*Optional*): When in :ref:`engineering mode`, indicates the
+ status of the OUT pin, otherwise ``false``. OUT pin indication depends on the
+ :ref:`light function` configuration. Might need to update to the latest firmware to use this.
All options from :ref:`Binary Sensor `.
-- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are using multiple components.
+- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are
+ using multiple components.
+
+.. note::
+
+ By default, each of the :doc:`Binary Sensor ` components above includes the
+ following :ref:`filter` by default to prevent flooding Home Assistant with state updates:
+
+ .. code-block:: yaml
+
+ - settle: 1000ms
+
+ If you have defined other filters, this default will be overridden; you may of course add it back to your custom
+ filter(s) as above if you wish.
+
+ To remove the default filter for any given binary sensor instance, add ``filters: []`` to its configuration.
Sensor
------
-The ``ld2410`` sensor allows you to use your :doc:`ld2410` to perform different
-measurements.
+The ``ld2410`` sensors allow reporting of various measurements the sensor takes.
.. code-block:: yaml
sensor:
- platform: ld2410
light:
- name: light
+ name: Light
moving_distance:
name: Moving Distance
still_distance:
@@ -95,57 +111,57 @@ measurements.
name: Detection Distance
g0:
move_energy:
- name: g0 move energy
+ name: G0 move energy
still_energy:
- name: g0 still energy
+ name: G0 still energy
g1:
move_energy:
- name: g1 move energy
+ name: G1 move energy
still_energy:
- name: g1 still energy
+ name: G1 still energy
g2:
move_energy:
- name: g2 move energy
+ name: G2 move energy
still_energy:
- name: g2 still energy
+ name: G2 still energy
g3:
move_energy:
- name: g3 move energy
+ name: G3 move energy
still_energy:
- name: g3 still energy
+ name: G3 still energy
g4:
move_energy:
- name: g4 move energy
+ name: G4 move energy
still_energy:
- name: g4 still energy
+ name: G4 still energy
g5:
move_energy:
- name: g5 move energy
+ name: G5 move energy
still_energy:
- name: g5 still energy
+ name: G5 still energy
g6:
move_energy:
- name: g6 move energy
+ name: G6 move energy
still_energy:
- name: g6 still energy
+ name: G6 still energy
g7:
move_energy:
- name: g7 move energy
+ name: G7 move energy
still_energy:
- name: g7 still energy
+ name: G7 still energy
g8:
move_energy:
- name: g8 move energy
+ name: G8 move energy
still_energy:
- name: g8 still energy
+ name: G8 still energy
.. _ld2410-sensors:
Configuration variables:
************************
-- **light** (*Optional*, int): When in :ref:`engineering mode`, indicates the light sensitivity, otherwise ``unknown``.
- Value between ``0`` and ``255`` inclusive. Though it seems that the value ``85`` is the lowest value at complete darkness.
+- **light** (*Optional*, int): When in :ref:`engineering mode`, indicates the light
+ sensitivity, otherwise ``unknown``. Value between ``0`` and ``255`` inclusive.
All options from :ref:`Sensor `.
- **moving_distance** (*Optional*, int): Distance in cm of detected moving target.
All options from :ref:`Sensor `.
@@ -161,40 +177,55 @@ Configuration variables:
All options from :ref:`Sensor `.
- **gX** (*Optional*): Energies for the Xth gate (X => 0 to 8).
- - **move_energy** (*Optional*, int): When in :ref:`engineering mode`, the move energy of the gate, otherwise ``unknown``.
- Value between ``0`` and ``100`` inclusive.
+ - **move_energy** (*Optional*, int): When in :ref:`engineering mode`, the move energy of
+ the gate, otherwise ``unknown``. Value between ``0`` and ``100`` inclusive.
All options from :ref:`Sensor `.
- - **still_energy** (*Optional*, int): When in :ref:`engineering mode`, the still energy of the gate, otherwise ``unknown``.
- Value between ``0`` and ``100`` inclusive.
+ - **still_energy** (*Optional*, int): When in :ref:`engineering mode`, the still energy of
+ the gate, otherwise ``unknown``. Value between ``0`` and ``100`` inclusive.
All options from :ref:`Sensor `.
-- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are using multiple components.
+- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are
+ using multiple components.
+
+.. note::
+
+ By default, each of the :doc:`Sensor ` components above includes the following
+ :ref:`filter` by default to prevent flooding Home Assistant with state updates:
+
+ .. code-block:: yaml
+
+ - throttle_with_priority: 1000ms
+
+ If you have defined other filters, this default will be overridden; you may of course add it back to your custom
+ filter(s) as above if you wish.
+
+ To remove the default filter for any given sensor instance, add ``filters: []`` to its configuration.
Switch
------
-The ``ld2410`` switch allows you to control your :doc:`ld2410`.
+The ``ld2410`` switches allow you to enable or disable sensor features from the front end.
.. code-block:: yaml
switch:
- platform: ld2410
engineering_mode:
- name: "engineering mode"
+ name: Engineering mode
bluetooth:
- name: "control bluetooth"
+ name: Control bluetooth
.. _ld2410-engineering-mode:
Configuration variables:
************************
-- **engineering_mode** (*Optional*): enable/disable engineering mode. Defaults to ``false``.
- Notice this requires more resources and is not recommended to be enabled when not necessary.
- All options from :ref:`Switch `.
+- **engineering_mode** (*Optional*): enable/disable engineering mode. Note that this requires more resources and is not
+ recommended to be enabled when not necessary. All options from :ref:`Switch `.
- **bluetooth** (*Optional*): Turn on/off the bluetooth adapter. Defaults to ``true``.
All options from :ref:`Switch `.
-- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are using multiple components.
+- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are
+ using multiple components.
.. _ld2410-number:
@@ -209,58 +240,58 @@ The ``ld2410`` number allows you to control the configuration of your :doc:`ld24
number:
- platform: ld2410
timeout:
- name: timeout
+ name: Timeout
light_threshold:
- name: light threshold
+ name: Light threshold
max_move_distance_gate:
- name: max move distance gate
+ name: Max move distance gate
max_still_distance_gate:
- name: max still distance gate
+ name: Max still distance gate
g0:
move_threshold:
- name: g0 move threshold
+ name: G0 move threshold
still_threshold:
- name: g0 still threshold
+ name: G0 still threshold
g1:
move_threshold:
- name: g1 move threshold
+ name: G1 move threshold
still_threshold:
- name: g1 still threshold
+ name: G1 still threshold
g2:
move_threshold:
- name: g2 move threshold
+ name: G2 move threshold
still_threshold:
- name: g2 still threshold
+ name: G2 still threshold
g3:
move_threshold:
- name: g3 move threshold
+ name: G3 move threshold
still_threshold:
- name: g3 still threshold
+ name: G3 still threshold
g4:
move_threshold:
- name: g4 move threshold
+ name: G4 move threshold
still_threshold:
- name: g4 still threshold
+ name: G4 still threshold
g5:
move_threshold:
- name: g5 move threshold
+ name: G5 move threshold
still_threshold:
- name: g5 still threshold
+ name: G5 still threshold
g6:
move_threshold:
- name: g6 move threshold
+ name: G6 move threshold
still_threshold:
- name: g6 still threshold
+ name: G6 still threshold
g7:
move_threshold:
- name: g7 move threshold
+ name: G7 move threshold
still_threshold:
- name: g7 still threshold
+ name: G7 still threshold
g8:
move_threshold:
- name: g8 move threshold
+ name: G8 move threshold
still_threshold:
- name: g8 still threshold
+ name: G8 still threshold
.. _ld2410-light-threshold:
@@ -290,7 +321,8 @@ Configuration variables:
Value between ``0`` and ``100`` inclusive. See default values below.
All options from :ref:`Number `.
-- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are using multiple components.
+- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are
+ using multiple components.
.. list-table:: Default values for gate threshold
:widths: 25 25 25
@@ -330,18 +362,18 @@ Configuration variables:
Button
------
-The ``ld2410`` button allows you to perform actions on your :doc:`ld2410`.
+The ``ld2410`` button allows you to perform actions on your sensor.
.. code-block:: yaml
button:
- platform: ld2410
factory_reset:
- name: "factory reset"
+ name: Factory reset
restart:
- name: "restart"
+ name: Restart
query_params:
- name: query params
+ name: Query params
Configuration variables:
************************
@@ -352,21 +384,22 @@ Configuration variables:
All options from :ref:`Button `.
- **query_params** (*Optional*): Refresh all sensors values of the device.
All options from :ref:`Button `.
-- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are using multiple components.
+- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are
+ using multiple components.
Text Sensor
-----------
-The ``ld2410`` text sensor allows you to get information about your :doc:`ld2410`.
+The ``ld2410`` text sensors allow reporting of sensor metadata.
.. code-block:: yaml
text_sensor:
- platform: ld2410
version:
- name: "firmware version"
+ name: Firmware version
mac_address:
- name: "mac address"
+ name: MAC address
Configuration variables:
************************
@@ -375,41 +408,44 @@ Configuration variables:
All options from :ref:`Text Sensor `.
- **mac_address** (*Optional*): The bluetooth mac address. Will be set to ``unknown`` when bluetooth is off.
All options from :ref:`Text Sensor `.
-- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are using multiple components.
+- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are
+ using multiple components.
Select
------------
+------
-The ``ld2410`` select allows you to control your :doc:`ld2410`.
+The ``ld2410`` selects allow you to configure your sensor hardware.
.. code-block:: yaml
select:
- platform: ld2410
distance_resolution:
- name: "distance resolution"
+ name: Distance resolution
baud_rate:
- name: "baud rate"
+ name: Baud rate
light_function:
- name: light function
+ name: Light function
out_pin_level:
- name: out pin level
+ name: Out pin level
.. _ld2410-light-function:
Configuration variables:
************************
-- **distance_resolution** (*Optional*): Control the gates distance resolution. Can be ``0.75m`` or ``0.2m``. Defaults to ``0.75m``.
- All options from :ref:`Select `.
-- **baud_rate** (*Optional*): Control the serial port baud rate. Defaults to ``256000``.
- Once changed, all sensors will stop working until a fresh install with an updated :ref:`UART Component ` configuration.
+- **distance_resolution** (*Optional*): Control the gates distance resolution. Can be ``0.75m`` or ``0.2m``.
+ Defaults to ``0.75m``. All options from :ref:`Select `.
+- **baud_rate** (*Optional*): Control the serial port baud rate. Defaults to ``256000``. Once changed, all sensors will
+ stop working until you reinstall your configuration with an updated :ref:`UART Component ` configuration.
All options from :ref:`Select `.
-- **light_function** (*Optional*): If set, will affect the OUT pin value, based on :ref:`light threshold`. Can be ``off``, ``low`` or ``above``. Defaults to ``off``.
+- **light_function** (*Optional*): If set, will affect the OUT pin value, based on
+ :ref:`light threshold`. Can be ``off``, ``low`` or ``above``. Defaults to ``off``.
All options from :ref:`Select `.
- **out_pin_level** (*Optional*): Control OUT pin ``away`` value. Can be ``low`` or ``high``. Defaults to ``low``.
All options from :ref:`Select `.
-- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are using multiple components.
+- **ld2410_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the :doc:`ld2410` component if you are
+ using multiple components.
Automations
-----------
@@ -451,15 +487,16 @@ To change the password from HA you can use the following example config:
OUT pin
-------
-In order to monitor the presence indicated by the component, with the :ref:`light function` taken
-under account, you can set up a :ref:`GPIO Binary Sensor `:
+If you connect the LD2410's ``OUT`` pin to a GPIO pin, you can set up a :ref:`GPIO Binary Sensor `
+to monitor the presence status indicated by the sensor, potentially including the state of its
+:ref:`light function`, if enabled:
.. code-block:: yaml
binary_sensor:
- platform: gpio
pin: GPIOXX
- name: gpio out pin presence
+ name: GPIO Out pin presence
device_class: presence
diff --git a/components/sensor/ld2412.rst b/components/sensor/ld2412.rst
new file mode 100644
index 0000000000..440ca120d8
--- /dev/null
+++ b/components/sensor/ld2412.rst
@@ -0,0 +1,481 @@
+LD2412 Sensor
+=============
+
+.. seo::
+ :description: Instructions for setting up LD2412 sensors for use with ESPHome.
+ :image: ld2412.jpg
+
+Component/Hub
+-------------
+
+The ``ld2412`` sensor platform allows you to use HI-LINK LD2412 motion and presence sensors with ESPHome.
+
+The :ref:`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``.
+
+Use of a hardware UART is highly recommended as it best supports the default 115200 baud rate of the sensor module.
+
+.. figure:: images/ld2412.png
+ :align: center
+ :width: 50.0%
+
+ LD2412 motion and presence sensor
+
+.. code-block:: yaml
+
+ # Example configuration entry
+ ld2412:
+
+Configuration variables:
+************************
+
+- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component `, which is
+ necessary if you have multiple UARTs defined in your configuration.
+- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this component.
+
+Binary Sensor
+-------------
+
+The ``ld2412`` binary sensors allow you to quickly determine various states reported by the sensor.
+
+.. code-block:: yaml
+
+ binary_sensor:
+ - platform: ld2412
+ has_target:
+ name: Presence
+ has_moving_target:
+ name: Moving Target
+ has_still_target:
+ name: Still Target
+ dynamic_background_correction_status:
+ name: Dynamic Background Correction Status
+
+
+Configuration variables:
+************************
+
+- **has_target** (*Optional*): If true target detect either still or in movement.
+ All options from :ref:`Binary Sensor `.
+- **has_moving_target** (*Optional*): True if a moving target is detected.
+ All options from :ref:`Binary Sensor `.
+- **has_still_target** (*Optional*): True if a still target is detected.
+ All options from :ref:`Binary Sensor `.
+- **dynamic_background_correction_status** (*Optional*): True while the sensor is performing dynamic background
+ correction. All options from :ref:`Binary Sensor `.
+- **ld2412_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the component. Required when using multiple
+ components.
+
+.. note::
+
+ By default, each of the target :doc:`Binary Sensor ` components above includes the
+ following :ref:`filter` by default to prevent flooding Home Assistant with state updates:
+
+ .. code-block:: yaml
+
+ - settle: 1000ms
+
+ If you have defined other filters, this default will be overridden; you may of course add it back to your custom
+ filter(s) as above if you wish.
+
+ To remove the default filter for any given binary sensor instance, add ``filters: []`` to its configuration.
+
+Sensor
+------
+
+The ``ld2412`` sensors allow reporting of various measurements the sensor takes.
+
+.. code-block:: yaml
+
+ sensor:
+ - platform: ld2412
+ moving_distance:
+ name : Moving Distance
+ still_distance:
+ name: Still Distance
+ moving_energy:
+ name: Move Energy
+ still_energy:
+ name: Still Energy
+ detection_distance:
+ name: Detection Distance
+ light:
+ name: light
+ gate_0:
+ move_energy:
+ name: Gate 0 move energy
+ still_energy:
+ name: Gate 0 still energy
+ gate_1:
+ move_energy:
+ name: Gate 1 move energy
+ still_energy:
+ name: Gate 1 still energy
+ gate_2:
+ move_energy:
+ name: Gate 2 move energy
+ still_energy:
+ name: Gate 2 still energy
+ gate_3:
+ move_energy:
+ name: Gate 3 move energy
+ still_energy:
+ name: Gate 3 still energy
+ gate_4:
+ move_energy:
+ name: Gate 4 move energy
+ still_energy:
+ name: Gate 4 still energy
+ gate_5:
+ move_energy:
+ name: Gate 5 move energy
+ still_energy:
+ name: Gate 5 still energy
+ gate_6:
+ move_energy:
+ name: Gate 6 move energy
+ still_energy:
+ name: Gate 6 still energy
+ gate_7:
+ move_energy:
+ name: Gate 7 move energy
+ still_energy:
+ name: Gate 7 still energy
+ gate_8:
+ move_energy:
+ name: Gate 8 move energy
+ still_energy:
+ name: Gate 8 still energy
+ gate_9:
+ move_energy:
+ name: Gate 9 move energy
+ still_energy:
+ name: Gate 9 still energy
+ gate_10:
+ move_energy:
+ name: Gate 10 move energy
+ still_energy:
+ name: Gate 10 still energy
+ gate_11:
+ move_energy:
+ name: Gate 11 move energy
+ still_energy:
+ name: Gate 11 still energy
+ gate_12:
+ move_energy:
+ name: Gate 12 move energy
+ still_energy:
+ name: Gate 12 still energy
+ gate_13:
+ move_energy:
+ name: Gate 13 move energy
+ still_energy:
+ name: Gate 13 still energy
+
+.. _ld2412-sensors:
+
+Configuration variables:
+************************
+
+- **light** (*Optional*, int): When in :ref:`engineering mode`, indicates the light
+ sensitivity, otherwise indicates ``unknown``. Value between ``0`` and ``255`` inclusive. Note that this is an
+ arbitrary unit and does not correspond to any particular unit of measurement for intensity. All options from
+ :ref:`Sensor `.
+- **moving_distance** (*Optional*, int): Distance in cm of detected moving target. All options from
+ :ref:`Sensor `.
+- **still_distance** (*Optional*, int): Distance in cm of detected still target. All options from
+ :ref:`Sensor `.
+- **moving_energy** (*Optional*, int): Energy for moving target. Value between ``0`` and ``100`` inclusive. All options
+ from :ref:`Sensor `.
+- **still_energy** (*Optional*, int): Energy for still target. Value between ``0`` and ``100`` inclusive. All options
+ from :ref:`Sensor `.
+- **detection_distance** (*Optional*, int): Distance in cm of target. All options from :ref:`Sensor `.
+- **gate_X** (*Optional*): Energy values for gate X, where X is in the range of 0 to 13.
+
+ - **move_energy** (*Optional*, int): When in :ref:`engineering mode`, the move energy of
+ the gate, otherwise indicates ``unknown``. Value between ``0`` and ``100`` inclusive. All options from
+ :ref:`Sensor `.
+ - **still_energy** (*Optional*, int): When in :ref:`engineering mode`, the still energy of
+ the gate, otherwise indicates ``unknown``. Value between ``0`` and ``100`` inclusive. All options from
+ :ref:`Sensor `.
+
+- **ld2412_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the component. Required when using multiple
+ components.
+
+.. note::
+
+ By default, each of the :doc:`Sensor ` components above includes the following
+ :ref:`filter` by default to prevent flooding Home Assistant with state updates:
+
+ .. code-block:: yaml
+
+ - throttle_with_priority: 1000ms
+
+ If you have defined other filters, this default will be overridden; you may of course add it back to your custom
+ filter(s) as above if you wish.
+
+ To remove the default filter for any given sensor instance, add ``filters: []`` to its configuration.
+
+Switch
+------
+
+The ``ld2412`` switches allow you to enable or disable sensor features from the front end.
+
+.. code-block:: yaml
+
+ switch:
+ - platform: ld2412
+ engineering_mode:
+ name: Engineering Mode
+ bluetooth:
+ name: Bluetooth
+
+.. _ld2412-engineering-mode:
+
+Configuration variables:
+************************
+
+- **bluetooth** (*Optional*): Turn on/off the bluetooth adapter. Defaults to ``true``. All options from
+ :ref:`Switch `.
+- **engineering_mode** Turn on/off the engineering mode. All options from :ref:`Switch `.
+- **ld2412_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the component. Required when using multiple
+ components.
+
+.. _ld2412-number:
+
+Number
+------
+
+The ``ld2412`` number allows you to control the configuration of your module.
+
+.. code-block:: yaml
+
+ number:
+ - platform: ld2412
+ timeout:
+ name: Presence Timeout
+ min_distance_gate:
+ name: Minimum Distance Gate
+ max_distance_gate:
+ name: Maximum Distance Gate
+ light_threshold:
+ name: Light Threshold
+ gate_0:
+ move_threshold:
+ name: Gate 0 Move Threshold
+ still_threshold:
+ name: Gate 0 Still Threshold
+ gate_1:
+ move_threshold:
+ name: Gate 1 Move Threshold
+ still_threshold:
+ name: Gate 1 Still Threshold
+ gate_2:
+ move_threshold:
+ name: Gate 2 Move Threshold
+ still_threshold:
+ name: Gate 2 Still Threshold
+ gate_3:
+ move_threshold:
+ name: Gate 3 Move Threshold
+ still_threshold:
+ name: Gate 3 Still Threshold
+ gate_4:
+ move_threshold:
+ name: Gate 4 Move Threshold
+ still_threshold:
+ name: Gate 4 Still Threshold
+ gate_5:
+ move_threshold:
+ name: Gate 5 Move Threshold
+ still_threshold:
+ name: Gate 5 Still Threshold
+ gate_6:
+ move_threshold:
+ name: Gate 6 Move Threshold
+ still_threshold:
+ name: Gate 6 Still Threshold
+ gate_7:
+ move_threshold:
+ name: Gate 7 Move Threshold
+ still_threshold:
+ name: Gate 7 Still Threshold
+ gate_8:
+ move_threshold:
+ name: Gate 8 Move Threshold
+ still_threshold:
+ name: Gate 8 Still Threshold
+ gate_9:
+ move_threshold:
+ name: Gate 9 Move Threshold
+ still_threshold:
+ name: Gate 9 Still Threshold
+ gate_10:
+ move_threshold:
+ name: Gate 10 Move Threshold
+ still_threshold:
+ name: Gate 10 Still Threshold
+ gate_11:
+ move_threshold:
+ name: Gate 11 Move Threshold
+ still_threshold:
+ name: Gate 11 Still Threshold
+ gate_12:
+ move_threshold:
+ name: Gate 12 Move Threshold
+ still_threshold:
+ name: Gate 12 Still Threshold
+ gate_13:
+ move_threshold:
+ name: Gate 13 Move Threshold
+ still_threshold:
+ name: Gate 13 Still Threshold
+
+Configuration variables:
+************************
+
+- **timeout** (*Optional*, int): Time in seconds for which the presence state will remain after presence is no longer
+ detected. Defaults to ``5s``. All options from :ref:`Number `.
+- **min_distance_gate** (*Optional*, int): Maximum distance gate for movement detection. Value between ``1`` and ``12``
+ inclusive. Defaults to ``1``. All options from :ref:`Number `.
+- **max_distance_gate** (*Optional*, int): Maximum distance gate for still detection. Value between ``2`` and ``13``
+ inclusive. Defaults to ``13``. All options from :ref:`Number `.
+- **light_threshold** (*Optional*, int): Threshold for the light to activate the OUT pin of the sensor. All options
+ from :ref:`Number `.
+- **gate_X** (*Optional*): Threshold values for gate X, where X is in the range of 0 to 13.
+
+ - **move_threshold** (**Required**, int): Threshold for the gate for motion detection. For the respective gate, a
+ value above this level will result in detection of movement. Value between ``0`` and ``100`` inclusive. See
+ default values below. All options from :ref:`Number `.
+ - **still_threshold** (**Required**, int): Threshold for the gate for still detection. For the respective gate, a
+ value below this level will result in detection of stillness. Value between ``0`` and ``100`` inclusive. See
+ default values below. All options from :ref:`Number `.
+
+- **ld2412_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the component. Required when using multiple
+ components.
+
+Button
+------
+
+The ``ld2412`` button allows you to perform actions on your sensor.
+
+.. code-block:: yaml
+
+ button:
+ - platform: ld2412
+ factory_reset:
+ name: Factory Reset
+ restart:
+ name: Restart
+ query_params:
+ name: Query Params
+ start_dynamic_background_correction:
+ name: Start Dynamic Background Correction
+
+Configuration variables:
+************************
+
+- **factory_reset** (*Optional*): This command is used to restore all configuration values to their original values.
+ All options from :ref:`Button `.
+- **restart** (*Optional*): Restart the device. All options from :ref:`Button `.
+- **query_params** (*Optional*): Refresh all sensors values of the device. All options from
+ :ref:`Button `.
+- **start_dynamic_background_correction** (*Optional*): Start the Dynamic Background Correction All options from
+ :ref:`Button `.
+- **ld2412_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the component. Required when using multiple
+ components.
+
+Text Sensor
+-----------
+
+The ``ld2412`` text sensors allow reporting of sensor metadata.
+
+.. code-block:: yaml
+
+ text_sensor:
+ - platform: ld2412
+ version:
+ name: Firmware Version
+ mac_address:
+ name: Mac Address
+
+Configuration variables:
+************************
+
+- **version** (*Optional*): The firmware version. All options from :ref:`Text Sensor `.
+- **mac_address** (*Optional*): The bluetooth mac address. Will be set to ``unknown`` when bluetooth is off. All
+ options from :ref:`Text Sensor `.
+- **ld2412_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the component. Required when using multiple
+ components.
+
+Select
+------
+
+The ``ld2412`` selects allow you to configure your sensor hardware.
+
+.. code-block:: yaml
+
+ select:
+ - platform: ld2412
+ out_pin_level:
+ name: Hardware Output Pin Level
+ distance_resolution:
+ name: Distance Resolution
+ light_function:
+ name: Light Function
+ baud_rate:
+ name: Baud Rate
+
+.. _ld2412-light-function:
+
+Configuration variables:
+************************
+
+- **distance_resolution** (*Optional*): Control the gates distance resolution. Can be ``0.75m``, ``0.5m`` or ``0.2m``.
+ Defaults to ``0.75m``. All options from :ref:`Select `.
+- **baud_rate** (*Optional*): Allows changing the baud rate of the LD2412's serial port. Defaults to ``115200``. Once
+ changed, sensors will stop working until the :ref:`UART Component ` is updated with the new baud rate in your
+ device's configuration. All options from :ref:`Select `.
+- **out_pin_level** (*Optional*): Allows selection of the LD2412's OUT pin behavior when the sensor detects presence.
+ Can be ``low`` or ``high``. Defaults to ``low``. All options from :ref:`Select `.
+- **light_function** (*Optional*): Allows selection of how the LD2412's OUT pin will react to the light level. Can be
+ ``off``, ``below`` or ``above``. Note that this works in conjunction with presence detection. See the reference
+ manual for details.
+- **ld2412_id** (*Optional*, :ref:`config-id`): Manually specify the ID for the component. Required when using multiple
+ components.
+
+OUT pin
+-------
+
+The LD2412's ``OUT`` pin provides a simple hardware mechanism which reports whether the sensor detects presence (and
+light) or not. If you wish, you can set up a :ref:`GPIO Binary Sensor `:
+
+.. code-block:: yaml
+
+ binary_sensor:
+ - platform: gpio
+ pin: GPIOXX
+ name: LD2412 Out Pin Status
+ device_class: presence
+
+
+Calibration Process
+-------------------
+
+To calibrate your sensor, perform the following:
+
+1. Enable :ref:`engineering mode`.
+2. Monitor the ``gate_X_move_energy`` and ``gate_X_still_energy`` :ref:`sensors`.
+3. Change the :ref:`thresholds` and repeat step 2 until you are satisfied.
+4. Disable :ref:`engineering mode`.
+
+As an alternative, you can simply leave the room, turn on the "Dynamic background correction" and let it calibrate
+itself.
+
+See Also
+--------
+
+- `Official Datasheet and user manuals `_
+- `Source of inspiration for implementation `_
+- :apiref:`ld2412/ld2412.h`
+- :ghedit:`Edit`
diff --git a/components/sensor/ld2450.rst b/components/sensor/ld2450.rst
index eab26f81a2..f0f3b5535c 100644
--- a/components/sensor/ld2450.rst
+++ b/components/sensor/ld2450.rst
@@ -47,7 +47,6 @@ properly support the default 256000 baud rate of the LD2450 module.
# ld2450 configuration
ld2450:
id: ld2450_radar
- throttle: 1000ms
Configuration variables:
************************
@@ -55,8 +54,6 @@ Configuration variables:
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID for this :doc:`ld2450` component.
- **uart_id** (*Optional*, :ref:`config-id`): Manually specify the ID of the :ref:`UART Component ` to use.
Required if you have multiple UARTs configured.
-- **throttle** (*Optional*, int): Time in milliseconds to control the rate of data updates. Defaults to ``1000ms``.
-
.. _ld2450-binary-sensors:
@@ -88,6 +85,20 @@ Configuration variables:
- **has_still_target** (*Optional*): True if a still target is detected.
All options from :ref:`Binary Sensor `.
+.. note::
+
+ By default, each of the :doc:`Binary Sensor ` components above includes the
+ following :ref:`filter` by default to prevent flooding Home Assistant with state updates:
+
+ .. code-block:: yaml
+
+ - settle: 1000ms
+
+ If you have defined other filters, this default will be overridden; you may of course add it back to your custom
+ filter(s) as above if you wish.
+
+ To remove the default filter for any given binary sensor instance, add ``filters: []`` to its configuration.
+
.. _ld2450-sensors:
Sensor
@@ -206,6 +217,23 @@ Configuration variables:
- **moving_target_count** (*Optional*, int): Count of moving targets in the zone. All options from
:ref:`Sensor `.
+.. note::
+
+ By default, each of the :doc:`Sensor ` components above includes the following
+ :ref:`filters` by default to prevent flooding Home Assistant with state updates:
+
+ .. code-block:: yaml
+
+ - timeout:
+ timeout: 1s
+ value: last
+ - throttle_with_priority: 1000ms
+
+ If you have defined other filters, this default will be overridden; you may of course add it back to your custom
+ filter(s) as above if you wish.
+
+ To remove the default filters for any given sensor instance, add ``filters: []`` to its configuration.
+
.. _ld2450-switch:
Switch
diff --git a/components/sensor/packet_transport.rst b/components/sensor/packet_transport.rst
index 1dd91ff757..15cc6871e3 100644
--- a/components/sensor/packet_transport.rst
+++ b/components/sensor/packet_transport.rst
@@ -20,8 +20,8 @@ It requires a ``packet_transport`` component to be configured.
packet_transport:
- platform: ...
-Configuration variables
------------------------
+Configuration variables:
+------------------------
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
- **provider** (**Required**, string): The name of the provider node.
diff --git a/components/sensor/sensor-filter-delta.rst b/components/sensor/sensor-filter-delta.rst
index 70142f61da..3ef57e8c95 100644
--- a/components/sensor/sensor-filter-delta.rst
+++ b/components/sensor/sensor-filter-delta.rst
@@ -7,7 +7,7 @@ This difference can be calculated in two ways an absolute difference or a percen
If a number is specified, it will be used as the absolute difference required.
For example if the filter were configured with a value of 2 and the last value passed through was 10,
-only values greater than 12 or less than 8 would be passed through.
+only values greater than or equal to 12 or less than or equal to 8 would be passed through.
.. code-block:: yaml
@@ -16,8 +16,9 @@ only values greater than 12 or less than 8 would be passed through.
If a percentage is specified a percentage of the last value will be used as the required difference.
For example if the filter were configured with a value of 20% and the last value passed through was 10,
-only values greater than 12 or less than 8 would be passed through.
-However, if the last value passed through was 100 only values greater than 120 or less than 80 would be passed through.
+only values greater than or equal to 12 or less than or equal to 8 would be passed through.
+However, if the last value passed through was 100 only values greater than or equal to 120 or less than or
+equal to 80 would be passed through.
.. code-block:: yaml
diff --git a/components/sensor/sensor-filter-throttle_with_priority.rst b/components/sensor/sensor-filter-throttle_with_priority.rst
new file mode 100644
index 0000000000..86a93f6923
--- /dev/null
+++ b/components/sensor/sensor-filter-throttle_with_priority.rst
@@ -0,0 +1,17 @@
+``throttle_with_priority``
+**************************
+
+Throttle the incoming values unless they match a prioritized value. When this filter gets an incoming value, it first
+checks if it matches one of the prioritized values. If so, the value is passed through immediately. Otherwise, it
+checks if the last incoming value is at least ``specified time period`` old. If it is not older than the configured
+value, the value is not passed forward.
+
+.. code-block:: yaml
+
+ # Example filters:
+ filters:
+ - throttle_with_priority:
+ timeout: 1s
+ value:
+ - nan
+ - 0
diff --git a/components/sensor/sensor-filter-timeout.rst b/components/sensor/sensor-filter-timeout.rst
index 2986e8f1b6..1327291b41 100644
--- a/components/sensor/sensor-filter-timeout.rst
+++ b/components/sensor/sensor-filter-timeout.rst
@@ -1,10 +1,14 @@
``timeout``
-************
+***********
-After the first value has been sent, if no subsequent value is published within the
-``specified time period``, send a templatable value which defaults to ``NaN``.
-Especially useful when data is derived from some other communication
-channel, e.g. a serial port, which can potentially be interrupted.
+After the first value has been sent, if no subsequent value is published within the specified ``timeout`` period, send
+a templatable value which defaults to ``NaN``. The value may also be set to ``last``, which will result in the last
+value received by the filter being sent again.
+
+This filter particularly is useful when:
+
+- data is derived from some communication channel (a serial port, for example) which can potentially be interrupted.
+- placed ahead of a throttle filter to ensure that the last value published will pass through the throttle.
.. code-block:: yaml
@@ -14,4 +18,6 @@ channel, e.g. a serial port, which can potentially be interrupted.
- timeout:
timeout: 10s
value: !lambda return 0;
-
+ - timeout:
+ timeout: 10s
+ value: last # sent value will be the last value received by the filter
diff --git a/components/substitutions.rst b/components/substitutions.rst
index 30dee90532..b1e9983947 100644
--- a/components/substitutions.rst
+++ b/components/substitutions.rst
@@ -87,7 +87,7 @@ Lists can be indexed: ``${ unused_pins[2] }``
scale: 1.5
sensor_pin:
number: 3
- inverted: true
+ inverted: true
debug_label:
width: 200
height: 20
@@ -114,7 +114,7 @@ Lists can be indexed: ``${ unused_pins[2] }``
name: Binary sensor on pin ${sensor_pin.number}
pin: ${sensor_pin}
-Note that in other projects Jinja uses the ``{{ ... }}`` syntax for expression delimiters.
+Note that in other projects Jinja uses the ``{{ ... }}`` syntax for expression delimiters.
In ESPHome we have configured Jinja to use ``${...}`` instead, so it is the same as the
existing substitution syntax and to avoid conflicts with Home Assistant's own use of Jinja.
@@ -142,6 +142,15 @@ library is exposed as a module:
To see what mathematical functions ara available,
refer to `Python math library `_ documentation.
+Built-in functions
+^^^^^^^^^^^^^^^^^^
+
+In addition to the Jinja expressions, ESPHome supports a number of built-in functions that can be used in substitutions.
+
+- ``ord`` Returns the Unicode code point for a given character. Example: ``ord("A") == 65``
+- ``chr`` Returns the character for a given Unicode code point. Example: ``chr(65) == "A"``
+- ``len`` Returns the length of the string. Example: ``len("Hello") == 5``
+
.. _substitute-include-variables:
Substitute !include variables
diff --git a/components/switch/factory_reset.rst b/components/switch/factory_reset.rst
index 71c870448a..a437f12a34 100644
--- a/components/switch/factory_reset.rst
+++ b/components/switch/factory_reset.rst
@@ -40,6 +40,7 @@ Configuration variables:
See Also
--------
+- :doc:`/components/factory_reset`
- :doc:`shutdown`
- :doc:`restart`
- :doc:`safe_mode`
diff --git a/components/switch/index.rst b/components/switch/index.rst
index 002570d6ca..50f0a6b6f3 100644
--- a/components/switch/index.rst
+++ b/components/switch/index.rst
@@ -110,6 +110,34 @@ This action turns a switch with the given ID off when executed.
then:
- switch.turn_off: relay_1
+.. _switch-control_action:
+
+``switch.control`` Action
+*************************
+
+This action allows you to control a switch with more flexibility than the basic ``turn_on`` and ``turn_off`` actions.
+It accepts a templatable ``state`` parameter, making it useful when the desired switch state is determined dynamically.
+
+.. code-block:: yaml
+
+ on_...:
+ then:
+ - switch.control:
+ id: relay_1
+ state: true
+
+ # Or with a template
+ - switch.control:
+ id: relay_1
+ state: !lambda |-
+ return id(some_sensor).state > 50.0;
+
+Configuration variables:
+
+- **id** (**Required**, :ref:`config-id`): The ID of the switch to control.
+- **state** (**Required**, boolean, :ref:`templatable `):
+ The state to set the switch to. ``true`` turns the switch on, ``false`` turns it off.
+
.. _switch-is_on_condition:
.. _switch-is_off_condition:
@@ -196,6 +224,36 @@ ON/OFF itself).
on_turn_off:
- logger.log: "Switch Turned Off!"
+.. _switch-on_state_trigger:
+
+``switch.on_state`` Trigger
+***************************
+
+This trigger is activated each time the switch changes state (either ON or OFF).
+It provides the new state as a boolean variable ``x`` that can be used in the automation.
+
+.. code-block:: yaml
+
+ switch:
+ - platform: gpio # or any other platform
+ # ...
+ on_state:
+ - light.control:
+ id: my_light
+ state: !lambda return x;
+ - if:
+ condition:
+ lambda: 'return x;'
+ then:
+ - logger.log: "Switch is now ON!"
+ else:
+ - logger.log: "Switch is now OFF!"
+
+The variable ``x`` is a boolean that represents the new state:
+
+- ``true`` when the switch turns ON
+- ``false`` when the switch turns OFF
+
See Also
--------
diff --git a/components/sx127x.rst b/components/sx127x.rst
index c89244bb6d..7bd94b3e55 100644
--- a/components/sx127x.rst
+++ b/components/sx127x.rst
@@ -367,7 +367,6 @@ the pin should be driven low before ``set_mode_tx`` and pulled high / released b
pa_power: 17
remote_receiver:
- id: rx_id
pin:
number: GPIO32
mode:
@@ -379,7 +378,6 @@ the pin should be driven low before ``set_mode_tx`` and pulled high / released b
dump: raw
remote_transmitter:
- id: tx_id
pin:
number: GPIO32
mode:
@@ -393,12 +391,12 @@ the pin should be driven low before ``set_mode_tx`` and pulled high / released b
on_transmit:
then:
- sx127x.set_mode_standby
- - lambda: 'id(tx_id)->digital_write(false);'
+ - remote_transmitter.digital_write: false
- sx127x.set_mode_tx
on_complete:
then:
- sx127x.set_mode_standby
- - lambda: 'id(tx_id)->digital_write(true);'
+ - remote_transmitter.digital_write: true
- sx127x.set_mode_rx
button:
diff --git a/components/udp.rst b/components/udp.rst
index 41a8aee6ba..1bc8d1f39c 100644
--- a/components/udp.rst
+++ b/components/udp.rst
@@ -37,8 +37,8 @@ UDP, like any other network protocol, does not provide a guarantee that data wil
even provide any indication whether data has been successfully delivered or not.
-Write Action
-------------
+``udp.write`` Action
+--------------------
To write data to the UDP port, use the ``udp.write`` action. This action takes a single argument, the data to write to the UDP port.
diff --git a/components/wifi.rst b/components/wifi.rst
index 75d2a82092..7b5232d86c 100644
--- a/components/wifi.rst
+++ b/components/wifi.rst
@@ -81,9 +81,10 @@ Configuration variables:
- **output_power** (*Optional*, string): The amount of TX power for the WiFi interface from 8.5dB to 20.5dB. Default for ESP8266 is 20dB, 20.5dB might cause unexpected restarts.
- **fast_connect** (*Optional*, boolean): If enabled, directly connects to WiFi network without doing a full scan
- first. This is required for hidden networks and can significantly improve connection times. Defaults to ``off``.
+ first. This is required for hidden networks and can significantly improve connection times (thus reducing power consumption). Defaults to ``off``.
The downside is that this option connects to the first network the ESP sees, even if that network is very far away and
- better ones are available.
+ better ones are available. If multiple networks are configured, the last successfully connected one is tested first.
+ In case it fails, all networks are then tested one after the other in their declared order, starting with the first one in the list.
- **passive_scan** (*Optional*, boolean): If enabled, then the device will perform WiFi scans in a passive fashion. Defaults to ``false``.
- **enable_btm** (*Optional*, bool): Only on ``esp32`` with ``esp-idf``. Enable 802.11v BSS Transition Management support.
@@ -92,7 +93,7 @@ Configuration variables:
- **on_connect** (*Optional*, :ref:`Automation `): An action to be performed when a connection is established.
- **on_disconnect** (*Optional*, :ref:`Automation `): An action to be performed when the connection is dropped.
- **enable_on_boot** (*Optional*, boolean): If enabled, the WiFi interface will be enabled on boot. Defaults to ``true``.
-
+- **use_psram** (*Optional*, boolean): For ESP32 only, requests that the WiFi libraries try to allocate memory from PSRAM. Defaults to ``false``. Requires PSRAM to be configured.
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
Access Point Mode
diff --git a/conf.py b/conf.py
index 41860d7bee..4b1440970f 100644
--- a/conf.py
+++ b/conf.py
@@ -71,9 +71,9 @@
# built documents.
#
# The short X.Y version.
-version = "2025.7"
+version = "2025.8"
# The full version, including alpha/beta/rc tags.
-release = "2025.7.5"
+release = "2025.8.0b1"
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
diff --git a/cookbook/lambda_magic.rst b/cookbook/lambda_magic.rst
index fededae084..67f41c5211 100644
--- a/cookbook/lambda_magic.rst
+++ b/cookbook/lambda_magic.rst
@@ -284,74 +284,6 @@ will return ``NaN``, which corresponds to ``unknown`` sensor state.
name: "Number from text"
-Factory reset after 5 quick reboots
------------------------------------
-
-One may want to restore factory settings (like Wi-Fi credentials set at runtime, or clear restore states) without having to
-disassemble or dismount the devices from their deployed location, whilst there's no network access either. The example below
-shows how to achieve that using lambdas in a script by triggering the factory reset switch after the system rebooted 5 times
-with 10-second timeframes.
-
-.. code-block:: yaml
-
- # Example config.yaml
- esphome:
- name: "esphome_ld2410"
- on_boot:
- priority: 600.0
- then:
- - script.execute: fast_boot_factory_reset_script
- esp32:
- board: esp32-c3-devkitm-1
-
- substitutions:
- factory_reset_boot_count_trigger: 5
-
- globals:
- - id: fast_boot
- type: int
- restore_value: yes
- initial_value: '0'
-
- script:
- - id: fast_boot_factory_reset_script
- then:
- - if:
- condition:
- lambda: return ( id(fast_boot) >= ${factory_reset_boot_count_trigger});
- then:
- - lambda: |-
- ESP_LOGD("Fast Boot Factory Reset", "Performing factotry reset");
- id(fast_boot) = 0;
- fast_boot->loop();
- global_preferences->sync();
- - button.press: factory_reset_button
- - lambda: |-
- if(id(fast_boot) > 0)
- ESP_LOGD("Fast Boot Factory Reset", "Quick reboot %d/%d, do it %d more times to factory reset", id(fast_boot), ${factory_reset_boot_count_trigger}, ${factory_reset_boot_count_trigger} - id(fast_boot));
- id(fast_boot) += 1;
- fast_boot->loop();
- global_preferences->sync();
- - delay: 10s
- - lambda: |-
- id(fast_boot) = 0;
- fast_boot->loop();
- global_preferences->sync();
-
- wifi:
- id: wifi_component
- ap:
- ap_timeout: 0s
- reboot_timeout: 0s
-
- captive_portal:
-
- button:
- - platform: factory_reset
- id: factory_reset_button
- name: "ESPHome: Factory reset"
-
-
See Also
--------
diff --git a/guides/cli.rst b/guides/cli.rst
index e4e412a4dc..74359adae5 100644
--- a/guides/cli.rst
+++ b/guides/cli.rst
@@ -75,6 +75,16 @@ The ``esphome run `` command is the most common command for ESPHome. It
Manually specify the upload port/IP to use. For example ``/dev/cu.SLAB_USBtoUART``, or ``192.168.1.176``
to perform an OTA.
+
+ Multiple ``--device`` options can be specified to provide fallback addresses. ESPHome will
+ try each address in order until one succeeds. This is particularly useful for devices with
+ multiple IP addresses (IPv4/IPv6).
+
+ Example:
+
+ .. code-block:: console
+
+ esphome run my-device.yaml --device 192.168.1.100 --device 2001:db8::1
.. option:: --upload_speed BAUD_RATE
@@ -141,6 +151,15 @@ The ``esphome upload `` validates the configuration and uploads the most
Manually specify the upload port/IP address to use. For example ``/dev/cu.SLAB_USBtoUART``, or ``192.168.1.176``
to perform an OTA.
+
+ Multiple ``--device`` options can be specified to provide fallback addresses. ESPHome will
+ try each address in order until one succeeds.
+
+ Example:
+
+ .. code-block:: console
+
+ esphome upload my-device.yaml --device 192.168.1.100 --device 2001:db8::1
.. option:: --upload_speed BAUD_RATE
@@ -267,6 +286,16 @@ The ``esphome logs `` command validates the configuration and shows all
.. option:: --device SERIAL_PORT
Manually specify a serial port/IP to use. For example ``/dev/cu.SLAB_USBtoUART``.
+
+ Multiple ``--device`` options can be specified to provide fallback addresses. When using the
+ native API for logs, all addresses are passed to the API client which uses the Happy Eyeballs
+ algorithm (RFC 8305) to efficiently connect using the fastest available address.
+
+ Example:
+
+ .. code-block:: console
+
+ esphome logs my-device.yaml --device 192.168.1.100 --device 2001:db8::1
.. option:: --reset
diff --git a/guides/esp32_arduino_to_idf.rst b/guides/esp32_arduino_to_idf.rst
new file mode 100644
index 0000000000..83f34a3fcc
--- /dev/null
+++ b/guides/esp32_arduino_to_idf.rst
@@ -0,0 +1,208 @@
+ESP32 Arduino to ESP-IDF Migration Guide
+=========================================
+
+.. seo::
+ :description: Guide for migrating ESP32 devices from Arduino framework to ESP-IDF
+ :image: esp32.svg
+
+Starting with ESPHome 2026.1.0, the default framework for ESP32 will change from Arduino to ESP-IDF. This guide will help you migrate your existing configurations or make an informed choice about which framework to use.
+
+.. note::
+
+ This change only affects ESP32, ESP32-S2, ESP32-S3, and ESP32-C3 variants.
+ Newer variants (ESP32-C6, ESP32-H2, ESP32-P4, etc.) already default to ESP-IDF
+ as they have limited or no Arduino support.
+
+Why the Change?
+---------------
+
+ESP-IDF (Espressif IoT Development Framework) is the official development framework for ESP32. It offers several advantages:
+
+- **Smaller Binaries**: Up to 40% reduction in binary size
+- **Better Performance**: More optimized for ESP32 hardware
+- **Custom Builds**: Firmware is built specifically for your device configuration
+- **Active Development**: All ESPHome developers use and test with ESP-IDF
+- **Latest Features**: New ESP32 features are available in ESP-IDF first
+
+Trade-offs
+----------
+
+While ESP-IDF offers many benefits, there are some trade-offs to consider:
+
+- **Compile Times**: Initial compilation takes approximately 25% longer
+- **Component Compatibility**: Some components may need to be replaced with ESP-IDF compatible alternatives
+- **Library Differences**: Arduino-specific libraries won't be available
+
+Making Your Choice
+------------------
+
+Option 1: Migrate to ESP-IDF (Recommended)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Add the following to your ESP32 configuration:
+
+.. code-block:: yaml
+
+ esp32:
+ board: esp32dev # Your board type
+ framework:
+ type: esp-idf
+
+Option 2: Stay with Arduino
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you prefer to continue using Arduino (which will remain supported), explicitly specify it:
+
+.. code-block:: yaml
+
+ esp32:
+ board: esp32dev # Your board type
+ framework:
+ type: arduino
+
+Migration Steps
+---------------
+
+1. **Backup Your Configuration**: Always keep a backup of your working configuration before making changes.
+
+2. **Check Component Compatibility**: When you compile with ESP-IDF, ESPHome will automatically notify you if any components are incompatible and suggest alternatives.
+
+3. **Update Your Configuration**: Add the framework specification as shown above.
+
+4. **Clean Build Files**: After changing frameworks, clean your build files:
+
+ **Using ESPHome CLI:**
+
+ .. code-block:: bash
+
+ esphome clean your-config.yaml
+
+ **Using ESPHome Dashboard:**
+
+ - Click on the three-dot menu for your device
+ - Select "Clean Build Files"
+
+5. **Compile and Test**: Compile your configuration and test thoroughly:
+
+ **Using ESPHome CLI:**
+
+ .. code-block:: bash
+
+ esphome compile your-config.yaml
+ esphome upload your-config.yaml
+
+ **Using ESPHome Dashboard:**
+
+ - Click "INSTALL" on your device
+ - Choose your preferred upload method (USB, OTA, etc.)
+ - The dashboard will automatically compile and upload
+
+Common Component Replacements
+-----------------------------
+
+When migrating to ESP-IDF, you may need to replace some components. ESPHome will automatically suggest alternatives when available:
+
+**Components with ESP-IDF Alternatives:**
+
+.. list-table::
+ :header-rows: 1
+ :widths: 50 50
+
+ * - Arduino Component
+ - ESP-IDF Alternative
+ * - :doc:`bme680_bsec `
+ - :doc:`bme68x_bsec2 `
+ * - :doc:`fastled_clockless `
+ - :doc:`esp32_rmt_led_strip `
+ * - :doc:`fastled_spi `
+ - :doc:`spi_led_strip `
+ * - :doc:`neopixelbus `
+ - :doc:`esp32_rmt_led_strip `
+
+**Arduino-Only Components:**
+
+The following components currently require Arduino framework and don't have ESP-IDF alternatives yet:
+
+- :doc:`ac_dimmer ` - AC dimmer control
+- :doc:`dsmr ` - Dutch Smart Meter integration
+- :doc:`heatpumpir ` - IR-based heat pump control
+- :doc:`midea ` - Midea air conditioner control
+- :doc:`WLED Effect ` - WLED UDP Realtime Control integration
+
+If you need these components, you should continue using the Arduino framework.
+
+.. note::
+
+ Component compatibility is constantly improving. Check the component documentation
+ or try compiling with ESP-IDF to see if alternatives have become available.
+
+Troubleshooting
+---------------
+
+Compilation Errors
+^^^^^^^^^^^^^^^^^^
+
+If you encounter compilation errors after switching to ESP-IDF:
+
+1. Check the error message for component compatibility issues
+2. Look for suggested alternatives in the error output
+3. Clean your build files and try again
+4. Check the component documentation for ESP-IDF specific notes
+
+Build Time
+^^^^^^^^^^
+
+ESP-IDF compilation takes approximately 25% longer than Arduino:
+
+- On modern desktop systems: ~15-30 seconds additional time
+- On Raspberry Pi 5: ~1 minute additional time
+- On Raspberry Pi 4 or older: 3-5 minutes additional time
+- Subsequent builds are faster but still proportionally slower
+- The longer build time is due to ESP-IDF's more comprehensive optimization process
+
+Performance Considerations
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ESP-IDF generally offers better performance, but:
+
+- Initial boot time might be slightly different
+- Some timing-sensitive operations may need adjustment
+- WiFi and Bluetooth behavior might have subtle differences
+
+Frequently Asked Questions
+--------------------------
+
+**Q: Will Arduino framework be removed?**
+ A: No, Arduino framework will continue to be supported. Only the default is changing.
+
+**Q: Do I have to migrate immediately?**
+ A: No, but you should explicitly specify your framework choice to avoid the automatic change in 2026.1.0.
+
+**Q: Can I switch back to Arduino if ESP-IDF doesn't work for me?**
+ A: Yes, you can switch between frameworks at any time by changing your configuration.
+
+**Q: Will my existing devices be affected?**
+ A: Only when you recompile. Devices already running will continue to work as before.
+
+**Q: How do I know which framework my device is currently using?**
+ A: Check your device's log output during boot, or look at your configuration file.
+
+Getting Help
+------------
+
+If you encounter issues during migration:
+
+1. Check the `ESPHome Discord `__ for community support
+2. Review component-specific documentation
+3. Search existing `GitHub issues `__
+4. Create a new issue if you find a bug
+
+Remember, the migration is optional, and both frameworks will continue to be supported. Choose the option that best fits your needs!
+
+See Also
+--------
+
+- :doc:`/components/esp32`
+- :doc:`/guides/faq`
+- `ESP-IDF Documentation `__
+- `Arduino-ESP32 Documentation `__
diff --git a/guides/installing_esphome.rst b/guides/installing_esphome.rst
index 79a393a3f2..ba8d99c906 100644
--- a/guides/installing_esphome.rst
+++ b/guides/installing_esphome.rst
@@ -28,7 +28,7 @@ It should show something like:
.. code-block:: console
- Python 3.10.1
+ Python 3.11.13
Looks good? You can go ahead and install ESPHome:
@@ -48,7 +48,7 @@ It should show something like:
.. code-block:: console
- Version: 2025.5.2
+ Version: 2025.8.0
.. note::
@@ -84,7 +84,7 @@ It should show something like:
.. code-block:: console
- Version: 2025.5.2
+ Version: 2025.8.0
@@ -93,18 +93,18 @@ It should show something like:
- If you encounter any issues with Homebrew installation, please check the
`ESPHome Homebrew Formula `_ page
for additional information.
- - Homebrew may not always provide the latest version immediately. Updating Homebrew will
- automatically update ESPHome. If this is ok for you, Homebrew is the easiest way to
+ - Homebrew may not always provide the latest version immediately. Updating Homebrew will
+ automatically update ESPHome. If this is ok for you, Homebrew is the easiest way to
install ESPHome.
**pip**
For the latest version, use the pip installation. This may be more difficult to set up
-and may need additional dependencies and path settings. Setting up a virtual environment is
+and may need additional dependencies and path settings. Setting up a virtual environment is
highly recommended. If you are not familiar with Python virtual environments, Homebrew
may be easier.
-You will require Python 3.10 or newer. While your Mac may have a version of Python installed it may not be up-to-date.
+You will require Python 3.11 or newer. While your Mac may have a version of Python installed it may not be up-to-date.
Python can be installed from the `official site `_
or with Homebrew. Once Python is installed, create and activate a virtual environment and install ESPHome with pip:
@@ -126,7 +126,7 @@ Linux
-----
Your distribution probably already has Python installed. Confirm that it is at
-least version 3.10:
+least version 3.11:
.. code-block:: console
@@ -136,7 +136,7 @@ It should show something like:
.. code-block:: console
- Python 3.10.1
+ Python 3.11.13
Looks good? Now create a virtual environment to contain ESPHome and it's dependencies.
@@ -176,7 +176,7 @@ It should show something like:
.. code-block:: console
- Version: 2025.5.2
+ Version: 2025.8.0
If you get an error like "Command not found", you need to add the binary to
your ``PATH`` using ``export PATH=$PATH:$HOME/.local/bin``.
diff --git a/guides/supporters.rst b/guides/supporters.rst
index 11620f2108..16949b0ee6 100644
--- a/guides/supporters.rst
+++ b/guides/supporters.rst
@@ -94,6 +94,7 @@ Contributors
- `Alex Iribarren (@alexiri) `__
- `alexmaurer-madis (@alexmaurer-madis) `__
- `Alex Mekkering (@AlexMekkering) `__
+- `Alexander Pertrovichev (@alexup4it) `__
- `Alex (@alexyao2015) `__
- `Alfredo (@alfredopironti) `__
- `Alibloke (@Alibloke) `__
@@ -276,6 +277,7 @@ Contributors
- `Borja Burgos (@borjaburgos) `__
- `Brian Orpin (@borpin) `__
- `BoukeHaarsma23 (@BoukeHaarsma23) `__
+- `Bpgoa (@Bpgoa) `__
- `Patrik Hermansson (@bphermansson) `__
- `brabl2 (@brabl2) `__
- `brainiac27 (@brainiac27) `__
@@ -533,6 +535,7 @@ Contributors
- `Dirk Heinke (@DirkHeinke) `__
- `Dirk Jahnke (@dirkj) `__
- `Dennis (@dirrgang) `__
+- `Stian Knudsen (@dislabled) `__
- `Andrea Casini (@ditadipolvere08) `__
- `Johann V. (@divinitas) `__
- `dj-bauer (@dj-bauer) `__
@@ -552,6 +555,7 @@ Contributors
- `DominikBitzer (@DominikBitzer) `__
- `Dominik (@DomiStyle) `__
- `Don Burch (@donburch888) `__
+- `Chris Beswick (@doobry) `__
- `Derek M. (@doolbneerg) `__
- `Dorian Zedler (@dorianim) `__
- `Mark Dietzer (@Doridian) `__
@@ -915,6 +919,7 @@ Contributors
- `Jouni Paulus (@j-paulus) `__
- `J0RD4N300 (@J0RD4N300) `__
- `Jacob Carrell (@JacobCarrell) `__
+- `Tim Jacobs (@jacobstim) `__
- `jacobswe (@jacobswe) `__
- `Fredrik Gustafsson (@jagheterfredrik) `__
- `Jan Harkes (@jaharkes) `__
@@ -1241,6 +1246,7 @@ Contributors
- `Piotr Majkrzak (@majkrzak) `__
- `Major Péter (@majorpeter) `__
- `Dmitry (@mak-42) `__
+- `Max Slotov (@makstech) `__
- `Kasper Malfroid (@malfroid) `__
- `Malle355 (@Malle355) `__
- `raymonder jin (@mamil) `__
@@ -1853,6 +1859,7 @@ Contributors
- `Dennis Skinner (@Skinner927) `__
- `Brian Slesinsky (@skybrian) `__
- `Jordan W. Cobb (@skykingjwc) `__
+- `Alex-Yves CREPIN (@Slicit) `__
- `slimeinacloak (@slimeinacloak) `__
- `Sebastian Lövdahl (@slovdahl) `__
- `SmartbobAutomatyka (@SmartbobAutomatyka) `__
@@ -2200,4 +2207,4 @@ Contributors
- `Christian Zufferey (@zuzu59) `__
- `Zynth-dev (@Zynth-dev) `__
-*This page was last updated August 5, 2025.*
+*This page was last updated August 13, 2025.*
diff --git a/guides/troubleshooting.rst b/guides/troubleshooting.rst
index e0893dbb7a..dfc9d362aa 100644
--- a/guides/troubleshooting.rst
+++ b/guides/troubleshooting.rst
@@ -112,10 +112,23 @@ If you already have a stack trace but need to decode it, you can use the `ESP St
This tool runs entirely in your browser - no data is sent to any server, ensuring your firmware and debug information remain private.
+Performance Troubleshooting
+---------------------------
+
+If your device is experiencing performance issues such as:
+
+- Slow response times
+- Missed sensor readings
+- Connectivity problems
+- Components not updating as expected
+
+The :doc:`/components/runtime_stats` component can help identify which components are consuming the most processing time or blocking the event loop. See the runtime_stats documentation for detailed usage instructions and examples.
+
See Also
--------
- :doc:`/components/logger` - Configure logging levels and outputs
- :doc:`/components/debug` - Debug component for additional diagnostics
+- :doc:`/components/runtime_stats` - Performance analysis and debugging
- :doc:`/components/safe_mode` - Safe Mode recovery guide
- :doc:`/guides/faq` - Frequently asked questions
diff --git a/images/esp-now.svg b/images/esp-now.svg
new file mode 100644
index 0000000000..da79da804d
--- /dev/null
+++ b/images/esp-now.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/images/ld2412.jpg b/images/ld2412.jpg
new file mode 100644
index 0000000000..8cfaef826f
Binary files /dev/null and b/images/ld2412.jpg differ
diff --git a/images/nrf52.svg b/images/nrf52.svg
new file mode 100644
index 0000000000..61c6962f94
--- /dev/null
+++ b/images/nrf52.svg
@@ -0,0 +1 @@
+
diff --git a/images/tab5.jpg b/images/tab5.jpg
new file mode 100644
index 0000000000..2066562b4d
Binary files /dev/null and b/images/tab5.jpg differ
diff --git a/schema_doc.py b/schema_doc.py
index beb9ca00e3..0486c426e9 100644
--- a/schema_doc.py
+++ b/schema_doc.py
@@ -150,6 +150,9 @@ def doctree_resolved(app, doctree, docname):
"components/output/index": {
"Base Output Configuration": "output.schemas.FLOAT_OUTPUT_SCHEMA",
},
+ "components/packet_transport/index": {
+ "Packet Transport Component": "packet_transport.schemas.TRANSPORT_SCHEMA",
+ },
"components/remote_transmitter": {
"Remote Transmitter Actions": "remote_base.schemas.BASE_REMOTE_TRANSMITTER_SCHEMA",
},
@@ -760,17 +763,19 @@ def depart_title(self, node):
self.previous_title_text = node.astext()
self.title_id = node.parent["ids"][0]
- def find_props_previous_title(self):
+ def find_props_previous_title(self, fail_silently=False):
comp = self.json_component or self.json_platform_component
if comp:
- props = self.find_props(comp)
+ props = self.find_props(comp, fail_silently)
if self.previous_title_text in props:
prop = props[self.previous_title_text]
if prop:
- self.props = self.find_props(prop)
+ self.props = self.find_props(prop, fail_silently)
else:
# return fake dict so better errors are printed
+ if fail_silently:
+ return # do not lose original props
self.props = {"__": "none"}
def visit_Text(self, node):
@@ -836,7 +841,7 @@ def visit_list_item(self, node):
self.filled_props = True
self.current_prop, found = self.update_prop(node, self.props)
if self.current_prop and not found:
- self.find_props_previous_title()
+ self.find_props_previous_title(True)
self.current_prop, found = self.update_prop(node, self.props)
if self.current_prop and not found:
logger.info(