I’ve been battling with this myself recently and have tried a bunch of variations.
What I’ve found, is that if I use the name: None - it does nothing.
This:
Will still give me this:
But this:
Will give me this:
The only way to avoid it is to remove “friendly_name” from the esphome: part of the config, but that impacts other things.
For now, I’m just going to have to manually change the IDs and in Home Assistant for nearly 40 devices. 
I’m really surprised that this change was made. Now I need to manually rename a lot of entities each time or simply not use friendly_name in my configs. We should have the option to opt-out and disable prefixing friendly name to entities in Home Assistant.
Just getting started with HA and moving from tasmota and found this thread as I try to apply some best practices so I don’t end up living with stuff I don’t like. I really just want it to append the ID to the device name, and use friendly names in the UI. I’d like to just have one underscore in the name, not several.
Honestly while I remain appreciative of an open source product run by volunteers, this is one of the most seriously bad implementations I have seen where the idea of making things magic for users actually makes it more difficult for even slightly sophisticated users. It has also gotten extended into zwave naming and other places as well. Lutron (the company) does something similar prefixing room to device names that you might not want there.
The result are sensor names like fan.den_fan_fan or fan.den_den_fan littered throughout my setup.
I’ve just given up and whenever adding a device I spend time in the integration page and rename the sensors that do not make sense.
It’s not that defaults are bad – it is when the design actively prevents defaults from being overridden at the source. So while I can fix it in Home Assistant itself by renaming an entity, if I remove an esphome device and re-add it, I have to go through all its entities again, I can’t build them into the esphome code properly.
So to your question… don’t make yourself nuts in the esphome code, there are some things that simply will not work. You can always renamed them later (settings, integrations, device, entity, settings, and override the friendly and sensor name there). They “stick” there unless you delete and re-add the device.
Did you look at the documentation? It covers these topics and reading it would explain why you’re having issues and how to make corrections.
It also mentions this at the top of just about every sensor, switch documentation page and it’s kind of hard to miss. This is why you need to read through and make use of the documentation provided to you.
Believe me I’ve spent days reading and trying different alternatives. A big part of the issue is that many of us use 3rd party templates on git that tend using a friendly name, with whatever side effects that causes. I also willingly admit I did all my experimenting soon after this came out and maybe some aspects have been fixed.
Here’s a simple example of the most common problem:
substitutions:
device_name: flood7
device_description: Novostellar 25W RGBWW flood light
friendly_name: Flood7
name: flood7
ipaddr: 192.168.130.72
packages:
stuff: !include standard-setup-template.yaml
also: !include novostellar_floodlight_25w_template.yaml
more: !include ha-time-template.yaml
And in that 2nd include is this:
light:
- platform: rgb
name: None
red: red
green: green
blue: blue
id: thelight
The result of that is the entity light.flood7_flood7
Now all those includes are mine, I could probably get rid of the friendly name entirely, but that’s not always an option as you can’t do something simple (or could not last I checked) like “None” for the friendly name itself as a substitution.
The only fix I have found to avoid the doubling for that is a single space (not an empty string):
light:
- platform: rgb
name: ' '
red: red
That gives an appropriate light.flood7 entity name, though it gives a blank display name at least in some places:
Now I confess my experimentation was almost all in the months immediately after this change. And at least then the “Name: None” simply did not work in many circumstances at all.
So as I said to the recent poster – I mostly gave up, and fix them in HA. If there really is a way to make these things work as a general case I have not found it, especially when one may be required to define a friendly name for a project being included in git (a blank or the word “None” as a substitution for it when in an include did not work, at least back then). You are stuck with it and can’t override it other than in HA as best I can tell.
Now maybe I’m just dense, but please do not assume I did not read what was written. I did. I tried and tried and tried, then gave up (ages ago).
You’re using “friendly_name” which is automatically added entity names. You’re also specifying an id and name for each entity. according to my math, that is 3 different naming configurations you’re using when you only need to use 1.
For me, I was using Esphome long before “friendly_name” was added so for me, I just don’t use it and I give my entities either an id or name and id and that’s it. Simple.
The ID is necessary for internal use.
If I omit the name in the above example it is not brought into HA at all.
So I’m not clear how I can make this work while also using a friendly name. Please understand – this was a simple example, and in this example I could probably omit friendly name. But a lot of third party software (I recall at least two) had friendly name substituted throughout their code, so you have to specify something (omitting it doesn’t cause the reference to the substitution to be ignored, it just becomes a syntax error).
So in something like my (prior house) hot water heater, which had a ton of entities, the friendly name caused everything to be prefixed (e.g. hphw_stuff, hphw_stuff2) but when it was time for the main item (I think it was a climate though I forget), it always came up something like hphw_hphw when what you wanted was just hphw.
Please… given that I must have friendly name defined as SOMETHING (i.e. the substitution), how can I make my example work without doubling up the name, so it simply becomes “flood7”.
Or… please… tell me how to do a substitution for code that has friendly name replacements in it, so that they are treated as “friendly name not defined”.
Why shouldn’t that light become “Flood7” (not duplicated) when I set name to “None” for example? That would seem to make sense.
The single space trick does not always work.
I have no agency to complain and that is not what I am doing. Just trying to get this right.
I am moving from another system to HA/esphome and am totally amazed at how much it does for you compared to the tools I was using. I am about to migrate about 50 tasmota devices between three locations so I’m trying to understand best practices and create reusable code so I don’t end up where I am with the other tools I was using and how hard they became to manage.
I mostly just want to expedite the deployment of devices/entities similar to this:
device:
name: cloudfree2outletbarn (the type of device really helps me)
name_in_ui: Bar Outlets (that I can easily add to dashboards)
entities:
cloudfree2outletbarn_outlet1 (or _neonsign)
cloudfree2outletbarn_outlet2 (or _spotlights)
cloudfree2outletbarn_wifistrength
cloudfree2outletbarn_uptime
cloudfree2outletbarn_reset
...
entity names:
Bar Neon Sign
Bar Spot Lights
Bar Outlets - Wifi
Bar Outlets - Uptime
Bar Outlets - Reset
...
and not end up with entities that read like this:
cloudfree2outletbarn_bar_outlets_bar_outlets_reset
I’m sure I could live with it as is, and it may not impact much in the grand scheme of things, but I’m trying to do this right so I don’t spend hours unraveling things I’ve planned poorly in the future.
I’ve done a number of tests using blank names, removing friendly names, etc. but I haven’t yet gotten the results I believe I want.
Note
If you have a friendly_name set for your device and you want the sensor to use that name, you can set name: None.
Now this isn’t always 100% the case. For example if you needed to point to an entity then you’d need to specify an id but, for most things you only need either a single id or name. Not both and absolutely not both and friendly_name.
For example here.
Either I am being dense or I’m not communicating properly.
In my example the friendly name is “Flood7” which is also the device name. If I set the Name field to “None” I end up with Flood7_Flood7.
The ID is used internally to control lighting effects, and it’s purposely different (“TheLight”) so I could see if it had some effect on naming; it did not appear to.
What is it you expect to happen with Name of the Light set to “None”. Are you not expecting the doubled name? Because nothing I do can get rid of that, except to use Name and make it a space (not missing, not None, but a space, which I suspect is an oversight in the syntax not the intended purpose).
Let me fix this so it’s a little more clear what is happening (especially for the recent poster):
substitutions:
device_name: devname
device_description: Novostellar 25W RGBWW flood light
friendly_name: frndlyname
name: thename
ipaddr: 192.168.130.72
packages:
stuff: !include standard-setup-template.yaml
also: !include novostellar_floodlight_25w_template.yaml
more: !include ha-time-template.yaml
In the “also”:
esphome:
name: ${name}
friendly_name: ${friendly_name}
comment: ${device_description}
light:
- platform: rgb
name: None
red: red
green: green
blue: blue
id: thelight
With this setup, the light comes through as entity light.thename_frndlyname.
Other entities with explicit names like this:
switch:
- platform: restart
id: restartid
name: reboot
restore_mode: restore_default_off
come through as “switch.thename_reboot” with the device name field prefixing the entities (not the friendly name as you might think – and the switch name field becomes the suffix).
To make it a bit more confusing, the “device” shown if you go to settings, integrations, select esphome (the icon, not the word “devices”), is different from the name of the device. If you rename it (as I just did), it shows the renamed item there, but if you select devices it is the unrenamed item. I have no idea what circumstance these two separate names for the device are used, sort of an “integration device name” and a “device name” (but this doesn’t much impact the entity naming issue).
Just to be clear – with it all my own code I can fix this by just leaving off friendly name and using the name field in the switch the way I want it:
substitutions:
device_name: devname
device_description: Novostellar 25W RGBWW flood light
friendly_name: frndlyname
name: thename
ipaddr: 192.168.130.72
packages:
stuff: !include standard-setup-template.yaml
also: !include novostellar_floodlight_25w_template.yaml
more: !include ha-time-template.yaml
In the “also”:
esphome:
name: ${name}
# friendly_name: ${friendly_name} <<<< removed
comment: ${device_description}
light:
- platform: rgb
name: ${thename}
red: red
green: green
blue: blue
id: thelight
Now the light comes through as light.thename as you would expect, though now I have to go through all the other entities and prefix those with ${name} as well to restore the original behavior.
But with all my own code I can do this. It’s when there is code that expects friendly name that you run into the trouble. I’ve seen authors lamenting this doubled name on a central item as well. And forking their code rather than just including it would allow me to fix them, but it’s both tedious and also then prevents me from benefiting (at least easily) from their improved versions.
My point is that it’s nice to say there is a workaround, but once you decide to declare a friendly_name, there are some things you just can’t do properly (my trick of a single space notwithstanding, as that doesn’t always work either especially inside includes or extends).
Now… to your original point – maybe I just plain missed the documentation that would make this make sense and give me the workaround. If so, please point it out. Better still in the context of my example with friendly name declared, how can I fix the entity name of the light to be ONLY the friendly name?
Like I said earlier, I don’t use friendly name. It’s a relatively new feature that wasn’t needed before and isn’t needed by me.
You don’t need to configure options that aren’t needed that’s why it tells you which are Optional or Required.
friendly_name (Optional, string):
pin (Required, Pin): The pin to count pulses on.
Then why are you taking such issue with me for not doing my homework on friendly_name?
It’s not “needed” but git-based contributed code often uses it making it more difficult to avoid.
Im not taking issue, im just pointing out the value of using the documentation and stressing how important it is.
So, if you find a Git repo that uses friendly_name whats the problem? Surely your keyboard has a “del” key just like everyone elses so, im failing to see how using your “del” key is some insurmountable problem.
Except of course you haven’t read it well enough to give me a solution that works in the context of Friendly Name, but only well enough to berate me for not reading it.
I’m not sure why I continue this argument (since you are clearly here to argue not help), but in case the rationale I see is wrong perhaps someone else can point it out. Or it may help others understand.
In the sort of include examples I’ve given, git would be included by reference, not by a separate fork. Examples I had were the Rheem Heat Pump Hot Water Heater, Sonoff wall panel, and the Ratgdo garage door opener. These were under active development and improvement, and by incorporating by reference all I had to do was compile/install to obtain the latest features.
By comparison if I had to copy the repository (either by just downloading or a fork), so as to make use of the delete key you believe I am unaware of, I would have to manually merge in the author’s changes into mine (an error prone process in addition to time consuming) every time I wanted to incorporate the latest features.
I.e. it defeats one of the more useful aspects of sharing esphome projects.
In the end I’m using friendly name and then setting the main entity to “name: none” and that seems to be working.
For other buttons or switches (entities) I’m specifying a name and it’s being prefixed by the friendly name, but only once.