P if it looks like it changed the user will see it that way period. You know this. This isn’t doomsday it’s reality yih know why I raise issues like this. Another lead balloon.
Sure, but it’s not, so don’t say it is 
That creates a false understanding of the situation.
2 Likes
Update: I just reread the release notes and is this only about friendly name rendering? That is the device name isn’t stored with the entity, it’s just when rendered?
Question about this:
This inconsistency has been one of the most common sources of confusion in Home Assistant, and one of the most frequently discussed topics in our community. Starting with this release, we’ve made this consistent. Entity names now always include the device name as context, whether the name was set by an integration or by you. Renaming that entity to “Ambient temp” will now produce “Motion Sensor Ambient temp,” just as the system would for integration-provided names.
This means you cannot rename the entity w/o having the device name prefixed? And the entity name is always tied to the the devce name?
Doesn’t that completely break the abstraction between devices end entities?
I have a number of devices that have completely unrelated entities. Think of an ESPHome device (that I really have) that is named “Garage ESP32” and has the garage temp, has a relay for a irrigation valve in front of the house, a motion sensor on the porch and controls a light and motion sensor in the laundry room.
This happens: I decide to split off the laundry light to a different device and now I have to rename my entities because the device name is now tied to the entity.
The beauty of the entities is they can be absract things (light.laundry_room) and what device runs that can be changed w/o breaking things.
Entities (mostly) belong to a device and thus you can always get to the device page from an entity.
2 Likes
Uhhuh and your turn to buy the popcorn my friend… Will be VERY bad
Perception == reality (from the user filter… Always, even if not true)
This one needs at LEAST a month of user education.
And again, you’re basing all your comments off what we’ve gathered so far in beta and you’re making comments like this is set in stone. It is not, please wait and temper your comments.
Sooo we are not supposed to comment? How do we get feedback in. And with that no I will not put it on my system. So?
1 Like
Correct, which is where all the push back is coming from.
However, to play devils advocate, if custom cards use the new system for presenting names (where the user chooses via a field which name to show), this will be a moot point. Because these custom cards can default it to the user set values not the friendly name.
I’m currently pushing for the friendly_name to just be the entity name (which doubles as the user set name). Hopefully this will go through and then no custom cards will need to be updated for the time being. It will also keep templates the same without needing to move to entity_name.
1 Like
You can comment, but all you’re doing is saying “OMG LETS GET POPCORN”. That’s not feedback, that’s causing a scene.
We all want whats best for this, including the developers. So lets try to have a normal conversation.
4 Likes
And I have three dashboards full of custom cards that don’t now? The feedback is don’t it’s gonna hurt lemme get the popcorn…
Correct, custom cards are likely using the state object name (derived from friendly name) or the friendly_name under the hood, not the new system that was introduced a couple of versions ago.
And to be clear, w/o a device name override, this entity:
➜ .storage jq '.data.entities[]|select(.entity_id == "sensor.zen_15_lefty_electric_consumption_a")|{entity_id,original_name,name}' core.entity_registry
{
"entity_id": "sensor.zen_15_lefty_electric_consumption_a",
"original_name": "Electric Consumption [A]",
"name": null
}
with this template {{ state_attr('sensor.zen_15_lefty_electric_consumption_a', 'friendly_name' ) }} will include the device name and display Zen 15 Left Electric Consumption [A].
Currently you can supply your own name like this:
➜ .storage jq '.data.entities[]|select(.entity_id == "sensor.zen_15_lefty_electric_consumption_a")|{entity_id,original_name,name}' core.entity_registry
{
"entity_id": "sensor.zen_15_lefty_electric_consumption_a",
"original_name": "Electric Consumption [A]",
"name": "Pump Current in Amp"
}
And then the friendly_name above shows: Pump Current in Amp – exactly as the user intended.
The change is so that would now show: Zen 15 Left Pump Current in Amp – always prefixing the device name?
This inconsistency has been one of the most common sources of confusion in Home Assistant,
Is it really a big source of confusion that renaming an entity means it is named what you renamed it to? I’m just unclear what the problem this is attempting to solve.
I don’t know the history, but I assume the ability to rename an entity implied being able to rename it w/o the device’s name.
1 Like
I have read the beta notes twice and I do not understand let alone oversee the impact of this change. And I am a long time user of ha, back to the old versioning number times.
I think the release notes should show some very clear examples to illustrate the change. Can a utility be provided that lists the changes to the actual installation before actually committing the changes? Are external services like node red, appdaemon or esphome affected?
Yes, for friendly_name
There’s plenty of feedback here, but that’s (obviously) a huge and seemingly a nonsensical change. Besides breaking all the places we use the friendly names, an entity and device may have little in common in an abstract sense.
Or in a practical sense.
1 Like
From my point of view: changing friendly name from, say, “temperature” to “outside temperature” ( if name of device is outside) is generally not needed, or in my case even disturbing. Example: If i have, say, one card for all outside data then name of card is “outside”, then i have:
- temperature
- Humidity
- Pressure
- Etc—
I can see from card’s name that these values are for “outside”, no need for repetition. All my esphome friendly names are without device’s name.
Now, if i understand corectly (but i hope i don’t) then new data will be:
- outside temperature
- outside humidity
- outside pressure
- …
Which is not only not needed but ugly looking… so, again, i hope i’m just understand this wrong…
2 Likes
Some integration are problematic because they don’t support sub-devices (Overkiz, zha groups)
For esphome, it supports sub-devices so your entities can be split into multiple devices : ESPHome Core Configuration - ESPHome - Smart Home Made Simple
You can have a device called “Laundry light” and another called “Front porch” with an entity named “Motion”.
1 Like
I never used that feature as I think of devices as physical things. But, since areas are tied to devices it kind of forces the need for being able to create essentially virtual devices – if one uses areas extensively. (I don’t but everyone does things differently. And perhaps is an argument that areas should be on entities instead of devices?)
Maybe others don’t see the value of the abstraction between devices and entities as I do.
Forcing (vs. defaulting to) a naming convention does seem a bit antithetical to the core of HA’s flexibility.
I will not participate in beta, nor will I install the release for at least a couple of months to see how this pans out.
The Home Approval Factor for HA will be down the drain. I will also refrain from any discussion on this change. I don’t have time nor the will to fight this change, or deal with the fallout here.
If I cannot edit the device name out because it is obvious or included elsewhere in the name, then this is a royal pain. Do you realize many languages would put the device name last, or that the device name is waaaay to verbose to be of use? Devices that switch two separate lights, what do you call those? An air quality sensor with 20 types of sensors does not need to explain that the CO2 level is measured by an air quality sensor, but the device name does need to explain what kind of device it is.
The release notes also fail to provide the benefit for the user. Consistency how? If I want inconsistent names, that is up to me to decide. You state I should not need to worry about naming conventions, yet you force one on every entity of every user. So it is is to make the users happy or the devs? You claim to do user research, What percentage of users serveyed are in favour?
15 Likes
I’m sorry to harp on this, but this release is coming soon and I’m having a hard time grasping how this won’t really impact a huge number of people w/o any way to fix. Am I missing something?
I just took a look at my yaml:
➜ config fgrep -r friendly_name packages automations.yaml scripts.yaml | wc -l
49
So every place I use that will now prefix the device name?
I build up lists of names for display in various places like formatted tables in Markdown cards, add/exclude lists, in message I send to phones and in text I announce on media players, etc. That is, not just on pre-made dashboard cards. All that gets impacted?
I’m baffled because I can’t imagine that kind of use wasn’t anticipated.
I don’t know how many people look at these beta threads. Should this change be made more known before the release?
I’m not sure popcorn is going to be enough to handle the response to this.
1 Like
Looking at the image in the release notes it seem it’s not just the friendly name that is changed but also the entity id.
If it was just friendly name, would it be a breaking change?
Yet again a release with “yeah we know this is bad but we’ll do it anyway… And don’t blame is now, we created this evil plan back in 2022”
No no no no!
Stop with this now.
We as users must have options to keep it as it is.
I get that this might make it slightly easier for new people but this change will destroy more senior installs for hours or days for no good reason more than “quality scale”.
2 Likes