|
36 | 36 | api:
|
37 | 37 | port: 6053
|
38 | 38 | batch_delay: 50ms # Reduce latency for real-time applications
|
| 39 | + listen_backlog: 2 # Allow 2 pending connections in queue |
| 40 | + max_connections: 6 # Allow up to 6 simultaneous connections |
| 41 | + max_send_queue: 10 # Maximum queued messages per connection before disconnect |
39 | 42 | encryption:
|
40 | 43 | key: "YOUR_ENCRYPTION_KEY_HERE"
|
41 | 44 | reboot_timeout: 30min
|
|
44 | 47 | ## Configuration variables
|
45 | 48 |
|
46 | 49 | - **port** (*Optional*, int): The port to run the API server on. Defaults to `6053`.
|
| 50 | +- **listen_backlog** (*Optional*, int): The maximum number of pending connections in the listen queue. Must be between 1 and 10. |
| 51 | + Defaults to `1` for ESP8266/RP2040, `4` for ESP32 and other platforms. Lower values use less memory but may reject connections during bursts. |
| 52 | +- **max_connections** (*Optional*, int): The maximum number of simultaneous API connections allowed. Must be between 1 and 20. |
| 53 | + Defaults to `4` for ESP8266/RP2040, `8` for ESP32 and other platforms. Each connection uses approximately 500-1000 bytes of RAM. |
| 54 | + |
| 55 | + > [!NOTE] |
| 56 | + > Each API connection consumes approximately 500–1000 bytes of RAM while connected. ESP8266 and RP2040 devices have limited |
| 57 | + > RAM available (ESP8266 typically has around 40KB of free RAM after boot, but this can drop to under 20KB once sensors and other components are configured; RP2040 uses LWIP raw sockets with similar constraints), so be careful not to set this value too high or it may cause out-of-memory crashes. |
| 58 | + > The defaults are set to balance memory usage with allowing multiple simultaneous connections. |
| 59 | + |
| 60 | +- **max_send_queue** (*Optional*, int): The maximum number of messages that can be queued for sending per connection before the connection is dropped. Must be between 1 and 64. |
| 61 | + Defaults to `5` for ESP8266/RP2040, `8` for ESP32/BK72xx/RTL87xx/LN882x, `16` for host platform. This prevents memory exhaustion when a client is slow or network-stalled. |
| 62 | + Each queued message uses approximately 8-12 bytes of overhead plus the message size. |
| 63 | + |
| 64 | + > [!NOTE] |
| 65 | + > When the send queue is full for a connection, the device will log an error and disconnect that client to prevent out-of-memory crashes. |
| 66 | + > Slow clients, poor WiFi connections causing retries, or network congestion may trigger this. Increase this value if legitimate clients are being disconnected, but be mindful |
| 67 | + > of memory constraints on embedded devices. |
| 68 | + |
47 | 69 | - **encryption** (*Optional*): If present, encryption will be enabled for the API. Using encryption helps to secure the
|
48 | 70 | communication between the device running ESPHome and the connected client(s).
|
49 | 71 |
|
|
93 | 115 | Before using any of the actions below, you'll need to tell Home Assistant to allow your device to
|
94 | 116 | perform actions.
|
95 | 117 |
|
| 118 | +> [!NOTE] |
| 119 | +> Starting with ESPHome 2025.10.0, you can configure actions to receive and process responses from |
| 120 | +> Home Assistant using `capture_response`, `on_success`, and `on_error`. See [Action Response Handling](#action-response-handling) for details. |
| 121 | + |
96 | 122 | Open the ESPHome integration page on your Home Assistant instance:
|
97 | 123 |
|
98 | 124 | [](https://my.home-assistant.io/redirect/integration/?domain=esphome)
|
@@ -180,6 +206,20 @@ on_...:
|
180 | 206 | - **variables** (*Optional*, mapping): Optional variables that can be used in the `data_template`.
|
181 | 207 | Values are [lambdas](#config-lambda) and will be evaluated before sending the request.
|
182 | 208 |
|
| 209 | +- **capture_response** (*Optional*, boolean): Enable capturing the response from the Home Assistant action call. |
| 210 | + When enabled, `on_success` must be configured. Defaults to `false`. |
| 211 | + |
| 212 | +- **response_template** (*Optional*, [templatable](#config-templatable), string): Optional Jinja template to process |
| 213 | + the action response data. This template is evaluated on the Home Assistant side with Home Assistant's templating engine. |
| 214 | + Requires `capture_response: true`. |
| 215 | + |
| 216 | +- **on_success** (*Optional*, [Automation](#automation)): Optional automation to execute when the Home Assistant action |
| 217 | + call succeeds. When `capture_response: true`, the response data is available as a `response` variable of type `JsonObjectConst`. |
| 218 | + See [Action Response Handling](#action-response-handling). |
| 219 | + |
| 220 | +- **on_error** (*Optional*, [Automation](#automation)): Optional automation to execute when the Home Assistant action |
| 221 | + call fails. See [Action Response Handling](#action-response-handling). |
| 222 | + |
183 | 223 | Data structures are not possible, but you can create a script in Home Assistant and call with all
|
184 | 224 | the parameters in plain format.
|
185 | 225 |
|
@@ -213,6 +253,74 @@ on_...:
|
213 | 253 | blue: '71'
|
214 | 254 | ```
|
215 | 255 |
|
| 256 | +#### Action Response Handling |
| 257 | + |
| 258 | +> [!NOTE] |
| 259 | +> Action response handling is available in ESPHome 2025.10.0 and later. |
| 260 | + |
| 261 | +You can configure actions to receive and process responses from Home Assistant. This enables bidirectional |
| 262 | +communication where ESPHome can not only call Home Assistant actions but also handle their responses. |
| 263 | + |
| 264 | +##### Basic Success/Error Handling |
| 265 | + |
| 266 | +Use `on_success` and `on_error` to respond to action completion: |
| 267 | + |
| 268 | +```yaml |
| 269 | +on_...: |
| 270 | + - homeassistant.action: |
| 271 | + action: light.toggle |
| 272 | + data: |
| 273 | + entity_id: light.demo_light |
| 274 | + on_success: |
| 275 | + - logger.log: "Toggled demo light" |
| 276 | + on_error: |
| 277 | + - logger.log: "Failed to toggle demo light" |
| 278 | +``` |
| 279 | + |
| 280 | +##### Capturing Response Data |
| 281 | + |
| 282 | +To capture and process response data from actions, set `capture_response: true`. When enabled, `on_success` must be configured |
| 283 | +and the response data is available as a [`JsonObjectConst`](https://arduinojson.org/v7/api/jsonobjectconst/) variable named `response`. |
| 284 | + |
| 285 | +```yaml |
| 286 | +# Example: Get weather forecast and parse JSON response |
| 287 | +on_...: |
| 288 | + - homeassistant.action: |
| 289 | + action: weather.get_forecasts |
| 290 | + data: |
| 291 | + entity_id: weather.forecast_home |
| 292 | + type: hourly |
| 293 | + capture_response: true |
| 294 | + on_success: |
| 295 | + - lambda: |- |
| 296 | + JsonObjectConst next_hour = response["response"]["weather.forecast_home"]["forecast"][0]; |
| 297 | + float next_temperature = next_hour["temperature"].as<float>(); |
| 298 | + ESP_LOGI("weather", "Temperature next hour: %.1f", next_temperature); |
| 299 | +``` |
| 300 | + |
| 301 | +##### Using Response Templates |
| 302 | + |
| 303 | +Use `response_template` to extract and format data from complex responses using Home Assistant's Jinja templating engine. |
| 304 | +This requires `capture_response: true`. |
| 305 | + |
| 306 | +```yaml |
| 307 | +# Example: Extract temperature using a template |
| 308 | +on_...: |
| 309 | + - homeassistant.action: |
| 310 | + action: weather.get_forecasts |
| 311 | + data: |
| 312 | + entity_id: weather.forecast_home |
| 313 | + type: hourly |
| 314 | + capture_response: true |
| 315 | + response_template: "{{ response['weather.forecast_home']['forecast'][0]['temperature'] }}" |
| 316 | + on_success: |
| 317 | + - lambda: |- |
| 318 | + float temperature = response["response"].as<float>(); |
| 319 | + ESP_LOGI("weather", "Temperature next hour: %.1f", temperature); |
| 320 | +``` |
| 321 | + |
| 322 | +When `response_template` is used, the processed result is available in `response["response"]`. |
| 323 | + |
216 | 324 | {{< anchor "api-homeassistant_tag_scanned_action" >}}
|
217 | 325 |
|
218 | 326 | ### `homeassistant.tag_scanned` Action
|
|
0 commit comments