Merge branch 'next' into feat/add-support-for-wts01

swoboda1337 · web-flow · commit 0edb4d097edb · 2025-09-23T22:14:03.000-04:00
diff --git a/content/changelog/2025.9.0.md b/content/changelog/2025.9.0.md
@@ -21,6 +21,7 @@ developer tools while maintaining backward compatibility for most use cases.
 **Key Highlights:**
 
 - **MIPI RGB Display support** for high-performance color displays with dedicated hardware acceleration
+- **ESPHome Builder improvements** with support for uploading existing YAML files and blank configurations
 - **Camera JPEG encoder** enabling efficient image compression and streaming capabilities  
 - **Enhanced NRF52 features** including DFU (Device Firmware Update) support
 - **Extensive memory optimizations** reducing flash and RAM usage across all platforms
@@ -62,6 +63,15 @@ ESPHome 2025.9.0 introduces comprehensive support for MIPI RGB displays through
 MIPI RGB displays offer superior performance for applications requiring high-quality graphics, smooth animations, and
 professional-grade user interfaces.
 
+## ESPHome Builder Enhancements
+
+The ESPHome Builder web interface now offers improved flexibility for getting started with your projects:
+
+**New Capabilities:**
+
+- **Upload existing YAML files** to continue working on configurations created elsewhere
+- **Start with a blank configuration** for complete customization from scratch
+
 ## Camera JPEG Encoder
 
 The new {{< docref "/components/camera/camera_encoder" >}} component adds efficient JPEG compression capabilities to
@@ -148,6 +158,18 @@ and advanced setups may require updates.
 
 <!-- markdownlint-disable MD013 -->
 
