* aioesphomeapi update
* Bump aioesphomeapi to 31.0.0
There are some breaking changes with the protobuf naming and types
required some refactoring
changelog: https://github.com/esphome/aioesphomeapi/compare/v30.2.0...v31.0.0
* actually include the commit to bump the lib
* 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
These tests do not need a config entry, only the integration
to be set up. Since I cannot replicate the issue locally after
1000 runs, I switched it to use async_setup_component to minimize
the potential problem area and hopefully fix the flakey test
I also modified the test to explictly set up hassio to ensure
the patch is effective since we have to patch a late import
last observed flake: https://github.com/home-assistant/core/actions/runs/14503715101/job/40689452294?pr=143106
* 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.
