Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to remove the prefixing of "friendly_name" since this affects the voice assistant #2476

Open
rarroyo6 opened this issue Nov 10, 2023 · 12 comments

Comments

@rarroyo6
Copy link

Describe the problem you have/What new integration you would like

The prefixing of "friendly_name" to entities should be optional, or have a way to disable it.
Please describe your use case for this integration and alternatives you've tried:

When the "friendly_name" gets prefixed to the name of an entity, especially when a ESP node handles multiple different type of entities, it can sometimes make the name incoherent. This can sometimes be acceptable to look at, but when the name is used by voice assistant, it can make the sentence completely awkward or too wordy.
I know that the name can be changed in the UI, or an alias can be created, but it should be possible to do this from the beginning.
Additional context

Here is an example of the problem:
I have a ESP node with a friendly name of "Pool chemical controller", then in that node I have entities "Chlorine pump", "Acid pump", plus a few others and a variety of sensors.
If I want to turn on the chlorine pump, right now I have to say "Turn on the pool chemical controller chlorine pump", I should be able to just say "Turn on the chlorine pump".

@ChristophCaina
Copy link

as a workaround, you could use the Alias feature in HomeAssistant for changing the entity name...
grafik

@rarroyo6
Copy link
Author

rarroyo6 commented Nov 26, 2023

as a workaround, you could use the Alias feature in HomeAssistant for changing the entity name... grafik

As I mentioned in the original post, I know that I can add an alias, but that doesn't solve the problem.
For example; in my back yard I have a Sonoff 4 channel relay board. The friendly name of the node is "Backyard Sonoff 4ch relay board", which shows up like it should on the ESPHome dashboard. That relay board has four entities: Fence lights, Tree lights, Fairy lights, and Pond light.
Even if I add an alias to the entities, on the main dashboard the entities look like "Backyard 4ch relay board Fence lights", which doesn't make much sense.
Lets take a simpler case, when I added a friendly name to my kitchen light node, the entity name became "Kitchen light Kitchen light", if I took off the name on the switch and just left the ID, then it wouldn't show up on the dashboard, so I had to do the following as a workaround:

switch:
  name: ''
  id: kitchen_light

I don't see any purpose to prefix the entities, maybe there is one, but it should be optional, not forced.

@clinta
Copy link

clinta commented Dec 7, 2023

The purpose is incredibly useful to me. I have several of the same device type, like an s31 relay for example, and I use templates to mange the configuration. So in my template I can have something simple like name: Button, then if the friendly name is "Living Room Lamp", in home assistant I get "switch.living_room_lamp_button".

I depend on this, and if it is optional it should be opt-out, except in one case. In the case of an empty name like name: None or name: "", the documented behavior is that this should use the friendly_name, but because of the prefixing it is repeated. This should be fixed by default. I should not end up with an entity of switch.living_room_lamp_living_room_lamp, when I use name: None for the relay. It should just be switch.living_room_lamp.

@rarroyo6
Copy link
Author

rarroyo6 commented Dec 7, 2023

The purpose is incredibly useful to me. I have several of the same device type, like an s31 relay for example, and I use templates to mange the configuration. So in my template I can have something simple like name: Button, then if the friendly name is "Living Room Lamp", in home assistant I get "switch.living_room_lamp_button".

I depend on this, and if it is optional it should be opt-out, except in one case. In the case of an empty name like name: None or name: "", the documented behavior is that this should use the friendly_name, but because of the prefixing it is repeated. This should be fixed by default. I should not end up with an entity of switch.living_room_lamp_living_room_lamp, when I use name: None for the relay. It should just be switch.living_room_lamp.

I have no problem with the opt-out function, but it should not be forced, because it does not fit all the use cases.
By the way, what I do on my templates is:
name: ${node_display_name} button
that way I have full control of how the node is named.
In the case of my 4 relay board, each relay is independent of the other ones, so the names don't have any relation to each other.

@Linwood-F
Copy link

