I thought it might be useful to provide a real world example of some hurdles that not being able to manually set the the entity_id AND the friendly_name for each template using the modern template approach. Good news, is that there are a few workarounds, listed above, that have ultimately allowed me to make this work and keep manageable for now, just not as clean as I was able to keep it before.
I have ~100 electrical power sensors I’m tracking in my config. Having this many sensors reporting regularly can cause lots of performance issues, and where I am doing calculations on those sensors, the impact is multiplied by several x. Doing calculations on 3 power sensors together that report state every 5 seconds, you may end up with many more calculated state changes instead of 1. This is ultimately why I wanted to move to the new trigger based sensors where I can just do that calculation every 30 seconds or so. (I do understand there are many different ways I could handle this, but when I started, this seemed like the easiest approach for my needs)
Because each integration uses a slightly different naming standard for reporting power, I chose to make an individual templated sensor for each item I wanted to track. In other words, if my Shelly plug reports power under a sensor name of “sensor.power_office_plug”, then I manually create a template sensor with an entity_id in a naming convention which tells me the breaker box and electrical circuit that device is plugged into. Organization is important, because I’m also doing calculations that look at my total power used on a circuit, then subtract out my known power, like the office plug, to determine what my unknown power usage is on that circuit.
Many of the integrations, like logbook, recorder, and InfluxDB only allow you to easily include / exclude based on entity_id name, so that becomes critical to have named in a standard way otherwise each sensor has to be added manually. When you get to the point of having 100+ devices, the idea of individually editing those names in the GUI also isn’t great. For that reason, I’m using “Name:” to define my new trigger based sensors, which gives me the exact entity_id that need and allows me to use all of my pre-existing logic and dashboards I’ve built in lovelace and Grafana. This is all working fine on the backend which is great, but the unfortunate side effect, is that the “friendly_name” is then forced in the sensor as an attribute matching the entity_id. Similarly to how the integrations mentioned above rely on entity_id, most of the lovelace cards and dashboards have been designed to rely on friendly_name, which causes some challenges. I’m pretty sure it is the dichotomy of accounting for both frontend and backend needs that some people are finding challenging. (Probably in the niche or more complex configurations like mine has become)
Fortunately, the easiest workaround for now, is to add a customization section which maps out all of the friendly names for each of those sensors. Due to the way I designed this, I needed to add 100 entries in the customize section to set the friendly_name for each of those sensors. Doesn’t seem like the cleanest approach, but it is working fine. Ideally, in the future, if I can control both my exact entity_id name and my friendly_name as an attribute where I define my trigger based sensor, it would be a bit nicer, IMO. Thanks all!
thanks!