Please rollback entity ID recreation with area ID as prefix

[vint66]

The problem

Could you rollback the #170560 or make area ID optional to ignore it.

• It is making it impossible to auto-fix entity IDs which is used to be so useful to clean up a mess in case of large set of entities.
• It is breaking a lot of stuff in existing dashboards as now entity got changed.
• It is not suitable case where device could change room or be moved
• 'recreate entity ids' is dangerous and could not be used

What version of Home Assistant Core has the issue?

core-2026.6.0

What was the last working version of Home Assistant Core?

core-2026.5.4

What type of installation are you running?

Home Assistant OS

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response

[kattcrazy]

I have an integration that can assist with the issue of the changed entities and broken dashboards: Lost Entity Finder. I do think that area shouldn't be included in the entity ID personally, but it's not up to me!

[septillion-git]

Although I like the area in the entity id, because it used to be a lot harder to see the area in the past I already have the area in the device name. And apparently a lot of people with me.

So I think:

• a change like this shall not happen this quietly
• Would be a very good idea to at least build in a check the area isn't already in the device name

[vint66]

The system used to have perfect balance in this area by maintaining clean hierarchy - area, device, entity. Apart of rare case where entity does not have device.
These days HASS shows area entity belongs to (in dashboard) and has methods to get entities of an area.

I'm not sure about motivation of this change, but it this is popular request can it be at least configurable feature please.

[DaveOzzie]

My light.kitchen_light_1 was renamed light.kitchen_kitchen_light_1.
Is this a bug or does someone think this is a good idea?

[kattcrazy]

My light.kitchen_light_1 was renamed light.kitchen_kitchen_light_1. Is this a bug or does someone think this is a good idea?

Second option

[balloob]

Entity with unique IDs (99% of entities) reserve their entity ID the first time they are added to Home Assistant and will get the exact same entity ID when loaded in the future. This means that this change only impacts new entities, it will not break existing dashboards or automations.

For people that are sharing that it breaks their workflow, can you explain how often you add new integrations and how this particular change impacts the things you do?

[septillion-git]

That makes it especially breaking. As I do regularly add new devices. That means that

• OR i have to break my naming convention I have used for nearly 10 years
• OR those new devices get ridiculous entity id's

And yeah, if I would start today, with how visible area's are now in the UI and pickers, I would probably not prefix the device name with an area anymore. But that wasn't the case when I started so for me and others is was a very logical naming convention. Especially because entity id's where not prefixed with area which would otherwise give you "light.bulb" and "light.bulb_2" for two bulbs in different rooms. And with a complete setup of nearly 300 devices that's also not something I'll change in an hour now. And I'm clearly not the only one.

So yeah, I do like the prefix if you start out now. Same with device name as prefix for an entity. Leads to better entity id's. But for older users this leads a bit to a split.

So I think a good middle ground would be to:

• Have a system setting for it
• Or do a check if the device name already starts with the area name, if so, don't prefix.

Think the latter would be easy and universal to implement.

[vint66]

The change does not break anything unless entities are regenerated.
It could happen due to following reasons:

• A device was added with one name (let say Tesla), then was renamed (as Model Y) and finally more entities of that device were enabled. E.g, Teslemetry with tens of entities.
  • I usually regenerate entity names in this case to have them named using the same pattern.
• Integration could have extra entities added with an update.
• A device got moved in between areas. E.g. soil moisture for plan as plan might move over the house without me even knowing it :).
• A device has an area name in there. This will double prefix their entities and limiting flexibility to name device (unless one doe s not care about double prefix).

Those use cases above are actually quite common, at least for my setup, so I used to regenerate entity IDs in bulk for all entities in the system.

@balloob could you add more context on why this change was approved? Are the any plans, changes coming needed this? It is breaking logical relationship as commented in the #173125 (comment) where Area now got into entity which does not have direct relationship to it.

[bcat]

A few thoughts here:

• Logically, I don't understand the naming pattern anymore: It made sense to me that entity IDs were named device_property, because the property is intrinsic to the device. I'm not going to take the temperature sensor from one thermometer and physically move it to a different one.
• But area is not coupled to device in the same way. I can (and do) move devices between rooms, and it's odd to me that means their entity IDs will then be outdated.
• I don't add new devices all the time, but I do try to keep my naming scheme consistent. Which means regenerating entity IDs if they've deviated from the standard.
• Perhaps, purely for Home Assistant, I should just strip the redundant area out of device names. But 1) not all my devices have it (just the ones where it makes sense), and 2) I don't only use Home Assistant to control devices.
• This last point is critical to me: I primarily use Google Home and Philips Hue for device control, and having the room name in the device name (sometimes!) really helps out there. HA is additive, to me, and so I don't want to change my naming scheme (going back years) just to make its entity IDs less silly looking.