First, let me say I hate the whole concept of the automatically prefixed friendly name, and it was absolutely the most disruptive rollout of anything I have encountered in HA in many years of using it. I think many of us use various tricks to work around it (e.g. using name with a single space as opposed to empty strings).

That said, I think some care has to be taken in changing it yet again. The other thing that has happened is 3rd parties have rolled out very useful (and widely used) git based implementations, which make it more complicated to change THEIR code (e.g. forking and merging updates -- and HA thinks YAML is hard to edit!).

For example, I personally would like to see any such control over whether or not to prefix be locally controlled, and by that I mean in different parts of the same esphome program. If I have includes from GIT, and local includes of my own standard code in the same file, being able to have some kind of pragma declaration might work, where one is #PREFIX OFF and #PREFIX ON (clearly not that syntax, just as an example) that has a respected scope.

But please... stop breaking existing code for this. It was a royal mess most have gotten past, I am sure it was well intentioned but it was a mess. Don't make another with trying to add more lipstick to this pig.

@rarroyo6
Copy link
Author

This change has affected Voice Assistant, Automations, Scripts, and Dashboards.
I'm still finding some rarely used automations that when I realize they didn't work and check why, it turns out that they have the old name before it was prefixed.
I've also come across some old EspHome nodes that had not been updated, and were working fine. After updating them, the names changed and created more problems.

@alexruffell
Copy link

alexruffell commented Feb 29, 2024

I have this issue too. My most common use case is when I create devices in ESPHome that can be turned on or off, or opened and closed.

I am modifying the default YAML of the ratgdo and since my ratgo is called "Overhead Garage Door", I do not want anything added to the entity name... in other words it must match the device name. I have tried a few things:

name: None (does not work, I just get "none" as a name)
name: "" (does not work)
name: " " (works as desired but it seems more like exploiting a bug)

My end goal is for the cover entity that controls the "Overhead Garage Door" to be called cover.overhead_garage_door which is also the name of the device (ratgdo). Simply put, some way for an entity to get the device name and nothing else would be great. Before the automated prepending was done, I had full control and it worked perfectly... sadly the "facilitation" works in most cases but caused major annoyance in these particular cases (frequent in my case).

Summary: What @clinta said sounds perfect - #2476 (comment)

Edit: Other case I just found. I modified my ratgdo to turn on/off a parking laser. Sometimes I need to turn it on/off manually (mostly verbally via Alexa in the car). Giving the entity a name of "Parking Laser" resulted in an entitiy name of switch.overhead_garage_door_parking_laser. As already stated by others, I really want a way to override the prefixing so that the name is simply "Parking Laser" (think voice control without having to use aliases, etc.).

@kooswillem
Copy link

You can overwrite (change) the entity ID in 'Developer Tools -> States page' by finding the entity, clicking on the 'i' icon (more information) and then in the pop-up window click the sprocket icon. Change the entity ID and confirm by clicking 'Update' in the left bottom corner of this pop-up window.

@alexruffell
Copy link

@kooswillem I rename my entities frequently and do so simply by clicking on its name, then clicking the cog wheel which opens a window where you can edit both the name and entity name however I try to create ESPHome devices that don't require it by default. Before the naming was 'automated' I had full control of it and could make it work exactly as desired, now I can't (see issue described above)

@nagyrobi
Copy link
Member

nagyrobi commented Apr 2, 2024

You can overwrite (change) the entity ID in 'Developer Tools -> States page' by finding the entity, clicking on the 'i' icon (more information) and then in the pop-up window click the sprocket icon. Change the entity ID and confirm by clicking 'Update' in the left bottom corner of this pop-up window.

You should avoid doing that on long term and with many entities. If for any reason in the future you need to remove and re-add the ESPHome node to HA, you'll have to do the renames again manually, for all your automations and data history to be functional again.

@Unfocused
Copy link

@alexruffell wrote:

name: None (does not work, I just get "none" as a name)

This should work - I'd suggest filing a separate bug report (not feature request) just for this.

@Unfocused
Copy link

With specifying None as the name, some of the use-cases mentioned here would work well with the sub-device/multi-device config being added in this PR:

For background discussion on that, see:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants