Platform esphome does not generate unique IDs.

[nerdgarden]

Operating environment/Installation (Hass.io/Docker/pip/etc.):

Homeassistant managed on RaspiOS ESP (ESP32/ESP8266, Board/Sonoff):

Shelly 1, Sonoff T1 ESPHome version (latest production, beta, dev branch)

Version: 1.15.3

Affected component:

All

Description of problem: I receive an error in Home Assistant logs and devices appearing and disappearing:

2020-11-16 19:58:04 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID sala_da_pranzobinary_sensorsala_da_pranzo already exists - ignoring binary_sensor.sala_da_pranzo 2020-11-16 19:58:04 ERROR (MainThread) [homeassistant.components.light] Platform esphome does not generate unique IDs. ID sala_da_pranzolightsala_da_pranzo already exists - ignoring light.sala_da_pranzo 2020-11-16 19:58:16 ERROR (MainThread) [homeassistant.util.logging] Exception in _on_device_update when dispatching 'esphome_5d78a31df7543f3794c3d702aebacfca_on_device_update': () Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/esphome/init.py", line 545, in _on_device_update if self._entry_data.available: File "/usr/src/homeassistant/homeassistant/components/esphome/init.py", line 560, in _entry_data return self.hass.data[DATA_KEY][self._entry_id] KeyError: '5d78a31df7543f3794c3d702aebacfca' 2020-11-16 19:58:16 ERROR (MainThread) [homeassistant.util.logging] Exception in _on_device_update when dispatching 'esphome_5d78a31df7543f3794c3d702aebacfca_on_device_update': () Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/esphome/init.py", line 545, in _on_device_update if self._entry_data.available: File "/usr/src/homeassistant/homeassistant/components/esphome/init.py", line 560, in _entry_data return self.hass.data[DATA_KEY][self._entry_id] KeyError: '5d78a31df7543f3794c3d702aebacfca' 2020-11-16 19:58:17 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID sala_da_pranzobinary_sensorsala_da_pranzo already exists - ignoring binary_sensor.sala_da_pranzo 2020-11-16 19:58:17 ERROR (MainThread) [homeassistant.components.light] Platform esphome does not generate unique IDs. ID sala_da_pranzolightsala_da_pranzo already exists - ignoring light.sala_da_pranzo 2020-11-16 19:58:17 ERROR (MainThread) [homeassistant.components.light] Platform esphome does not generate unique IDs. ID pulsantiera_cucinalightcucina already exists - ignoring light.cucina 2020-11-16 19:58:17 ERROR (MainThread) [homeassistant.components.light] Platform esphome does not generate unique IDs. ID pulsantiera_cucinalightsala_piccola already exists - ignoring light.sala_piccola 2020-11-16 19:58:17 ERROR (MainThread) [homeassistant.components.light] Platform esphome does not generate unique IDs. ID pulsantiera_cucinalightingresso_due already exists - ignoring light.ingresso_due 2020-11-16 19:58:17 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID pulsantiera_cucinabinary_sensorpulsantiera_cucina already exists - ignoring binary_sensor.pulsantiera_cucina

Problem-relevant YAML-configuration entries:

esphome:
  name: pulsantiera_bagno_ingresso
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_pass

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Pulsantiera Bagno Ingresso"
    password: "ahIvFcsB6Rg1"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO0
      mode: INPUT_PULLUP
      inverted: True
    id: toggle_1
    on_press:
      then:
        - light.toggle: light_1
  - platform: gpio
    pin:
      number: GPIO9
      mode: INPUT_PULLUP
      inverted: True
    id: toggle_2
    on_press:
      then:
      - light.toggle: light_2
  - platform: gpio
    pin:
      number: GPIO10
      mode: INPUT_PULLUP
      inverted: True
    id: toggle_3
    on_press:
      then:
        - light.toggle: light_3
  - platform: status
    name: "Pulsantiera Bagno Ingresso"

status_led:
  # Register the blue LED as status led
    pin:
      number: GPIO13
      inverted: True

output:
  - platform: gpio
    id: relay_1
    pin: GPIO12
  - platform: gpio
    id: relay_2
    pin: GPIO5
  - platform: gpio
    id: relay_3
    pin: GPIO4

light:
  # ... and then make a light out of it.
  - platform: binary
    id: light_1
    output: relay_1
    name: "Bagno ingresso"
  - platform: binary
    id: light_2
    output: relay_2
    name: "Ingresso"
    on_turn_on:
    - delay: 0.1s
    - light.turn_off: light_2
  - platform: binary
    id: light_3
    output: relay_3
    name: "Sala Grande"

Logs (if applicable):

PASTE DEBUG LOG HERE

Additional information and things you've tried:

[akomelj]

I am experiencing a similar problem.

I am NOT using ESPHome integration in Home Assistant and instead rely on MQTT auto discovery for various reasons.

ESPHome generates non-unique unique_id identifiers for some sensors and switches and most of the time Home Assistant does not pick these sensors and switches up, complaining that unique_ids are not unique enough (Home Assistant 0.118.4). Whether these sensors are later visible in Home Assistant UI or not, depends on pure luck with timing how device discovery messages are published to MQTT, how historic data is restored, how Home Assistant is restarted, etc.

A simple fix is obvious. However - as it probably breaks backwards compatibility and may cause some sensors from older version devices to be duplicated - I would like some further comments from the authors of ESPHome.

In mqtt_component.cpp:

         } else {
           // default to almost-unique ID. It's a hack but the only way to get that
           // gorgeous device registry view.
-          root["unique_id"] = "ESP" + this->component_type() + this->get_default_object_id_();
+          root["unique_id"] = get_mac_address() + "-" + this->component_type() + "-" + this->get_default_object_id_();
         }

Let's use restart switch with name Restart as an example. Before change, the uniquely generated ID for this generic MQTT switch is ESPswitchrestart and may conflict with any other ESPHome device using the same definition of the switch (i.e. when reusing configuration via split configuration files or just friendly naming the restart switch Restart). :-)

The proposed change generates a different, hopefully globally unique ID and Home Assistant happily registers the switch with the device: cc50e34ba6fb-switch-restart.

Any comment on why this hasn't been implemented would be greatly appreciated - I've noticed that get_mac_address() is used when generating IDs in some out-of-the-box sensors (i.e. Wi-fi info, etc) so I assume some reason exists for not doing it generically. Can someone elaborate what that comment "default to almost-unique ID. It's a hack but the only way to get that gorgeous device registry view." means or if generating unique unique_ids may be a bad idea?

[john-arvid]

Same problem here, every time I restart home assistant I get this problem for one specific device.

[YvesZH]

+1 Same here

[The-Deep-Sea]

+1 An alternative to the approach using the mac address is using the node name. According to the documentation: This is the name of the node. It should always be unique in your ESPhome network.

[CarlosGS]

Any tips to fix this?

ERROR (MainThread) [homeassistant.components.light] Platform esphome does not generate unique IDs. ID bombilla_estudiolightbombilla_estudio already exists - ignoring light.bombilla_estudio

We only need to know where is it actually checking. Not sure if that's .storage :thinking:

Edit 15/06: I think this behavior has improved over time. Lately it was easy to fix by deleting and re-adding any duplicated entities:

[tvwerkhoven]

I have the same problem. When there are esphome entities connected with:

1. multiple sensors of the same platform
2. for platforms which do not have a static unique id

Homeassistant only reads 1 (random?) sensor of this pool.

For example: the BME280 or MH-Z19B sensors both show this problem, whereas 1wire sensors (such as Dallas) do not.

Proposed fix

• Current method: generating uniqueid with `` (e.g. esp_livingsensormh-z19_co2)
• Proposed fix: generate uniqueid with `_(e.g.esp_livingsensormh-z19_co2_my_sensor_id1`)

It will be up to the user to ensure <sensor_id> is unique, but that's better than having no control. I'm not sure where in the codebase unique_id is generated, but hopefully someone can help.

Example

In my case I address a sensor twice in an esphome node, 1x to show the actual value, 1x to show the exponential moving average (ema) on an oled. However, Homeassistant only accepts one of these sensors, and ignores the other, because both get the unique_id esp_livingsensormh-z19_co2. The proposed fix would give these two sensors unique_ids: esp_livingsensormh-z19_co2_mh_z19 and esp_livingsensormh-z19_co2_mh_z19_ema

sensor:
  - platform: mhz19
    id: mh_z19
    co2:
      name: "MH-Z19 CO2"
      id: mh_z19_co2
    temperature:
      name: "MH-Z19 Temperature"
      id: mh_z19_temp
    update_interval: 60s
    uart_id: myuart1
  - platform: mhz19
    id: mh_z19_ema
    co2:
      name: "MH-Z19 CO2"
      id: mh_z19_co2_ema
      filters:
      - exponential_moving_average:
          alpha: 0.0028 # We want ~12 hour averaging, at 60s update, that's 12*3600/60 = 720points, thus alpha should be 2/1440 ~ 0.0028 
          send_every: 1
    update_interval: 60s # if changed also update alpha
    uart_id: myuart1

[tvwerkhoven]

Update: it seems I was wrong, unique_id is generated with _, so as a user one should ensure <sensor_name> is unique across all esphome entities you want to use with Home Assistant.

[OttoWinter]

@akomelj Yes, the MQTT integration does not have a great default way to generate unique IDs. As you said it doesn't contain the MAC address/node name. That's an issue dating quite a while back and we tried to fix it, but as you said it's a pretty big breaking change and so would first need HA to add some functionality to migrate unique IDs.

BUT, that's only for MQTT, most other posts here appear to be about api connectivity with HA. There, unique_ids do contain the device name, and so the generated unique IDs should be "more" safe. But there appears to be a bug in the HA integration somewhere that creates those exceptions, I haven't found how to replicate nor what it could be yet.

Let's keep this issue about the api unique id error, not MQTT unique ids.

[probot-esphome[bot]]

api source api issues api recent changes _{^{(message by IssueLinks)}}

[juicejuice]

@OttoWinter I definitely get this with the HA "api" integration for ESPHome. If there is anything I can investigate or do to help track it down just let me know. It seems to happen randomly e.g. I restarted HA yesterday and now one of my new ESPHome devices is unavailable, HA log reports the unique ID issue. I have solved in the past by removing and readding the relevant device integrations but the problem will still come back from time to time.

Edit: I'm on RPi4, HassOS (or whatever we call it now) 2021.6.6 and ESPHome 1.18.0. I've got one problem device right now where I've fiddled with the config a few times to get it setup right. This seems to have led to the issue for "hotwater_switch" device:

.storage $ grep hotwater_switchswitchhotwater_heater *
core.entity_registry:                "unique_id": "hotwater_switchswitchhotwater_heater",
esphome.38da479338445a76c982fb29a6ca5533:                "unique_id": "hotwater_switchswitchhotwater_heater",
esphome.94369006d8c98a67607bc76ee5a553fe:                "unique_id": "hotwater_switchswitchhotwater_heater",
esphome.a2a117e34a6e646fbf7e6882f372790a:                "unique_id": "hotwater_switchswitchhotwater_heater",
.storage $ 

Interesting to note that the "config_entry_id" in the core.entity_registry is getting mixed up. The 38da4 item is listed in core.entity_registry for a different ESPHome device, not the hotwater_switch. So the core.entity_registry and esphome. files are out of sync with each other. This seems to be matching what I experience and perhaps this is getting close to the root cause? I'll try clear some old esphome. files out to see if that helps.

Edit2: clearing out the old files fixed the issue. I'm not sure how they got mixed up but a fixup tool could be the easy solution e.g. something that looks to reconcile the core. file contents with the esphome. file contents.

Edit3: inspection of core.device_registry shows that many of my ESPHome devices have two or more "config_entries". I'm not really familiar with HA internals but I would expect each device to have a single config_entry. I assume the problem occurs when two config_entry IDs are present but the matching esphome.* files are for different devices, as I have seen here.

[OttoWinter]

inspection of core.device_registry shows that many of my ESPHome devices have two or more "config_entries". I'm not really familiar with HA internals but I would expect each device to have a single config_entry.

Oh that is very interesting! I have absolutely no idea how that can happen, because ESPHome just writes to the esphome.{config_entry_id} file (and each config entry is fully independent, on the esphome integration side there's no communication whatsoever between config entries).

That makes me think maybe there's a race condition or something in the HA Storage system maybe?

[juicejuice]

@OttoWinter I'm digging into this a little more but I'm only an HA user rather than developer so it's taking some time. From my system snapshot I can see a number of ESPHome devices have duplicate/triplicate config_entries in core.device_registry. The IDs are pointing to different devices e.g. it's not that I have duplicate configurations for the same device in core.config_entries.

One idea that came to mind is that my LAN is using DHCP for the ESPHome devices. Is it possible that my DHCP server is sometimes assigning an IP to a new device that used to belong to an older device? So when I setup a new device it gets confused because the old IP has been recycled for the new device? (I noticed that each device's IP is stored as the "host" value for each entry_id in core.config_entries)

[OttoWinter]

Thanks @juicejuice - I just looked into my core.device_registry and I too see lots of devices have multiple items under the config_entries key (each time one of them is the right one, but a different one points to a completely random config entry/device).

If yours and my issues are the same - or have the same root cause - then that rules out DHCP. I only use static IP assignments. It also rules out mDNS as being involved, because my HA deployment is in a docker container without mDNS access.

About the host thing: That's the host that was initially entered when setting up in the integrations screen. How did you set up the device? Via entering the host manually or by autodiscovery?

[juicejuice]

@OttoWinter thanks - good details and it seems DHCP was a bad guess :) Most of my ESPHome devices were setup via autodiscovery but for a few of them I typed in the mDNS hostname manually e.g. "something.local". In all cases IP addresses are showing in core.config_entries, none of them have the hostname for that field. Is that expected?

BTW I've now written a Python script that extracts all the relevant data from the .storage config files. The preliminary JSON output is already proving insightful. I'll do a little more research on my data set, maybe pull it into Excel, and report anything interesting that pops out.

[OttoWinter]

In all cases IP addresses are showing in core.config_entries, none of them have the hostname for that field. Is that expected?

Huh, that definitely should not be the case. After some digging it looks like that was introduced here https://github.com/home-assistant/core/pull/34753

(but unrelated to this issue I think)

Edit: created an issue about that here: https://github.com/home-assistant/core/issues/52239

[juicejuice]

@OttoWinter I'm running out of good ideas on this one. I would need to know a lot more about the internals to continue diagnosis. I'll clean up my config and then keep an eye out if it happens again and try to figure out what triggered it. In the meantime I'm listing my findings here in case it helps others.

These observations are related to the config files in the homeassistant .storage folder:

1. core.device_registry tracks all devices and allows for a single device ID to have multiple "config_entries" IDs
2. when there are multiple "config_entries" IDs for a single ESPHome device, these are for config_entries of different ESPHome devices!
3. these mismatched config_entries IDs cause unique ID errors in the HA log and the ESPHome devices become unavailable in HA and Lovelace (ESPHome still sees them correctly)
4. the core.config_entries, core.entity_registry, and esphome.* files all match up nicely, no duplicate IDs or mismatches; the problems always stem from the core.device_registry getting tangled up
5. ESPHome also leaves behind "orphaned" esphome. files where devices have been adjusted in the past, it doesn't appear these are ever cleaned up, although their relevant config_entries are removed from the core. files

[OttoWinter]

Thanks so much @juicejuice ! This insight is helping a lot for understanding this complex issue!

I've deployed my setup with more logging, and am hoping to catch this issue happening (but so far hasn't happened). I tried all sorts of things, reconnecting devices like crazy, disabling, deleting etc. Is there some way you could consistently get to that state?

If possible, some debug logs might be helpful - the affected code doesn't appear to log very much, but maybe it could still help. You can turn up the logging like this in your HA configuration.yaml:

logger:
  # ...
  logs:
    homeassistant.components.esphome: debug
    homeassistant.helpers.device_registry: debug
    homeassistant.helpers.storage: debug
    homeassistant.helpers.entity_registry: debug

Ad 5: Yeah, those files aren't removed, but that also isn't a big issue because they're essentially ignored after the entry is removed (nevertheless, I implemented removal upon entry removal here: https://github.com/home-assistant/core/pull/52296)

[juicejuice]

Thanks @OttoWinter I am cleaning up my config then will enable the debugging and keep an eye on things. I have a suspicion it is something related to HA updates but that is just a hunch, perhaps it is some other background process like the race condition you suggested. The "damage" does seem cumulative, I can see a trail for some devices where the later added devices have incrementally corrupted the configuration. Good idea on the esphome. cleanup too! I have already accumulated 44 old/unused files vs 23 actual esphome. files.

[juicejuice]