+## Release 2025.9.1 - September 19
+
+<details>
+<summary></summary>
+
+- [mqtt] Fix KeyError when MQTT logging configured without explicit level [esphome#10774](https://github.com/esphome/esphome/pull/10774) by [@bdraco](https://github.com/bdraco)
+- fix(packet_transport): Add initialization for sensor configuration in packet transport [esphome#10765](https://github.com/esphome/esphome/pull/10765) by [@TMaYaD](https://github.com/TMaYaD)
+- [core] Fix ESP8266 mDNS compilation failure caused by incorrect coroutine priorities [esphome#10773](https://github.com/esphome/esphome/pull/10773) by [@bdraco](https://github.com/bdraco)
+- [gpio] Fix unused function warnings when compiling with log level below DEBUG [esphome#10779](https://github.com/esphome/esphome/pull/10779) by [@bdraco](https://github.com/bdraco)
+
+</details>
+
 ## Full list of changes
 
 ### New Features
diff --git a/content/components/_index.md b/content/components/_index.md
@@ -1050,6 +1050,7 @@ ESPHome to cellular networks. **Does not encompass Wi-Fi.**
 "Status LED","components/status_led","led-on.svg","dark-invert"
 "Sun","components/sun","weather-sunny.svg","dark-invert"
 "Tuya MCU","components/tuya","tuya.png",""
+"Z-Wave Proxy","components/zwave_proxy","z-wave.svg",""
 {{< /imgtable >}}
 
 ## Cookbook
diff --git a/content/components/bluetooth_proxy.md b/content/components/bluetooth_proxy.md
@@ -51,10 +51,9 @@ bluetooth_proxy:
 ```
 
 - **active** (*Optional*, boolean): Enables proxying active connections. Defaults to `true`.
-- **cache_services** (*Optional*, boolean): Enables caching GATT services in NVS flash storage which significantly speeds up active connections. Defaults to `true` when using the ESP-IDF framework.
+- **cache_services** (*Optional*, boolean): Enables caching GATT services in NVS flash storage which significantly speeds up active connections. Defaults to `true`.
 - **connection_slots** (*Optional*, int): The maximum number of BLE connection slots to use.
-  Each configured slot consumes ~1KB of RAM. This can only be adjusted when using
-  the `esp-idf` framework up to a maximum of `9`. It is recommended not to exceed `5`
+  Each configured slot consumes ~1KB of RAM, with a maximum of `9`. It is recommended not to exceed `5`
   connection slots to avoid memory issues. Defaults to `3`.
   The value must not exceed the total configured `max_connections`
   for {{< docref "esp32_ble_tracker/" >}}.
diff --git a/content/components/esp32_ble.md b/content/components/esp32_ble.md
@@ -54,7 +54,7 @@ The `disable_bt_logs` option intelligently disables only the Bluetooth logging c
 
 {{< /note >}}
 
-- **connection_timeout** (*Optional*, [Time](#config-time)): The maximum time to wait for a BLE connection to be established. Only available when using ESP-IDF framework. Defaults to `20s`.
+- **connection_timeout** (*Optional*, [Time](#config-time)): The maximum time to wait for a BLE connection to be established. 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
@@ -72,7 +72,7 @@ The `advertising` option is an advanced feature that manually enables BLE advert
 {{< /note >}}
 
 - **advertising_cycle_time** (*Optional*, [Time](#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`.
+- **max_notifications** (*Optional*, integer): The maximum number of BLE characteristics that can have notifications enabled across all connections. Defaults to `12`.
 
   - Range: 1 to 64
   - This is a global limit shared across all BLE connections
diff --git a/content/components/esp32_ble_tracker.md b/content/components/esp32_ble_tracker.md
@@ -99,8 +99,7 @@ you can use OTA updates again.
 - **id** (*Optional*, [ID](#config-id)): Manually specify the ID for this ESP32 BLE Hub.
 - **max_connections** (*Optional*, int): The maximum number of BLE connection slots to use.
   Each configured slot consumes ~1KB of RAM. It is recommended not to exceed `5`
-  connection slots to avoid memory issues. Defaults to `3`.
-  This can only be adjusted when using the `esp-idf` framework up to a maximum of `9`.
+  connection slots to avoid memory issues. Defaults to `3`, with a maximum of `9`.
   This value cannot exceed the total number of `connection_slots` for the
   {{< docref "bluetooth_proxy/" >}} component combined with the total
   configured {{< docref "ble_client/" >}} instances.
diff --git a/content/components/images/z-wave.svg b/content/components/images/z-wave.svg
@@ -0,0 +1 @@
+<svg viewBox="0 0 124 25" id="svg5" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"><defs id="defs9"/><path d="M5 0H119a5 5 0 015 5v15a5 5 0 01-5 5H5a5 5 0 01-5-5V5a5 5 0 015-5z" style="fill:#000" id="path2"/><g aria-label="Z-WAVE" id="component-text" style="font-weight:900;font-size:25px;font-family:Montserrat;letter-spacing:1.1px;fill:#fffffc"><path d="m5.8 21v-3.625l9.75-11.35.725 2.05H6.05V3.5H21.475V7.125l-9.75 11.35L11 16.425H21.875V21z" id="path11"/><path d="m24.400007 15.9v-4.25h7.5v4.25z" id="path13"/><path d="m39.224975 21-5.6-17.5h6.075l4.525 14.775h-3.05l4.8-14.775h5.425l4.475 14.775h-2.925l4.725-14.775h5.6l-5.6 17.5h-6.325l-3.65-12.1h1.7l-3.85 12.1z" id="path15"/><path d="m63.149935 21 7.65-17.5h5.8l7.65 17.5h-6.1l-5.65-14.7h2.3l-5.65 14.7zm4.55-3.05 1.5-4.25h8.05l1.5 4.25z" id="path17"/><path d="m90.799908 21-7.4-17.5h6.35l6.025 14.775h-3.775l6.2-14.775h5.800002L96.599908 21z" id="path19"/><path d="m111.07491 10h7.8v4.25h-7.8zm.4 6.55h8.75V21h-14.55V3.5h14.225v4.45h-8.425z" id="path21"/></g></svg>
diff --git a/content/components/substitutions.md b/content/components/substitutions.md
@@ -151,6 +151,21 @@ In addition to the Jinja expressions, ESPHome supports a number of built-in func
 
 {{< anchor "substitute-include-variables" >}}
 
+## Disabling Jinja and substitutions
+
+You can prevent ESPHome from substituting variables or processing Jinja by means of the `!literal` tag before any value:
+
+```yaml
+substitutions:
+  value: "Test Value"
+lvgl:
+  widgets:
+    - label:
+        text: !literal "This is a ${value}"
+```
+
+In the above example, the value of the `text` property will be, literally, `This is a ${value}`.
+
 ## Substitute !include variables
 
 ESPHome's `!include` accepts a list of variables that can be substituted within the included file.
diff --git a/content/components/touchscreen/ektf2232.md b/content/components/touchscreen/ektf2232.md
@@ -16,13 +16,13 @@ The [I²C](#i2c) is required to be set up in your configuration for this sensor
 touchscreen:
   - platform: ektf2232
     interrupt_pin: GPIOXX
-    rts_pin: GPIOXX
+    reset_pin: GPIOXX
 ```
 
 ## Configuration variables
 
 - **id** (*Optional*, [ID](#config-id)): Manually set the ID of this touchscreen.
-- **rts_pin** (*Optional*, [Pin Schema](#config-pin_schema)): The reset pin of the controller.
+- **reset_pin** (*Optional*, [Pin Schema](#config-pin_schema)): The reset pin of the controller.
 - **interrupt_pin** (*Optional*, [Pin Schema](#config-pin_schema)): The touch detection pin.
 
 - All other options from [Base Touchscreen Configuration](#config-touchscreen).
diff --git a/content/components/uart.md b/content/components/uart.md
@@ -65,10 +65,17 @@ uart:
 - **rx_pin** (*Optional*, [Pin](#config-pin)): The pin to receive data on from the ESP's perspective. Use the full pin
   schema and set `inverted: true` to invert logic levels. Not supported by host platform.
 
+- **flow_control_pin** (*Optional*, [Pin](#config-pin)): ESP32 only. The pin used to for hardware RS485 flow control.
+  Use of this setting enables half-duplex mode. Use the full pin schema and set `inverted: true` to invert logic levels.
+
 - **port** (*Optional*, string): Host platform only. Unix style name of the port to use.
 - **rx_buffer_size** (*Optional*, int): The size of the buffer used for receiving UART messages. Increase if you use an
   integration that needs to read big payloads from UART. Defaults to `256`.
 
+- **rx_full_threshold** (*Optional*, int): ESP32 only. After receiving this number of bytes, the data becomes available for processing.
+  The default is calculated at compilation time to be approximately ten milliseconds (about 8 bytes at 9600 baud, 114 bytes at 115200 baud).
+  
+- **rx_timeout** (*Optional*, int): ESP32 only. This value specifies a number of bytes used to determine the duration of the timeout. The duration of the timeout is based on the amount of time it would take to receive this number of bytes. In other words, for a given value and baud rate, doubling the baud rate will halve the duration of the timeout. After the timeout has elapsed, the data becomes available for processing. Defaults to ``2``.
 - **data_bits** (*Optional*, int): The number of data bits used on the UART bus. Options: 5 to 8. Defaults to 8.
 - **parity** (*Optional*): The parity used on the UART bus. Options: `NONE`, `EVEN`, `ODD`. Defaults to `NONE`.
 - **stop_bits** (*Optional*, int): The number of stop bits to send. Options: 1, 2. Defaults to 1.
@@ -88,8 +95,8 @@ be accurate at higher baud rates.
 logger and leave others available. If you have configured the logger to use a different hardware UART, the pins
 used for hardware sharing change accordingly.
 
-The ESP32 has three UARTs. ESP32 lite variant chips (ESP32-C3, ESP32-S2, ESP32-S3, etc) may have fewer UARTs
-(usually two). Any pair of GPIO pins can be used, as long as they support the proper output/input modes.
+The original ESP32 has three UARTs. ESP32 variants (ESP32-C3, ESP32-S2, etc.) may have a different number of UARTs
+(usually between two to six). Any pair of GPIO pins can be used, as long as they support the proper output/input modes.
 
 The ESP8266 has two UARTs; the second of which is TX-only. Only a limited set of pins can be used. `UART0` may
 use either `tx_pin: GPIO1` and `rx_pin: GPIO3`, or `tx_pin: GPIO15` and `rx_pin: GPIO13`. `UART1` must
@@ -213,6 +220,10 @@ Below are the methods to read current settings and modify them dynamically:
 ```cpp
     // RX buffer size
     id(my_uart).get_rx_buffer_size();
+    // RX FIFO full threshold
+    id(my_uart).get_rx_full_threshold();
+    // RX timeout
+    id(my_uart).get_rx_timeout();
     // Stop bits
     id(my_uart).get_stop_bits();
     // Data bits
@@ -261,11 +272,18 @@ Below are the methods to read current settings and modify them dynamically:
   Available methods for runtime changes:
 
 ```cpp
-    // Set TX/RX pins
+    // Set TX/RX/Flow control pins
     id(my_uart).set_tx_pin(InternalGPIOPin *tx_pin);
     id(my_uart).set_rx_pin(InternalGPIOPin *rx_pin);
+    id(my_uart).set_flow_control_pin(InternalGPIOPin *flow_control_pin);
     // RX buffer size
     id(my_uart).set_rx_buffer_size(size_t rx_buffer_size);
+    // RX FIFO full threshold (in bytes units)
+    id(my_uart).set_rx_full_threshold(size_t rx_full_threshold);
+    // RX FIFO full threshold (in time units)
+    id(my_uart).set_rx_full_threshold_ms(uint8_t time);
+    // RX timeout
+    id(my_uart).set_rx_timeout(size_t rx_timeout);
     // Stop bits
     id(my_uart).set_stop_bits(uint8_t stop_bits);
     // Data bits
diff --git a/content/components/wifi.md b/content/components/wifi.md
@@ -104,8 +104,8 @@ wifi:
 - **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.
-- **enable_rrm** (*Optional*, bool): Only on `esp32` with `esp-idf`. Enable 802.11k Radio Resource Management support.
+- **enable_btm** (*Optional*, bool): Only on `esp32`. Enable 802.11v BSS Transition Management support.
+- **enable_rrm** (*Optional*, bool): Only on `esp32`. Enable 802.11k Radio Resource Management support.
 
 - **on_connect** (*Optional*, [Automation](#automation)): An action to be performed when a connection is established.
 - **on_disconnect** (*Optional*, [Automation](#automation)): An action to be performed when the connection is dropped.
diff --git a/content/components/zwave_proxy.md b/content/components/zwave_proxy.md
@@ -0,0 +1,95 @@
+---
+description: "Instructions for setting up the Z-Wave Proxy in ESPHome."
+title: "Z-Wave Proxy"
+params:
+  seo:
+    description: Instructions for setting up the Z-Wave Proxy in ESPHome.
+    image: z-wave.svg
+---
+
+The `zwave_proxy` component allows proxying of Z-Wave data frames between a
+[Z-Wave Modem SoC](https://www.silabs.com/wireless/z-wave/800-series-modem-soc) and
+[Z-Wave JS](https://zwave-js.github.io/zwave-js/) via ESPHome's {{< docref "/components/api" >}} over
+the {{< docref "/components/wifi" >}} or {{< docref "/components/ethernet" >}}. This allows for more flexibility when
+placing your Z-Wave hardware within your home.
+
+As the Z-Wave modem SoC communicates via a serial connection, you need to have a [UART](#uart) defined in your ESPHome
+device's configuration.
+
+In addition, the `zwave_proxy` expects to proxy messages via ESPHome's {{< docref "/components/api" >}}; this is also
+required in your configuration.
+
+{{< note >}}
+Number of connections
+
+While ESPHome supports multiple API connections/clients, only a single client may subscribe to and receive proxied
+Z-Wave data frames at any given time.
+
+{{< /note >}}
+
+## Configuration
+
+```yaml
+# Example configuration entry
+zwave_proxy:
+```
+
+- **id** (*Optional*, [ID](#config-id)): Manually specify the ID for the `zwave_proxy`.
+
+## Maximizing performance
+
+Low latency is key to achieving an optimal experience with Z-Wave (or any) wireless devices.
+
+It's important to understand that using the `zwave_proxy` *will* increase latency between your Z-Wave devices and
+Z-Wave JS -- this is simply the consequence of passing messages from one medium to another.
+
+Under near-ideal conditions:
+
+- With a direct serial connection to the Z-Wave modem SoC, latency may be as low as approximately 20 milliseconds (ms).
+- When introducing the Z-Wave proxy component, it's still possible to achieve low latency -- we've seen as low as 35
+  ms! However, in practice, it's more realistic to expect 50-60 ms, assuming decent RF conditions.
+
+In general, any duration less than 100 ms is quite acceptable in terms of latency; this value is generally a good
+target to keep in mind.
+
+## Maximizing reliability
+
+In addition to low latency, reliability is also critical to an optimal experience.
+
+**A wired Ethernet connection will provide the best reliability for the Z-Wave proxy.** Ethernet offers:
+
+- More stable and predictable latency
+- No connection drops or lag due to RF interference
+- Immunity to environmental conditions
+
+### Wi-Fi considerations
+
+Wi-Fi is impacted by:
+
+- Interference from other RF devices
+- Environmental conditions, such as:
+  - People/pets moving around a room
+  - Building construction materials
+  - Air density, quality, and even humidity
+
+These factors can periodically cause momentary signal instability. While Wi-Fi devices typically recover automatically,
+this comes at the expense of temporarily degraded performance (latency) and, in more extreme cases, brief loss of
+connectivity.
+
+If you choose to use Wi-Fi to bridge your Z-Wave modem to Z-Wave JS:
+
+- Confirm that there is a strong, stable Wi-Fi signal available in the location you'll place your Z-Wave proxy.
+- Do not attempt to place your Z-Wave proxy at or near the edge of the coverage area your Wi-Fi router/access point
+  provides. If in doubt, move it closer to your Wi-Fi router/access point.
+- If you find that your Z-Wave devices are not operating reliably, you might try:
+  - moving your Z-Wave proxy closer to your Wi-Fi router/access point.
+  - changing the Wi-Fi channel your Wi-Fi router/access point is using.
+  - getting a better Wi-Fi router/access point. In particular, many ISP-provided Wi-Fi routers are designed to be
+    cost-effective and are not optimized for performance.
+
+## See Also
+
+- {{< docref "/components/api" >}}
+- {{< docref "/components/ethernet" >}}
+- {{< docref "/components/wifi" >}}
+- {{< apiref "zwave_proxy/zwave_proxy.h" "zwave_proxy/zwave_proxy.h" >}}
diff --git a/content/guides/supporters.md b/content/guides/supporters.md
@@ -708,6 +708,7 @@ ESPHome was originally founded by [Otto Winter (@OttoWinter)](https://github.com
 - [星野SKY (@FlyingFeng2021)](https://github.com/FlyingFeng2021)
 - [flyize (@flyize)](https://github.com/flyize)
 - [风飘雨 (@flyrainning)](https://github.com/flyrainning)
+- [Ben Curtis (@Fmstrat)](https://github.com/Fmstrat)
 - [foltymat (@foltymat)](https://github.com/foltymat)
 - [footswitch (@footswitch)](https://github.com/footswitch)
 - [Fabio Pugliese Ornellas (@fornellas)](https://github.com/fornellas)
@@ -2036,6 +2037,7 @@ ESPHome was originally founded by [Otto Winter (@OttoWinter)](https://github.com
 - [Tinkerfish (@tinkerfish)](https://github.com/tinkerfish)
 - [TJ Horner (@tjhorner)](https://github.com/tjhorner)
 - [Theodore Ni (@tjni)](https://github.com/tjni)
+- [Subhash Chandra (@TMaYaD)](https://github.com/TMaYaD)
 - [Max Efremov (@Tmin10)](https://github.com/Tmin10)
 - [tmpeh (@tmpeh)](https://github.com/tmpeh)
 - [Christian (@Tntdruid)](https://github.com/Tntdruid)
@@ -2229,4 +2231,4 @@ ESPHome was originally founded by [Otto Winter (@OttoWinter)](https://github.com
 - [Christian Zufferey (@zuzu59)](https://github.com/zuzu59)
 - [Zynth-dev (@Zynth-dev)](https://github.com/Zynth-dev)
 
-*This page was last updated September 17, 2025.*
+*This page was last updated September 19, 2025.*