Given the amount of tension and stress that entity ID discussions cause, why not make this configurable? Choose whatever HA maintainers think makes sense as the default, but let users use template syntax for the ID generation if they want something different.

[kattcrazy]

In my setup, I do frequently either reset entity ids, add new device, or add new intergrations.

I absolutely understand having the device name in the entity id, as @bcat said I'm not going to move the entity between devices. However the area is entirely different. It's like putting the label in the id. It's a field that could frequently change.

On a intergration page, it lists devices as [DEVICE NAME]. If I were to name my devices like 'Light Bulb" so that the entities were then less repetitive, without the area prefix, I wouldn't have a clue which room it belongs to because area is not shown quickly, only when editing.

My suggestions are
(a) Remove the change as it doesn't appear to follow the roadmap anyway OpenHomeFoundation/roadmap#73 (comment)
(b) Make it optional
(c) Anywhere the device name is shown, show area too

I don't mean to create stress, but I think this was a change that should have been properly discussed.

[FalconUK]

It seems likely that this issue, or something related to it, has broken all of my template helpers, on first adding a new template helper in 2026.6.1.
Now, all of my template helpers, and a few other types of helper (sum, derivative, change device type of a switch, statistics, filter) , aren't fully editable in the Helpers GUI, and I have no way of fixing them.

Sensors appear to be given different auto-created names, based on when I set either the area or the associated device, when I first created the helper, or after - without telling me. So I now have:

• sensor.outside_backgarden2_back_garden_2_snapshots
• sensor.driveway3_driveway_3_snapshots

Whereas all previous helper template sensors were just called sensor._snapshots, without any issues.

[chaddugas]

I am also not a fan of this change. Every single device in my house is already prefixed with the area name in the device name. I have been really strict about device naming convention and entity_id hygiene and this change kind of breaks that whole thing apart for me in several ways:

1. Any new device I add I either have to manually change every entity id to remove the double area name in the entity id, or I have to drop the area name from the device.
2. I frequently use the recreate entity ids tool when adding a new device, when moving a device to a different part of my home, or just because I decided I want a different name for the device. Now every time I use it, it wants to change all the id's to something like [domain].living_room_living_room_floor_lamp_rssi or whatever.
3. I also frequently use the recreate entity id tool to check for any entities that may have snuck through that do not match their devices friendly name. Previously if I went to entities > select all > recreate entity ids of selected, I would occasionally have like three or four entities that needed to be updated. Now when I do that on the entities page I get 1122 entities that are going to be renamed.

I don't particularly want to go back and remove the area name prefix from all 227 devices I have in my home. Partly because that sounds like a pain - I am sure I could write some python to automate it, but I don't really feel like I should have to do that. But mostly because I also use the area name in the device name to disambiguate between devices visually when they are in a list. Otherwise I have like four lights all named 'Floor Lamp' that I can't tell apart.

Anyway, I agree this should either roll back, be optional, or the logic to append the area slug should check for the existence of the area slug at the start of an entity id before adding it.

---

Edit to add: it's funny that in the PR that made this change, there is a comment saying this is going to cause "frustration from users", but then everyone was basically told to shut up because they didn't like getting notifications about the discussion.

[kattcrazy]

Edit to add: it's funny that in the #170560 that made this change, there is a comment saying this is going to cause "frustration from users", but then everyone was basically told to shut up because they didn't like getting notifications about the discussion.

Did see that the discussion was a little... unfruitful!!

[jamesmyatt]

In my opinion, this is a big surprise and annoyance to existing users. We've all planned our set-ups around the area name not being included in the entity IDs. For example, device names are already unique (often automatically) and area names being verbose and intended for UI (e.g. "James's Office"). Areas might be set or changed after the device has already been added and commissioned, especially for integrations that create devices automatically, leading to inconsistencies. Otherwise, there's lots of manual work to update (automatic) device names and areas and regenerate IDs and reflect the new IDs into dashboards and automations and scripts.

While something like this is probably a good principle in the long-term, it really should have gone through Labs and user feedback first. It should probably also have waited for features like purpose-specific triggers and dashboard strategies, which make entity IDs less important, to mature and embed in the ecosystem before being shipped.

For me, though, this further embeds the falsehood that every entity is associated with exactly one area. For example:

• A heating zone usually covers multiple areas.
• A light or sensor (e.g. temperature or presence) in an open-plan space might belong multiple areas (e.g. kitchen vs TV vs dining). Or am I expected to put all of the devices into one massive combined area?
• An internal door state belongs to the two areas that it leads between (e.g. kitchen-lounge); if it's wired, then the associated hub is associated with a third area.
• What's the expected area for a mobile device? Is it the area that it's currently in, the area it's most often in, the area whose dashboard I want to see the sensors on, a virtual area called "Mobile", or no area (with the associated warnings)?