ESPhome renames devices

After recent updates my esphome device are renamed because of an ip reassignment it says. Now my esp32-ble trackers suddenly has changed in the name of my co2 sensor?!?
Logfile:
Name of device co2-slpk-ouders changed to esp32-ble-tracker, potentially due to IP reassignment

22:29:48 – (WAARSCHUWING) ESPHome - bericht kwam voor het eerst om 22:25:50 en verschijnt 20 keer

Logger: homeassistant.components.esphome
Source: components/esphome/init.py:306
Integration: ESPHome (documentation, issues)
First occurred: 22:25:50 (20 occurrences)
Last logged: 22:29:48

Name of device co2-slpk-ouders changed to esp32-ble-tracker, potentially due to IP reassignment

Anyone else has troubles after recent updates of HA? Running now on: Home Assistant 2022.2.8 and ESPHome version: 2022.2.1. I didn’t change the ip-adresse of my devices. HA is restarted and devices recently has done an update using this ESPHome integration. Is it possible to also assign mac-adresses to prevent this? I think this is very strange behaviour.

Exactly the same thing happened to me today. Completely out of the blue.
The weird thing is that the esphome integration still shows everything as it should be and even connecting to the logs works as it is supposed to.
The HA log however shows the warning message described in the opening post and HA reports all the sensors of the affected esp as unavailable.

It might be coincidence, but my esp also got swapped with a esp configured as a ble tracker.

Additionally this error shows up in the HA log:

Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:520
Integration: Sensor (documentation, issues)
First occurred: 13:46:37 (6 occurrences)
Last logged: 13:46:37

Platform esphome does not generate unique IDs. ID ble-trackersensorluftfeuchtigkeit_1 already exists - ignoring sensor.luftfeuchtigkeit_1
Platform esphome does not generate unique IDs. ID ble-trackersensorakku_lywsd03mmc_1 already exists - ignoring sensor.akku_lywsd03mmc_1
Platform esphome does not generate unique IDs. ID ble-trackersensortemperatur_2 already exists - ignoring sensor.temperatur_2
Platform esphome does not generate unique IDs. ID ble-trackersensorluftfeuchtigkeit_2 already exists - ignoring sensor.luftfeuchtigkeit_2
Platform esphome does not generate unique IDs. ID ble-trackersensorakku_lywsd03mmc_2 already exists - ignoring sensor.akku_lywsd03mmc_2

Even though I’ve disconnected the ble tracker from its power supply.

1 Like

I spend many hours yesterday trying to fix this, but wasn’t able to. Two esphome nodes were mixed up beyond repair. I even completely deleted them from esphome and added them in from scratch (new names, new fixed ip, new esp32’s). But esphome kept mixing them up. I have no idea why these 2, where the other nodes were working fine.

In the end I had to roll back to a backup and everything was fine again. This was the backup created before upgrading to HA core 2022.11.2, so this is probably what caused it.

Is anyone else seeing the same thing happen? Guess I won’t be upgrading HA anymore for some time and hopefully the issue will be gone in a future release.

2 Likes

I am seeing the same:

2022-11-19 16:18:48.972 WARNING (MainThread) [homeassistant.components.esphome] Name of device esp32-bew changed to esp-energy, potentially due to IP reassignment
2022-11-19 16:19:48.990 WARNING (MainThread) [homeassistant.components.esphome] Name of device esp32-bew changed to esp-energy, potentially due to IP reassignment
2022-11-19 16:20:49.026 WARNING (MainThread) [homeassistant.components.esphome] Name of device esp32-bew changed to esp-energy, potentially due to IP reassignment
2022-11-19 16:21:49.044 WARNING (MainThread) [homeassistant.components.esphome] Name of device esp32-bew changed to esp-energy, potentially due to IP reassignment
2022-11-19 16:22:49.201 WARNING (MainThread) [homeassistant.components.esphome] Name of device esp32-bew changed to esp-energy, potentially due to IP reassignment

The device esp32-bew is currently offline (it’s my irrigaten system which is currently in storage until next summer), esp-energy is working fine.

It also started after updating to 2022.11.2 - never seen it before.

I’ve opened an issue here:

2 Likes

My issue was closed as a duplicate, the other issue does not see any progress. I assume that this is fringe case users have to work through themselves.

1 Like

Rolling back to the previous HA release fixed the issue for me initially and since then I haven’t tried updating again.
I’m waiting a couple more months and then just hope the issue is resolved, because I have no clue what is causing it or where to even start fixing it.
It’s kind of weird that no one apart from a few had these problems.

1 Like

It is weird - nevertheless, there was a PR for a fix which I guess will be in 2023.1 (it was not on the point releases for 2022.12). You’ll probably have to remove and re-add the device but should be good from there.

2 Likes

Nope … did so multiple times by now.
Even the steps
remove
re-compile the ESP device
reboot the HA system not just the core
and re-add the ESP
finally resulted in the very same errorlog with non unique IDs.

The only point I’m aware of to check for IDs is the have a closer look at the config files stored within the .storage subdir, and sorry to say … all IDs are unique.

If I should guess whats wrong … the error thrown is next best error reached, but it likely got nothing to do with the real error. Or there’s another place where IDs are stored I didn’t come across yet.
Anyone with a deeper knownledge where to have a closer look for IDs?

It’s probably because this bug is just fixed with the next ha core release (which hosts the esphome integration and is in charge for the ID generation).

Yep seen that and also followed the yet closed issue about “unique IDs”.
Sympthoms match but the reasons disgussed didn’t.
We’ll see if utilising the mac would cure anything, I still doubt that since noone was able to name the location where somthing gets listed being non-unique.

Let’s see how it turns out with 2023.1 - we know more by the end of the week…

1 Like

Getting the same issue (…already exists, ignoring duplicate…) here with about 5 devices (out of a couple dozen) after a power-outage caused a restart of HA and all the ESPs. It’s likely that some of the ESPs were issued new IP addrs by DHCP.
I found duplicate records (with differing IPs) in .storage/core.config_entries, but there are probably dups elsewhere within .storage that I haven’t discovered yet.

But I did find a workaround.
HA doesn’t seem to tolerate well when ESPHome devices reappear on the net using IP addrs formerly assigned to other ESPHome devices (e.g. after a full net and DHCP restart).
I came upon this process:
If HA complains about deviceX being a duplicate, find its IP addr, and look for it in .storage/core.config_entries.
You may find that another device (deviceY) is listed within, using the same IP addr.
Go to the Integrations/ESPHome list, find deviceY. There will be two of them. One will have at least ‘2 devices’ named (deviceX will be the second one) .
Delete that deviceY entry. (the other deviceY entry will still be listed, and will have only 1 device)
This is hard to describe without images or text that’s far better than I’ve done here. The idea, though, is that even though ‘deviceX’ shows up in the logs, the problem is with the redundant/obsolete deviceY record, and the common link is the IP addr.

1 Like