@OttoWinter here is something else interesting - three of the problem devices have "manufacturer = AsusWRT Tracked Device" instead of "manufacturer = espressif". I wonder if there is an unexpected interaction with other addons/plugins/etc.

[The-Deep-Sea]

@juicejuice I had the same thing with an AI Thinker ESP32-CAM some time ago. Here, however, it was the "AVM FRITZ!Box Tools" integration that the device suddenly claimed for itself.

[OttoWinter]

@juicejuice Yeah that is unrelated - some integrations (like AsusWRT and AVM) track mac addresses on the network, and add entities for them (and thus also device_registry entries). So those entries are fine

[juicejuice]

I've been monitoring this and all of a sudden some of my devices are back to being in "duplicated" state. I haven't updated, added/removed devices, or made any other configuration changes. It's late here so I've downloaded a snapshot to inspect more closely. A quick look at the logs (with @OttoWinter recommended debug options) shows entries like this:

2021-07-12 16:38:08 DEBUG (zeroconf-Engine-241) [homeassistant.components.esphome] 192.168.0.193: Triggering reconnect because of received mDNS record record[ptr,in,_esphomelib._tcp.local.]=4500/4499,entrance_switch._esphomelib._tcp.local.
2021-07-12 16:38:08 DEBUG (MainThread) [homeassistant.components.esphome] Can't connect to ESPHome API for entrance_switch (192.168.0.193): Error connecting to ('192.168.0.193', 6053): [Errno 113] Connect call failed ('192.168.0.193', 6053)
2021-07-12 16:38:13 DEBUG (zeroconf-Engine-241) [homeassistant.components.esphome] 192.168.0.193: Triggering reconnect because of received mDNS record record[ptr,in,_esphomelib._tcp.local.]=4500/4499,entrance_switch._esphomelib._tcp.local.
2021-07-12 16:38:14 DEBUG (MainThread) [homeassistant.components.esphome] Can't connect to ESPHome API for entrance_switch (192.168.0.193): Timeout while waiting for API response!
2021-07-12 16:38:29 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID entrance_switchbinary_sensorentrance_switch_button_a already exists - ignoring binary_sensor.entrance_switch_button_a
2021-07-12 16:38:29 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID entrance_switchbinary_sensorentrance_switch_button_b already exists - ignoring binary_sensor.entrance_switch_button_b
2021-07-12 16:38:29 ERROR (MainThread) [homeassistant.components.switch] Platform esphome does not generate unique IDs. ID entrance_switchswitchentrance_switch_b already exists - ignoring switch.entrance_switch_b
2021-07-12 16:38:29 ERROR (MainThread) [homeassistant.components.switch] Platform esphome does not generate unique IDs. ID entrance_switchswitchentrance_switch_reboot already exists - ignoring switch.entrance_switch_reboot
2021-07-12 16:38:29 ERROR (MainThread) [homeassistant.components.light] Platform esphome does not generate unique IDs. ID entrance_switchlightentrance_switch_a already exists - ignoring light.entrance_switch_a
2021-07-12 16:38:29 INFO (MainThread) [homeassistant.components.esphome] Successfully connected to 192.168.0.193

I don't see anything that hints at what might be causing the entities to be duplicated all of a sudden :(

[GazTheGeek]

Hi All,

I have the same issue with one of my Sonoff devices. I have more than one on the network.

Platform esphome does not generate unique IDs. ID bh_sonoff02switchmain_garage_lights already exists - ignoring switch.main_garage_lights Platform esphome does not generate unique IDs. ID bh_sonoff03switchstairs_light already exists - ignoring switch.stairs_light

With bh_sonoff02 I usually need to disable then enable the device after every restart otherwise the device is not available to home assistant but it is showing green in the ESPHome page.

Happy to help with diagnosis if someone can point me in the right direction.

[ptr727]

Just noticed the same issue, happens with two Sonoff TH10's named "sonoff_th10_garage_fan_1" and "sonoff_th10_garage_fan_2".

HA reports:

