Guys, it’s the weekend. Relax. People aren’t working. And do not tag people to demand responses.
1 Like
ESP-Home developers never stop amaze us.
The amount of undocumented breaking changes is too much now.
In the past at least it would only affect what you compiled but now they found a new way to screw us.
2 Likes
I tried removing the customisations after fixing the names and for me they reverted back to “wrong” names after a restart. I’ve put the customisations back in place.
4 Likes
I was following the second, post update procedure
1 Like
I’m surprised this change went in and that it wasn’t flagged as a Breaking Change or mentioned in any way in the release notes.
I understand the change, and for the most part, I agree with it.
However, I have an ESPHome based security system that I made years ago before Konnected.io was available. Now every entity has a “Security System ” for the frontend name. The change seems to assume that each ESPHome device only covers a single area.
This makes the integration more confusing as each entity needs to have a name override.
Sorry for this question but I’m a bit confused. I understand Petro’s solution since I’m using the customize.yaml for entities that are not defined in the UI like for instance the Utility Meters. So I don’t mind to make all the changes in all my ESPs (and take the chance to upgrade them to a newer version) but I need to know what I need to change on the ESPHome yaml to avoid this impact on Home Assistant 2025.5.x. I’m a bit concern of the change on IDs if it is the case.
I can share some examples of my devices if that helps.
Thanks!
Entity_id’s do not change, once they are registered they remain in tact. Names are a bit different. There is the default onboarding name, and then a name that’s overridden by the user. What was updated here is the default onboarding name. So if you never added your own name, it will appear as if your name now has the device in front of it.
1 Like
Note however that this is not long-term solution. Ok, it is if you set-and-forget your devices, which i don’t; i often change some stuff, add, remove…
So, am i now stuck with editing customize.yaml each time? 
2 Likes
Alright about the ids it is clear. I never changed the on-boading names in Home Assistant. Example:
This entity:
is defined in ESPHome as
substitutions:
devicename: daikin-air-sensor-floor-1
friendly_name: Daikin Air Sensor Floor 1
device_description: DAIKIN Air Sensor BRY88AB151K
esphome:
name: $devicename
comment: ${device_description}
.........
sensors:
- name: "${friendly_name} CO2"
id: daikinco2
accuracy_decimals: 0
unit_of_measurement: "ppm"
device_class: carbon_dioxide
.........
another example:
esphome:
name: solenoidevalve1s
friendly_name: Valvula Solenoide Lateral e Traseiras
on_boot:
then:
- switch.turn_off: solenoidevalve1s
.............
- platform: template
name: ""
id: solenoidevalve1s
optimistic: true
turn_on_action:
- uart.write: [0xA0, 0x02, 0x00, 0xA2] # turn off relay 2 avoid both ON
- delay: 500ms
- uart.write: [0xA0, 0x01, 0x01, 0xA2] # turn on relay 1
- delay: 500ms
- uart.write: [0xA0, 0x01, 0x00, 0xA1] # turn off relay 1
turn_off_action:
- uart.write: [0xA0, 0x01, 0x00, 0xA1] # turn off relay 1 avoid both ON
- delay: 500ms
- uart.write: [0xA0, 0x02, 0x01, 0xA3] # turn on relay 2
- delay: 500ms
- uart.write: [0xA0, 0x02, 0x00, 0xA2] # turn off relay 2
on_turn_on:
- script.execute: failsafe
on_turn_off:
- script.stop: failsafe
script:
- id: failsafe
then:
- delay: 15min
- switch.turn_off: solenoidevalve1s
As you can see I’ve never gave names is HA and if it is possible I would like to keep that approach even that I have to change all the ESPHome devices fw.
In short my question is what changed is needed in the ESPHome yaml to keep the actual names?
Hm… it’s not. I’m just exploring my odds… if i write this code:
esphome:
name: my_device
friendly_name: my device
then i set a sensor:
sensor:
id: my_sensor
name: my sensor
...
How will this sensor look in HA? Ok, name will be “my device my sensor”. But what will it’s ID be?
Will it be
- “sensor.my_device_my_sensor” or
- “sensor.my_sensor” ?
So, is it now for proper id a must to have our own prefix ${my_device}? Ok, i do have such prefixes for id’s now and all is as i want it, but i’ve had the same system for my naming, too, but it turned out that now it’s all fu**ed up… so, i can expect that something similar can happen with id’s… ???
What’s “official proper way” to name id’s (if any at all)? It would make sense that if we’re forced with auto-add name prefix that HA also auto-adds id prefix… either all or nothing.
1 Like
Both will be my device my sensor if you’re adding this to the system for the first time. If it existed and you updated and you didn’t overwrite the name: the name will be my device my sensor and the entity id will be whatever it was prior to update. If you overwrote the name, nothing will change.
1 Like
Thanks, i’ll test this with a new dummy device then…
So, for new designs it’s something we’ll have to take into account, which is… ok, acceptable. What’s bad is that i have appr. 40 devices which now need reprogramming… 
Also, there are cases where this could be the problem… for example:
bedroom climate: if i set friendly name of my esp module to “Bedroom climate” and id to “bedroom_climate”, i wonder what can i put for ID of my “climate” sensor since i’m stuck with “climate.bedroom_climate” (which is fine, btw). But what i mean is: i need climate’s id for internal operations inside esphome’s code. So, whatever i put it will be added to the end…or will it?
Pavel, you’ve made your opinion clear about 15 times now. You don’t need to keep repeating yourself.
1 Like
No, you got me wrong. it’s now about opinion (anymore), it’s just searching for solutions.
See the solutions I posted above, the one marked with the check.
Yeah, i did that already and i thank you for that, but for the future (for new devices) i was looking for somewhat more elegant solution out of the start, not just “correcting wrongly set program”…
1 Like
Every ui integration right now follows this paradigm. Claiming it’s wrongly set is disingenuous, it’s just not something you like. At this point we should understand that esphome is unique in that the chip can interface to multiple devices and that should probably be accounted for. Also, with the upcoming device changes, we are likely to see new naming options in the ui/frontend to account for situations like this.
As for your question, you’ll likely have to get inventive to make the device name hidden during the onboarding of a new sensor.
2 Likes
It’s not something I like either. In fact I think it is downright stupid having to rename all my entities twice.
How is that in any way “smart”?
5 Likes
I understand it’s not ideal, but every other integration that provides devices does this, esphome was the only one that didn’t. Consistency is key and esphome was not consistent with the rest of HA.
A few breaking changes as possible should be the key.