I have a naming system. It has worked well for 8 years. Now you are forcing me to change this and ruining my carefully laid out dashboards.
I understand creating a structured naming scheme for new users is beneficial but there are many existing users that do not need or want this. Make it optional.
Are you talking about entity naming (which is fully configurable)?
I’m talking about the upcoming November release.
I also have a naming scheme that works remarkably well for me, after many trials over the years.
In my case, I have a rather techie naming system for referencing my devices, purely for maintaining the system, but the entity names are driven by what makes sense when talking to the voice assistant. And that varies by device/entity; example- there’s no point in qualifying the area for “Clothes washer Cycle done”, but I do need to specify the area for “Laundry room ceiling light”. Besides voice assistant, this also makes entities nicely findable for automations, etc. And I tend to disable entities that I don’t use, so I really don’t care what names the system assigns to those.
I hope this doesn’t all get disrupted next Wednesday; we shall see.
And the planned deprecation of friendly names will wreak havoc on legacy template sensors and automation where friendly names were used more frequently.
Yes! I also name my devices and entities somewhat similarly, with more descriptive device names but entity names that are as short as possible.
Enforcing name concatenation is a terrible, terrible idea. It perhaps makes some sense for purely configuration/diagnostic entities, where the names are very seldom customised. But absolutely not for controls/sensor entities.
If HA insist on making this the new default, please give us opt-outs on both a global level and per entity. For me personally, the per entity opt-out would actually be the best solution, but a global toggle is also really required.
Otherwise this change is downright unacceptable. Personally I will have to resort to Device-Tools for making new pseudo-devices that certain entities are moved to, in order to preserve a naming scheme that makes sense to me.
Took me about 10-15 minutes to go through all my dashboards and remove the “device” tag from each entity name. It’s pretty easy with a click for each one, but a waste of time that should not have to be done. Turn it off by default and let people who want it turn it on. Also if you use auto entities in your cards it can do the whole card with one click.
Just want to add my 2¢ and hard disagree. The entity naming changes are long overdue and will be a big improvement for HA in the long term.
Why will it be an improvement, when something gets lost?
I strongly disagree; I believe this one’s going to land (with a resounding THUD) right up there with the original implementation of Backup… We’ll see. I am against both the forced nature of this change and HOW it’s being implemented. Im already having problems with ents that are perfectly valid and apparently if they don’t inherit the area of parent then you need to do something additional (to something that’s been valid for years) to make it valid again? But also, Beta is ‘too late’ for anything to change or get pulled in a release - sooo. We just gotta see how it lands with the user community. (I’m pretty sure the user community as a whole, sans a few who frequent the community site, has no idea)
The goal is unclear (ok make it better - i still fail to see how this does that) THey ahve not explained the WHY at all.
I to some degree I agree.
BUT, the focus is always the new users.
Everything is done for the new users, EVERYTHING!
And a lot is at the cost of long term users.
There was a time when new devices generally was named by the manufacturer, so it could be Sonoff X and then you might name the entity, or you just gave it a friendly name.
I still have a few devices that I just haven’t bothered changing the name on, they are still named Sonoff or IKEA.
Then when you used them in automations or cards you just took the friendly name so it could be "{{ state_attr('binary_sensor.xxx', 'friendly_name') }} door is left open".
I understand that with the new naming this no longer is needed, but why should I be forced to backtrack my full installation and figure out what will break du to this change.
Why can’t it keep it for legacy devices and entities.
Sure, we don’t fully know what the deprecation of the friendly name means but it’s a constant worry.
Every new release you think, what are they going to break for us now.
It didn’t use to be like this, and it shouldn’t have be either.
In case anyone is reading this, and doesn’t understand the context:
(Not sure if this is or how it might impact me, I’ll find out next week :))
The Home Assistant 2026.11 release introduces a backward-incompatible change where entity display names are now composed from the device name and the entity name (e.g., “Thermostat Temperature” instead of just “Temperature”). This shift aims to provide consistent context across the system, meaning cards, badges, and rows without explicit names will automatically show the device name followed by the entity name.
Key aspects of this change include:
Entity IDs remain unchanged, ensuring existing automations, scripts, and dashboards continue to work without breaking.
Voice assistant compatibility is preserved by keeping old displayed names as aliases, so commands like “turn on the ceiling light” still function.
Template updates are recommended, as the friendly_name attribute is planned for deprecation; users should switch to entity_name(), device_name(), or area_name() functions in templates.
User controls include the ability to rename the device to affect all its entities, enable the “Main entity of the device” setting for primary controls, or set explicit custom names on dashboard cards to override the default composition.
This change is part of an ongoing effort to eliminate the need for users to manually include location or device information in entity names, as the system now handles this context automatically. The stable release is expected on 4 November 2026
The problem occurs if an existing user has already included this information manually before this automatic naming scheme was introduced.
This leads to unwanted duplication in the names. e.g. Upstairs Faikin Climate Upstairs Climate, instead of just Upstairs Climate. It will mess up your dashboards.
It’s not difficult to fix, just time consuming annoying and authoritarian.
If you are going to go ahead with this forced concatenation then please at least add a check for repeated strings first. I often seen entity IDs like light.lounge_lounge_downlights
This should be really easy to avoid.
Yeah. Don’t do it. Easy.
Its just the entity names though? The user fronted “display” names remain the same?
I just looked at some of my entities, and strangely they already seem to have device added to the front of the entity name.
What will break if the hidden identity names have something changed on your setup? (seems like a nothing burger to me, but have you guys got custom scripts or something that need specific entity names that will break or something?)
I don’t see anything different in your images.
How so? I think a ton of people do not understand this change and are just talking out their butts. Template entities only populate friendly name variable in attributes. So the only current linkage to friendly_name is that it exists in the entities attributes. If you reference that attribute on the state object, that’s the only thing that would break. But again, that’s not contained to the template entity. That’s confined to any time you attempt to access the attribute friendly_name from a template itself. The replacement for that is entity_name filter/function.
Even then, template entities are able to set attributes. After the deprecation, you can just add the friendly_name attribute back.
Yes.
A lot of more advanced automation has that.