2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.climate] Platform esphome does not generate unique IDs. ID sonoff_th10_garage_fan_1climatesonoff_th10_garage_fan_1_thermostat already exists - ignoring climate.sonoff_th10_garage_fan_1_thermostat
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.sensor] Platform esphome does not generate unique IDs. ID c82b96069b29-uptime already exists - ignoring sensor.sonoff_th10_garage_fan_1_uptime
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.sensor] Platform esphome does not generate unique IDs. ID c82b96069b29-wifisignal already exists - ignoring sensor.sonoff_th10_garage_fan_1_wifi_signal
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.sensor] Platform esphome does not generate unique IDs. ID dallas-4E3C01D075B62428 already exists - ignoring sensor.sonoff_th10_garage_fan_1_temp
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.sensor] Platform esphome does not generate unique IDs. ID c82b96069b29-wifiinfo-ip already exists - ignoring sensor.sonoff_th10_garage_fan_1_wifi_ip
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.sensor] Platform esphome does not generate unique IDs. ID c82b96069b29-wifiinfo-ssid already exists - ignoring sensor.sonoff_th10_garage_fan_1_wifi_ssid
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.sensor] Platform esphome does not generate unique IDs. ID c82b96069b29-wifiinfo-bssid already exists - ignoring sensor.sonoff_th10_garage_fan_1_wifi_bssid
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.sensor] Platform esphome does not generate unique IDs. ID c82b96069b29-version already exists - ignoring sensor.sonoff_th10_garage_fan_1_version
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.switch] Platform esphome does not generate unique IDs. ID sonoff_th10_garage_fan_1switchsonoff_th10_garage_fan_1_restart already exists - ignoring switch.sonoff_th10_garage_fan_1_restart
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.switch] Platform esphome does not generate unique IDs. ID sonoff_th10_garage_fan_1switchsonoff_th10_garage_fan_1_relay already exists - ignoring switch.sonoff_th10_garage_fan_1_relay
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID sonoff_th10_garage_fan_1binary_sensorsonoff_th10_garage_fan_1_status already exists - ignoring binary_sensor.sonoff_th10_garage_fan_1_status
2021-07-25 16:12:56 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform esphome does not generate unique IDs. ID sonoff_th10_garage_fan_1binary_sensorsonoff_th10_garage_fan_1_button already exists - ignoring binary_sensor.sonoff_th10_garage_fan_1_button

[bundabrg]

Is there a work around for this? I have missing devices and devices that are linked to each other possibly due to IP address changes. Should I just statically assign my IPs?

[poldim]

Getting one occurrence of this on one of my devices. This only happens on the one reboot switch on this device, and none of the other 5 switches on the same device. Searching my entire HA config folder for the ID only finds the two results below:

Source: helpers/entity_platform.py:592
Integration: Switch (documentation, issues)

Platform esphome does not generate unique IDs. ID esphome_powerstrip_dk_deskswitchdk_desk_powerstrip_reboot already exists - ignoring switch.dk_desk_powerstrip_reboot

[chbarg]

Hello, it seems like the MQTT variable discovery_unique_id_generator: mac does not work for sensors. I use it like this:

mqtt: broker: 192.168.3.200 username: mqtt password: mysecret discovery_unique_id_generator: mac

My sensors are getting the same unique ID and HA does not like it.

Any suggestions?

Thank you

[Hohenloherin]

2022-04-03 12:35:27 ERROR (MainThread) [homeassistant.components.switch] Platform esphome does not generate unique IDs. ID esp32-hofswitchhof_oeffnen already exists - ignoring switch.hof_oeffnen

It works well, but I repeatedly find this error in the logs of the core. After setup of the ESPHOME integration and the first steps with the ESP32 I had to change the script and redefined the switch's name. Since then I find these error messages.

[ssieb]

You need to remove the old device from the HA integrations list.

[Hohenloherin]

What I did now twice without success: I deleted the esphome integration restarted ha and added the integration again. Or do you mean delete the device completely from the devices list?

[ssieb]

What do you mean by "delete the esphome integration"? The esphome addon? I mean that you should delete the device from the esphome section of the Devices & Integrations page on HA.

[Hohenloherin]

This is exactly what I mean too and what I did, but this does not help. There must be somewhere else another place where something goes wrong. Any other hints?

[swifty99]

Hi, same here, I do not want to intefere in the Home Assistant internals. However I tried a lot to get rid of:

