OK, thanks, that’s what I thought.
It would have been more convenient to be able to control all of these in the yaml configuration. Maybe in the future…
Alright, I misunderstood it. Thanks!
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!
3 Likes
I stumbled over the same questions when I tried to migrate my old template sensors to the new syntax but I gave up for now.
I don‘t get it why I am not able to just set the name and ID simple in YAML.
Is there some kind of design guide that changed and the template integration is trying to follow?
Why is unique_id not used for the ID in the GUI and name as name? Why such a strange and unclear behavior?
Before I had to set the ID and then I was able to provide a friendly_name at least for this integration. Others had name. THis is really unintuitive…
1 Like
I guess we should close this FR, since we now can set any name in template: including templates. And since 2021.8.2 we can now use the top level integration template: in packages, there is no reason anymore to keep using the legacy format.
@petro, will you please close this too, and mark it solved?
Sure, if you like. Are you sure this changed from the original conversation? I haven’t verified.
well, it still isn’t possible in the legacy format, but since we now have no reason anymore to keep using that, and use template in packages, for me personally the FR is no longer necessary.
Also, I thinks the odds are low the dev team will ever implement it, because of the same reason…
Then, we should keep this open because it’s not really solved. It doesn’t hurt anyone to keep it open. You’re welcome to change your watch pattern on it so it no longer notifies you.
ok, cool. thanks.
its just that
my FR there, was also based on not yet grasping the full impact of the template: integration. It is in fact possible, but friendly_name: has been replaced by name:. Allowing full template possibilities.
as a matter of fact, it is was I am doing in 65 package (to go)… replace:
sensor:
platform: template
sensors:
legacy_format:
friendly_name: Legacy formatted sensor
value_template: >
{{ states('sensor.example')}}
to
template:
- sensor:
- unique_id: legacy_format
name: Legacy formatted sensor
state: >
{{ states('sensor.example')}}
and we can change that now to:
template:
- sensor:
- unique_id: legacy_format
# functionality below was the actual FR, use template in (friendly_)name
name: >
{{ states('sensor.time'}}: Legacy formatted sensor
state: >
{{ states('sensor.example')}}
with that, the original FR has been fulfilled?
I mean, that’s what I said before and I thought that added template_ to the entity_id which is what upset everyone
1 Like
yes, thats a bit funny.
But, that (adding prefix template_ to the entity_id) only happens when. you don’t set a name in the config.
If you do, and use identical unique_id and name, creation is perfect. (entity_id == unique_id)
If you set another name than unique_id, entity_id is set to name, and you have to manually edit the entity_id in UI (to have it be exactly like unique_id).
this is still somewhat clumsy, but in the end , it is a onetime effort. And most of all, the template can be used for name: …
o well. I am fine either way, but for me this is no longer necessary.
Well I am still irritated about how this should work.
I changed my whole template config now to the new format, I set a unique_id and a name resulting in an entity_id made from the name, then I changed the entity_id with the GUI.
Reading the docs also is strange to me, all required there is “state” but then I get an “unnamed sensor”, how am I supposed to find it then? And I can’t do anything with it because it has no unique_id.
Shouldn’t be name or unique_id be required?
And why am I forced to change the entity_id with the GUI and am not able to set this all in the YAML config?
Why isn’t just the unique_id used for entity_id too if given?
IMHO name should be also required, with a name a unique_id could be created maybe like the docs says with “template_” prefix and the entity_id is then made form the name too.
With the updates in 2021.8.2, it’s great that I can now consolidate my modern templates into the same packages file with all of the other related components for good organization. That said, the ability to define a specific entity_id, and at the same time within the template specify a different unique friendly name, is still not possible. So I do agree this FR is still a open, but guessing it won’t likely get a lot of attention since the simple workaround is just to add any friendly names you want to specify within your customize section as a one off effort.
You can set a name different from your unique_id.
Not sure what your issue really is?
Thank you for pointing that out. I just made a correction to my post where I said unique_id when I meant to say entity_id. In my case, I’m using a naming pattern in my entity_id’s in order to filter and process my sensors. So can name the templates to get the desired entity_id, but then I’m not able to specify a friendly_name that will look nice in the reporting and dashboards without doing a customization or manually editing the entities.
Use custom attributes for that purpose. It makes it much easier to filter entities and eliminates long-winded entity names packed with metadata.
well, you can. once the entities have a unique_id, you can set any entity_id you like in the ui of the entity. I set my entities to have the same object_id and unique_id, and some of those have another (more friendly) name. Or even use a template for name. Anything is possible really.
just an example:
- unique_id: dark_sky_forecast_1
name: >
{{as_timestamp(now() + timedelta(days=1))|timestamp_custom('%a %-d %b')}}: {{
states('sensor.dark_sky_forecast_icon_1d').replace('-',' ')|capitalize}}
state: >
{{- states('sensor.dark_sky_forecast_daytime_high_temperature_1d')|round(0)}}°/
{{- states('sensor.dark_sky_forecast_overnight_low_temperature_1d')|round(0)}}°/
{{- states('sensor.dark_sky_forecast_precip_probability_1d')|round(0)}}%
picture: >
{{'/local/weather/icons/' ~ states('sensor.dark_sky_forecast_icon_1d') ~ '.png'}}
In concept, this is what I would like to do, but I experimented quite a bit with this approach and unfortunately I got stuck because there are still too many of the integrations and cards that only don’t allow efficient use of custom attributes. As an example, just look at the Recorder which is one of the fundamental components of Home Assistant and it only allows filtering by using the entity_id name.
If I’m understanding correctly, the first time this entity is created, you manually go in via the ui and edit the entity_id. Once you do that, the entity_id will remain unchanged, but the “Friendly Name” can continue to be changed as needed? Thanks
