* Improve human-readable prompt when requesting ESPHome credentials
Users reported difficulty identifying which device needs reauthentication, especially when names are similar (e.g., `power-meter` vs `power-meter-EEFF`). Previously, only the hostname was shown, which led to confusion. This change includes the config entry title or friendly name—when available—in the prompt to make device identification easier.
* Update homeassistant/components/esphome/config_flow.py
* add missing cover
* tweaks
* one more
* one more
* cover
* some are ``, some are not, make them all ``
* Apply suggestions from code review
---------
Co-authored-by: Paulus Schoutsen <balloob@gmail.com>
* Improve ESPHome abort messages for already-configured devices
Users often struggle to identify which ESPHome device is already configured—especially when replacing a device or renaming an existing one.
This PR improves the abort messages to include more helpful details, so users can pinpoint the conflicting device without needing to dig through the `core.config_entries` file manually.
* Update homeassistant/components/esphome/strings.json
Correct handling of empty name for ESPHome devices
If the name was set to "", ESPHome should treat this as if the
name is empty. Since protobuf treats empty fields as "" we need
to handle this as `None` internally as otherwise it leads to
friendly names like "Friendly Name " with a trailing space and
unexpected entity_id formats
fixes#132532
* Bump aioesphomeapi to 29.10.0
changelog: https://github.com/esphome/aioesphomeapi/compare/v29.9.0...v29.10.0
* Validate ESPHome mac address before updating IP on discovery
In some cases the data coming in from discovery may be
stale since there is a small race window if devices
get new IP allocations. Since some routers do not update
their names right away and zeroconf has a non-zero TTL
there is a small window where the discovery data can be
stale. This is a rare condition but it does happen. With
aioesphomeapi 29.10.0+ and ESPHome 2025.4.x+ we can validate
the mac address even without the correct encryption key
which allows us to be able to always validate the MAC
before updating the IP from any discovery method.
* tweaks
* fix test
* Fix ESPHome update entities being loaded before device_info is available
Since we load platforms when restoring config, the update
platform could be loaded before the connection to the
device was finished which meant device_info could still
be empty. Wait until device_info is available to
load the update platform.
fixes#135906
* Apply suggestions from code review
* move comment
* Update entry_data.py
Co-authored-by: TheJulianJES <TheJulianJES@users.noreply.github.com>
---------
Co-authored-by: TheJulianJES <TheJulianJES@users.noreply.github.com>
* Fix old ESPHome entities not being removed when configuration changes
fixes#140756
* make sure all callbacks fire
* make sure all callbacks fire
* make sure all callbacks fire
* make sure all callbacks fire
* revert
* cover
ESPHome always uses .0 in the URL for the changelog,
and we never had a patch version in the stable
BLE version field so we need to switch it to
.0 for the URL.
J. Nick Koston
Paulus Schoutsen
Franck Nijhof
Michael Hansen
Norbert Rittel