Platform esphome does not generate unique IDs. ID gastzimmerbinary_sensordrucker_versorgung_an already exists - ignoring binary_sensor.drucker_versorgung_an
Platform esphome does not generate unique IDs. ID gastzimmerbinary_sensorgast_anwesenheit already exists - ignoring binary_sensor.gast_anwesenheit
Platform esphome does not generate unique IDs. ID gastzimmerbinary_sensordrucker_tr already exists - ignoring binary_sensor.drucker_tur
Platform esphome does not generate unique IDs. ID gastzimmerbinary_sensortaster_gast already exists - ignoring binary_sensor.taster_gast

These error messages are kind of persistant. And yes, I removed the integration a lot of times, reflashed, whatso ever. I believe the problem is somewhere in the "unique" ID generation. I reflash and reuse ESP things a lot. Old sensors show up with new devices (disabled as not existant anymore) if an old board is reused. I found no way to remove them. For me it looks like MAC adresses are used and unique is not so unique. Guessing here.

Jan

[poldim]

These error messages are kind of persistant. And yes, I removed the integration a lot of times, reflashed, whatso ever. I believe the problem is somewhere in the "unique" ID generation. I reflash and reuse ESP things a lot. Old sensors show up with new devices (disabled as not existant anymore) if an old board is reused. I found no way to remove them. For me it looks like MAC adresses are used and unique is not so unique. Guessing here.

Yes, I think these messages happen if you've repurposed a previously used ESP for something else.

[dflvunoooooo]

These error messages are kind of persistant. And yes, I removed the integration a lot of times, reflashed, whatso ever. I believe the problem is somewhere in the "unique" ID generation. I reflash and reuse ESP things a lot. Old sensors show up with new devices (disabled as not existant anymore) if an old board is reused. I found no way to remove them. For me it looks like MAC adresses are used and unique is not so unique. Guessing here.

Yes, I think these messages happen if you've repurposed a previously used ESP for something else.

I have the same problem. How do we get rid of this problem?

[Hohenloherin]

Last days I was looking for an esp32 which I flashed with adapted and updated yaml. To my astonishment I couldn't find this esp32, call it esp32(1), anymore in ESPHOME. I used the espressif website https://espressif.github.io/esptool-js/ to erase the brick and reflash it with the yaml/bin again. It just appeared in the wlan network but did not pop up in ESPHOME. I started to flash the same yaml on a new esp32, call it esp32(2), with same manual IP address, same result, no esp32 popping up. Nothing. Took back the old esp32(1) and what I wonder as a sudden my esp32cam which I broke recently showed up as present. But it is physically not connected to power it's just in a shielded bag on the desk, unable to connect to any network. I then opened the core.config_entries file and looked for the ip addresses of these esps. To my surprise I found no more esp32cam in it, but several versions of the esp32(1) and of course the esp32(2).

Then I looked into the file "core.device-registry" and found there also the entries of the mac-addresses:

        "area_id": [ "hof" ],
        "config_entries": [
          "7ef877658f00bdb590030434ffdd79f6",
          "0a31f08df69d54ab382f63c6f8dd311a",
          "0bf48b43881146354a53e84d3276b8a7"
        ],
        "configuration_url": "homeassistant://hassio/ingress/5c53de3b_esphome",
        "connections": [
          [
            }, "mac",
            "95:b5:65:2c:3a:98"
          ]
        ],
        "disabled_by": null,
        "entry_type": null,
        "hw_version": null,
        "id": "4f1ef63a86b916a9083d7d1d4d00669f",
        "identifiers": [
          [
            }, "fritz",
            "95:b5:65:2c:3a:98"
          ]
        ],
        }, "manufacturer": "espressif",
        }, "model": "esp32dev",
        }, "name_by_user": null,
        }, "name": "bt-zaehler-tor",
        "sw_version": "2023.2.4 (Mar 14 2023, 21:18:51)",
        "via_device_id": "221791cfebad9b00839e8d1ad6ee2c6b"
      }

I can now also confirm that the mac address is indeed used to identify the devices and also the entities.

It's about time, I think, that Homeassistant provides us with a way to delete devices and entities completely again, if it is possible. Otherwise we will see these problems again and again.

[bdraco]

Home Assistant changed the unique id format in 2023.11.x to fix this issue. If you still have a problem, please delete and recreate the config entry. If that doesn't fix it please continue at https://github.com/home-assistant/core/issues/new/choose

[Joshfindit]

@bdraco can you provide a link to the documentation or code about that change?

[bdraco]

https://github.com/home-assistant/core/pull/99451