add friendly_name_template to template binary_sensor

[Mariusthvdb]

Context

The issue motivating this decision, and any context that influences or constrains the decision. Your motivation cannot include that the frontend is not representing the data correctly, as that is a frontend issue.

Proposal

The change that you're proposing.

not really sure I you want a discussion here, but reading this Id ask here to be sure.

Add a friendly_name_template to the template binary_sensor integrations

Consequences

What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.

Please let me illustrate this with an example, which I have also posted in the Feature request thread on the community and seems to get a lot of support. Another thread on the subject: https://community.home-assistant.io/t/friendly-name-template-not-for-binary-sensors/53755

    binary_sensor.low_lux_input:
      friendly_name_template: >
        Low lux input - {{ states('input_number.low_lux') }}

would be really nice and simple, and has the same format as we can use on the regular template sensor:

frontdoor_motion_sensor_light_level:
  friendly_name_template: >
    Frontdoor: 
    {% set light_level = states.sensor.frontdoor_motion_sensor.attributes.light_level %}
    {%- if light_level <=1 %}
      bright moonlight
    {%- elif light_level <=3000 %}
      night light
    {%- elif light_level <= 10000 %}
      dimmed light
    {%- elif light_level <= 17000 %}
      ‘cosy’ living room
    {%- elif light_level <= 22000 %}
      ‘normal’ non-task light
    {%- elif light_level <= 25500 %}
      working / reading
    {%- elif light_level <= 28500 %}
      inside daylight
    {%- elif light_level <= 33000 %}
      maximum to avoid glare
    {%- elif lux <= 40000 %}
      clear daylight
    {%- elif light_level <= 51000 %}
      direct sunlight
    {% else %}
      too bright!
    {% endif %}

It would allow for very useful and state dependent name-changing of the sensor, and add great flexibility.

thanks for considering.

[UMH-Home]

I think this would be a useful addition to many integrations, most of the basic codi g appears to have been done but in hopes of harmonisation it should be integrated across the board. But if it needs to start on one platform and spread that would at least be movement.

[Mariusthvdb]

thing is, we (I) could start a PR, but it would be a waste of time and personal resources if flagged negatively here..

talking about a PR, I would do that on the template binary_sensor platform, and not as @UMH-Home suggests wisely, 'across the board' (there are quite a few Template integrations that would benefit by this). That would be definitely beyond my skill set...

So Ill await the response of the core dev team on the subject ok?

[UMH-Home]

I would agree that the template binary sensor platform is where the most benefit would be seen.

[balloob]

We shouldn't make names dynamic. Names are relatively static for most entities out there and I don't see why template entities should be an exception.

[Mariusthvdb]

Is this a veto already or can I add to my first post?

Please let me do so: in this particular case I Have a binary sensor being on or off depending on the state of the input_number. I find myself always having to check the input_number itself, because I can’t template the state of that input_number into the name. And it holds vital information in relation to the binary.

As we can do with the template sensors. And which is a great tool for a more descriptive interface.

Have the name of the entity and it’s state both describe important information regarding the same functionality, (without having to look at a more-info window, which requires yet an extra user action.) would a major plus.

I’ll illustrate the larger template I with a screen shot to make even clearer why this is such a desirable functionality:

Regular sensors without templates in name:

And the ones with a template making it much more significant. I would very much think this would benefit the binary_sensor, for the exact same reason:

Hope you can have another look at it.
Thanks

[balloob]

State field is for the state, name field is for the name.

You're proposing to allow using the name field as yet another state field.

We should not do that.

[balloob]

The first paragraph of the issue template contains this text:

Your motivation cannot include that the frontend is not representing the data correctly, as that is a frontend issue.

The motivation of this issue is to have the frontend represent data differently.

[Mariusthvdb]

No, I am proposing the same option for template binary_sensor as available for template sensor.

Don’t see the difference. So much for a discussion...

[Mariusthvdb]

The first paragraph of the issue template contains this text:

Your motivation cannot include that the frontend is not representing the data correctly, as that is a frontend issue.

The motivation of this issue is to have the frontend represent data differently.

yes, the latter is almost correct. The motivation of this issue is to have add the option to make the frontend represent data differently.

And no, I am not stating 'the frontend is not representing the data correctly'.

I was suggesting we could add to the current 'correct' representation a template field, so we can have it represent an even more meaningful name.

Which would make it a valid motivation on both sides.

Call it a Nickname if needed. Which can depend on other circumstances. In real life Nicknames are very common. We don't blink an eye. I am merely suggesting we can add that to the current integration.

It already is available in HA, nothing new.

[UMH-Home]

The current binary sensor has classification but this does not cover all languages nor cater for the fact that some window/door sensors report on when open, others when closed.
I know there are ways round this but they are all a bit clunky.
I once had to help a Portuguese guy report his window status using a template sensor instead of just a binary sensor. Allowing this would simplify such instances and also allow 'descriptive'/fun statuses to be displayed.

Edit: another thought occurs. Multi language ability regardless of the language chosen in the frontend.

[Aldaran]

"Your motivation ..." - well thought out, they say, somehow, they dared to offer unnecessary work ...

PS And why did you then make this possibility for sensor (as in example) 'https://www.home-assistant.io/integrations/template/'. And also made it possible to change and add an attribute but it does not concern, of course, friendly_name ..

[gsemet]

I would also like to see friendly_name_template for binary_sensor, like it is for sensors (or you remove from sensor)

[Aldaran]

I would also like to see friendly_name_template for binary_sensor, like it is for sensors (or you remove from sensor)

I found a workaround for this situation using python_scripts / set_state.py:
https://community.home-assistant.io/t/how-to-manually-set-state-value-of-sensor/43975/37

But unfortunately, it does not work everywhere, as for example, in the integration of the Mobile App 'device_tracker', instead of changing the data, it creates a copy of the device with the data that we added (had to change), because in fact device_tracker was created in home assistant memory and not globally in known_devices.yaml. Or if the sensors have updates, simply overwriting what we have changed.

[gsemet]

I ended up with a sensor and icon_template. only thing I do not have yet is the color change when open

[Mariusthvdb]

new template: integration offers friendly_name_template:, or you can use a template on the field for friendly_name:

nop package support though, so still not perfect, but hey, at least you can choose now.

[Aldaran]

I ended up with a sensor and icon_template. only thing I do not have yet is the color change when open

As far as I understand, the color change is custom components or card styles (most likely all taken together).

[gsemet]

new template: integration offers friendly_name_template:, or you can use a template on the field for friendly_name:

nop package support though, so still not perfect, but hey, at least you can choose now.

thanks but this does not support the "is_state" function ("limited templates"???)

[Mariusthvdb]

yes it does:

sensor:
  - unique_id: track_marijn
    state: >
      {{'In huis' if is_state('device_tracker.life360_marijn','home') else 'Uit huis'}}
    picture: >
      /local/images/family/marijn_bmj_{{'home' if
         is_state('device_tracker.life360_marijn','home') else 'not_home'}}.png
    attributes:
      friendly_name: >
       {{'Marijn is ' if is_state('device_tracker.life360_marijn','home') else 'Marijn vertrok '}}

[gsemet]

ok but i need a binary_sensor.

and why don't you have a "plaform" line ?

[Mariusthvdb]

this is the contents of an !include file. so the platform line is in the configuration.yaml

template: !include template.yaml

did you try the binary_sensor? it would be very surprising if it would be different from the regular sensor config.

In any case please add here https://community.home-assistant.io/t/add-bring-back-friendly-name-to-template-sensors/305717, because this is closed, and the FR is open