I’m unclear what to do with this new naming convention. I’m guilty of naming my devices “Family Room Fan”, which is mixing an area and a device, of course.
And I assign it the “Family Room” area. So, now my entity IDs look like this:
button.family_room_family_room_fan_stop
I agree with separating them (and in this case I’d just call my device “Fan”). Making “area” an integral part of the name makes sense, but what I find a bit baffling is that areas are not a required field on an device.
Is the idea (and the recommendation) to name devices “Fan” and assign an area? If so, shouldn’t the area be required?
I’m just curious how others are dealing with this change. I mean, button.family_room_family_room_fan_stop just isn’t great naming.
Either Rename the Device/entities manually, Or
Set your Naming-Strategy, to exclude “Area”
In /Settings/System/Entity-ID-Format, You un-tick “Area”
Then you go to your Device, and Rename-It, then you click the 3 dots, and “Recreate-Entities”
If that doesn’t work, you can Delete the Device and Add it Again, still using only " Device / Entity " in Your " Entity ID format ", and it should be renamed as you want
Ok, thanks all. I’m aware of how to rename entities and changing the new format.
Seems like with that 2026.8 change the “team” is pushing to make areas more first-class, which would make sense. Are they going to make areas required?
The default is now to have an area prefixed, so are the devs thinking “Name you device ‘Fan’, not ‘Living Room Fan’”?
The problem there is HA moves devices to “deleted_devices” in the entity registry and then when you re-add the device (and maybe this is dependent on the integration) it will use the same unique_id and then HA will “restore” what was used before.
I just went though that and had to manually edit core.entity_registry to clear out old “deleted” entities.
I Hope Absolutely Not , i think they just thought it was a good idea to add it be default, You can remove that one, but not Device/Entity
Your Second question, sounds absurd , but i don’t know how the Devs actually think, in this case i believe , they didn’t think.
But yes Spite many people Don’t Use Areas, or Just in Some cases Use Areas, Some Not, it does seems like they either don’t really know their Userbase, or they want to force all into using them everywhere ( Thinking like them, thou i doubt they think so )( Which bring us back to my first thought, They didn’t think
( I have lots of device/entities i Don’t want in Any Areas, And Don’t want populated to their in-famous Pre-Populated-Dashboards )
gee, why do you bring up these questions to me
Yeah, this is another “hiccup” in my opinion, wth is the point in saving “deleted” Devices, They Are freaking Deleted for a reason !.
This is another Idea, which just mess things up for people, maybe they thought of a scenario where ( Their New Prioritized Customers ) accidentally deleted, or regretted or what ever, And so to make it easier for “Some” they save this info there ( as it in many cases also still are entries in the DB )(if people don’t clean out there)
As i said, i Really Don’t Know How they Think, It’s just making it a PITA to save such, for No Good Reasons !
Yeah, have to wonder why you would restore something explicitly deleted – I suppose because the entity_id is used as the meta ID in the DB, so it’s kept to retain history. (Maybe update the meta ID instead to the new entity?)
There’s also the “_2” issue. Obviously, if a device is added that wants the same entity ID there’s a conflict to resolve. Currently that happens silently. I have an issue now with a zooz plug (where it reads 0.0W and 13A at the same time!) and re-included to see if that would fix it. I forgot to delete the device and the device came back with a bunch of _2 entities and a bunch of automations just didn’t fire for a few days…
I feel when a _2 happens a warning should be shown to the user.
Unless “someone” explicit insisting naming their entities with a _x(number)
But yes, a warning, that a devices already have an entity with that name/suggesting rename … ( Sometimes i actually seen this , “entity already exists” when trying to i.e rename, but apparently not when things happens “under the hood”
( it’s like … oh shit, wth we put a trailing _x after …done, finished, satisfied ?
( I ones installed 10 aqara temps, in a batch as they were in the aqara hub i added(they were named there differently ! ) … In HA, Same lame looong name, with repeated words and only difference was trailing _1-10,
So maybe that’s why they came up with the idea adding Area into that equation ( Thou abit hard as they have to be installed in the integration first before adding them to an Area ) , same with my Ikea Device, i add the HUB to an integration All Devices in a Batch … They simply hasn’t “reviewed” All scenarios now when they Want To Unify HA, for simplicity reasons(for someone), which is a lame cause. They fu for people, and time changes UI’s, Ways of Working/ Thinking, and What’s “modern” or mainstream etc. etc.
In 5-10 years those current dev-teams move on, and new devs/idea comes in …and here we go again !!!
I’ve just stopped caring what my entity_id format is. I have my Entity ID format set to {device}_{floor}_{area}_{entity} and if it’s going to be used in the front end I can give it a name (retrievable with entity_name()). Add appropriate Labels on everything I need to manipulate and I’m good to go.
The only person that’s ever going to see them is me, and as long as the format is sensible how they sound, or read, is simply irrelevant to me.
I didn’t start off this way, but once I started writing scripts where I avoided any hard coded entity ids it just stopped mattering.
One reason ifor not making area mandatory s that some devices don’t need an area, or to give them one might be confusing eg a mobile phone or a health device, or a robot vacuum cleaner.
Other way round. 2026.8 added the ability to control which properties of the device made it into the name. A couple of releases before that, area was indeed a mandatory part of the name & people complained (with good reason), since there was no way of controlling it.
All the new menus and lists show the entity name, area name and device name. The idea behind the new system is that you don’t need to add the area name to the device name because of this reason. Keep the device name as-is, attach the area and generate the entity_id.
Of course, you can ignore this and remove area from the entity id generate and just go with device name and entity name.
I wonder if voice assistants isn’t also a reason – because they are (sometimes) aware of their “area”, so you can walk into a room and say “Turn on the light”, as one normally would say.
Well, implementation details are not quite there… Doesn’t seem that the area is translating into “Groups” in Alexa. [1]
3rd party apps can’t create groups in alexa. It’s always been this way. 3rd party apps will create “grouped devices” that show up as the device type. Home assistant does not do this.
, but i don’t know how the Devs actually think, in this case i believe , they didn’t think.
