To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file:

external_components:
  - source: github://pr#14061
    components: [web_server]
    refresh: 1h

(Added by the PR bot)

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.11%. Comparing base (7e11817) to head (ccf1f41).
⚠️ Report is 5 commits behind head on dev.

@@           Coverage Diff           @@
##              dev   #14061   +/-   ##
=======================================
  Coverage   74.11%   74.11%           
=======================================
  Files          55       55           
  Lines       11590    11590           
  Branches     1578     1578           
=======================================
  Hits         8590     8590           
  Misses       2598     2598           
  Partials      402      402           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Additionally, optional fields like preset and fan_mode were omitted from SSE state events when unset, causing the frontend's Object.assign() merge to leave stale values from a previous state.

That sounds like a bug in the frontend

Additionally, optional fields like preset and fan_mode were omitted from SSE state events when unset, causing the frontend's Object.assign() merge to leave stale values from a previous state.

That sounds like a bug in the frontend

It's arguably more of a protocol design issue than a frontend bug. SSE state events are designed as partial updates merged via Object.assign(). The issue is that when an optional field like preset transitions from set → unset, omitting it from the payload gives the frontend no signal to clear the previous value. The frontend would need to track which fields are expected per entity type and explicitly null missing ones, which adds complexity and couples the frontend tightly to backend schema knowledge.

Always including supported fields (with empty string as the "unset" sentinel) keeps the contract simple: if a trait is supported, the field is always present in the payload, and the frontend can rely on the value it receives.

Also see the discord thread
https://discord.com/channels/429907082951524364/1473752675106422824

That seems like a design mismatch. If we are expecting partial updates and we aren't comparing against the previous state, we end up sending everything anyways

It looks like this puts us out of sync with the REST API

That seems like a design mismatch. If we are expecting partial updates and we aren't comparing against the previous state, we end up sending everything anyways

You're right — other components (fan, cover, valve) omit optional fields when not supported/set. Climate is unique in having mutually exclusive optional pairs (fan_mode/custom_fan_mode, preset/custom_preset) which other entity types don't have. Happy to align the approach if there's a preferred pattern — should the frontend handle clearing stale values for missing keys instead?

We probably need to do something with the frontend for climate to minimize the payload coming from the backend since we keep allocating larger and larger json payloads on the device to the point we will start to have a problem

Also we are trying to fix the heap churn issue with the web_server with long connected SSE in #13625 so if we can keep the climate payload under 512 bytes it will never allocate once that PR is merged

We are sending min_temp/max_temp/step every time as well and we don't need to. And for water heater its wrong...

note that clang-format is still failing https://github.com/esphome/esphome/actions/runs/22166826625/job/64095845122?pr=14061

Reworked based on feedback. The PR now only touches the backend minimally. I updated description with the changes and reasoning.

Memory Impact Analysis

Components: web_server
Platform: esp8266-ard

Note: This analysis measures static RAM and Flash usage only (compile-time allocation).
Dynamic memory (heap) cannot be measured automatically.
⚠️ You must test this PR on a real device to measure free heap and ensure no runtime memory issues.

This analysis runs automatically when components change. Memory usage is measured from a representative test configuration.

For reference the frontend PR: esphome/esphome-webserver#191

Current version LGTM